Diseño de Bases de Datos Diseño Lógico Estándar - xtec.cataarmeng4/c3/teoria/u2/Transformacion...
Transcript of Diseño de Bases de Datos Diseño Lógico Estándar - xtec.cataarmeng4/c3/teoria/u2/Transformacion...
Diseño de Bases de Datos Diseño Lógico Estándar
A. De Miguel y P. Martínez
1.- Etapas del diseño lógicoDiseño lógico estándarDiseño lógico específico
2.- Transformación del esquema conceptual al lógico estándar
3.- Reglas concernientes al modelo básico
4.- Reglas concernientes a las extensiones del modelo E/RTransformación de dependencias en identificación y en existenciaTransformación de interrelaciones exclusivasTransformación de tipos y subtiposTransformación de la dimensión temporalTransformación de atributos derivadosTransformación de interrelaciones de grado superior a dos
Diseño de Bases de Datos Diseño Lógico Estándar
A. De Miguel y P. Martínez
A) Diseño lógico estándar
- Elaboración del esquema lógico estándar (ELS) que se apoya en el modelo lógico estándar (MLS) -Relacional, Codasyl, Jerárquico-
- El ELS se describirá utilizando el lenguaje estándar, si existe, del modelo de datos correspondiente (v.g. el SQL92)
B) Diseño lógico específico
- Con el ELS, y teniendo en cuenta el modelo lógico específico (MLE) propio del SGBD, se elabora el esquema lógico específico (ELE), que será descrito en el LDD del producto comercial que estemos utilizand.o
Etapas del diseño lógico
Diseño de Bases de Datos Diseño Lógico Estándar
A. De Miguel y P. Martínez
REQUISITOS DE LOS
PROCESOS YEL ENTORNO
ESQUEMA CONCEPTUAL
ESQUEMA LÓGICO
ESTANDAR
ESQUEMA LÓGICO
ESPECÍFICO
Diseñológico
ESPECIFICACIONESPARA LOS PROCESOS
MODELOLÓGICO
ESTANDAR
MODELOLÓGICO
ESPECÍFICO
ENTRADAS
Etapas del diseño lógico
Diseño de Bases de Datos Diseño Lógico Estándar
A. De Miguel y P. Martínez
El paso de un esquema en el modelo E/R al relacional se basa en los principios siguientes:
• Todo tipo de entidad se convierte en una relación
• Todo tipo de interrelación N:M se transforma en una relación
• Todo tipo de interrelación 1:N da lugar:• al fenómeno de propagación de clave• a una nueva relación
La pérdida de semántica que se pueda apreciar no implica un peligro parala integridad de la base de datos, ya que se definen restricciones de integridad referencial que aseguran la conservación de la misma.
Transformación del esquema conceptual al lógico éstandar
Diseño de Bases de Datos Diseño Lógico Estándar
A. De Miguel y P. Martínez
Transformación del esquema conceptual al lógico éstandar
Ejemplo de paso del ME/R al modelo relacional
LIBRO (Código, Título, Idioma, ..., Nombre_e)
EDITORIAL (Nombre_e, Dirección, Ciudad, País)
ESCRIBE (Nombre_a, Código)
AUTOR (Nombre_a, Nacionalidad, Institución)
EDITORIAL LIBROEdita
1:N
AUTOREscribe
N:M Nombre_e Código Nombre_a
Diseño de Bases de Datos Diseño Lógico Estándar
A. De Miguel y P. Martínez
*El modelo lógico estándar admite dominios
Tipo_docu
ME/R
MRCREATE DOMAIN Tipo_Docu AS CHAR(8) CHECK (VALUE IN (‘Libros’,’Artículo’,’Otros’)) EXTENSIÓN
CREATE DOMAIN Tipo_Docu AS CHAR(8) INTENSIÓN
Reglas concernientes al modelo básico1. Transformación de Dominios
Diseño de Bases de Datos Diseño Lógico Estándar
A. De Miguel y P. Martínez
Reglas concernientes al modelo básico2. Transformación de Entidades
• El modelo lógico estándar posee el objeto RELACION o TABLA mediante el cual representamos las entidades.
• Para su definición disponemos en el SQL de la sentencia CREATE TABLE
“ Cada tipo de entidad se transforma en una relación”
Diseño de Bases de Datos Diseño Lógico Estándar
A. De Miguel y P. Martínez
Reglas concernientes al modelo básico3. Transformación de Atributos de Entidades
Un atributo de una entidad se transforma en un atributo (columna) de la relación enla cual se ha transformado la entidad; si el atributo estaba definido sobre un dominio,en el modelo relacional queda también definido sobre el mismo dominio (con la excep-ciónde los atributos multivaluados).
3.1.- Identificador principal (IP): Se transforma en la clave primaria de la relación. El lenguaje lógico estándar (SQL 92 en nuestro caso) recoge este concepto con la cláusula PRIMARY KEY.
3.2.- Identificadores alternativos (IA): Se transforman en claves alternativas en el modelo relacional. En el LLE se recoge por medio de la cláusula UNIQUE.
3.3.- Atributos obligatorios: Se transforman en una columna de la relación en la cual se ha transformado la entidad, no admitiendo valores nulos (NOT NULL).
3.4.- Atributos multivaluados: Se crea una nueva relación formada con la clave primaria de la entidad y el atributo multivaluado, siendo ambos clave primaria de la nueva relación (hay otras posibilidades.
Diseño de Bases de Datos Diseño Lógico Estándar
A. De Miguel y P. Martínez
SOCIO
Cod_socio
Nombre
Apellido
Domicilio
Teléfono
Tipo
ME/R
MR
SOCIOCod_socio Nombre Apellido Domicilio Teléfono Tipo
00001000020000300004
.
.
03456
Susana Adolfo Antonio Miguel
.
.
Elena Martín
GarcíaMartín
SánchezHidalgo
.
.
Rios Ros 22San Ben 44Ppe. Ver. 66De María 60
Goya 445
.
.
4138060413141941398657567676
.
.
9192919
IPAI
I
.
.
Clave Primaria
SOCIO (Cod_socio, Nombre, Apellido, Domicilio, Teléfono, Tipo)
Reglas concernientes al modelo básico
Ejemplo de transformación de una entidad
Diseño de Bases de Datos Diseño Lógico Estándar
A. De Miguel y P. Martínez
Reglas concernientes al modelo básico
EMPLEADO
Domicilio
Teléfono
Fecha_nac
Cod_emp
Cargo
Idioma
EMPLEADO (Cod_emp, Domicilio, Cargo, Idioma, Fecha_nac)TELEFONOS (Cod_emp, Teléfono)
admite valores nulos
Ejemplo de transformación de una entidad con atributos opcionales y multivaluados
Diseño de Bases de Datos Diseño Lógico Estándar
A. De Miguel y P. Martínez
Reglas concernientes al modelo básico4. Transformación de Interrelaciones: Interrelaciones N:M:
• Un tipo de interrelación N:M se transforma en una relación que tendrá como clave primaria la concatenación de los IP de los tipos de entidad que asocia (Hay cierta pérdida de semántica).
• Los atributos que forman la clave primaria de esta relación son clave ajena respecto a cada una de las tablas donde este atributo es clave primaria. Se especifica en el LLE con la cláusula FOREIGN KEY
• Hay que estudiar que ocurre en los casos de borrado y modificación de la clave primaria referenciada. Las opciones son:
restringido (RESTRICT) (lo toma por omisión)puesta a nulo (SET NULL)puesta a valor por defecto (SET DEFAULT)operación en cascada (CASCADE)
Diseño de Bases de Datos Diseño Lógico Estándar
A. De Miguel y P. Martínez
Reglas concernientes al modelo básico4. Transformación de Interrelaciones
AUTOR DOCUMENTO
Cod_autor
(1,N)
Escribe
N:M (0,N)
Cod_docuME/R
Transformación de una interrelación N:M
MR
ESCRIBE (Cod_autor, Cod_docu , ...)
AUTOR (Cod_autor, .........)
DOCUMENTO (Cod_docu, .........)
CREATE TABLE ESCRIBE(Cod_docu lsbns, Cod_autor Codigos_A, .............PRIMARY KEY (Cod_docu,Cod_autor)FOREIGN KEY (Cod_docu) REFERENCES DOCUMENTO
ON DELETE CASCADEON UPDATE CASCADE,
FOREIGN KEY (Cod_autor) REFERENCES AUTORON DELETE CASCADEON UPDATE CASCADE
Diseño de Bases de Datos Diseño Lógico Estándar
A. De Miguel y P. Martínez
Reglas concernientes al modelo básico4. Transformación de Interrelaciones
¿Qué ocurre con las cardinalidades mínimas de 1?¿Qué hay que controlar al insertar, borrar y modificar en AUTOR,
ESCRIBE y DOCUMENTO?
PROCEDIMIENTOS ALMACENADOS Y DISPARADORES
Ejemplo: Si insertamos en DOCUMENTO hay que insertar una tupla en ESCRIBE. Se necesita un disparador con la Transacción:
Insertar DOCUMENTOPreguntar el AUTOR del documento (Cod_autor)Si Cod_autor=NULL Abortar transacciónInsertar ESCRIBE (Cod_autor, Cod_docu)
¿y si se borra de ESCRIBE?
Diseño de Bases de Datos Diseño Lógico Estándar
A. De Miguel y P. Martínez
Reglas concernientes al modelo básico4. Transformación de Interrelaciones: Interrelaciones 1:N
A) Propagar el AIP del tipo de entidad que tiene card. máx. 1 al que tiene N.
( P érdida de s emántica ---> des aparece la interrelación )
Pertenece
(0,N) (1,1)1:N
EDITORIALLIBRO
Nombre Cod_editorial
Título Cod_libro
ME/R
MRLIBRO (Cod_libro, Título, ..., Cod_editorial)
EDITORIAL (Cod_editorial, Nombre, ...)
Diseño de Bases de Datos Diseño Lógico Estándar
A. De Miguel y P. Martínez
Reglas concernientes al modelo básico4. Transformación de Interrelaciones: Interrelaciones 1:N
LIBRO EDITORIALEdita
Título
Cod_libro
Nombre
Cod_editorialLIBRO (Cod_libro ...)
EDITORIAL (Cod_editorial, ...)
EDITA (Cod_libro ,Cod_editorial)
ME/R
MR1:N
(0,1)(1,n)
B) Transformarla en una relación, como si se tratara de una interrelación N:M
Cuando:1) El número de ocurrencias interrelacionadas de la entidad que propaga su clave es
pequeño (existen muchos valores nulos)2) Cuando se prevé que dicha interrelación, en un futuro, se convertirá en una de tipo
N:M3) Cuando la interrelación tiene atributos propios
Diseño de Bases de Datos Diseño Lógico Estándar
A. De Miguel y P. Martínez
Reglas concernientes al modelo básico4. Transformación de Interrelaciones: Interrelaciones 1:N
TEMAConsta
(0,N)
(0,1)1:N
MRSOLUCIÓN A)
TEMA (Cod_tema, ... , Cod_tema_sup)
CREATE TABLE CONSTA(Cod_Tema Codigos, Cod_Tema_Sup Codigos,PRIMARY KEY (Cod_Tema)FOREIGN KEY (Cod_Tema) REFERENCES TEMA
ON DELETE CASCADEON UPDATE CASCADE,
FOREIGN KEY (Cod_Tema_Sup) REFERENCES TEMAON DELETE CASCADEON UPDATE CASCADE
TEMA( Cod_tema...)
CONSTA( Cod_tema,Cod_tema_sup)
SOLUCION B)
Diseño de Bases de Datos Diseño Lógico Estándar
A. De Miguel y P. Martínez
Reglas concernientes al modelo básico4. Transformación de Interrelaciones: Interrelaciones 1:N
EDITORIAL
LIBRO
(1,1)
1:NEdita
(0,n)
Cod_editorial
Cod _libro
ME/R MR
EDITORIAL (Cod_editorial, .....)
LIBRO (Cod_libro, ...., Cod_editorial)
clave ajenaNOT NULL
Transformación de cardinalidades mínimas (1)
BorradoModificación
restringidocascada
Diseño de Bases de Datos Diseño Lógico Estándar
A. De Miguel y P. Martínez
Reglas concernientes al modelo básico4. Transformación de Interrelaciones: Interrelaciones 1:N
Transformación de cardinalidades mínimas (2)
EDITORIAL
LIBRO
1:NEdita
Cod_editorial
Cod _libro
EDITORIAL (Cod_editorial, .....)
LIBRO (Cod_libro, ...., Cod_editorial)
clave ajenaNOT NULL
( 1,1)
( 1,n) ?BorradoModificación
restringidocascada
Diseño de Bases de Datos Diseño Lógico Estándar
A. De Miguel y P. Martínez
Reglas concernientes al modelo básico4. Transformación de Interrelaciones: Interrelaciones 1:1
Una interrelación de tipo 1:1 es un caso particular de una N:M o de una 1:N, por lo que no hay regla fija para la transformación de este tipo de interrelación en el modelo relacional estándar. Dependiendo de :
• Las cardinalidades mínimas,• Recoger mayor semántica,• Mantener la integridad,• Evitar los valores nulos• Motivos de eficiencia• Conservar las simetrías naturales• Si la interrelación tiene atributos
Aplicaremos a) Crear una nueva relaciónb) Propagar una clavec) Propagar ambas claves{
Diseño de Bases de Datos Diseño Lógico Estándar
A. De Miguel y P. Martínez
Reglas concernientes al modelo básico4. Transformación de Interrelaciones: Interrelaciones 1:1
a) C rear una nueva relac i nó
* La clave primaria puede ser tanto Cod_hombre como Cod_mujer
HOMBRE MUJER
Matrimonio
1:1
ME/R
MR
( 1)Cod_hombre clave ajena que referencia HOMBRE, borrado y modificación en CASCADA
(2)Cod_mujer clave ajena que referencia MUJER, borrado y modificación en CASCADA
MATRIMONIO (Cod_hombre(1), Cod_mujer(2)*)
HOMBRE (Cod_hombre, ........)
MUJER(Cod_mujer, ........)nulos no permitidosClave alternativa
(0,1) (0,1)
Diseño de Bases de Datos Diseño Lógico Estándar
A. De Miguel y P. Martínez
Reglas concernientes al modelo básico4. Transformación de Interrelaciones: Interrelaciones 1:1
a) C rear una nueva relac i nó
* Esta solución puede ser conveniente si las cardinalidades mínimas de ambas entidades son cero a fin de evitar los valores nulos y conservar las simetrías naturales. También puede ser adecuada si la interrelación tiene atributos.
* Es poco eficiente en las recuperaciones que impliquen una combinación entre las tres relaciones.
Diseño de Bases de Datos Diseño Lógico Estándar
A. De Miguel y P. Martínez
Reglas concernientes al modelo básico4. Transformación de Interrelaciones: Interrelaciones 1:1
b) Propagar una c lave
EMPLEADO DEPARTAMENTO
Responsable(1,1) (0,1)
1:1
ME/R
MR EMPLEADO (Cod_E...)
DEPARTAMENTO (Cod_D,...,Cod_E)
Si una de las entidades que participa en la interrelación posee cardinalidades (1,1), mientras que en la otra son (0,1), conviene propagar la clave de la entidad con cardinalidades (1,1) a la tabla resultante de la entidad con cardinalidades (0,1)
Cod_E clave ajena referencia aEMPLEADO; borrado Restringidomodificación en Cascada
nulos no permitidosclave alternativa
Diseño de Bases de Datos Diseño Lógico Estándar
A. De Miguel y P. Martínez
Reglas concernientes al modelo básico4. Transformación de Interrelaciones: Interrelaciones 1:1
b) Propagar una c lave
* Se recoge la cardinalidad mínima 1 de EMPLEADO (con nulos no permitidos)
* Se pierden las simetrías naturales; así si se desea recuperar los datos del DEPARTAMENTO cuyo responsable es un determinado EMPLEADO (Cod_E = “x”), solo hay que hacer una operación de restricción sobre la tabla de DEPARTAMENTO. En cambio, la obtención de los datos de un EMPLEADO que es responsable de un determinado DEPARTAMENTO supone hacer una combinación entre ambas tablas.
* Se evitan valores nulos
* Es mas eficiente en ciertas recuperaciones
Diseño de Bases de Datos Diseño Lógico Estándar
A. De Miguel y P. Martínez
Reglas concernientes al modelo básico4. Transformación de Interrelaciones: Interrelaciones 1:1
c ) Propagar ambas c laves
Cod_b clave ajena que referencia B, borrado y modificación en CASCADA
Cod_a clave ajena que referencia A, borrado y modificación en CASCADA
A (Cod_a, .........,Cod_b
B (Cod_b, ..........,Cod_a)
nulos no permitidosClave alternativa
A B
I
1:1
ME/R
MR
(1,1) (1,1)
nulos no permitidosClave alternativa
No permitir modificación de claves ajenasInserción en A o en B con disparadores
Diseño de Bases de Datos Diseño Lógico Estándar
A. De Miguel y P. Martínez
Reglas concernientes al modelo básico4. Transformación de Interrelaciones: Interrelaciones 1:1
c ) Propagar ambas c laves
• Se pueden recoger las cardinalidades mínimas y mantener la integridad mediante disparadores o mediante la opción diferible.
• Se conservan simetrías.
• Eficiencia en la recuperación (menor en la actualización).
Diseño de Bases de Datos Diseño Lógico Estándar
A. De Miguel y P. Martínez
Reglas concernientes al modelo básico4. Transformación de Interrelaciones: Atributos en Interrelaciones
MRPARTICIPACIÓN (Cod_autor, cod_libro, derechos)
AUTOR (Cod_autor, .........)
LIBRO (Cod_libro, .........)
ME/R
AUTOR LIBRO
Cod_autor
(1,N)
Participación
N:M (0,N)
Cod_libro
derechos
Diseño de Bases de Datos Diseño Lógico Estándar
A. De Miguel y P. Martínez
Reglas concernientes al modelo básico4. Transformación de Interrelaciones: Atributos en Interrelaciones
EJEMPLAR ( Cod_ejem, título, ...)
SOCIO ( Cod_socio, nombre, apellidos, ...)
PRESTA ( Cod_ejem, cod_socio, Fecha_i, Fecha_f )
Ejemplo de transformación de una interrelación con atributos multivaluados
Presta
Fecha_i Fecha_f
EJEMPLAR SOCIO
(1,n) (0,n)
Diseño de Bases de Datos Diseño Lógico Estándar
A. De Miguel y P. Martínez
Reglas concernientes al modelo básico5. Transformación de restricciones sobre Dominios y Atributos
• Podemos restringir a un rango determinado los valores de un dominio por medio de la cláusula RANGE BETWEEN
• Podemos determinar por enumeración los valores que puede tomar una columna en una tabla con la cláusula IN
• Podemos expresar una condición que debe cumplir un conjunto de atributos con la cláusula CHECK
CHECK (Fecha_Ini< Fecha_Fin)
Diseño de Bases de Datos Diseño Lógico Estándar
A. De Miguel y P. Martínez
Reglas concernientes a las extensiones del Modelo E/R1. Transformación de Dependencia en Identificación
Utilizamos el mecanismo de propagación de clave
(0,N)(1,1)
1:N
LIBRO
Num_ejemplar
Cod_libroME/R
EJEMPLARID
tiene
MRLIBRO (Cod_libro , , ...)
EJEMPLAR (Cod_libro, Num_ejemplar , ...)
clave_ajenaON DELETE CASCADEON UPDATE CASCADE
Cod_ejem
Diseño de Bases de Datos Diseño Lógico Estándar
A. De Miguel y P. Martínez
Reglas concernientes a las extensiones del Modelo E/R2. Transformación de Interrelaciones exclusivas
LIBRO
(0,n)
EDITORIAL
UNIVERSIDAD
Edita1(0,1)
(0,1)Edita2
(0,n)
EDITORIAL (Cod_E.....................)
UNIVERSIDAD(Cod_U....................)
LIBRO (Cod_L......., Cod_E,Cod_U)
Cod_E clave ajena ref. EDITORIALmodificacion CASCADA/RESTRICT
Cod_U clave ajena ref. UNIVERSIDADmodificación CASCADA/RESTRICT
CHECK ((Cod_E IS NULL AND Cod_U IS NOT NULL) OR (Cod_E IS NOT NULL AND Cod_U IS NULL))
Diseño de Bases de Datos Diseño Lógico Estándar
A. De Miguel y P. Martínez
Reglas concernientes a las extensiones del Modelo E/R3. Transformación de Tipos y Subtipos
Elegiremos una estrategia u otra dependiendo de que sea la semántica o la eficiencia la que prime para el usuario en un momento determinado.
Diseño de Bases de Datos Diseño Lógico Estándar
A. De Miguel y P. Martínez
Reglas concernientes a las extensiones del Modelo E/R3. Transformación de Tipos y Subtipos
Opción A) Englobar todos los atributos de la entidad y sus subtipos en UNA SOLA RELACIÓN, cuando los subtipos se diferencien en muy pocos atributos y las interrelaciones que los asocian sean las mismas para todos los subtipos.
DOCUMENTO (Codigo …,….,…,…,Tipo_Documento)
También hay que especificar las restricciones semánticas (subtipos disjuntos):
CHECK ((Tipo_Documento = ‘ARTICULO’ AND Año_Edición IS NULL AND Codigo_Editorial IS NULL)
OR (Tipo_documento = ‘LIBRO’ AND Código_Revista IS NULL AND Fecha_publicación IS NULL))
Diseño de Bases de Datos Diseño Lógico Estándar
A. De Miguel y P. Martínez
Reglas concernientes a las extensiones del Modelo E/R3. Transformación de Tipos y Subtipos
Opción A)
• El atributo discriminante de la jerarquía podrá admitir valores nulos en el caso de que la jerarquía sea parcial y deberá declararse como NOT NULL si la jerarquía es total.
• Por otra parte, el atributo discriminante constituirá un grupo repetitivo si los subtipos solapan, (debiendo, por tanto, separar este atributo en una relación aparte y crear una relación que asocie este atributo con la relación resultante del supertipo). También es posible modificar el check anterior.
• Más eficiente.• Poca semántica• Muchos nulos si hay exclusividad
Diseño de Bases de Datos Diseño Lógico Estándar
A. De Miguel y P. Martínez
Reglas concernientes a las extensiones del Modelo E/R3. Transformación de Tipos y Subtipos
Opción B) Crear una relación para el supertipo y tantas relaciones como subtipos haya, con sus atributos correspondientes. Esta es la solución cuando existen muchos atributos distintos entre los subtipos y se quieren mantener los atributos comunes a todos ellos en una relación.
• Mayor semántica• Más ineficiente• Parcialidad/Totalidad controlada con el atributo discriminante• Exclusividad/Solapamiento controladas mediante una Aserción
Diseño de Bases de Datos Diseño Lógico Estándar
A. De Miguel y P. Martínez
Reglas concernientes a las extensiones del Modelo E/R3. Transformación de Tipos y Subtipos
Opción C) Considerar relaciones distintas para cada subtipo, que contengan además los
atributos comunes. Se elegiría esta opción cuando se dieran las mismas condiciones que en el caso anterior - muchos atributos distintos - y los accesos realizados sobre
los datos de los distintos supertipos siempre afectan a los atributos comunes.
• Más eficiente en las consultas a atributos de subtipos• Menos eficiente en las consultas al supertipo• Poca semántica• Introducimos redundancias• Parcialidad no admitida y Totalidad si.• Exclusividad controlada mediante un check
Diseño de Bases de Datos Diseño Lógico Estándar
A. De Miguel y P. Martínez
ME/R
DOCUMENTO
es_un
LIBRO
(1,1)
(0,1) (0,1)
ARTÍCULO
TIPO
a. DOCUMENTO (código, título, idioma, ...... tipo)
b. DOCUMENTO (código, título, idioma, ...tipo)
ARTÍCULO (código, ...)
LIBRO (código, ...)
c. LIBRO (código, título, idioma, ...)
ARTÍCULO (código, título, idioma, ...)
MR
Reglas concernientes a las extensiones del Modelo E/R3. Transformación de Tipos y Subtipos
Diseño de Bases de Datos Diseño Lógico Estándar
A. De Miguel y P. Martínez
Reglas concernientes a las extensiones del Modelo E/R4. Transformación de la dimensión temporal (!!cuidado¡¡)
DISFRUTA (cod_C, f_inicio, cod_H, f_fin)
CLIENTE (cod_C, .........................)
HOTEL (cod_H, .........................)
HOTEL CLIENTE
(0,N) (0,N)
disfruta
N:M
f_inicio f_fin
cod_H cod_C
ME/R
MR
Diseño de Bases de Datos Diseño Lógico Estándar
A. De Miguel y P. Martínez
Reglas concernientes a las extensiones del Modelo E/R5. Transformación de atributos derivados
IDtieneEJEMPLAR
(1,n) (1,1)LIBRO
Código
Tïtulo
N_ejemplaresD1
1:N
ME/R
MR
LIBRO (código, título, N_ejemplares)
Comprobación: check o aserción (atributo con redundancia controlada)Cálculo: disparador en inserción y modificación (atributo derivado)
Diseño de Bases de Datos Diseño Lógico Estándar
A. De Miguel y P. Martínez
NOMBRE_E DIRECCIÓN CIUDAD PAÍSeditorial
COD_DOC TÍTULO IDIOMA NUM_COPIAS NOMBRE_E _ _ libro
COD_DOC IDENTIFICATIVO COD_DOC NOMBRE_T NOMBRE_Tejemplar tratatema
constaCOD_DOC NUM_SFECHA_PIDENTIFICATIVO FECHA_Spresta consta
socio DOMICILIO TELNUM_S DNI TIPO_S
TEMA_ S TEMA__P
Reglas concernientes a las extensiones del Modelo E/RGrafo Relacional
Diseño de Bases de Datos Diseño Lógico Estándar
A. De Miguel y P. Martínez
Reglas concernientes a las extensiones del Modelo E/R6. Transformación de interrelaciones de grado superior a dos
Regla general:
C_A Atr_A
C_C Atr_C
C_B Atr_B
I
A B
C
Atr_I
A ( C_A, Atr_A ............)
B ( C_B, Atr_B..............)
C ( C_C, Atr_C..............)
I (C_A, C_B, C_C, Atr_I)
Diseño de Bases de Datos Diseño Lógico Estándar
A. De Miguel y P. Martínez
Reglas concernientes a las extensiones del Modelo E/R6. Transformación de interrelaciones de grado superior a dos
Análisis más refinado:
A) Cardinalidad máx. N y min. 1
I
A B
C
(1,n) (1,n)
(1,n)
Sería aplicable la regla general. Claves ajenas con borrado y modificación en cascada
C_A C_B
C_C
Atri_a
Atri_c
Atri_b
Diseño de Bases de Datos Diseño Lógico Estándar
A. De Miguel y P. Martínez
Reglas concernientes a las extensiones del Modelo E/R6. Transformación de interrelaciones de grado superior a dos
Análisis más refinado:B) Cardinalidad máx. N y min. 0
I
A B
C
(1,n) (1,n)
(o,n)
I1
Sería aplicable la regla general, pero en la relación I, no aparecerían las ocurrencias interrelacionadas de A y B que tuvieran ocurrencias de C (la clave no admitenulos) y podría ser conveniente crear una interrelación I1 entre A y B (puntos en la figura)
C_A C_B
C_C
Atri_a
Atri_c
Atri_b
Diseño de Bases de Datos Diseño Lógico Estándar
A. De Miguel y P. Martínez
Reglas concernientes a las extensiones del Modelo E/R6. Transformación de interrelaciones de grado superior a dos
Análisis más refinado:C) Cardinalidad máx. N y min. 0 en dos de las interrelaciones
I
A B
C
(0,n) (0,n)
(1,n)
Regla general e interrelaciones binarias
C_A C_B
C_C
Diseño de Bases de Datos Diseño Lógico Estándar
A. De Miguel y P. Martínez
Reglas concernientes a las extensiones del Modelo E/R6. Transformación de interrelaciones de grado superior a dos
Análisis más refinado:D) Cardinalidad máx. N en dos interrelaciones y 1 en la otra
I
A B
C
(1,n) (1,n)
(0,1)
I ( C_A, C_B, C_C , Atr_I)
NULL NOT NULLC_C
C_A C_B
C_C
Diseño de Bases de Datos Diseño Lógico Estándar
A. De Miguel y P. Martínez
Reglas concernientes a las extensiones del Modelo E/R6. Transformación de interrelaciones de grado superior a dos
Análisis más refinado:
E) Cardinalidad máx. N en una interrelacion y 1 en las otras dos
I
A B
C
(1,1) (1,1)
(0,n)
A B
C
I1I2
C_A C_B
C_C
C_A C_B
C_C
Sólo si existe alguna restricción adicional entre
las entidades