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.
Anlisis de requisitos. Especificacin funcional

Diseo conceptual: traduccin del anlisis de requisitos al esquema conceptual. Representacin generalmente grfica de las entidades y sus relaciones.
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

ER, ORM UML

Esquema de datos

Herramientas CASE

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

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 0..N 1..N stars 1..N STAR addr

Name phones street city

owns

1..1 STUDIO Name address

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

10

Clasificacin de herramientas CASE

Se pueden clasificar atendiendo a:
Las fases del ciclo de vida del desarrollo de sistemas que cubren Su funcionalidad

Curso 2010-2011

Marta Zorrilla - UC

11

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.

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

13

Componentes
Repositorio o diccionario de datos
Almacn de los elementos definidos

Mdulo diagramtico
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

Curso 2010-2011

Marta Zorrilla - UC

14

Productos ms utilizados
ERWin PowerDesigner (Sybase) EasyCASE Oracle designer (Discoverer) Visio (Microsoft)

Curso 2010-2011

Marta Zorrilla - UC

15

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

Curso 2010-2011

Marta Zorrilla - UC

16

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.

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
Modelo bsico versus modelo extendido

Relaciones n-arias Extensiones del modelo

Generalizacin y especializacin Restricciones entre relaciones Agregacin

Elementos estticos
Entidades Relaciones Dominios y valores Atributos

Notacin E/R vs. UML Ejemplos

Restricciones
Identificadores Cardinalidades de atributos Cardinalidades de relaciones

Curso 2010-2011

Marta Zorrilla - UC

19

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

Curso 2010-2011

Marta Zorrilla - UC

20

Elementos estticos
Entidad (entity)
Objeto que existe y se distingue de los dems. Pueden ser concretos
P. ej.: un libro, una persona,..

O abstractas
P.ej.: prstamo, pedido,

Atributo (attribute)
Propiedades que caracterizan a las entidades. Clave primaria: atributos que identifican a la entidad
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
(0:1)

EMPLEADO
(0:m)

AUTOR
(1:n)

preside
(1:1)

1:1

trabaja

1:m

escribe

n:m

(1:1)

(1:m)

PRESIDENTE

DPTO

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 constituye N:M Forma parte de

Curso 2010-2011

Marta Zorrilla - UC

24

Relaciones
ISBN

LIBRO
1:1
ID

EMPLEADO
1:1

NRP

tiene
0:N 0:N

tiene

EJEMPLARES

estado numcopia

HIJOS

DNI

Dependencia de identificacin

Dependencia de existencia

Curso 2010-2011

Marta Zorrilla - UC

25

Atributos y claves
PERSONA IDPersona Nombre Fecha nacimiento Edad DNI Profesin Telfonos Identificador

Direccin Calle CP Localidad Atributo compuesto

Atributo derivado Clave candidata Admite nulos Multivaluado

MUJER
1:1

ALUMNO Fecha Curso acad.

n:m matricula

matrimonio HOMBRE

ASIGNATURA

Curso 2010-2011

Marta Zorrilla - UC

26

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)

Curso 2010-2011

Marta Zorrilla - UC

27

Prstamos de la biblioteca
SOCIO
(0,n)

CodSocio nombre dni SEDE Biblio.

(1:1)

CodSed nombre localidad

prestar

FechaAlta FechaPrevistaDev FechaDev

(0:n) (0:n)
ID

ubicado publicado
(0:n)

(1:1) EDITORIAL

(0,n)

(1:1)

LIBRO
(0:n) (0:n)

EJEMPLAR numEjemplar

en

titulo Codlib fecha ISBN

en
(1:1)

IDEdit nombre

Estado

escrito
(1:n)

IDIOMA IDAutor nombre Apellido_1

IDIdioma nombre

AUTORES

Curso 2010-2011

Marta Zorrilla - UC

28

Prstamos de la biblioteca
SOCIO
(1:1)

CodSocio nombre dni SEDE Biblio.

(1:1)

CodSed nombre localidad

a
(0:n)

PRESTAMO
(0:n)

NumPrest FechaAlta FechaPrevistaDev FechaDev

(0:n) (0:n)
ID

ubicado publicado
(0:n)

(1:1) EDITORIAL

de un
(1:1) (1:1)

LIBRO
(0:n) (0:n)

EJEMPLAR numEjemplar

en

titulo Codlib fecha ISBN

en
(1:1)

IDEdit nombre

Estado

escrito
(1:n)

IDIOMA IDAutor nombre Apellido_1

IDIdioma nombre

AUTORES

Curso 2010-2011

Marta Zorrilla - UC

30

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.

Curso 2010-2011

Marta Zorrilla - UC

31

Gestin docente
ASIGNATURA
(1:1)
ID

(1:1- dia - hora) (0:n)

da ocupa

(1:n)

CodAsig
Nombre Crditos Carcter Curso

hora

AULA

Nro

(1:1)

PROFESOR
(0:n) (1:1)

tiene
(0:n)

NroPersonal nombre Apellido_1

imparte

GRUPO
(1:n)

pertenece Max-alum CodGrupo

(1:1) (0:1)

dirige

DPTO Calificacin consta

(0:n)

CodDpto nombre

Convocatoria (1..2)
(0:n)

MATRICULA

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

33

Relaciones n-arias
(0:n)

(sin redundancia)
(0:n)

PROVEEDOR Puede intervenir

(1:n) (0:n)

precio Puede suministrar

(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 NroPersona nombre Apellido_1

Calificacin crediticia

CLIENTE

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

35

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.

Curso 2010-2011

Marta Zorrilla - UC

36

Generalizacin y especializacin
PERSONA (t,e) Total exclusiva MUJER PERSONA Total con solapamiento ESTUDIANTE

(t,s) EMPLEADO

HOMBRE

PERSONA (p,e) Parcial exclusiva

EMPLEADO Parcial con solapamiento INVESTIGADOR

(p,s) DOCENTE

DIRECTOR ADMINISTRATIVO

Curso 2010-2011

Marta Zorrilla - UC

37

Restriccin de exclusividad

percibe PERSONA Est en

BECA

CONTRATO

La persona o percibe una beca o est contratado

Curso 2010-2011

Marta Zorrilla - UC

38

Restriccin de exclusin

imparte PERSONA recibe CURSO

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 PERSONA hacen

IDIOMA

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 opera HOSPITAL

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 COCHE

(1:1)

(1:1)

(4:4)

CHASIS

MOTOR

RUEDA

FLOTA

(1:n)

BARCO

Ordenado por num_barco

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

PRUEBA

Codpru nombre tipo

1:n

atendido

fecha hora nrp especialidad

MEDICO

Curso 2010-2011

Marta Zorrilla - UC

44

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.

Curso 2010-2011

Marta Zorrilla - UC

45

Evitar las redundancias (y 2)

Curso 2010-2011

Marta Zorrilla - UC

46

Hay problema de redundancia?

1:n

PROFESOR
1:n

1:n

investiga Imparte

Participa

1:n

1:n 1:n

1:n

1:n

TEMA

Consta

1:n

CURSO

Curso 2010-2011

Marta Zorrilla - UC

49

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

Curso 2010-2011

Marta Zorrilla - UC

50

Gestin de compras
(1:1)

PROVEEDOR

suministra

CodProv nombre tfno c/c

Direccin

(0:n)

(1:1)

Con/del FechaPed NumPed FechaEntrega Estado Importe pedido precioCompra unidades descuento iva numLinea
(0:n)

Calle CP Localidad NumPago FechaPago Tipo pago Concepto c/c cantidad

PEDIDO
(0:n)

PAGO

consta

(1:n)

ARTICULO

Codart nombre precioUd iva

Curso 2010-2011

Marta Zorrilla - UC

51

Generalizacin del tipo de pago

PAGO
(1:1)

NumPago FechaPago Concepto cantidad

DISCRIMINANTE

Tipo pago (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

60

Tabla de contenidos
Elementos bsicos
Dominios y atributos Definicin de relacin Clases de relaciones

Restricciones de integridad
Inherentes Definidas por el usuario

Valores nulos Esquemas relacionales SGBD relacionales

Curso 2010-2011

Marta Zorrilla - UC

61

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.

Curso 2010-2011

Marta Zorrilla - UC

62

Elementos bsicos
RELACIN
Es la estructura bsica del modelo relacional. Se representa mediante una tabla.

DOMINIO
Es el conjunto vlido de valores que toma un atributo. Existen con independencia de cualquier otro elemento.

ATRIBUTO
Representa las propiedades de la relacin. Se representa mediante una columna.

TUPLA
Es una ocurrencia de la relacin. Se representa mediante una fila.

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 Carmen Ana Pedro Marie calle Calvo Sotelo Castellana Torres Quevedo Eliseos cliente ciudad Santander Madrid Logroo Pars

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):
das de la semana = {lunes, martes, mircoles, sbado, domingo}

Intensin (mediante un tipo de datos):

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

65

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.

Curso 2010-2011

Marta Zorrilla - UC

66

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.

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

Marta Zorrilla - UC

68

Ejemplo

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 Temporales

Base (definidas por el usuario y del sistema) Vistas Vistas materializables Definidas por el usuario Vistas temporales Vistas materializables temp.

Sin nombre

Temporales

Resultado de una consulta (intermedio o final)

Curso 2010-2011

Marta Zorrilla - UC

70

Terminologa

!CUIDADO!, una relacin no es una tabla. Ni una tabla es un fichero. Existen diferencias entre los conceptos.

Curso 2010-2011

Marta Zorrilla - UC

71

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

Curso 2010-2011

Marta Zorrilla - UC

72

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.

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

74

Clave (key)

(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

75

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

Curso 2010-2011

Marta Zorrilla - UC

76

Restricciones semnticas
Clave Primaria (PRIMARY KEY):

(y 2)

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):
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

77

Restricciones semnticas: Foreign key

Integridad Referencial (FOREING KEY):
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.

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

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.

Curso 2010-2011

Marta Zorrilla - UC

78

Ejemplo
BANCOS
ENTIDAD 0893 0059 3428 5632 NOMBRE Santander Popular Bilbao Vizcaya Banesto

OFICINAS
ENTIDAD 0893 3428 0893 5632 0893 CODIGO_OFICINA 001 022 022 213 300 POBLACION Madrid Las Palmas Gldar Oviedo Barcelona DIRECCION Castellana, 73 Triana, 21 R. Moreno, 3 Ura, 43 Diagonal, 435

Curso 2010-2011

Marta Zorrilla - UC

79

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.

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

81

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.

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 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 where CE.nrp = CT.nrp and

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

85

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(*)

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

88

Gestores relacionales (MR vs ANSI)

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

Gestin docente
(0:n)

Curso 2010-2011

Marta Zorrilla - UC

clase CodAsig

da hora
(1:n)

95

(1:1)

AULAS

CodAula capacidad

ASIGNATURA
(1:1)
ID

Nombre Crditos Carcter Curso

(1:1)

tiene
(0:n)

imparte

PROFESOR
(0:n) (1:1)

NroPersonal nombre Apellido_1

GRUPO
(1:n)

Max-alum CodGrupo Calificacin pertenece

(1:1)

dirige
(0:1)

consta
(0:n)

DPTO

Convocatoria (1..2)
(0:n)

CodDpto nombre

MATRICULA

CursoAcad CodMatr

realiza

(1:1)

ALUMNOS

CodAlu nombre dni

Curso 2010-2011

Marta Zorrilla - UC

96

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)

Curso 2010-2011

Marta Zorrilla - UC

97

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)

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) Dpto (CodDpto, nombre) Matricula (CodMatr, cursoacad) Grupo (CodAsig, CodGrp, max_alum)
Grupo (CodAsig,CodGrp,max_alum,NroPersonal) Profesor (NroPersonal, nombre, apellido1, CodDpto)

Profesor (NroPersonal, nombre, apellido1) Dpto (CodDpto, nombre, CodProfDirige) Matricula (CodMatr, cursoacad,CodAlu)

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 CodProfDirige not null CodDpto not null

Dpto (CodDpto, nombre, CodProfDirige) Alumno (CodAlu, nombre, dni) Matricula (CodMatr, cursoacad, CodAlu)
U:C D:C

U:C D:No action

Profesor (NroPersonal, nombre, apellido1, CodDpto)

U:C D:No action CodAlu not null

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

U:C D:Not action

Grupo (CodAsig, CodGrupo, max_alum, NroPersonal)

U:C D:C

U:C D:Not action NroPersonal not null

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

U:C D:Not action

U:C D:Set null

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

CREATE ASSERTION maxAlumAula CREATEASSERTION dirige_dpto AS CHECK not ASSERTION convocatorias CREATE not exists ( select count(*) from CLASEexists a,GRUPO g CHECK c,AULA CHECK not exists ( select count(*) from CONSTA (SELECT * FROM Dpto WHERE CodProfDirige NOT IN where group by Codmatr,CodAsig,CodGrp c.codAula=a.CodAula and c.CodAsig=g.CodAsig and (SELECT NroPersonal having count(*)>2) FROM Profesor where 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 maternidad

hijo

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

OFICINA(codElem, actividad , Coef, cc) VIVIENDA (codElem, numHab , Coef, cc)

(t,e)

Crear un sola relacin

local oficina vivienda tipo comercio horario N hab. actividad

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 Codpru nombre tipo

1:1
atendido

1:n
MEDICO nrp especialidad

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

Curso 2010-2011

Marta Zorrilla - UC

106

Agregacin
COCHE

(1:1)

(1:1)

(4:4)

CHASIS

MOTOR

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 S N

TRABAJO

suministro

PIEZA

N:M:S N:M:1 N:1:1

SUMINISTRO (CodProv, CodPieza, CodTrab) SUMINISTRO (CodProv, CodPieza, CodTrab) 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

110

Ej: Transformacin de restricciones