Tema 4. DISEÑO LÓGICO Objetivos

Presentación del tema: "Tema 4. DISEÑO LÓGICO Objetivos"— Transcripción de la presentación:

1 Tema 4. DISEÑO LÓGICO Objetivos
Comprender la conveniencia y ventajas de disponer de un esquema lógico de BD independiente de un SGBD particular Conocer las reglas de transformación de un esquema conceptual en el MERE en un esquema lógico en el MR Conocer cómo evitar la posible pérdida de semántica al traducir elementos del MERE a elementos del MR Conocer estrategias de elección de la opción de diseño lógico más adecuada entre varias alternativas posibles Conocer guías y recomendaciones para trasladar un esquema en el MR a un esquema en el modelo de datos específico soportado por el SGBD de implementación

2 DISEÑO LÓGICO..a grandes rasgos
Transformación Esquema Conceptual  Esquema Lógico de Datos El objetivo del diseño lógico es convertir los esquemas conceptuales en un esquema lógico que se ajuste al modelo de SGBD sobre el que se vaya a implementar el sistema. Ya que aquí se trata el diseño de bases de datos relacionales, en esta etapa se obtiene un conjunto de relaciones (tablas) que representen los datos de interés. Este conjunto de relaciones se valida mediante la normalización, técnica que se estudia en el próximo tema.

3 DISEÑO LÓGICO Mientras que el objetivo fundamental del diseño conceptual es completitud y la expresividad de los esquemas conceptuales, el objetivo del diseño lógico es obtener una representación que use, del modo más eficiente posible, los recursos que el modelo de SGBD posee para estructurar los datos y para modelar las restricciones.

4 Esquema Conceptual  Esquema Lógico de Datos
DISEÑO LÓGICO Transformación Esquema Conceptual  Esquema Lógico de Datos Objetivos del Diseño lógico: Eliminar redundancias, conseguir máxima simplicidad, evitar cargas suplementarias de programación, ... Conseguir una estructura lógica adecuada, un equilibrio entre requisitos de usuario y eficiencia de implementación, ... PORTABILIDAD Introducción de exigencias del SGBD específico lo más tarde posible. Implementación del diseño lógico sobre diferentes SGBD Migración entre versiones de un mismo SGBD

5 ETAPAS del DISEÑO LÓGICO
Diseño Lógico Estándar (DLS) Se elige el modelo de datos de representación, no el SGBD Transformación independiente del SGBD específico y otras consideraciones físicas Esquema Conceptual  Esquema Lógico Estándar (ELS) Uso de un Modelo Lógico de datos eStándar (MLS) Relacional, Red, Jerárquico, Orientado a Objetos Se elige el MODELO DE DATOS, no el SGBD concreto ELS descrito mediante lenguaje estándar del modelo de datos SQL-92 en el Modelo Relacional Diagrama de Estructura de Datos

6 ETAPAS del DISEÑO LÓGICO
Diseño Lógico Específico (DLE) Se elige el SGBD específico Adaptación del Esquema de la BD a un SGBD concreto (comercial) Esquema Lógico Estándar  Esquema Lógico Específico (ELE) Uso del Modelo Lógico propio del SGBD elegido Informix, Oracle, DB2, Interbase,... ELE descrito mediante lenguaje DDL del SGBD específico

7 DISEÑO LÓGICO ESTÁNDAR (DLS)
Reglas para el modelo básico Dominios Atributos Tipos de entidad  Relación Tipos de relación N:M  Relación 1:1;1:N;N:1  ¿relación o propagación? Reglas para extensiones del modelo Relaciones exclusivas Jerarquías de G/E Pérdida de Semántica en la Transformación del EC al ELS Tanto las entidades como las interrelaciones en un diagrama ER se transforman en relaciones. El esquema lógico estándar representa ambos tipos de objetos (entidad, interrelación) de la misma forma (relación), y no es posible saber si una relación (en el ELS) proviene de un objeto de uno u otro tipo (en el EC), salvo que se anote en la documentación asociada al proceso de transformación, o bien al esquema lógico estándar. Además, en la “Propagación de clave” el nombre de la interrelación “desaparece”, lo cual también supone la consiguiente pérdida de semántica. Pero estas pérdidas de semántica NO implican pérdida de integridad, puesto que ésta queda asegurada mediante las correspondientes y adecuadas Reglas (restricciones) de Integridad.

8 DISEÑO LÓGICO ESTÁNDAR (DLS)
 Pérdida de semántica !! ¿de donde proviene una relación? desaparición de relaciones Cod_libro M N LIBRO escribe AUTOR Cod_Autor (0,m) (0,n) Esquema relacional: (0,n) N AUTOR(cod_autor, … ) LIBRO(cod_libro, …, cod_editorial,… ) EDITORIAL(cod_editorial, … ) ESCRIBE(cod_autor, cod_libro, … ) edita 1 (1,1) FK FK Pérdida de Semántica en la Transformación del EC al ELS Tanto las entidades como las interrelaciones en un diagrama ER se transforman en relaciones. El esquema lógico estándar representa ambos tipos de objetos (entidad, interrelación) de la misma forma (relación), y no es posible saber si una relación (en el ELS) proviene de un objeto de uno u otro tipo (en el EC), salvo que se anote en la documentación asociada al proceso de transformación, o bien al esquema lógico estándar. Además, en la “Propagación de clave” el nombre de la interrelación “desaparece”, lo cual también supone la consiguiente pérdida de semántica. Pero estas pérdidas de semántica NO implican pérdida de integridad, puesto que ésta queda asegurada mediante las correspondientes y adecuadas Reglas (restricciones) de Integridad. EDITORIAL FK Cod_Editorial Solución: Anotarlo en la documentación; reglas de integridad

9 DLS: Dominios Transformación directa: El modelo relacional admite dominios aunque no disponibles en la mayor parte de las implementaciones comerciales. DOMINIOS El modelo relacional estándar admite los dominios como un elemento más del esquema (además de las relaciones y restricciones generales), aunque la mayoría de las implementaciones comerciales no incluyen soporte para los dominios. ENTIDADES (*No explicar nada acerca de los atributos ni de las claves, pues ya se verá después.*)

10 DLS: Entidades regulares
Cada atributo simple  Atributo de R Identificador principal  Clave primaria de R (cláusula PRIMARY KEY) Identificador alternativo  Clave alterna de R (cláusula UNIQUE + NOT NULL ) DOMINIOS El modelo relacional estándar admite los dominios como un elemento más del esquema (además de las relaciones y restricciones generales), aunque la mayoría de las implementaciones comerciales no incluyen soporte para los dominios. ENTIDADES (*No explicar nada acerca de los atributos ni de las claves, pues ya se verá después.*)

11 DLS: Atributos compuestos
A) “Eliminar” atributo compuesto y considerar todos sus componentes como atributos simples dni PERSONA fechaNac nombre calle ciudad provincia PERSONA fechaNac dni dirección nombre calle ciudad provincia PERSONA fechaNac dni dirección nombre ATRIBUTO COMPUESTO (a) Si un atributo de una entidad E, está formado por tres componentes, la relación R correspondiente tendrá 3 atributos simples, cada uno proveniente de un componente. (b) El valor del atributo será la concatenación de los valores de los componentes. Si es necesario acceder a los componentes de forma individual, será la aplicación (el programador) la que realice la “partición” para obtener los valores de cada componente a partir del valor del atributo. Otra opción sería especificar que el atributo de R toma valores en un dominio compuesto, por ejemplo el atributo fechaNacimiento declarado sobre el dominio DATE, compuesto a su vez por YEAR, MONTH, DAY. B) “Eliminar” los componentes y considerar el atributo compuesto como un único atributo

12 DLS: Atributos multivaluados de entidades
Atributo Multivaluado de E Nueva Relación S, en la que el atributo multivaluado se representa como un atributo simple A S contendrá, un atributo F, clave ajena a la clave primaria de R Clave Primaria de S = (F,A) | A PERSONA fechaNac dni dirección (1,n) nombre PERSONA fechaNac dni nombre PERSONA(dni, nombre, fechaNac) DIRECCION_PERSONA(dni, dirección) Si la clave primaria de la relación R correspondiente a la entidad E, era compuesta (varios atributos), todos ellos (como atributos simples) pasan a la nueva relación S (correspondiente al atributo multivaluado), y todos ellos forman la clave ajena a la clave primaria de R DIRECCION PERSONA dni dirección FK ¡¡ cardinalidades max y min !!

13 DLS: Atributos derivados
Es necesario decidir si se almacena o no Si se almacena, será un atributo de la relación que corresponda y deberá crearse un disparador que calcule su valor y lo mantenga actualizado Si no se almacena, deberá crearse un procedimiento que calcule su valor cada vez que se solicite

14 DLS: Interrelaciones Binarias 1:1
I R (a) Participación TOTAL de ambos tipos de entidad ÚNICA RELACIÓN R. Cuando... Los tipos de entidad NO participan en otros tipos de interrelación Propagación de claves en una u otra dirección (indiferente) Clave Primaria de R = clave primaria de R1 o de R2 (*si son distintas*) La otra será clave alternativa (NOT NULL UNIQUE) Atributos simples de IR o componentes simples de atributos compuestos, también se incluyen como atributos de la relación R E1 E2 R1 R2 codCli En el caso de que en ambas entidades las claves primarias sean equivalentes (como ocurre en el ejemplo del cliente y su información de envío), sólo se mantiene una de ellas en la relación resultado, pues la otra no es necesaria. codCli INFORMACION CLIENTE (1,1) ENVIO numCasa (1,1) nomCli cp calle CLIENTE( codCli, nomCli, numCasa, calle, cp, ...)

15 DLS: Interrelaciones 1:1 (2)
(b) Una entidad con participación TOTAL y otra con PARCIAL (b.1) PROPAGACIÓN DE CLAVE. Cuando... La clave de la entidad con participación parcial “se propaga” hacia la entidad con participación total Un empleado de una empresa puede ser el gerente de un (único) departamento (desde cierta fecha, en la que fue nombrado como tal), o bien no dirigir ninguno. codEmp numDep EMPLEADO DIRIGE DEPARTAMENTO (1,1) (0,1) La clave de la entidad EMPLEADO (con participación parcial) se propaga, para conseguir “captar” la semántica de la cardinalidad mínima 1 de DEPARTAMENTO. Si se propagara en el otro sentido (es decir, si cada empleado contuviera el numero del departamento que dirige) no se recogería tal semántica (podrían existir departamentos sin gerente asignado) y además, se producirían muchos valores nulos (empleados que NO dirigen departamentos), tal y como se muestra a continuación: EMPLEADO DEPARTAMENTO codEmp numDepDir (UNIQUE) fechaInicDir numDep nomDep 20 NULL (#) NULL 1 Compras /08/ Contabilidad (*) 35 NULL (#) NULL 3 Informática /07/79 (#) Empleado NO director (NULOS) (*) Departamento sin Gerente (cardMin = 0) Esta sería la transformación correcta: EMPLEADO DEPARTAMENTO codEmp numDep nomDep codDirector(+) fechaInicDir 1 1 Compras /07/79 Informática /08/72 15 (+) Debe ser NOT NULL (cardMin(DEPARTAMENTO, DIRIGE)=1) y UNIQUE (cardMax(DEPARTAMENTO, DIRIGE)=1) OJO: La cardinalidad máxima 1 para la entidad DEPARTAMENTO, NO se asegura haciendo PK(numDep,codDirector), pues de este modo, un empleado podría dirigir varios departamentos, o un departamento podría tener varios gerentes (aunque la combinación de los dos valores sí es un valor único). Este problema se ve claramente en el siguiente ejemplo: DEPARTAMENTO numDep codDirector nomDep 1 15 Compras 2 15 Contabilidad ·Empleado 15 dirige DOS departamentosUNIQUE(codDirector) 2 10 Contabilidad ·Departamento 2 tiene DOS gerentes  PK(numDep) 3 10 Informática nomEmp nomDep fechaInic EMPLEADO(codEmp, nomEmp, ...) DEPARTAMENTO(numDep, nomDep, codDirector, fechaInicDir...) FK (NOT NULL, UNIQUE)

16 DLS:Interrelaciones 1:1 (3)
(b) Una entidad con participación TOTAL y otra con participación PARCIAL (b.2) NUEVA RELACIÓN R. Cuando... Hay pocas instancias del tipo de Interrelación IR Atributos de R: claves primarias de R1 y de R2 son claves ajenas (a la clave primaria de R1 y de R2, respectivamente) son claves candidatas en R » uno de ellos será la Clave Primaria de R (la de participación total, si existe) » el otro será Clave Alternativa de R (NOT NULL, UNIQUE) atributos simples (o componentes simples de atributos compuestos) de IR Evita NULOS en los atributos propagados EMPLEADO(codEmp, nomEmp, ...) DIRIGE(codEmp, numDep, fechaInic) DEPARTAMENTO(numDep, nomDep,...) Participación ¿Total? FK FK

17 DLS: Interrelaciones 1:1 (4)
(b) Una entidad con participación TOTAL y otra con participación PARCIAL (b.3) Muchas instancias del tipo de relación: ÚNICA RELACIÓN. Atributos: todos (los de los tipos entidad e interrelación) Clave Primaria: la de la entidad con participación PARCIAL (EMPLEADO) Debe permitirse NULOS en los atributos propagados (empleados NO directores) desde la entidad con participación TOTAL y desde la interrelación CREATE TABLE EMPLEADO ( codEmp códigos PRIMARY KEY, nomEmp nombres, ..., numDepDir códigos UNIQUE,NULL nomDepDir nombres, NULL fechaInicDir fechas, NULL ...) EMPLEADO codEmp nomEmp ...numDepDir nomDepDir ... fechaInicDir 20 Juárez NULL NULL NULL 10 Gómez Informatica /08/72 35 Anarca NULL NULL NULL 15 Santos Compras /07/79 El atributo numDepDir (departamento del cual el empleado es el director, no es el departamento al que pertenece ese empleado) debe ser UNIQUE, para que cardMax(DEPARTAMENTO,DIRIGE)=1.

18 DLS: Interrelaciones 1:1 (y 5)
(c) Ambos tipos entidad con participación PARCIAL NUEVA RELACIÓN R. R se construye exactamente igual que en el caso (b.2) Evita los valores nulos que aparecerían si se propagara la clave de R1 a R2 o viceversa (caso (b.1)) lugar nif nif HOMBRE MATRIMONIO MUJER (0,1) (0,1) fecha El atributo nifEsposo (correspondiente a la PK de la otra relación debe ser UNIQUE y NOT NULL. HOMBRE(nif, ...) MATRIMONIO(nifEsposa, nifEsposo, fecha, lugar) MUJER(nif, ...) FK (NOT NULL UNIQUE) FK

19 DLS: Interrelaciones 1:N
Interrelaciones Binarias 1:N (a) PROPAGACIÓN DE CLAVE En R2 se incluyen nuevos atributos para contener valores de... clave primaria de R1 Clave ajena en R2 hacia R1 (ojo con acciones disparadas por Integridad Referencial) atributos simples (o componentes simples de atributos compuestos) de IR (a.1) Card(E2)=(1,1) -- Participación TOTAL u obligatoria de E2 en IR E1 E2 IR R1 R2 1 N codProv PROVINCIA CIUDAD nombreCiudad 1 N ESTA_EN (1,1) (0,n) nomProv PROVINCIA(codProv, nomProv, ...) CIUDAD(nomCiudad, codProv, ...) FK: NULOS NO PERMITIDOS

20 DLS: Interrelaciones 1:N (2)
(a.2) Card(E2)=(0,1) -- Participación PARCIAL u opcional de E2 en IR nomMuseo 1 N CUADRO codCuadro PINACOTECA EXPONE titulo (0,1) (1,n) pintor ciudad sala NULOS PERMITIDOS CUADRO(codCuadro, titulo, pintor, nomMuseo, sala...) PINACOTECA(nomMuseo, ciudad, ...) Es posible la existencia de cuadros pertenecientes a colecciones situadas en casas particulares. FK

21 DLS:Interrelaciones 1:N (y 3)
(b) NUEVA RELACIÓN R. Cuando... Aparecen demasiados NULOS en la clave propagada (pocas ocurrencias del tipo interrelación), o IR tiene varios atributos propios, o IR puede transformarse en un futuro en un tipo interrelación N:M R se construye exactamente igual que para interrelaciones 1:1 (caso b.2) Clave primaria: atributo procedente de la entidad con cardinalidad N  E2 matricula nif ESTUDIANTE 1 N COCHE PROPIETARIO_DE nombre (0,n) modelo (0,1) Sigue siendo necesario incluir Restricciones de Integridad para conseguir las cardinalidades mínimas con valor 1. (*Análogas a las que aparece en la transparencia Cap6-16*) En el ejemplo, ·E1 es ESTUDIANTE. Si su cardinalidad fuera (1,n), todo estudiante sería propietario de, al menos, un coche. Hace falta la restricción de integridad para asegurar esto, es decir, para que toda instancia de ESTUDIANTE esté interrelacionada con al menos una instancia de COCHE. ·E2 es COCHE. Si su cardinalidad fuera (1,1) significaría que todo coche siempre es propiedad de un estudiante. Hace falta la restricción de integridad para asegurar que toda instancia de COCHE esté interrelacionada con al menos una instancia de ESTUDIANTE. ESTUDIANTE(nif, nombre, ...) COCHE_DE_ESTUDIANTE(nifEstudiante, matricula) COCHE(matricula, modelo, ...) FK FK

22 DLS:Interrelaciones N:M
Interrelaciones Binarias N:M Nueva relación R cuyos atributos son: uno(s) por cada clave primaria de R1 y R2 Son claves ajenas a la clave primaria de R1 y R2, respectivamente Su combinación (concatenación) forma la clave primaria de R atributos simples (o componentes simples de atributos compuestos) del tipo interrelación E1 E2 IR R1 R2 derechosAutor codAutor AUTOR LIBRO isbn ESCRIBE titulo (1,4) (0,n) nomAutor Nota: Los derechos de autor son el porcentaje que el autor cobra por la venta del libro. Por tanto será un entero de dos dígitos (de 0 a 99 %) fechaFin AUTOR(codAutor, nomAutor, ...) ESCRIBE(codAutor, isbn, fechaFin, derechosAutor) LIBRO(isbn, titulo, ...) FK FK

23 DLS: InterRelaciones M:N
Especificación de las acciones disparadas por Integridad Referencial CREATE TABLE ESCRIBE (codAutor Autores, codLibro Codigos CONSTRAINT max_autores_libro CHECK (NOT EXISTS (SELECT codLibro FROM ESCRIBE GROUP BY codLibro HAVING COUNT(*)>4), fechaFin DATE NOT NULL, derecAutor NUMBER(2) DEFAULT 20, PRIMARY KEY (codAutor, codLibro), FOREIGN KEY(codAutor) REFERENCES AUTOR(codAutor) ON DELETE NO ACTION ON UPDATE CASCADE, FOREIGN KEY(codLibro) REFERENCES LIBRO(isbn) ON DELETE CASCADE ON UPDATE CASCADE );

24 DLS: Cardinalidades Especificación de Restricciones: CARDINALIDADES MÍNIMA y MÁXIMA CREATE ASSERTION num_autores_libro CHECK ((4>=(SELECT MAX(ocurrencias) FROM (SELECT COUNT(*) AS ocurrencias FROM ESCRIBE GROUP BY codLibro)) AND ((1<=(SELECT MIN(ocurrencias) GROUP BY codLibro)); SET CONSTRAINTS {ALL | nombre_constraint`[,...]} {DEFERRED | INMEDIATE} INITIALLY {DEFERRED | INMEDIATE} Hemos de evitar... a) Que en ESCRIBE existan tuplas con el valor para codAutor a NULL (libro sin autor). ESCRIBE codAutor codLibro NULL Esto se consigue al hacer que la clave primaria de ESCRIBE sea codAutor, codLibro. b) Que en LIBRO exista una tupla para el libro y NO haya ninguna tupla para él en ESCRIBE (libro sin autor). Esta cardinalidad mínima 1, se consigue con la restricción que aparece tras el AND en el aserto anterior. Si en su lugar, detrás del AND pusiéramos... NOT EXISTS(SELECT * FROM ESCRIBE WHERE codAutor IS NULL) ... no estaríamos comprobando que todo libro ocurrencia de LIBRO debe tener una tupla correspondiente en la relación ESCRIBE que lo vincule a un AUTOR. Por eso es necesario contar las ocurrencias del libro en ESCRIBE para comprobar que, al menos, hay una.

25 DLS: Dependencia Existencia / Identificación
Dependencia en existencia e identificación (E2 depende de E1) Caso particular de IR 1:1 o 1:N con propagación de clave y participación total de E2 clave ajena F de R2 hacia R1 (atributo(s) propagado(s) de R1 a R2) no permite NULL clave primaria de R2: DEPENDENCIA EN EXISTENCIA atributo(s) clave primaria de R2 (identificador principal de E2) DEPENDENCIA EN IDENTIFICACIÓN combinación de atributos: F y clave parcial (discriminante) de R2 Actualizaciones y Borrados en R1 se transmiten en CASCADA hacia R2

26 DLS: Dependencia Existencia / Identificación (2)
TIENE E 1 N nifFam nifEmp EMPLEADO FAMILIAR nomEmp (1,1) (0,n) EMPLEADO ( nifEmp, nomEmp, ...) FK nulos no permitidos: NOT NULL ON DELETE CASCADE ON UPDATE CASCADE FAMILIAR ( nifFam, nifEmp, ... ) CREATE TABLE FAMILIAR ( nifFam nifs PRIMARY KEY, nifEmp nifs NOT NULL, FOREIGN KEY (nifEmp) REFERENCES empleado(nifEmp) ON DELETE CASCADE ON UPDATE CASCADE );

27 DLS: Dependencia Existencia / Identificación (3)
RECIBE ID 1 N fecha historial PACIENTE VISITA_MEDICA nombre hora (1,1) (1,n) observaciones PACIENTE ( historial, nombre, ...) nulos no permitidos ON DELETE CASCADE ON UPDATE CASCADE FK VISITA_MEDICA ( historial, fecha, hora, ... ) CREATE TABLE visita_médica ( historial códigos REFERENCES paciente ON DELETE CASCADE ON UPDATE CASCADE , fecha fechas, hora horas, observaciones VARCHAR(100), PRIMARY KEY (historial, fecha, hora) );

28 DLS: Atributo multivaluado en IR
Atributo Multivaluado de tipos interrelación IR Nueva Relación S, en la que el atributo multivaluado se representa como un atributo simple A m (0,n) IR E1 E2 R1 R R2 S

29 DLS: Reglas para el Modelo Básico
Atributo Multivaluado de tipos interrelación IR (cont.) Según IR sea... 1:1 S incluye un atributo F, clave ajena a la clave primaria de R1 o de R2 Clave Primaria de S = (F, A) 1:N ( E2 es el tipo entidad con cardinalidad N ) S incluye un atributo F, clave ajena a la clave primaria de R2 N:M S incluye dos atributos F1 y F2, clave ajena a las clave primaria de IR Clave Primaria de S = (F1, F2, A)

30 DLS:Atributos Multivaluados en IR
trimestre (1,3) Caso N:M nifProf maxNumAlumnos PROFESOR OFERTA SEMINARIO R1 PROFESOR(nifProf, ...) OFERTA(nifProf, numSeminario, maxNumAlumnos) SEMINARIO(numSeminario,...) SEMINARIO_OFERTADO(nifProfesor, numSemin, trimestre) (1,m) (0,n) FK numSeminario R FK R2 FK S F1 F2 A maxNumAlumnos nifProf nifProfesor + SEMINARIO numSemin PROFESOR OFERTA SEMINARIO OFERTADO trimestre numSeminario

31 DLS: Interrelaciones Reflexivas
jefe nifEmp EMPLEADO JEFE DE nomEmp subordinado EMPLEADO (nifEmp, nomEmp, ...) JEFE_DE(nifJefe, nifSubordinado, ...) Caso N:M EMPLEADO ( nifEmp, nomEmp, ...) JEFE_DE ( nifJefe, nifSubordinado, ... ) Caso 1:N EMPLEADO ( nifEmp, nomEmp, ..., nifJefe, ... ) ( Solución problemática si puede haber muchos empleados sin jefe  demasiados nulos ) Relación donde la clave primaria del tipo de entidad aparece DOS VECES Nombres de esos atributos según roles del tipo entidad en la interrelación

32 DLS: Interrelaciones Reflexivas (cont.)
codigo componente (0,n) N PRODUCTO 1 COMPUESTO_POR (0,1) agregado descripcion PRODUCTO(codigo, descripcion, ...) COMPONENTE(codAgregado, codComponente) --- un producto es componente de un único producto, o de ninguno FK FK (Al Producto Agregado o Compuesto) FK: nulos permitidos PRODUCTO(codigo, descripcion, codProducto,...) Producto o Componente

33 DLS: Interrelaciones n-arias
Relación R que incluye los atributos... Uno por cada clave primaria de R1, R2, R3... Serán claves ajenas a la relación Ri correspondiente Atributos simples o componentes simples de atributos compuestos de IR Clave primaria de R Normalmente, es la combinación de todas las claves externas hacia Ri pero es posible que la PK de R sea un subconjunto de esa superclave E1 E2 IR R1 R2 E3 R3

34 DLS: Interrelaciones N-arias
matricula COCHE nifCliente (0,1) fechaVenta nifVendedor CLIENTE VENTA VENDEDOR (0,n) (0,n) (0,n) BANCO cifBanco La superclave de VENTA es (matricula, nifCliente, nifVendedor, cifBanco). La cardinalidad máxima de COCHE en VENTA es 1, lo que significa que un coche participa, como mucho, en una interrelación de tipo VENTA (es decir, es adquirido una única vez). Esto indica que el coche identifica unívocamente a la venta en la que participa, de forma que matricula puede ser la clave primaria de VENTA.. Para asegurar que no haya ventas sin cliente o sin coche o sin vendedor, debería existir la restricción de integridad de que las claves ajenas (los atributos) propagadas desde las (claves primarias de las) entidades COCHE, CLIENTE, VENDEDOR, nunca pudieran tomar NULO. Si se considera que es posible realizar una venta sin la participación de un banco (venta directa), la clave ajena propagada desde BANCO debería tener NULOs permitidos. En general, si la cardinalidad máxima de una de los tipos de entidad Ei que participan en IR, es 1, la clave primaria de R podrá ser (sólo) el atributo clave ajena desde R a Ri, puesto que cada entidad de Ei participa sólo en una (única) ocurrencia del tipo interrelación IR. VENTA (matricula, nifVendedor, nifCliente, cifBanco, fechaVenta, ...) *¿Cuál es la superclave de esta relación?  concatenación **¿y cuál es su clave primaria?  matricula ***¿Cómo asegurar que no haya ventas sin cliente o sin coche o sin vendedor?  no nulos ****¿Puede reflejarse la existencia de ventas directas (sin banco)?  no poniendo no nulo en banco

35 Relaciones exclusivas (1)
Caso 1:N: Curso organizado O impartido por profesor CREATE TABLE Curso { cod_curso PRIMARY KEY Nom_curso ………… Director ..REFERENCES Profesor(idProf) ON UPDATE CASCADE Profesor..REFERENCES Profesor(idProf) ON UPDATE CASCADE …. CONSTRAINT organiza_xor_imparte CHECK (( director NOT IN (SELECT profesor FROM CURSO) AND (profesor NOT IN (SELECT director FROM CURSO)) };

36 Relaciones exclusivas (2)
Caso N:M: Alumno estudia titulaciones o cursa masters CREATE TABLE Alumno_estudia_titulacion { ………… Alu ..REFERENCES Alumno(numExp) ON DELETE / UPDATE CASCADE titu..REFERENCES Titulacion(idTit) ON UPDATE CASCADE …. PRIMARY_KEY(alu, titu), CONSTRAINT titulacion_xor_master CHECK (( alu NOT IN (SELECT alu FROM alumno_cursa_master) }; Similar para la tabla Alumno_cursa_master

37 Relaciones exclusivas (3)
Caso 1:1: Empleado jefe de departamento o director de sucursal CREATE TABLE Departamento { codDep ….PRIMARY KEY …. jefe ..REFERENCES Empleado(codEmp) ON UPDATE CASCADE CONSTRAINT jefe_ok CHECK (( jefe NOT IN (SELECT director FROM Sucursal) }; Similar para la tabla Sucursal

38 DLS: Jerarquías Jerarquías de Especialización/Generalización
(a) TRANSFORMACIÓN DIRIGIDA POR EL SUPERTIPO Los subtipos se diferencian en pocos atributos Interrelaciones establecidas con el supertipo o son las mismas para todos los subtipos Se crea una única relación R que contiene... TODOS los atributos del supertipo P y de los subtipos S1 y S2 un atributo nuevo -- atributo discriminante d de la jerarquía (posibles) nuevas restricciones semánticas La clave primaria de R es el atributo correspondiente al AIP del supertipo P S2 S1 d

39 DLS: Jerarquías (2) CREATE TABLE DOCUMENTO( codigo ... PRIMARY KEY,
titulo... , idioma ... , tipo ... , nomEditorial ... NULL, añoEdicion ... NULL, ... CHECK (( tipo = “ARTICULO” AND añoEdicion IS NULL AND nomEditorial IS NULL) OR ( tipo = “LIBRO” AND añoEdicion IS NOT NULL AND nomEditorial IS NOT NULL)) ); codigo DOCUMENTO idioma titulo Atributo DISCRIMINANTE tipo ARTÍCULO LIBRO Restricciones SEMÁNTICAS añoEdicion nomEditorial

40 Ventajas e Inconvenientes
DLS:Jerarquías (3) Si la jerarquía es TOTAL, el discriminante no permite NULOS Si la jerarquía es SOLAPADA, Tratar el discriminante como un ATRIBUTO MULTIVALUADO, o Añadir un atributo (booleano) por cada subtipo (indica si  o  al subtipo) Ventajas e Inconvenientes  Acceso eficiente a TODA la información sobre una entidad concreta (acceso a una sola relación)  *Aparición de nulos (atributos que proceden de subtipos para entidades que no pertenecen a tales subtipos) * Toda operación sobre subtipos debe “buscar” las instancias de los subtipos en el conjunto completo (supertipo) de instancias

41  Menos eficiente en el acceso
DLS: Jerarquías (4) (b) TRANSFORMACIÓN “TOTAL” Los subtipos se diferencian en muchos atributos Se desea mantener los atributos comunes en una relación separada una relación R para el supertipo P incluye atributos de P la clave primaria de R es el atributo correspondiente al AIP del supertipo una relación Ri para cada sutipo Si contiene atributos del subtipo Si y un atributo clave ajena hacia la clave primaria de R La clave primaria de cada Si es el atributo clave ajena a la clave primaria de R  *Funciona para todo tipo de jerarquías. Y es la mejor desde el punto de vista semántico. *Conviene si operaciones estrictamente locales a subtipos o a supertipo (pocas operaciones acceden conjuntamente a atributos de subtipos y supertipo)  Menos eficiente en el acceso P S2 S1 d Esta opción es la menos eficiente porque cuando se desea acceder a todos los atributos de una instancia de un subtipo, es necesario consultar dos relaciones: la del subtipo y la del supertipo (pues ahí están los atributos comunes a todos los subtipos); es decir, se necesita hacer una REUNION de ambas relaciones. Sin embargo, se incrementa la eficiencia del acceso (sólo) a atributos comunes.

42  *Funciona bien para jerarquías totales y disjuntas
DLS: Jerarquías ( y 5) (c) TRANSFORMACIÓN DIRIGIDA POR LOS SUBTIPOS Existen muchos atributos NO comunes (en los subtipos) Existen pocos atributos comunes (en el supertipo) Los accesos a datos de subtipos siempre afectan a datos comunes Se crea una relación Ri para cada sutipo Si contiene atributos del subtipo Si y atributos comunes (del supertipo) La clave primaria de cada Si es el atributo del AIP del supertipo  *Funciona bien para jerarquías totales y disjuntas *Conviene si el concepto representado por el supertipo no se requiere en el diseño lógico  *Con jerarquías solapadas aparecen “repeticiones” *Con jerarquías parciales surgen problemas de “falta de representación” de entidades no pertenecientes a ningún subtipo. P S2 S1 d * En jerarquías solapadas, se introduce redundancia de información, pues para una entidad que pertenezca a la vez a varios subtipos, se almacenará varias veces los valores de los atributos comunes (los correspondientes al supertipo). * Sin embargo en jerarquías parciales, una entidad que NO pertenezca a ninguna de los subtipos se pierde!! * Ninguna relación contiene las entidades que “sólo” pertenecen al supertipo. Para obtener todas las instancias del supertipo hay que hacer una UNION EXTERNA (unión en la que las relaciones participantes no son compatibles en tipo) de las relaciones correspondientes a los subtipos. * Además, para buscar una ocurrencia del supertipo, hay que buscar en todas las relaciones procedentes de los subtipos *Acceso muy eficiente a toda la información (REUNIÓN “integrada” en el propio esquema)

43 Categorías Clave sustituta PERSONA ( DNI,…,IdPropietario)
nombre nombre NºVehículo NºVehículo CAMIÓN PERSONA BANCO EMPRESA COCHE FechaCompra U U tiene matrícula VEHICULO MATRICULADO PROPIETARIO PERSONA ( DNI,…,IdPropietario) COCHE ( Nºvehículo,…) CAMIÓN ( Nºvehículo,…) VEHÍCULO MATRIC ( Nºvehículo, matrícula …) BANCO ( Nombre,…,IdPropietario) EMPRESA ( Nombre,…,IdPropietario) PROPIETARIO (IdPropietario, TipoPropietario) Clave sustituta

44 DISEÑO LÓGICO ESPECÍFICO (DLE)
Del Esquema Lógico Estándar al Esquema Lógico Específico (ELE) Conocimiento del SGBD ¿soporta el MLS?¿hasta qué punto?¿cómo escribir el ELE con la sintaxis propia del SGBD? Estudio de la correspondencia entre conceptos del MLS y del SGBD Pueden darse dos casos: 1. SGBD con soporte total del MLS sin restricciones Transformación (casi) directa al SQL propio del SGBD 2. SGBD no soporta algunos conceptos, o sí lo hace pero con restricciones Uso de conceptos distintos alternativos Programación complementaria La mayor parte del ELS sirve como ELE, así que sólo veremos los aspectos que necesitan transformaciones adicionales En el diseño lógico específico de nuevo se pierde semántica, aunque es posible recuperarla en parte (aunque sea formando parte de los procesos y no de la propia base de datos) En un sistema sin soporte para la integridad, por ejemplo, para controlar que determinadas operaciones no se puedan realizar, pues violarían la integridad de la base de datos, será necesario transferir esta semántica a los procedimientos o programas (aunque debería estar incluida en los datos, en forma de reglas de integridad). Algunos sistemas permiten crear procedimientos que se almacenan en la propia base de datos (en el catálogo). Otros no, de forma que el control de la integridad de los datos debe incluirse en el código de los procedimientos que conforman las aplicaciones que acceden a los datos. Otra opción sería definir reglas y/o triggers que están directamente asociados a los datos (si los soporta el SGBD) y se almacenan en la metabase (el catálogo), de forma que los procedimientos no se los pueden “saltar”, ya que es el SGBD el que “los ejecuta”.

45 DLE: transformaciones adicionales
Dominios Algunos productos comerciales sólo ofrecen sintaxis de definición de dominios, pero no implementan la semántica asociada Según Codd (1990) Declaración única de cada tipo de datos permitido en el esquema, Soporte de integridad y coherencia entre dominios (operaciones compatibles como la UNION, INTERSECCION, ...), Posibilidad de creación de operadores y características propias de los dominios, Facilitar la definición de comprobaciones del SGBD (menor/mayor que), Posible indexación sobre el dominio, no sobre las columnas de las tablas, Simplificar operaciones complejas sobre varias columnas, haciendola sobre el directamente sobre el dominio La mayoría NO ofrece ningún soporte para definición de dominios Definir tipo de datos, longitud, restricciones para cada atributo (columna) Simulación: Tablas de dominio y Procedimientos de comprobación de valores correctos Tabla de dominio *Una única columna *Tabla no modificable (INSERT, UPDATE, DELETE no permitidas, salvo para el DBA) *Contiene los valores posibles para atributos “del mismo dominio” Ejemplos: COLOR ESTADOCIVIL DNI azul S rosa C verde V #Los valores correctos serán los comprendidos rojo D entre la primera y la segunda (y última) tupla amarillo Ventajas de las Tablas de Dominio 1. Permiten aislar los datos de los procesos 2. Facilitan la compartición de datos 3. Permiten la estandarización de la edición y validación de los datos 4. Implican a los usuarios como responsables de los datos 5. Facilitan la extensión de los datos (es muy fácil introducir un nuevo valor en el dominio) Los procedimientos de comprobación realizarían una simulación de las funciones de control de integridad de los datos.

46 DLE: transformaciones adicionales
Claves Primarias Si el SGBD no dispone de sintaxis para definición de PK o sólo ofrece la sintaxis para hacerlo, pero no implementa su semántica (como Oracle6)... Especificar cada atributo componente de la PK como NOT NULL Especificar que la combinación de todos los componentes de la PK ha de tener valores únicos (y asegurar esto tras inserciones y actualizaciones) Mantener la definición de cada clave primaria como comentario en el catálogo del SGBD o, si éste lo soporta, incluir la definición sintáctica *Nota: en SQL2 no es obligatorio especificar la PK de una relación, en los productos comerciales tampoco (por compatibilidad con versiones anteriores) Para conseguir los valores únicos de los componentes de la clave primaria, puede crearse un índice único sobre la combinación de todos los componentes, mediante la sentencia CREATE UNIQUE INDEX, o bien mediante la cláusula UNIQUE. Una vez creado este índice único, es necesario asegurar su existencia cada vez que se inserta o actualiza una tupla (es decir, se crea con la tabla y ya no se destruye).

47 DLE: transformaciones adicionales
Claves Ajenas Unos productos soportan este concepto (a partir de Oracle7) Algunos lo hacen a nivel sintáctico, pero no implementan la semántica asociada (Oracle6) Otros permiten crear un procedimiento (almacenado en el catálogo) que implementa cada clave ajena El mecanismo de Integridad Referencial penaliza los tiempos de respuesta del sistema (a consultas interactivas, sobre todo) Borrados/actualizaciones en cascada La creación del procedimiento la realiza el programador, y además, debe crear uno para cada específico para cada clave ajena. La ventaja de que se almacene en el catálogo es que es el SGBD el que se ocupa de que se ejecute dicho procedimiento siempre que sea necesario, evitando que haya que invocarlo explícitamente desde los programas de aplicación.

48 DLE: transformaciones adicionales
Claves Ajenas (y 2) Algunos productos NO soportan este concepto, entonces... Introducir las restricciones de clave ajena FK como requisitos de especificación de programas Especificar como NOT NULL los atributos de FK con nulos no permitidos Mantener la definición de cada clave ajena como comentario en el catálogo del SGBD o, si éste lo soporta, incluir su definición sintáctica Utilizar mecanismos de seguridad (GRANT, REVOQUE) para prohibir operaciones de actualización interactivas que pueden violar RI referencial Crear un procedimiento que periódicamente compruebe y notifique posibles violaciones de la Integridad Referencial Es necesario incluir un procedimiento que compruebe periódicamente posibles violaciones de la Integridad Referencial, por si acaso ocurre algún fallo debido a un error en los programas o por una caída o fallo del sistema.

49 DLE: transformaciones adicionales
Otros conceptos del Modelo Relacional Será necesario crear procedimientos que verifiquen las restricciones de integridad definidas en la fase de Diseño Lógico Estándar Si el SGBD lo permite, se almacenarán en el catálogo del SGBD Si no, serán parte de los programas de aplicación Restricciones de integridad como especificaciones de procesos