Modelos de datos

Marta E. Zorrilla Pantalen

Universidad de Cantabria

Curso 2010-2011

Marta Zorrilla - UC

Curso 2010-2011

Marta Zorrilla - UC

Modelo de datos. Definicin

Conjunto de herramientas conceptuales para describir

la representacin de la informacin en trminos de
datos. Los modelos de datos comprenden aspectos
relacionados con: estructuras y tipos de datos,
operaciones y restricciones. Dittrich (1994).

Conjunto de conceptos, reglas y convenciones que

permiten describir y manipular los datos de la parcela
de un cierto mundo real que deseamos almacenar en la
base de datos. De Miguel et al. (1999).

Coleccin de herramientas conceptuales que se

emplean para especificar datos, las relaciones entre
ellos, su semntica asociada y las restricciones de
integridad.

Curso 2010-2011

Marta Zorrilla - UC

Fases del diseo

Fase inicial: anlisis de requisitos. Descripcin de la

informacin a gestionar y sus procesos. Entrevistas con
usuarios y expertos.

Diseo conceptual: traduccin del anlisis de requisitos

al esquema conceptual. Representacin generalmente
grfica de las entidades y sus relaciones.

Anlisis de requisitos. Especificacin funcional

Modelo ER, modelo UML, ORM

DFD, diagrama de casos, diagramas de colaboracin, de
secuencia, etc.

Implantacin en el gestor:



Diseo lgico: traduccin del modelo conceptual al LDD

del gestor correspondiente. Modelo relacional, OO, OR
Diseo fsico: determina la organizacin de archivos y las
estructuras de almacenamiento interno.

Curso 2010-2011

Marta Zorrilla - UC

Modelo, Esquema y Ejemplar

Mundo
real

Modelo de
datos

Esquema
de datos

Ejemplar del esquema:

instancia del esquema,
esto es, datos que en un
momento determinado
estn en el esquema

ER, ORM
UML

Herramientas
CASE

Relacional
Objeto relacional
Orientado a objetos
Jerrquico / red

Curso 2010-2011

Marta Zorrilla - UC

Modelos conceptuales

Caractersticas:






Independientes del SGBD

Mayor nivel de abstraccin
Mayor capacidad semntica
Ms enfocados al diseo de alto nivel
Interfaz usuario/informtico

Curso 2010-2011

Marta Zorrilla - UC

Ejemplo ER
Title
year
filmType
length
MOVIE

1..N

STAR

stars
1..N

0..N

addr

owns

1..1
STUDIO

Name
address

Name
phones
street
city

Curso 2010-2011

Marta Zorrilla - UC

Ejemplo UML

Movie
title
year
length
filmType
{color, blackAndWhite}
float lengthInHours()
void starNames (out
Set<String>);
void otherMovies ( in
Star, out Set<Movie>)

Studio

0..N

1..1 name
address
Star

1..N

1..N

name
Addr {street, city}
Phones(set)
void enrolled_in (in
Star s, Movie m)
void drop_enrolled_in
(in Star s, Movie m)

Curso 2010-2011

Marta Zorrilla - UC

Ejemplo ORM

Curso 2010-2011

Marta Zorrilla - UC

Herramientas CASE (Computer

Aided/Assisted Software/System Engineering)

Conjunto de programas que asisten a los

analistas, ingenieros de software y
desarrolladores, durante todos los pasos del
Ciclo de Vida de desarrollo de un Software.







Ayudan al diseo

verificacin de errores
Reducen el tiempo de desarrollo

generacin de cdigo y reutilizacin de objetos,
generadores de casos de pruebas
Mejoran la calidad
Facilitan el mantenimiento de los programas
Generan y estandarizan la documentacin
Aumentan la portabilidad de las aplicaciones

Curso 2010-2011

Marta Zorrilla - UC

Clasificacin de herramientas CASE

Se pueden clasificar atendiendo a:



Las fases del ciclo de vida del desarrollo

de sistemas que cubren

Su funcionalidad

10

Curso 2010-2011

Marta Zorrilla - UC

Segn ciclo de software

Herramientas integradas, I-CASE (Integrated

CASE): abarcan todas las fases del ciclo de vida del
desarrollo de sistemas. Son llamadas tambin CASE
workbench. Muy caras.
Herramientas de alto nivel, U-CASE (Upper CASE o
front-end), orientadas a la automatizacin y soporte de
las actividades desarrolladas durante las primeras fases
del desarrollo: anlisis y diseo.
Herramientas de bajo nivel, L-CASE (Lower CASE o back-end), dirigidas a las ltimas fases del desarrollo:
diseo detallado y generacin de cdigo.
Juegos de herramientas o Tools-Case, son el tipo
ms simple de herramientas CASE. Automatizan una
fase dentro del ciclo de vida.

11

Curso 2010-2011

Marta Zorrilla - UC

12

Segn su funcionalidad

Herramientas de anlisis y diseo



Permiten al desarrollador crear un modelo del sistema

que se va a construir y tambin la evaluacin de la
validez y consistencia de este modelo.

Herramientas de programacin (compiladores, editores

y depuradores )
Herramientas de gestin de prototipos
Herramientas de mantenimiento (ingeniera inversa,
reingeniera)
Herramientas de gestin de proyectos (planificacin,
seguimiento, medicin de costes).
Herramientas de soporte (gestin de la configuracin,
control de cambios, documentacin, etc.).
Herramientas de integracin y prueba


Sirven de ayuda a la adquisicin, medicin, simulacin y

prueba de los sistemas lgicos desarrollados.

Curso 2010-2011

Marta Zorrilla - UC

Componentes

Repositorio o diccionario de datos



Mdulo diagramtico


Almacn de los elementos definidos

Editores que recogen las distintas tcnicas

Generador de cdigo. Ingeniera inversa.

Generador de documentacin
Interfaz de usuario

INTERFAZ DE USUARIO
I
C
N

F
D
O
Modelos
I
R
G
M
O
E
Repositorio
S

13

Curso 2010-2011

Marta Zorrilla - UC

Productos ms utilizados

ERWin
PowerDesigner (Sybase)
EasyCASE
Oracle designer (Discoverer)
Visio (Microsoft)

14

Curso 2010-2011

Marta Zorrilla - UC

Eleccin de la herramienta de diseo

de bases de datos

Multiplataforma
Trabajo en grupo
Aspectos de seguridad
Software Open Source / licencia (precio)
Esquema de BD para diferentes gestores.
Comprobacin de restricciones
Sincronizacin con el gestor
Ingeniera inversa
Generacin de documentacin
Interfaz grfica cmoda e intuitiva
Capacidad de representacin respecto a la
notacin terica

15

Curso 2010-2011

Marta Zorrilla - UC

Deficiencias en herramientas CASE

Generalmente no recogen toda la riqueza semntica del

modelo de datos.
Falta de un modelo de restricciones que genere las reglas
de negocio en automtico.
No ayuda a especificar el modelo fsico adecuado, lo
indica el diseador, pero no le da pautas o medidas de
rendimiento.
No ofrecen la posibilidad de disear en entornos
distribuidos, OO, activas, no hay modelo que permita
representarlo.
Los atributos derivados pueden estar en el conceptual
por razones semnticas y en el fsico por razones de
eficiencia, el problema es que la regla por la que se
genera no se puede modelizar.

16

Modelo ER
Marta Zorrilla
Universidad de Cantabria

Curso 2010-2011

Marta Zorrilla - UC

17

Curso 2010-2011

Marta Zorrilla - UC

18

Tabla de contenidos

Evolucin histrica






Entidades
Relaciones
Dominios y valores
Atributos

Relaciones n-arias
Extensiones del modelo


Elementos estticos


Modelo bsico versus

modelo extendido




Notacin E/R vs. UML

Ejemplos

Restricciones




Generalizacin y especializacin
Restricciones entre relaciones
Agregacin

Identificadores
Cardinalidades de atributos
Cardinalidades de relaciones

Curso 2010-2011

Marta Zorrilla - UC

Evolucin histrica

Propuesto por Chen en dos artculos ya histricos, en

1976 y 1977.
Segn Chen, El Modelo E/R puede ser usado como una
base para una vista unificada de los datos, adoptando el
enfoque ms natural del mundo real que consiste en
entidades y relaciones.
Posteriormente otros autores lo han ampliado con
importantes aportaciones, formndose en realidad una
familia de Modelos de Datos.
Se abordar el modelo E/R bsico y el modelo E/R
extendido.
El Modelo E/R ha tenido una gran difusin en la comunidad
informtica dedicada a las BD, prueba de ello es que ha
sido el modelo ms extendido en las herramientas CASE
de ayuda al diseo de BD.
DATE critica al modelo ER diciendo que no es ms que una
fina capa por encima del modelo relacional

19

Curso 2010-2011

Marta Zorrilla - UC

20

Elementos estticos

Entidad (entity)



Objeto que existe y se distingue de los dems.

Pueden ser concretos

O abstractas

P.ej.: prstamo, pedido,

Atributo (attribute)



Propiedades que caracterizan a las entidades.

Clave primaria: atributos que identifican a la entidad

P. ej.: un libro, una persona,..

P.ej.: ISBN (PK), ttulo, idioma, para entidad libro

Dominio (domain)


Conjunto de valores permitidos para un atributo

P. ej: indicando el tipo de datos (por intensin)

P. ej: sexo-> M o F (por extensin)

Curso 2010-2011

Marta Zorrilla - UC

21

Entidades

Existen dos categoras de tipos de entidades:



Regulares o fuertes, que son aquellas cuyos

ejemplares tienen existencia por s mismos

Caso prstamos de la biblioteca: LIBRO y AUTOR
LIBRO

AUTOR

Dbiles, en las cuales la existencia de un ejemplar

depende de que exista un cierto ejemplar de otro
tipo de entidad

Caso del EJEMPLAR que depende de LIBRO
EJEMPLAR

Curso 2010-2011

Marta Zorrilla - UC

22

Elementos estticos (y 2)

Relacin (relationship)


Conexin semntica entre dos o ms entidades

Cardinalidad: n mximo de unidades de un

conjunto que se conecta o relaciona con una
entidad de otro y viceversa
COMPAIA

EMPLEADO

(0:1)

preside

1:1

(1:1)

PRESIDENTE

(0:m)

trabaja

(1:n)

1:m

(1:1)

DPTO

AUTOR

escribe

n:m

(1:m)

LIBRO

Curso 2010-2011

Marta Zorrilla - UC

23

Relaciones reflexivas

En estos casos se requiere especificar el

rol, papel que desempea en la relacin
PERSONA
madre
1:N

maternidad

hijo

MECANISMO
Compuesto
por

Forma
parte de

constituye
N:M

Curso 2010-2011

Marta Zorrilla - UC

24

Relaciones

LIBRO

ISBN

1:1

EMPLEADO

NRP

1:1
ID

tiene

tiene

0:N

EJEMPLARES

0:N

estado

HIJOS

numcopia
Dependencia
de
identificacin

Dependencia
de existencia

DNI

Curso 2010-2011

Marta Zorrilla - UC

25

Atributos y claves
PERSONA

Direccin
Calle CP Localidad

IDPersona
Nombre
Fecha nacimiento
Edad
DNI
Profesin

Identificador

Atributo derivado
Clave candidata
Admite nulos
Multivaluado

Telfonos

Atributo compuesto

MUJER
1:1

matrimonio
HOMBRE

ALUMNO
Fecha

Curso acad.
n:m matricula

ASIGNATURA

Curso 2010-2011

Marta Zorrilla - UC

Gestin de prstamos (ejemplo)

Requisitos:







La biblioteca est interesada en automatizar la

gestin de prstamos
El modo de funcionar es sencillo, bsicamente
requiere registrar el socio que se lleva el libro, y de
qu ejemplar se trata, as como las fechas de
entrega, devolucin prevista y de devolucin.
La biblioteca est organizada en diversas sedes y el
socio puede coger libros de cualquiera de ellas.
Del socio se tienen los datos personales bsicos.
Y de los libros, todos los campos descriptivos que los
caracterizan (ttulo, idioma, autores, editorial,
fecha,).
Adems de cada ejemplar se querr conocer el
estado en el que se encuentra (prestable, en
reparacin, fuera de circulacin)

26

Curso 2010-2011

Marta Zorrilla - UC

27

Prstamos de la biblioteca
CodSocio
nombre

SOCIO

dni

(0,n)

SEDE Biblio.

localidad

(1:1)

FechaAlta
FechaPrevistaDev
FechaDev

prestar

ubicado

(1:1) EDITORIAL

publicado

IDEdit
nombre

(0:n)
(0,n)

(0:n)

EJEMPLAR

(0:n)

numEjemplar
Estado

ID

en

(1:1)

LIBRO
(0:n)

(0:n)

escrito
(1:n)

AUTORES

CodSed
nombre

titulo
Codlib
fecha
ISBN
en

(1:1)

IDIOMA
IDAutor
nombre
Apellido_1

IDIdioma
nombre

Curso 2010-2011

Marta Zorrilla - UC

28

Prstamos de la biblioteca
CodSocio
nombre

SOCIO

dni

(1:1)

SEDE Biblio.

localidad

(1:1)

a
(0:n)

NumPrest
FechaAlta
FechaPrevistaDev
FechaDev

PRESTAMO
(0:n)

ubicado

(1:1) EDITORIAL

publicado

de un

IDEdit
nombre

(0:n)
(1:1)

(0:n)

EJEMPLAR

(0:n)

numEjemplar
Estado

ID

en

(1:1)

LIBRO
(0:n)

(0:n)

escrito
(1:n)

AUTORES

CodSed
nombre

titulo
Codlib
fecha
ISBN
en

(1:1)

IDIOMA
IDAutor
nombre
Apellido_1

IDIdioma
nombre

Curso 2010-2011

Marta Zorrilla - UC

Gestin docente (ejemplo)

Requisitos:







Cada profesor pertenece a un slo departamento y

debe pertenecer a uno.
El profesor puede impartir varios grupos de la misma
o distinta asignatura, y un grupo debe ser enseado
por un profesor.
Los alumnos se matriculan de varias asignaturas (al
menos una) cada curso acadmico pero han de
hacerlo en un grupo. A su vez un grupo tendr varios
alumnos matriculados. Cada grupo tendr asignado
un aula para cada da y hora de la semana.
La matrcula dar opcin a dos convocatorias de
examen con su respectiva calificacin.
Todo departamento debe tener un director, que es
profesor.
Los atributos de cada entidad son los que cabra
esperar.

30

Curso 2010-2011

Marta Zorrilla - UC

Gestin docente

31

(1:1- dia - hora)

da

(0:n)

ocupa

ASIGNATURA
(1:1)

(1:1)

PROFESOR

ID

tiene

imparte

(0:n)

(0:n)

(1:1)

pertenece

GRUPO

(1:1)

CodGrupo

NroPersonal
nombre
Apellido_1

dirige

Max-alum

(1:n)

Nro

AULA

hora

CodAsig
Nombre
Crditos
Carcter
Curso

(1:n)

(0:1)

DPTO

CodDpto
nombre

Calificacin
consta

Convocatoria (1..2)

(0:n)

MATRICULA

(0:n)

CursoAcad
CodMatr

realiza

(1:1)

ALUMNOS

CodAlu
nombre
dni

Curso 2010-2011

Marta Zorrilla - UC

32

Relaciones n-arias
PROVEEDOR

(0:1)

TRABAJO
(1:n)

compra

(1:n)

PIEZA

Una pieza Y en un trabajo Z una pareja (pieza, trabajo) la

suministran 0 o 1 proveedores.
Un proveedor X en un trabajo Z una pareja (proveedor,
trabajo) suministra 1, 2, .., n piezas.
Un proveedor X suministra una pieza Y una pareja (proveedor,
pieza) en 1, 2, .., n proyectos

Curso 2010-2011

Marta Zorrilla - UC

Relaciones n-arias
(0:n)

33

(sin redundancia)
(0:n)

PROVEEDOR

precio

Puede
intervenir

Puede
suministrar
(1:n)

(0:n)

(1:n)

TRABAJO
(1:n)

compra

(1:n)

PIEZA

cantidad
Precio ud.

(0:n)

necesita

(1:n)

Cantidad total

Curso 2010-2011

Marta Zorrilla - UC

34

Generalizacin y especializacin
PERSONA

Calificacin
crediticia

CLIENTE

NroPersona
nombre
Apellido_1

EMPLEADO

salario
puesto

La Generalizacin se considera como un caso especial de relacin entre uno

o varios tipos de entidad (subtipos) y un tipo ms general (supertipo), cuyas
caractersticas son comunes a todos los subtipos.
El mecanismo de abstraccin contrario se llama especializacin.

Curso 2010-2011

Marta Zorrilla - UC

Generalizacin y especializacin
La divisin en subtipos (especializacin) puede venir
determinada por una condicin predefinida (por ejemplo,
en funcin de los valores de un atributo llamado
discriminante).
La Generalizacin/Especializacin tiene dos restricciones
semnticas asociadas:
Totalidad (todo ejemplar del supertipo tiene que
pertenecer a algn subtipo). El caso contrario se llama
Parcialidad.
Solapamiento (un mismo ejemplar del supertipo puede
pertenecer a ms de un subtipo). El caso contrario se
llama Exclusividad.

35

Curso 2010-2011

Marta Zorrilla - UC

36

Generalizacin y especializacin
PERSONA
Total
exclusiva

(t,e)

HOMBRE

PERSONA

MUJER

(t,s)
EMPLEADO

ESTUDIANTE

EMPLEADO

PERSONA
(p,e)

Total con
solapamiento

Parcial
exclusiva

DIRECTOR ADMINISTRATIVO

(p,s)
DOCENTE

Parcial con
solapamiento
INVESTIGADOR

Curso 2010-2011

Marta Zorrilla - UC

37

Restriccin de exclusividad

percibe

BECA

PERSONA
Est en

CONTRATO

La persona o percibe una beca o est contratado

Curso 2010-2011

Marta Zorrilla - UC

38

Restriccin de exclusin

imparte
PERSONA

CURSO
recibe

La persona imparte o recibe el curso, no puede estar en

ambas relaciones a la vez

Curso 2010-2011

Marta Zorrilla - UC

39

Restriccin de inclusividad

dominan

IDIOMA

PERSONA
hacen

VIAJES INTERN.

Las personas que dominan idiomas son un subconjunto de

las que realizan viajes internacionales. Si una persona
participa en domina, tiene necesariamente que participar
en hacen viajes

Curso 2010-2011

Marta Zorrilla - UC

40

Restriccin de inclusin

atiende
MEDICO

HOSPITAL
opera

Los cirujanos son un subconjunto de los mdicos del hospital

Curso 2010-2011

Marta Zorrilla - UC

41

Agregacin

Es un tipo especial de relacin en la cual las

cardinalidades mnima y mxima del tipo de entidad
agregada siempre son (1,1)
Existen dos clases de agregaciones:


Compuesto/Componente:

permite representar que un todo se obtiene por la unin

de diversas partes que pueden ser tipos de entidades
distintas y que juegan diferentes roles en la agregacin.

Miembro/Coleccin:

permite representar un todo como una coleccin de

miembros, todos de un mismo tipo de entidad y todos
jugando el mismo rol.
Esta agregacin puede incluir una restriccin de orden de
los miembros dentro de la coleccin (indicando el atributo
de ordenacin).

Curso 2010-2011

Marta Zorrilla - UC

42

Ejemplos agregacin
Agregacin
Compuesto/Componente

(1:1)

CHASIS

FLOTA

(1:n)

BARCO

Ordenado por num_barco

COCHE

(1:1)

MOTOR

(4:4)

RUEDA

Agregacin
Miembro/Coleccin
con cardinalidades y
restriccin de orden

Curso 2010-2011

Marta Zorrilla - UC

43

Agregacin otros usos

Como herramienta para expresar relaciones entre relaciones o
entre relaciones y conjuntos de entidades

dni
nombre

ENFERMO

realizado

1:n

atendido

MEDICO

PRUEBA

fecha
hora
nrp
especialidad

Codpru
nombre
tipo

Curso 2010-2011

Marta Zorrilla - UC

Evitar las redundancias

Un elemento de un esquema es redundante si puede

ser eliminado sin prdida de semntica.
Existen dos formas principales de redundancia:


En los atributos (derivados o calculados):

Aunque son redundantes, no dan lugar a

inconsistencias siempre que en el esquema se indique
su condicin de derivados y la frmula mediante la que
han de ser calculados.

En las relaciones (tambin llamadas interrelaciones

derivadas):

Una relacin es redundante si su eliminacin no

implica prdida de semntica porque existe la
posibilidad de realizar la misma asociacin de
ejemplares por medio de otras relaciones.
Para ello es condicin necesaria pero no suficiente que
forme parte de un ciclo => Hay que estudiar
detenidamente los ciclos en el diagrama E/R.

44

Curso 2010-2011

Marta Zorrilla - UC

Evitar las redundancias (y 2)

45

Curso 2010-2011

Marta Zorrilla - UC

46

Hay problema de redundancia?

1:n

PROFESOR

1:n

1:n

investiga

Participa
Imparte

1:n

TEMA

1:n

1:n
1:n

Consta

1:n

1:n

CURSO

Curso 2010-2011

Marta Zorrilla - UC

Gestin de compras (ejemplo)

Requisitos:






Una empresa est interesada en automatizar su

proceso de compras
El modo de funcionar es sencillo, bsicamente
requiere registrar la hoja del pedido que realiza a un
determinado proveedor en una determinada fecha
En la hoja del pedido queda constancia del nmero
de unidades que compra de cada artculo y el precio
de compra, y en caso de que el proveedor o bien por
volumen o por promocin, le realiza un descuento,
tambin lo anota
Los productos que compran tienen distinto IVA
Generalmente el paga a sus proveedores al mes de
recibir la mercanca y por transferencia, aunque lo
puede hacer a plazos
Los atributos de cada entidad son los que cabra
esperar

49

Curso 2010-2011

Marta Zorrilla - UC

50

Gestin de compras
(1:1)

CodProv
nombre
tfno
c/c

PROVEEDOR

suministra

(0:n)

PEDIDO
(0:n)

consta

(1:1)

Calle CP Localidad

Con/del
FechaPed
NumPed
FechaEntrega
Estado
Importe pedido
precioCompra
unidades
descuento
iva
numLinea

(1:n)

Direccin

(0:n)

PAGO

ARTICULO

NumPago
FechaPago
Tipo pago
Concepto
c/c
cantidad

Codart
nombre
precioUd
iva

Curso 2010-2011

Marta Zorrilla - UC

51

Generalizacin del tipo de pago

PAGO
(1:1)

NumPago
FechaPago
Concepto
cantidad

Tipo pago

DISCRIMINANTE

(p,e)

tarjeta

transferencia
nmero
Fecha caducidad
Tipo tarjeta{crdito,dbito}

c/c

cheque
nmeroCheque
banco

Modelo relacional
Marta Zorrilla
Universidad de Cantabria

Curso 2010-2011

Marta Zorrilla - UC

59

Curso 2010-2011

Marta Zorrilla - UC

Tabla de contenidos

Elementos bsicos




Restricciones de integridad



Dominios y atributos
Definicin de relacin
Clases de relaciones
Inherentes
Definidas por el usuario

Valores nulos
Esquemas relacionales
SGBD relacionales

60

Curso 2010-2011

Marta Zorrilla - UC

Introduccin

En 1970, Codd public en ACM el trabajo

Un modelo de datos relacional para
grandes bancos de datos compartidos
donde propuso un nuevo Modelo de
Datos.

Se caracteriza por:




ser sencillo y uniforme (coleccin de tablas y

lenguajes declarativos)
slida fundamentacin terica: el modelo est
definido con rigor matemtico
se independiza del almacenamiento fsico y de
las aplicaciones.

61

Curso 2010-2011

Marta Zorrilla - UC

Elementos bsicos

RELACIN


DOMINIO


Es el conjunto vlido de valores que toma un

atributo. Existen con independencia de cualquier
otro elemento.

ATRIBUTO


Es la estructura bsica del modelo relacional. Se

representa mediante una tabla.

Representa las propiedades de la relacin. Se

representa mediante una columna.

TUPLA


Es una ocurrencia de la relacin. Se representa

mediante una fila.

62

Curso 2010-2011

Marta Zorrilla - UC

63

Ejemplo de relacin
El Universo de Discurso de una BD relacional est compuesto por un
conjunto de dominios {Di} y de relaciones {Ri} definidas sobre los
dominios.
atributos
nombre

calle

ciudad

Carmen
Ana
Pedro
Marie

Calvo Sotelo
Castellana
Torres Quevedo
Eliseos

Santander
Madrid
Logroo
Pars

cliente

tuplas

Curso 2010-2011

Marta Zorrilla - UC

64

Dominios
Un dominio es un conjunto nominado, finito y homogneo
de valores atmicos

Un dominio =>





se identifica por un nombre,

tiene un nmero finito de valores,
todos los valores son del mismo tipo, y
los valores son atmicos respecto del MR

Cada dominio puede definirse de dos maneras:



Extensin (dando sus posibles valores):

Intensin (mediante un tipo de datos):

das de la semana = {lunes, martes, mircoles, sbado, domingo}

peso = decimal

A veces se asocia al dominio su unidad de medida (kilos, metros,

etc.) y/o ciertas restricciones (como un rango de valores).

Curso 2010-2011

Marta Zorrilla - UC

Atributos
Un atributo (A) es la interpretacin de un determinado
dominio en una relacin, es decir el papel que juega en la
misma.

Notacin:
D = Dom (A) => D es el dominio de A

Un atributo y un dominio pueden llamarse igual, pero







Un atributo est siempre asociado a una relacin, mientras que

un dominio tiene existencia propia con independencia de las
relaciones.
Un atributo representa una propiedad de una relacin.
Un atributo toma valores de un dominio.
Varios atributos distintos (de la misma o de diferentes relaciones)
pueden tomar sus valores del mismo dominio.

65

Curso 2010-2011

Marta Zorrilla - UC

Relacin
Una relacin (matemticamente) es un subconjunto del
producto cartesiano de la lista de dominios {Di}

Esta definicin no tiene en cuenta a los atributos, por eso en

Bases de Datos se utiliza otra definicin un esquema de
relacin se compone de un nombre de relacin R, un conjunto
de n atributos {Ai} y de un conjunto de n dominios (no
necesariamente distintos) {Di} donde cada atributo ser
definido sobre un dominio.

Una relacin consta de los siguientes elementos:







Nombre de la relacin
Cabecera: conjunto de n pares atributo-dominio
Cuerpo: Conjunto de m tuplas
Esquema: constituido por el nombre de la relacin y la
cabecera
Estado: constituido por el esquema y cuerpo.

66

Curso 2010-2011

Marta Zorrilla - UC

67

Relacin (y 2)

Hay que diferenciar:




Esquema : conjunto de atributos {Ai} junto con sus dominios

Instancia : conjunto de tuplas r={t1,,tn} tal que ti=(x1,..,xn) con xj Dj

Esquema:
Persona [nombre: Nombres, calle: Calles, ciudad: Ciudades]
Instancia:
(Carmen, Calvo Sotelo, Santander),
(Ana, Castellana, Madrid),
(Pedro, Torres Quevedo, Logroo),
(Marie, Eliseos, Paris)

Se denomina cardinalidad o aridad de una relacin al nmero de

tuplas que hay en un esquema. Y grado al n de atributos.

Curso 2010-2011

Ejemplo

Marta Zorrilla - UC

68

Curso 2010-2011

Marta Zorrilla - UC

69

Base de datos relacional

Una base de datos relacional es un conjunto finito de relaciones {Ri}

Persistentes
Con nombre
Clases de
relaciones

Sin nombre

Base (definidas por el

usuario y del sistema)
Vistas
Vistas materializables

Temporales

Definidas por el usuario

Vistas temporales
Vistas materializables temp.

Temporales

Resultado de una consulta

(intermedio o final)

Curso 2010-2011

Marta Zorrilla - UC

Terminologa

!CUIDADO!, una relacin no es una tabla. Ni una tabla es un fichero.

Existen diferencias entre los conceptos.

70

Curso 2010-2011

Marta Zorrilla - UC

Restricciones inherentes

Las restricciones inherentes vienen impuestas por el propio

Modelo de Datos.

En el caso del MR, una relacin tiene unas propiedades

intrnsecas que no tiene una tabla, y que se derivan de la
misma definicin matemtica de relacin, ya que, al ser un
conjunto:





No puede haber dos tuplas iguales => obligatoriedad de la PK

El orden de las tuplas no es significativo.
El orden de los atributos no es significativo.
Cada atributo slo puede tomar un nico valor del dominio
subyacente

Se dice que la relacin est normalizada (en 1FN).

Otra restriccin es la regla de integridad de entidad:

Ningn atributo que forme parte de la clave primaria de una
relacin puede tomar un valor nulo

71

Curso 2010-2011

Marta Zorrilla - UC

Tabla vs. relacin

Una relacin es un concepto abstracto de origen

matemtico.
Una tabla es una forma de representar (implementar)
una relacin (una estructura de datos).
Una tabla no tiene las restricciones inherentes de una
relacin como conjunto:





Puede haber dos filas iguales.

Las filas estn ordenadas en el orden de grabacin fsica
por defecto o segn el valor de la clave primaria.
Los atributos tienen un orden segn se han definido en la
tabla.
En cada celda de una tabla puede haber uno o varios
valores. Si bien en el segundo caso se puede obtener una
tabla equivalente que cumple la regla de normalizacin.

72

Curso 2010-2011

Marta Zorrilla - UC

73

Clave (key)
Clave Candidata (Candidate Key): conjunto de atributos que
identifican unvoca y mnimamente cada tupla de la relacin.


De la definicin de relacin se deriva que siempre existe, al menos, una

clave candidata.
La propiedad de minimalidad implica que no se incluye ningn atributo
innecesario: CK cumple la propiedad de minimalidad si no existe un
atributo X tal que {CK-X} sea clave candidata.

Una relacin puede tener ms de una clave candidata. En este caso

se debe distinguir entre:
 Clave Primaria (Primary Key):
NRP para empleado

Es la clave candidata que el usuario escoge para identificar las tuplas

de la relacin.
Cuando slo existe una clave candidata, sta es la clave primaria.

Claves Alternativas (Alternative Key): DNI, PASAPORTE para

empleado

Las claves candidatas que no han sido escogidas como clave primaria.

Curso 2010-2011

Marta Zorrilla - UC

Clave (key)

74

(y 2)

Clave Ajena (Foreign Key): Se denomina clave ajena de una

relacin R2 a un conjunto no vaco de atributos cuyos valores han de
coincidir con los valores de una clave candidata de una relacin R1.



R1 y R2 pueden ser la misma relacin.

La clave ajena y la correspondiente clave candidata han de estar
definidas sobre el mismo dominio.

PK

CK

FK

EMPLEADO (NRP, dni, nombre, apellido, fecha_nac, trabaja_en,..)

DEPARTAMENTO (CodDpto, nombre, responsable,..)
PK

FK

Curso 2010-2011

Marta Zorrilla - UC

Restricciones semnticas

Son definidas por el usuario.

Son facilidades que el modelo ofrece a los diseadores
para que puedan reflejar en el esquema, lo ms
fielmente posible, la semntica del mundo real.
Los tipos de restricciones semnticas permitidos en el MR
(incorporados a SQL 92) son:








Clave Primaria (PRIMARY KEY)

Unicidad (UNIQUE)
Obligatoriedad (NOT NULL)
Integridad Referencial (FOREIGN KEY)
Verificacin (CHECK)
Asercin (CREATE ASSERTION)
Disparador (TRIGGER), incluido en SQL:1999

75

Curso 2010-2011

Marta Zorrilla - UC

Restricciones semnticas

Permite declarar un atributo o un conjunto de atributos como

clave primaria de una relacin => sus valores no se podrn
repetir ni se admitirn los nulos.
Ni el SQL92 ni los SGBDs relacionales obligan a la declaracin
de una clave primaria para cada tabla (el modelo terico s la
impone), aunque permiten la definicin de la misma.
Se debe distinguir entre la restriccin inherente de
obligatoriedad de la clave primaria y la restriccin semntica
que le permite al usuario indicar qu atributos forman parte de
la clave primaria.

Unicidad (UNIQUE):


(y 2)

Clave Primaria (PRIMARY KEY):



76

Los valores de un conjunto de atributos (uno o ms) no

pueden repetirse en una relacin. Permite la definicin de
claves alternativas.

Obligatoriedad (NOT NULL):



El conjunto de atributos no admite valores nulos.

Curso 2010-2011

Marta Zorrilla - UC

Restricciones semnticas: Foreign key

Integridad Referencial (FOREING KEY):



La condicin puede expresarse como R2.CA = R1.CC






Si una relacin R2 (relacin que referencia) tiene un

descriptor (subconjunto de atributos) CA que referencia a
una clave candidata CC de la relacin R1 (relacin
referenciada), todo valor de dicho descriptor CA debe
coincidir con un valor de CC o ser nulo.

El descriptor CA es, por tanto, una clave ajena de la relacin

R2.
Las relaciones R1 y R2 no son necesariamente distintas.
La clave ajena puede ser tambin parte (o la totalidad) de la
clave primaria de R2.
CA puede admitir nulos o tener restriccin de obligatoriedad
(NOT NULL).

Todo atributo de una clave primaria compuesta de una

relacin R2 que no est definido sobre un dominio
compuesto, debe ser clave ajena de R2 referenciando a
una relacin R1, cuya clave primaria sea simple.

77

Curso 2010-2011

Marta Zorrilla - UC

78

Ejemplo
BANCOS
ENTIDAD

NOMBRE

0893

Santander

0059

Popular

3428

Bilbao Vizcaya

5632

Banesto

OFICINAS
ENTIDAD

CODIGO_OFICINA

POBLACION

DIRECCION

0893

001

Madrid

Castellana, 73

3428

022

Las Palmas

Triana, 21

0893

022

Gldar

R. Moreno, 3

5632

213

Oviedo

Ura, 43

0893

300

Barcelona

Diagonal, 435

Curso 2010-2011

Marta Zorrilla - UC

Restricciones semnticas: Foreign key (y 2)

Integridad Referencial (FOREING KEY):



Adems de definir las claves ajenas, hay que

determinar las consecuencias que se producen al
borrar o actualizar la relacin referenciada. Segn el
estndar SQL92:

NO ACTION: rechazar la operacin de borrado o

modificacin.
CASCADE: propagar la modificacin (o borrado) de
las tuplas de la tabla que referencia.
SET NULL: poner valor nulo en la clave ajena de la
tabla que referencia.
SET DEFAULT: poner un valor por defecto en la clave
ajena de la tabla que referencia.

Los modos borrar y modificar son independientes, es

decir, cada uno tomar una de las cuatro opciones por
separado.

79

Curso 2010-2011

Marta Zorrilla - UC

80

Ejemplo
DEPARTAMENTO (CodDpto, nombre, responsable,..)

Modificacin: Cascade
Borrado: SET NULL

EMPLEADO (NRP, dni, nombre, apellido, fecha_nac, trabaja_en,..)

Modificacin: Cascade
Borrado: NO ACTION

PARTICIPA (CodProy, CodTarea, NRP, porcentaje)

TAREAS (CodProy, CodTarea, ttulo, responsable, fecha_ini, fecha_fin)

PROYECTO (CodProy, ttulo, fecha_ini, fecha_fin)

Curso 2010-2011

Marta Zorrilla - UC

Restricciones semnticas: Verificacin

CHECK: Comprueba, en toda operacin de

actualizacin, si el predicado es cierto o falso y,
en este ltimo caso, rechaza la operacin.
La restriccin de verificacin se define sobre un
nico elemento

CHECK (porcentaje > 0 and porcentaje <100)

O a nivel de relacin

CHECK (fecha_fin >= fecha_ini)



Siempre dentro de un CREATE TABLE. Puede o no

tener nombre.

81

Curso 2010-2011

Marta Zorrilla - UC

82

Restricciones semnticas: Asertos

ASSERTION: Acta de forma idntica a la anterior, pero

se diferencia de ella en que puede afectar a varios
elementos (por ejemplo, a dos relaciones distintas).
Su definicin no va unida a la de un determinado
elemento del esquema y siempre ha de tener un nombre.

CREATE ASSERTION ctrl_proyecto CHECK

(not exists (SELECT CE.trabaja_en as dpto_currito, CT.codproy, CT.codtarea
FROM empleado CE, participa CT

where CE.nrp = CT.nrp and

CE.trabaja_en not in(

SELECT RE.trabaja_en from empleado RE, tarea PT
where RE.nrp = PT.responsable and PT.codproy=CT.codproy and
PT.codtarea=CT.codtarea))
Empleados que participan en una tarea sean del mismo Dpto que su responsable

Curso 2010-2011

Marta Zorrilla - UC

83

Restricciones semnticas: Disparadores

Restriccin en la que el usuario pueda especificar la

respuesta (accin) ante una determinada condicin.

CREATE TRIGGER ctrl_participa ON PARTICIPA

DECLARE @total float

FOR

INSERT, UPDATE

AS

SELECT @total= count(*) FROM inserted

WHERE 100 < (select sum(porcentaje) from participa
where participa.nrp=inserted.nrp )
IF (@total>0)
BEGIN
RAISERROR (' Sobrecarga', 16, 1)
ROLLBACK TRANSACTION
RETURN
END

evitar la sobrecarga
de los trabajadores

Curso 2010-2011

Marta Zorrilla - UC

84

Valores nulos
Valor nulo: utilizado para representar informacin
desconocida, inaplicable, inexistente, no vlida, no
proporcionada, indefinida, etc.

Necesidad de los valores nulos en BD:



Crear tuplas (filas) con ciertos atributos cuyo valor es

desconocido en ese momento, p.e., la fecha de devolucin de un
prstamo.
Aadir un nuevo atributo a una relacin existente; atributo que,
en el momento de aadirse, no tendra ningn valor para las
tuplas de la relacin.
Atributos inaplicables a ciertas tuplas, por ejemplo, la editorial
para un artculo (ya que un artculo no tiene editorial) o la
profesin de un menor.

Requiere tener cuidado en las consultas (is null)

Curso 2010-2011

Marta Zorrilla - UC

Valores nulos (y 2)

El tratamiento de valores nulos exige redefinir las operaciones

de comparacin, aritmticas, de agregacin, etc. de forma
especfica para el caso en que un operando tome valor nulo.
Obliga a introducir nuevos operadores especiales: IS NULL ,
MAYBE
En las operaciones de comparacin se hace necesario definir
una lgica trivaluada incorporando el valor quizs (Q).

Se considera nulo el resultado de una suma, resta,

multiplicacin o divisin si alguno de los operandos toma valor
nulo.
En las agregaciones, no se consideran esas tuplas, a excepcin
del count(*)

85

Curso 2010-2011

Marta Zorrilla - UC

86

Esquemas relacionales

Ahora podemos dar una definicin ms completa de

esquema de una relacin:

R < A:D, S >

siendo





R el nombre de la relacin,
A la lista de atributos,
D los dominios sobre los que estn definidos los atributos, y
S las restricciones de integridad intraelementos (afectan a
atributos y/o tuplas de una nica relacin).

El esquema de una base de datos relacional ser:

< {Ri }, {Ii } >

siendo




el nombre del esquema relacional,

{Ri} el conjunto de esquemas de relacin, y
{Ii} el conjunto de restricciones de integridad
interelementos (afectan a ms de una relacin y/o dominio).

Curso 2010-2011

Marta Zorrilla - UC

87

Esquemas relacionales (y 2)

En trminos de implementacin en SQL, un esquema E

constar de:

E <R, D, T, V>
siendo




R el conjunto de esquemas de relacin (CREATE TABLE),

D el conjunto de definiciones de dominios (CREATE DOMAIN),
T el conjunto de restricciones de integridad entre relaciones y
sobre dominios (CREATE ASSERTION, CREATE TRIGGER, ...), y
V el conjunto de vistas (CREATE VIEW).

Curso 2010-2011

Marta Zorrilla - UC

Gestores relacionales (MR vs ANSI)

88

Curso 2010-2011

Marta Zorrilla - UC

89

Las 12 reglas de Codd (ComputerWorld 1985)

Cuando el MR triunf comercialmente, muchos fabricantes

que tenan productos antiguos no relacionales optaron
por retocarlos o camuflarlos aadindoles la etiqueta
relacional.
Esto supuso una confusin que Codd intent arreglar
publicando sus 12+1 reglas, que indican las caractersticas
que debe tener un SGBD para ser autnticamente
relacional.
Regla 0:


Un SGBD relacional debe emplear para gestionar la BD

exclusivamente sus facilidades relacionales.

De esta regla genrica se derivan las 12 reglas de CODD.

Curso 2010-2011

Marta Zorrilla - UC

90

Reglas de Codd (y 2)

1. Representacin de la informacin: Toda la informacin en la

Base de datos es representada de forma explcita y nica a nivel
lgico, por medio de valores en columnas de filas de tablas.
2. Acceso garantizado: Todo dato (valor atmico) debe ser
accesible mediante una combinacin de tabla, un valor de su clave y
el nombre de una columna.
3. Tratamiento sistemtico de valores nulos: El SGBD debe
soportar la representacin y manipulacin de informacin
desconocida y/o no aplicable, independientemente del tipo de dato.
4. Catlogo en lnea (diccionario de datos) basado en el modelo
relacional. La descripcin de la base de datos se debe representar en
el nivel lgico de la misma manera que los datos ordinarios, de
forma que los usuarios autorizados puedan consultarla con el mismo
lenguaje con el que consultan los datos.

Curso 2010-2011

Marta Zorrilla - UC

91

Reglas de Codd (y 3)

5. Sublenguaje de datos completo: El SGBD debe soportar al

menos un lenguaje relacional:




a) con sintaxis lineal.

b) que pueda ser usado interactivamente o en programas (embebido).
c) con soporte para operaciones de:

definicin de datos (p.e. declaracin de vistas).

manipulacin de datos (p.e. recuperacin y modificacin de tuplas).

restricciones de seguridad e integridad.

gestin de transacciones.

6. Actualizacin de vistas: todas las vistas tericamente

actualizables deben poder serlo en la prctica.
7. Insercin, modificacin y borrado de tuplas de alto
nivel: todas las operaciones de manipulacin de datos deben
operar sobre conjuntos de filas.

Curso 2010-2011

Marta Zorrilla - UC

92

Reglas de Codd (y 3)

8. Independencia fsica de los datos: cambios en los mtodos de

acceso fsico o la forma de almacenamiento no deben afectar al
acceso lgico a los datos.
9. Independencia lgica de los datos: los programas de
aplicacin no deben ser afectados por cambios en las tablas que
preservan la integridad.
10. Independencia de la integridad: Las restricciones de
integridad deben estar separadas de los programas, almacenadas en
el catlogo de la BD para ser editadas mediante un sublenguaje de
datos.
11. Independencia de la distribucin: Las aplicaciones no deben
verse afectadas al distribuir (dividir entre varias mquinas), o al
cambiar la distribucin ya existente de la Base de Datos.
12. Regla de no subversin: Si el sistema posee un interfaz de
bajo nivel (p.e. mediante llamadas en C), ste no puede utilizarse
para saltarse las reglas de integridad y las restricciones expresadas
por medio de un lenguaje de ms alto nivel.

Curso 2010-2011

Marta Zorrilla - UC

93

Ejercicio
Carretera (IdCarretera, nombre)
Area (IdArea, nombre)
Tramo (IdCarretera, NroTramo, Area)
Pasa (IdCarretera, NroTramo, CodMunicipio,PtokmEntra,PtoKmSale)
Municipio (CodMunicipio, nombre, localidad)

1. Qu recoge esta base de datos relacional?

2. Identifique las claves principales, claves candidatas y claves ajenas
3. En las restricciones de referenciabilidad indique las consecuencias del
borrado y la actualizacin
4. Aadiras alguna restriccin de integridad?

Del modelo ER al modelo

relacional
Marta Zorrilla
Universidad de Cantabria

Curso 2010-2011

Marta Zorrilla - UC

94

Curso 2010-2011

Marta Zorrilla - UC

Gestin docente

95

da
hora

clase

(1:1)

(0:n)

AULAS

CodAula
capacidad

PROFESOR

NroPersonal
nombre
Apellido_1

(1:n)

CodAsig
Nombre
Crditos
Carcter
Curso

ASIGNATURA
(1:1)
ID

(1:1)

tiene

imparte

(0:n)

(0:n)

GRUPO

(1:1)

Max-alum

(1:n)

pertenece

CodGrupo

(1:1)

Calificacin
consta

dirige
(0:1)

DPTO

Convocatoria (1..2)

CodDpto
nombre

(0:n)

MATRICULA

(0:n)

CursoAcad
CodMatr

realiza

(1:1)

ALUMNOS

CodAlu
nombre
dni

Curso 2010-2011

Marta Zorrilla - UC

Entidades

ENTIDADES  TABLAS







Se conservan los atributos y la clave principal.

Claves candidatas, establecer restriccin de unicidad.
Atributos compuestos  un campo por atributo
Atributos derivados  columnas calculadas
Atributos multivaluados  nueva tabla
Restricciones sobre atributos  lenguaje lgico

Ej:
Asignatura (CodAsig, nombre, crditos, carcter, curso)
Alumno (CodAlu, nombre, dni)
Aula (CodAula, capacidad)
Profesor (NroPersonal, nombre, apellido_1)
Dpto (CodDpto, nombre)
Matricula (CodMatr, cursoAcad)

96

Curso 2010-2011

Marta Zorrilla - UC

Entidades dbiles

ENTIDADES DBILES  TABLAS




Conserva todos sus atributos y se aade la clave

principal de la entidad fuerte de la que depende.
Si la relacin es de identificacin, la clave principal la
forma algn atributo de la entidad dbil y la clave
principal de la entidad fuerte.
Si la relacin es de existencia, tendr su propia clave,
pero se establecer borrado y actualizacin en cascada
con respecto la entidad fuerte (tambin se podra
restringir).

Ej:
Grupo (CodAsig, CodGrupo, max_alum)

97

Curso 2010-2011

Marta Zorrilla - UC

98

Relaciones

RELACIONES  TABLAS



La tabla a la que da lugar tendr como atributos las claves principales de

las entidades que se conectan y los atributos de la relacin.
La eleccin de la clave principal depende de la cardinalidad de la relacin

M:N

La PK estar formada, al menos, por las PK de las entidades que

relaciona. Dimensin temporal.
CONSTA (CodMatr, CodAsig, CodGrupo, Convocatoria, calificacin)

1:N

La PK estar formada por la PK de la entidad que participa con

cardinalidad N
PERTENECE (CodProf, CodDpto)

1:1

La PK estar formada por una de las PK de las entidades que

relaciona. La otra actuar como clave candidata.
DIRIGE (CodProf, CodDpto)

Curso 2010-2011

Marta Zorrilla - UC

99

Esquema obtenido
Asignatura (CodAsig, nombre, crditos, carcter, curso)
Alumno (CodAlu, nombre, dni)
Aula (CodAula, capacidad)
Profesor (NroPersonal, nombre, apellido_1)
Dpto (CodDpto, nombre)
Matricula (CodMatr, cursoacad)
Grupo (CodAsig, CodGrp, max_alum)
CONSTA (CodMatr, CodAsig, CodGrupo, Convocatoria, calificacin)
PERTENECE (NroPersonal, CodDpto)
DIRIGE (NroPersonal, CodDpto)
IMPARTE (CodAsig, CodGrupo, NroPersonal)
CLASE (CodAsig, CodGrupo, CodAula, hora, dia)
REALIZA (NumMatr,CodAlum)

N:N todo
clave si ms
de un grupo
en aula

Curso 2010-2011

Marta Zorrilla - UC

100

Esquema obtenido: reduccin de tablas

Asignatura (CodAsig, nombre, creditos, carcter, curso)
Alumno (CodAlu, nombre, dni)
Aula (CodAula, capacidad)

Profesor (NroPersonal, nombre, apellido1, CodDpto)

Profesor (NroPersonal, nombre, apellido1)

Dpto (CodDpto, nombre)

Dpto (CodDpto, nombre, CodProfDirige)

Matricula (CodMatr, cursoacad)

Matricula (CodMatr, cursoacad,CodAlu)

Grupo (CodAsig, CodGrp, max_alum)

Grupo (CodAsig,CodGrp,max_alum,NroPersonal)

CONSTA (CodMatr, CodAsig, CodGrp, Convocatoria, calificacin)

PERTENECE (NroPersonal, CodDpto)
DIRIGE (NroPersonal, CodDpto)
IMPARTE (CodAsig, CodGrupo, NroPersonal)
CLASE (CodAsig, CodGrupo, CodAula, hora, dia)
REALIZA(CodMatr,CodAlu)

Curso 2010-2011

Marta Zorrilla - UC

101

Esquema definitivo
U:C D:not action

Dpto (CodDpto, nombre, CodProfDirige)

CodProfDirige not null

U:C D:No action

CodDpto not null

Profesor (NroPersonal, nombre, apellido1, CodDpto)

Alumno (CodAlu, nombre, dni)
Matricula (CodMatr, cursoacad, CodAlu)

U:C D:No action

CodAlu not null

U:C D:C

CONSTA (CodMatr, CodAsig, CodGrupo, Convocatoria, calificacin)

U:C
D:Not action

Grupo (CodAsig, CodGrupo, max_alum, NroPersonal)

U:C D:C

U:C
D:Set null

U:C D:Not action

NroPersonal not null

Asignatura (CodAsig, nombre, crditos, carcter, curso)

CLASE (CodAsig, CodGrupo, CodAula, hora, dia)

Aula (CodAula, capacidad)

U:C
D:Not action

CREATE ASSERTION maxAlumAula

CREATEASSERTION
ASSERTIONdirige_dpto
convocatorias
CREATE
AS from
CHECK
not exists
CHECK not exists ( select
count(*)
CLASE
c,AULA a,GRUPO g
CHECK not exists ( select count(*) from CONSTA
(SELECT
where * FROM Dpto WHERE CodProfDirige NOT IN
group by Codmatr,CodAsig,CodGrp
c.codAula=a.CodAula
c.CodAsig=g.CodAsig
and
(SELECT
NroPersonal and
FROM
Profesor where
having
count(*)>2)
c.CodGrupo=g.CodGrupo and max_alum>capacidad)
Profesor.CodDpto=Dpto.CodDpto ));

Curso 2010-2011

Marta Zorrilla - UC

102

Relaciones unarias
0:N

PERSONA
1:1

madre

hijo

maternidad
Borrado: null
Modificacin: cascada

a)
persona (Codper, nombre,, codper_madre)
b)
persona (Codper, nombre, )
madre (Codper, codper_madre)

Borrado y
Modificacin: cascada o
not action

Nulos no permitidos

Curso 2010-2011

Marta Zorrilla - UC

103

Generalizacin

Crear una tabla por cada entidad que participa

ELEMENTO (codElem, Coef, cc)
LOCAL(CodElem, tipo_comercio, horario)
OFICINA(codElem, actividad)
VIVIENDA (codElem, numHab)

Crear una tabla para cada caso particular, eliminando

la entidad de nivel superior. No frecuente.
LOCAL(CodElem, tipo_comercio, horario , Coef, cc)

ELEMENTO
(1:1)

tipo

codElem
Coef. Part.
c/c

(t,e)

OFICINA(codElem, actividad , Coef, cc)

VIVIENDA (codElem, numHab , Coef, cc)

local

oficina vivienda
tipo comercio
horario

N hab.
actividad

Crear un sola relacin

ELEMENTO (CodElem, tipo, horario , tipo_comercio,
actividad, numhab,Coef, cc)

Curso 2010-2011

Marta Zorrilla - UC

104

Restricciones semnticas

Totalidad/parcialidad:


Se controla la totalidad prohibiendo la insercin

en el supertipo directamente, se har cuando se
inserte en los subtipos (disparadores)
La parcialidad no requiere disparadores

Exclusividad/solapamiento


Se requiere un aserto (o trigger) que compruebe

que si un ejemplar est en un subtipo no puede
estar en otro

Curso 2010-2011

Marta Zorrilla - UC

105

Agregacin
fecha
dni
nombre

ENFERMO

realizado

PRUEBA

1:1
atendido

1:n
MEDICO

nrp
especialidad

REALIZADO(dni,codpru, fecha)
ATENDIDO(dni,codpru, fecha,nrp)

Codpru
nombre
tipo

Curso 2010-2011

Marta Zorrilla - UC

106

Agregacin
COCHE

(1:1)

CHASIS

(1:1)

MOTOR

(4:4)

RUEDA

obligatorios

COCHE(Idcoche, fechafabr,, idchasis,idmotor)

coche_ruedas(idcoche,idrueda)
CHASIS(idchasis, nroserie, lon, anchura,)
MOTOR (idmotor, nroserie, rpm,)
RUEDA (idrueda, modelo,)

Curso 2010-2011

Marta Zorrilla - UC

107

Relaciones n-arias

No es directo, una relacin puede tener varias

interpretaciones y todas ellas vlidas.

Depende de la cardinalidad:



N:M:S, la PK el conjunto de las PK de cada relacin

N:M:1, la PK ser el conjunto de las PK con
cardinalidad distinta de 1
N:1:1, probablemente se dividir en dos relaciones
1:n

Curso 2010-2011

Marta Zorrilla - UC

108

Distintas interpretaciones
PROVEEDOR
M

TRABAJO

suministro

PIEZA

N:M:S

SUMINISTRO (CodProv, CodPieza, CodTrab)

N:M:1

SUMINISTRO (CodProv, CodPieza, CodTrab)

N:1:1

SUM1 (CodPieza, CodProv)

SUM2 (CodPieza, CodTrab)

Curso 2010-2011

Marta Zorrilla - UC

109

A tener en cuenta

Existen restricciones del modelo ER que

deben transformarse al modelo relacional
mediante check, asertos o disparadores









Cardinalidades mnimas en relaciones N:M y 1:N

(cuando no se controla con NOT NULL)
Cardinalidades mximas
Restringir el valor de un determinado campo
Condicin que han de cumplir los campos de una
determinada tabla
Exclusividad e inclusividad entre relaciones
Exclusividad en generalizaciones
Insertado y borrado en generalizaciones
Atributos derivados (cuando no es campo
calculado)

Curso 2010-2011

Marta Zorrilla - UC

Ej: Transformacin de restricciones

110