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



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



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



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



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



*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



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”



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.



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



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



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)



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



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?



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, ...)




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




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)




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




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



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{




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)




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.




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




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




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




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



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



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)



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)



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



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



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.




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




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




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




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



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/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



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)



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



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)




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




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




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




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




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

Diseño de Bases de Datos Diseño Lógico Estándar - xtec.cataarmeng4/c3/teoria/u2/Transformacion...

Documents

Transcript of Diseño de Bases de Datos Diseño Lógico Estándar - xtec.cataarmeng4/c3/teoria/u2/Transformacion...