Saltar al contenido principal
CargarIdioma (ES)Atención al cliente
EmpresarialesMóvilRedes socialesMarketingTecnologíaArte y fotografíaEmpleoDiseñoEducaciónPresentaciones y charlas públicasGobierno y org. sin ánimo de lucroAtención sanitariaInternetDerechoLiderazgo y gestiónMotorIngenieríaSoftwareReclutamiento y RR. HH.Venta al por menorVentasServiciosCienciasPYMES y liderazgoAlimentaciónMedio ambienteEconomía y finanzasDatos y análisisRelaciones con inversoresDeportesMeditaciónNoticias y políticaViajesDesarrollo personalSector inmobiliarioEntretenimiento y humorSalud y medicinaDispositivos y hardwareEstilo de vida
Robert Rodriguez, profile picture
Subido porRobert Rodriguez
2,621 vistas

Diseño Logico de base de datos

El documento aborda el diseño lógico de bases de datos, destacando la importancia de transformar esquemas conceptuales en lógicos independientemente del SGBD. Se describe el proceso de diseño lógico estándar y específico, las fases del diseño, así como las reglas para evitar la pérdida de semántica en la traducción de esquemas. También se incluyen técnicas como la normalización y la representación gráfica de los modelos de datos.

Educación◦
Descargado 26 veces
1 Tema 7. Diseño Lógico de Bases de Datos 1 7. Diseño lógico de bases de datos Objetivos • Comprender la conveniencia y ventajas de disponer de un esquema lógico de BD independiente de un SGBD comercial 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 Tema 7. Diseño Lógico de Bases de Datos 2 7. Diseño lógico de bases de datos Contenidos 7.1. Objetivos y fases del diseño lógico 7.2. Diseño lógico estándar 7.3. Diseño lógico específico Bibliografía [EN 2002] Elmasri, R.; Navathe, S.B.: Fundamentos de Sistemas de Bases de Datos. 3ª Ed. Addison-Wesley. (Cap. 9 y 16) [EN 1997] Elmasri, R.; Navathe, S.B.: Sistemas de bases de datos. Conceptos fundamentales. 2ª Ed. Addison-Wesley Iberoamericana. (Cap. 6, 14 y 21) [MPM 1999] de Miguel, A.; Piattini, M.; Marcos, E.: Diseño de bases de datos relacionales. Ra-Ma (Cap. 10 y 11) [CBS 1998] Connolly; Begg; Strachan: Database Systems: A Practical Approach to Design, Implementation and Management. 2nd Ed. Addison-Wesley (Cap. 8, 11, 9 y 12)
2 Tema 7. Diseño Lógico de Bases de Datos 3 • El objetivo principal es transformar el esquema conceptual de datos en el esquema lógico de datos • Otros objetivos del diseño lógico son ... – Eliminar redundancias – Conseguir máxima simplicidad – Evitar cargas suplementarias de programación para conseguir ... – una estructura lógica adecuada – un equilibrio entre los requisitos de usuario y la eficiencia • Diseño lógico con la máxima portabilidad I Introducción “tardía” del SGBD específico » Implementación del esquema lógico en distintos SGBD comerciales » Migración entre diferentes versiones de un mismo SGBD 7.1 Objetivos y fases del diseño lógico Objetivos Tema 7. Diseño Lógico de Bases de Datos 4 • Diseño Lógico Estándar (DLS) – Se elige el modelo de datos de representación, y no el SGBD – Transformación independiente del SGBD específico 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 describe el ELS mediante los elementos del modelo de datos • LDD de SQL-92 en el Modelo Relacional • Diagrama de Estructura de Datos 7.1 Objetivos y fases del diseño lógico Fases
3 Tema 7. Diseño Lógico de Bases de Datos 5 ‚ Diseño Lógico Específico (DLE) – Se elige el SGBD específico – Adaptación del esquema lógico a un SGBD comercial concreto Esquema Lógico Estándar ðð Esquema Lógico Específico (ELE) » Uso del Modelo Lógico de datos particular del SGBD elegido • Oracle, Informix, DB2, Interbase, Ingres, Sybase ... » Se describe el ELE mediante el LDD propio del SGBD específico • SQL de Oracle, ... 7.1 Objetivos y fases del diseño lógico Fases (y 2) Tema 7. Diseño Lógico de Bases de Datos 6 Reglas de traducción MERE ðð MR q Reglas para el modelo básico • Dominios • Atributos • Tipos de entidad • Tipos de relación q Reglas para las extensiones del modelo • Relaciones exclusivas • Jerarquías de Especialización/Generalización 7.2 Diseño lógico estándar MRMER Propagación de clave o relaciónTipo de Relación 1:1, 1:N, N:1 RelaciónTipo de Relación M:N Relación (tabla)Tipo de Entidad RESUMEN
4 Tema 7. Diseño Lógico de Bases de Datos 7 L Pérdida de semántica: – Una relación (tabla) puede provenir de una entidad o de una relación MERE – Si una relación 1:1, 1:N, N:1 se traduce con propagación de clave, «desaparece» el nombre de la relación Ejemplo de traducción 7.2 Diseño lógico estándar J Solución: – Anotación en la documentación asociada – Impedir pérdida de integridad, definiendo reglas de integridad apropiadas Tema 7. Diseño Lógico de Bases de Datos 8 Diagrama de Estructura de Datos, DED • Técnica de representación gráfica de los esquemas lógicos de datos en los modelos convencionales, en particular, el modelo relacional • Notación «a medio camino» entre el modelo Entidad-Relación y el Relacional • Soportados por herramientas CASE (ej. System Architect) • Uso del DED en la metodología METRICA – Fase 1: • ARS 3.2: Diseño del Esquema Lógico Actual de Datos • EFS 2.1: Construcción del Esquema Lógico de Datos • EFS 2.2: Normalización del Esquema Lógico de Datos 7.2 Diseño lógico estándar
5 Tema 7. Diseño Lógico de Bases de Datos 9 • Sólo relaciones binarias (dos entidades) • Sólo permitidas las relaciones 1:N – Transformación de relaciones 1:1 § Fusionar en una única entidad, o mantener la relación – Transformación de relaciones M:N § Creación de una entidad auxiliar + dos relaciones 1:N Ejemplo de relación N:1 EMPLEADO DEPARTAMENTO Pertenece a Características de un DED 7.2 Diseño lógico estándar Tema 7. Diseño Lógico de Bases de Datos 10 • 1FN: todo atributo con valor atómico – Evitar atributos multivalorados – Evitar atributos compuestos • 2FN: en toda entidad E, los atributos no identificadores dependen de manera total del identificador principal de E – Ningún atributo (no identificador) de E depende sólo de una parte de cualquier identificador (principal, alternativo) de E • 3FN: No existen dependencias funcionales transitivas entre los atributos de la entidad E – Todo atributo no identificador de E sólo depende directamente de los identificadores de E Normalización de un DED 7.2 Diseño lógico estándar
6 Tema 7. Diseño Lógico de Bases de Datos 11 • Dominio • Tipo de entidad – Se traduce a una relación (tabla) – Se recomienda usar el mismo nombre o uno similar PERSONA CREATE TABLE Persona ( ... ) ; MERE MR 7.2 Diseño lógico estándar Traducción de un dominio y un tipo de entidad MERE ESTADO_CIVIL: {S, C, V, D} MR CREATE DOMAIN Estado_civil AS CHAR(1) CHECK VALUE IN {‘S’, ‘C’, ‘V’, ‘D’} ; Tema 7. Diseño Lógico de Bases de Datos 12 • Atributo simple y monovaluado ð Columna • Atributo identificador – Id. principal ð Clave primaria (PRIMARY KEY) – Id. alternativo ð Clave alternativa (UNIQUE) • Podrá contener NULL si no se indica lo contrario 7.2 Diseño lógico estándar Traducción de un atributo PERSONA dirección teléfono dni numSS fechaNacim nombre nacionalidad altura CREATE TABLE Persona ( dni PRIMARY KEY, numSS UNIQUE NOT NULL, nombre ..., dirección ..., teléfono ..., fechaNacim ..., nacionalidad ..., altura ... ) ; MERE MR
7 Tema 7. Diseño Lógico de Bases de Datos 13 • Atributo compuesto.- Dos alternativas: a) «Eliminar» atributo compuesto y considerar todos sus componentes como atributos simples de la relación resultante b) «Eliminar» los componentes y considerar el atributo compuesto como un solo atributo de la relación ¿Cuándo será más adecuado utilizar una opción u otra? 7.2 Diseño lógico estándar Traducción de un atributo (2) MERE MR (DED) Tema 7. Diseño Lógico de Bases de Datos 14 • Atributo multivalorado – Nueva relación S, en la que el atributo multivalorado se representa como un atributo simple A – S contendrá un nuevo atributo F, clave ajena a la clave primaria de la relación correspondiente a la entidad – La clave primaria de S es la combinación (F, A) PERSONA (dni, nombre, fechaNac) DIRECC_PERSONA (dni, dirección) FK 7.2 Diseño lógico estándar Traducción de un atributo (3) PERSONA DIRECC_ PERSONA MR (DED) tiene PERSONA fechaNac dni dirección (1,n) nombre MERE [MPM 1999] MR CREATE TABLE Direcc_Persona ( dni ... dirección ... PRIMARY KEY (dni, dirección) FOREIGN KEY (dni) REFERENCES Persona(dni) ON DELETE CASCADE ON UPDATE CASCADE );
8 Tema 7. Diseño Lógico de Bases de Datos 15 • Atributo derivado – Es necesario decidir si se almacena o no 1. Si se almacena, será un atributo de la relación que corresponda y deberá crearse un disparador que calcule su valor 2. Si no se almacena, deberá crearse un procedimiento que calcule su valor cada vez que se solicita PERSONA (dni, nombre, fechaNac, edad) 7.2 Diseño lógico estándar Traducción de un atributo (y 4) PERSONA fechaNac dni edad nombre MERE [MPM 1999] MR Tema 7. Diseño Lógico de Bases de Datos 16 ðð Nueva relación R, que incluye... – claves ajenas hacia las claves primarias de R1 y de R2 § Su combinación (concatenación) forma la clave primaria de R – atributos del tipo de relación V (simples o componentes simples de atributos compuestos) AUTOR(codAutor, nomAutor, ...) ESCRIBE (autor, libro, derAutor, numPag) LIBRO(isbn, titulo, ...) FK FK E1 E2V R1 R2 R 7.2 Diseño lógico estándar Traducción de una relación binaria M:N AUTOR LIBRO numPaginas (1,n) (1,m) titulonomAutor codAutor isbnderechosAutor Escribe [MPM 1999]
9 Tema 7. Diseño Lógico de Bases de Datos 17 – Especificación de acciones de mantenimiento de la integridad referencial (NO ACTION, CASCADE, SET NULL, SET DEFAULT) CREATE TABLE Escribe ( autor Autores, libro Codigos, derAutor NUMBER(2) DEFAULT 20 CHECK (derAutor>0 AND derAutor<100), numPag NUMBER(2) NOT NULL CHECK (numPag>=0), PRIMARY KEY (autor, libro), FOREIGN KEY (autor) REFERENCES AUTOR(codAutor) ON DELETE NO ACTION ON UPDATE CASCADE, FOREIGN KEY (libro) REFERENCES LIBRO(isbn) ON DELETE CASCADE ON UPDATE CASCADE ); 7.2 Diseño lógico estándar Traducción de una relación binaria M:N (2) Tema 7. Diseño Lógico de Bases de Datos 18 – Especificación de restricciones o asertos para especificar las cardinalidades mínima y máxima Un libro debe tener entre 1 y 4 autores CREATE ASSERTION num_autores_por_libro CHECK ( (NOT EXISTS(SELECT * FROM Libro WHERE isbn NOT IN (SELECT libro FROM Escribe))) AND (4 >= (SELECT MAX(ocurrencias) FROM (SELECT COUNT(*) AS ocurrencias FROM Escribe GROUP BY libro))) ); 7.2 Diseño lógico estándar Traducción de una relación binaria M:N (y 3)
10 Tema 7. Diseño Lógico de Bases de Datos 19 1) Caso general ðð Propagación de clave – En R2 se incluyen nuevos atributos... § clave externa hacia la clave primaria de R1 § atributos de la relación V (simples o componentes simples de atributos compuestos) 1.1) Participación total de E2 en V CIUDAD( nomCiudad, provincia, ... ) PROVINCIA( codProv, nomProv, ... ) FK: NULOS NO PERMITIDOS E1 E2V R1 R2 1 N PROVINCIA CIUDAD (1,1) (1,n) nomProv codProv nombreCiudad contiene 1:N 7.2 Diseño lógico estándar Traducción de una relación binaria 1:N [EN 2002] card(E2)=( 1, 1) [MPM 1999] card(E1)=( 1, 1) ... [MPM 1999] Tema 7. Diseño Lógico de Bases de Datos 20 2.2) Participación parcial de E2 en V CUADRO(codCuadro, titulo, pintor, museo, sala...) PINACOTECA(nomMuseo, ciudad, ...) FK NULOS PERMITIDOS PINACOTECA CUADRO (0,1) (1,n) nomMuseo codCuadro Expone titulo pintor ciudad sala 7.2 Diseño lógico estándar Traducción de una relación binaria 1:N (2) [EN 2002] card(E2)=( 0, 1) [MPM 1999] card(E1)=( 0, 1)[MPM 1999]
11 Tema 7. Diseño Lógico de Bases de Datos 21 2) Se cumple uno o varios de estos supuestos: q La relación V tiene varios atributos propios § y no se desea propagarlos, para conservar la semántica q Hay pocas ocurrencias de la relación V § se tendrían demasiados nulos en la clave y atributos propagados q Es probable que en el futuro V se transforme en una M:N ESTUDIANTE COCHE (0,1) (0,n) nif matricula Propietario_de modelo nombre 1 : N 7.2 Diseño lógico estándar Traducción de una relación binaria 1:N (y 3) [MPM 1999] Tema 7. Diseño Lógico de Bases de Datos 22 2) (continuación) ðð Añadir una nueva relación R, que incluye... – claves ajenas hacia las claves primarias de R1 y de R2 § una será clave primaria de R: la propagada desde la entidad cuyas instancias participan como mucho una vez en la relación V – atributos de V (simples o componentes simples de atributos compuestos) ESTUDIANTE( nif, nombre, ... ) PROPIEDAD( coche, estudiante) COCHE( matricula, modelo, ... ) FK FK NN 7.2 Diseño lógico estándar Traducción de una relación binaria 1:N (y 3) [MPM 1999] ESTUDIANTE COCHE (0,1) (0,n) nif matricula Propietario_de modelo nombre 1 : N
12 Tema 7. Diseño Lógico de Bases de Datos 23 1) Participación total de ambas entidades – Las entidades no participan en otras relaciones ðð una única relación R, que incluye... – Todos los atributos de ambas entidades – Claves de R: § Clave primaria = clave primaria de R1 o de R2 (es indiferente) § La otra (N si es distinta) será alternativa (UNIQUE) y además NOT NULL – Atributos de la relación V (simples o componentes simples de atributos compuestos) PACIENTE ( nss, nombre, numHisto, fechaApert, centroSalud,... ) AK, NNPK 7.2 Diseño lógico estándar Traducción de una relación binaria 1:1 nombre centroSalud (1,1) (1,1) fechaApertura nss numHistoria ... MEDICO HISTORIALPACIENTE ... Tiene [MPM 1999] Tema 7. Diseño Lógico de Bases de Datos 24 2) Participación total de una entidad y parcial de la otra 2.1) Caso general ðð Propagación de clave – La clave de la entidad con participación parcial «se propaga» hacia la entidad con participación total → clave ajena – Los atributos de la relación V «siguen» a la clave propagada Un empleado puede no dirigir ningún departamento, o bien ser el gerente de uno de ellos (desde cierta fecha, en la que fue nombrado como tal) E1 E2V R1 R2 EMPLEADO(codEmp, nomEmp, ...) DEPARTAMENTO(numDep,nomDep, codDir, fechInicDir...) FK AK, NN 7.2 Diseño lógico estándar Traducción de una relación binaria 1:1 (2) [MPM 1999] (1,1) (0,1) DEPARTAMENTOEMPLEADO codEmp nomEmp nomDep numDep Dirige fechaInic NN
13 Tema 7. Diseño Lógico de Bases de Datos 25 2.2) Hay pocas instancias del tipo de relación ðð Añadir una nueva relación R que incluye... – claves ajenas hacia las claves primarias de R1 y de R2 § una será clave primaria de R (la de participación total, si existe) § la otra será clave alternativa en R (UNIQUE) y además NOT NULL – atributos (simples o componentes simples de atributos compuestos) de V • Esta alternativa evita los NULL que aparecerían en los atributos propagados si se propagara la clave (caso general (2.1)) EMPLEADO(codEmp, nomEmp, ...) DIRIGE (emp, dep, fechInic) DEPARTAMENTO(numDep, nomDep,...) FK FKAK,NN 7.2 Diseño lógico estándar Traducción de una relación binaria 1:1 (3) Tema 7. Diseño Lógico de Bases de Datos 26 2.3) Hay muchas instancias del tipo de relación ðð Una única relación R que incluye... – Todos los atributos de las entidades y de la relación – La clave primaria es la de la entidad con participación parcial – Debe permitirse NULL en los atributos procedentes de la entidad con participación total y de la relación CREATE TABLE Empleado( codEmp ... PRIMARY KEY, nomEmp ... , ..., numDepDir ... NULL UNIQUE, nomDepDir ... NULL, ..., fechInicDir ... NULL, ... ); 7.2 Diseño lógico estándar Traducción de una relación binaria 1:1 (4) NULL permite representar empleados que no dirigen ningún departamento UNIQUE asegura que un departamento sólo es dirigido por un empleado Los atributos monovaluados aseguran que un empleado pueda dirigir como mucho un departamento Atributos de EMPLEADO Atributos de DEPARTAMENTO Atributos de DIRIGE
14 Tema 7. Diseño Lógico de Bases de Datos 27 3) Participación parcial de ambas entidades ðð Añadir una nueva relación R • R se construye exactamente igual que en el caso (2.2) • Evita los NULL que aparecerían si se propagara la clave de R1 a R2 o viceversa (caso general (2.1)) (0,1) (0,1) MUJERHOMBRE nif nif Matrimonio Estándar fecha lugar HOMBRE(nif, ...) MATRIMONIO(esposa, esposo, fecha, lugar) MUJER(nif, ...) FK FK AK, NN Y... ¿qué acciones de mantenimiento de la integridad referencial debemos imponer para (todos los casos de) transformación de relaciones 1:1? 7.2 Diseño lógico estándar Traducción de una relación binaria 1:1 (y 5) NN NN [MPM 1999] Tema 7. Diseño Lógico de Bases de Datos 28 ðð Caso particular de relación 1:1 o 1:N con propagación de clave y participación total de E2 I Si V es 1:1 ð caso 2.1 ; Si V es 1:N ð caso 1.1 I – La clave ajena FK en R2 hacia R1 no permite NULL – La clave primaria de R2 depende del tipo de dependencia: • en Existencia – clave primaria propia de R2 (identificador principal de E2) • en Identificación – combinación de atributos: FK y clave de R2 • Las actualizaciones y borrados en la tabla R1 deben transmitirse en cascada hacia R2 (CASCADE) E1 E2V R1 R2 7.2 Diseño lógico estándar Traducción de dependencia en existencia y en identificación
15 Tema 7. Diseño Lógico de Bases de Datos 29 EMPLEADO ( nifEmp, nomEmp, ...) FAMILIAR ( nifFam, emp, ... ) FK NOT NULL ON DELETE CASCADE ON UPDATE CASCADE PACIENTE ( historial, nombre, ... ) VISITA_MEDICA ( historial, fecha, hora, ... ) FK NOT NULL ON DELETE CASCADE ON UPDATE CASCADE 1:N FAMILIAREMPLEADO (1,1) (0,n) E nifFamnifEmp nomEmp Tiene VISITA MEDICA PACIENTE 1:N (1,1) (1,n) ID fechahistorial nombre hora observ Acude 7.2 Diseño lógico estándar Traducción de dependencia en existencia y en identificación (y 2) [MPM 1999] Tema 7. Diseño Lógico de Bases de Datos 30 EMPLEADO Es jefe de subordinado jefe nifEmp nomEmp ðð Relación (tabla) que contiene dos claves externas hacia la clave primaria de la tabla correspondiente a la entidad – Nombradas según los roles de la entidad en la relación EMPLEADO ( nifEmp, nomEmp, ...) JEFE_EMP ( jefe, subordinado, ... ) Otra posibilidad en el Caso 1:N NN FK FK EMPLEADO ( nifEmp, nomEmp, ... ) JEFE_EMP ( jefe, subordinado, ... ) Caso M:N FKFK 7.2 Diseño lógico estándar Traducción de una relación binaria reflexiva EMPLEADO ( nifEmp, nomEmp, ..., jefe, ... ) NULL FK Caso 1:N solución problemática si puede haber muchos empleados sin jefe ( demasiados nulos ) [MPM 1999]
16 Tema 7. Diseño Lógico de Bases de Datos 31 PRODUCTO( código, descripción, agregado, ... ) FK NULL al producto compuesto Producto o Componente PRODUCTO (0,1) (0,n) descripción código Compuesto_por agregado componente 1 N 7.2 Diseño lógico estándar Traducción de una relación binaria reflexiva (y 2) un producto o no es componente de ningún producto, o lo es de solo uno PRODUCTO( código, descripción, ... ) COMPOSICIÓN( agregado, componente ) FK FK NN [EN 2002] Tema 7. Diseño Lógico de Bases de Datos 32 ðð Añadir una nueva relación R correspondiente a V, que incluye... – Claves ajenas hacia cada clave primaria de R1, R2, R3, etc. – Atributos de la relación V (simples o componentes simples de atributos compuestos) – La clave primaria de R § En general, es la combinación de todas las claves externas hacia R1, R2, R3, etc. § Pero es posible que sea un subconjunto de esa superclave E1 E2V R1 R2E3 R3 7.2 Diseño lógico estándar Traducción de una relación n-aria
17 Tema 7. Diseño Lógico de Bases de Datos 33 VENTA ( matricula, vendedor, cliente, banco, fechaVenta ) 1. ¿Cuál es la superclave de esta relación? 2. ¿y cuál es su clave primaria? 3. ¿Cómo asegurar que no haya ventas sin cliente, o sin coche, o sin vendedor? 4. ¿Puede reflejarse la existencia de ventas directas (sin banco)? 7.2 Diseño lógico estándar Traducción de una relación n-aria (y 2) CLIENTE VENDEDOR (0,n) (0,m) nifCliente nifVendedor Venta BANCO cifBanco COCHE matricula (0,1) (0,p) fechaVenta [EN 2002] Tema 7. Diseño Lógico de Bases de Datos 34 ðð Añadir restricciones de tipo CHECK Ejemplo para relaciones de tipo 1:N CREATE TABLE Curso ( codcurso ... PRIMARY KEY, nomcurso ..., ... director ... REFERENCES Profesor (idProf) ON UPDATE CASCADE , profesor ... REFERENCES Profesor (idProf) ON UPDATE CASCADE , CONSTRAINT organiza_exclusiva_imparte CHECK ( ( director NOT IN (SELECT profesor FROM Curso) ) AND ( profesor NOT IN (SELECT director FROM Curso) ) ) ... ); 7.2 Diseño lógico estándar Traducción de exclusividad de relaciones CURSO IMPARTEORGANIZA PROFESOR (0,n)(0,n) (1,1) (1,1) [MPM 1999]
18 Tema 7. Diseño Lógico de Bases de Datos 35 Ejemplo para relaciones de tipo M:N CREATE TABLE Alumno_Estudia_Titulación ( alu ... REFERENCES Alumno (numExp) ON DELETE CASCADE ON UPDATE CASCADE , titu ... REFERENCES Titulación (idTit) ON DELETE NO ACTION ON UPDATE CASCADE , PRIMARY KEY (alu, titu), CONSTRAINT titulación_xor_master CHECK ( alu NOT IN (SELECT alum FROM Alumno_Cursa_Master) ) ); CREATE TABLE Alumno_Cursa_Master ( alum ... REFERENCES Alumno (numExp) ON DELETE CASCADE ON UPDATE CASCADE , mast ... REFERENCES Master (codMast) ON DELETE NO ACTION ON UPDATE CASCADE , PRIMARY KEY (alum, mast), CONSTRAINT master_xor_titulación CHECK ( alum NOT IN (SELECT alu FROM Alumno_Estudia_Titulación) ) ); 7.2 Diseño lógico estándar Traducción de exclusividad de relaciones (2) [MPM 1999] cursaestudia ALUMNO (0,n)(0,n) (1,n) (1,n) TITULACIÓN MASTER Tema 7. Diseño Lógico de Bases de Datos 36 Ejemplo para relaciones de tipo 1:1 CREATE TABLE Departamento ( codDep ... PRIMARY KEY , ... , jefe ... REFERENCES Empleado (codEmp) ON DELETE NO ACTION ON UPDATE CASCADE , CONSTRAINT jefe_ok CHECK ( jefe NOT IN (SELECT director FROM Sucursal) ) ); CREATE TABLE Sucursal ( codSuc ... PRIMARY KEY , ... , director ... REFERENCES Empleado (codEmp) ON DELETE NO ACTION ON UPDATE CASCADE , CONSTRAINTdirector_ok CHECK ( director NOT IN (SELECT jefe FROM Departamento) ) ); 7.2 Diseño lógico estándar Traducción de exclusividad de relaciones ( y 3) [MPM 1999] Director_deJefe_de EMPLEADO (0,1)(0,1) (1,1) (1,1) DEPARTAMENTO SUCURSAL
19 Tema 7. Diseño Lógico de Bases de Datos 37 1. Transformación guiada por el supertipo • Los subtipos se diferencian en pocos atributos, • Las relaciones con otras entidades están establecidas con el supertipo, o • Las relaciones con otras entidades son las mismas para todos (o casi) los subtipos ðð Una única relación R que contiene... – Todos los atributos del supertipo P y de los subtipos B1 y B2 – El atributo discriminante d de la jerarquía E/G – (posibles) nuevas restricciones semánticas – La clave primaria de R es el identificador principal del supertipo P B2B1 d 7.2 Diseño lógico estándar Traducción de especialización/generalización [MPM 1999] Tema 7. Diseño Lógico de Bases de Datos 38 CREATE TABLE Empleado_Universidad ( nif ... PRIMARY KEY, nombre ... , tipo ... NOT NULL CHECK tipo IN (“pro”,“bec”,“pas”), categ ... NULL, tipoBeca ... NULL, activ ... NULL, ... ); 7.2 Diseño lógico estándar Traducción de especialización/generalización (2) [MPM 1999] Transformación guiada por el supertipo: Jerarquía disjunta total EMPLEADO UNIVERSIDAD nif PASPROFESOR nombre tipoBeca actividad tipo categoría BECARIO CHECK ( ( tipo = “pro” AND categ IS NOT NULL AND tipoBeca IS NULL AND activ IS NULL ) OR ( tipo = “bec” AND tipoBeca IS NOT NULL AND categ IS NULL AND activ IS NULL ) OR ( tipo = “pas” AND activ IS NOT NULL AND categ IS NULL AND tipoBeca IS NULL ) ) restricciones semánticas
20 Tema 7. Diseño Lógico de Bases de Datos 39 CREATE TABLE Documento ( código ... PRIMARY KEY, título ... , idioma ... , tipo ... NULL CHECK tipo IN (“artículo”, “libro”), nomRevista ... NULL, nomEditorial ... NULL, añoEdicion ... NULL, ... CHECK ( (tipo = “artículo” AND nomRevista IS NOT NULL AND añoEdicion IS NULL AND nomEditorial IS NULL) OR (tipo = “libro” AND nomRevista IS NULL AND añoEdicion IS NOT NULL AND nomEditorial IS NOT NULL) ) ); 7.2 Diseño lógico estándar Traducción de especialización/generalización (3) [MPM 1999] Transformación guiada por el supertipo: Jerarquía disjunta parcial DOCUMENTO código LIBROARTÍCULO título idioma añoEdicion nomEditorial tipo nomRevista Tema 7. Diseño Lógico de Bases de Datos 40 CREATE TABLE Individuo ( dni ... PRIMARY KEY, nombre ... , fechanac ... , estudia ... NOT NULL CHECK (estudia IN (‘Y’, ‘N’)), curra ... NOT NULL CHECK (trabaja IN (‘Y’, ‘N’)), titulación ... NULL, nss ... NULL UNIQUE, salario ... NULL, ... CHECK ( (estudia = ‘Y’ AND titulación IS NOT NULL) OR (estudia = ‘F’ AND titulación IS NULL) ) , CHECK ( (curra = ‘Y’ AND nss IS NOT NULL AND salario IS NOT NULL) OR (curra = ‘F’ AND nss IS NULL AND salario IS NULL) ) ); 7.2 Diseño lógico estándar Traducción de especialización/generalización (4) [MPM 1999] Transformación guiada por el supertipo: Jerarquía solapada parcial INDIVIDUO nif CURRANTEESTUDIANTE fechanac nombre nss salario actividad titulación Otras opciones: – Un solo atributo discriminante – Tratar discriminante como atributo multivalorado
21 Tema 7. Diseño Lógico de Bases de Datos 41 CREATE TABLE Universitario ( nif ... PRIMARY KEY, nombre ... , estudia ... NOT NULL CHECK tipo IN (“Y”, “N”), trabaja ... NOT NULL CHECK tipo IN (“Y”, “N”), titulación... NULL, salario ... NULL, ... CHECK ( ( estudia = “Y” AND titulación IS NOT NULL ) OR ( trabaja = “Y” AND salario IS NOT NULL ) ) ); 7.2 Diseño lógico estándar Traducción de especialización/generalización (5) [MPM 1999] Transformación guiada por el supertipo: Jerarquía solapada total UNIVERSITARIO nif ESTUDIANTE nombre salario tipo titulación EMPLEADO Otras opciones: – Un solo atributo discriminante – Tratar discriminante como atributo multivalorado Tema 7. Diseño Lógico de Bases de Datos 42 Transformación guiada por el supertipo J Ventajas – Acceso eficiente a toda la información sobre instancias de una entidad concreta (acceso a una sola tabla) L Inconvenientes – Aparición de nulos en los atributos que proceden de subtipos, para aquellas instancias que no pertenecen a tales subtipos – Una operación aplicada sólo sobre subtipos debe «buscar» las instancias de dichos subtipos en el conjunto completo de instancias (supertipo) 7.2 Diseño lógico estándar Traducción de especialización/generalización (6)
22 Tema 7. Diseño Lógico de Bases de Datos 43 2. Transformación total • Los subtipos se diferencian en muchos atributos • Se desea mantener los atributos comunes en una relación separada ðð Una relación para cada entidad – una relación R para el supertipo P, que incluye... § atributos de P § la clave primaria es el identificador principal del supertipo – una relación Ri para cada subtipo Bi, que incluye... § atributos del subtipo Bi § clave ajena hacia la PK de R (N propagación en cascada) § la clave primaria es la clave ajena a la clave primaria de R P B2B1 d 7.2 Diseño lógico estándar Traducción de especialización/generalización (7) Tema 7. Diseño Lógico de Bases de Datos 44 CREATE TABLE Documento ( código ... PRIMARY KEY, idioma ... , título ... ) ; CREATE TABLE Artículo ( código ... PRIMARY KEY REFERENCES Documento (código) ON DELETE CASCADE ON UPDATE CASCADE revista ... , fecha ... ) ; CREATE TABLE Libro ( código ... PRIMARY KEY REFERENCES Documento (código) ON DELETE CASCADE ON UPDATE CASCADE, edición ... , editorial ... ); 7.2 Diseño lógico estándar Traducción de especialización/generalización (8) [MPM 1999] Ejemplo de transformación total con jerarquía disjunta y parcial código LIBROARTÍCULO título idioma edición editorial tipo revista fecha DOCUMENTO
23 Tema 7. Diseño Lógico de Bases de Datos 45 Transformación total J Ventajas – Es válida para E/G de todo tipo (parcial/total – disjunta/solapada) – Quizá es «la mejor» desde el punto de vista semántico – Conviene si las operaciones son estrictamente «locales» a los subtipos o bien al supertipo, es decir, si casi nunca se accede a la vez a atributos de subtipo y supertipo L Inconvenientes – Menos eficiente en el acceso a todos los atributos (propios y heredados) de las instancias de un subtipo (¿Por qué?) 7.2 Diseño lógico estándar Traducción de especialización/generalización (9) Tema 7. Diseño Lógico de Bases de Datos 46 3. Transformación guiada por los subtipos • Hay muchos atributos no comunes (en subtipos) • Existen pocos atributos comunes (en supertipo) • Las operaciones que acceden a atributos de subtipos siempre afectan también a datos comunes ðð Una relación Ri para cada subtipo que contiene... – atributos del subtipo Bi y – atributos comunes (del supertipo) – La clave primaria de Ri es el identificador principal del supertipo P B2B1 d 7.2 Diseño lógico estándar Traducción de especialización/generalización (10)
24 Tema 7. Diseño Lógico de Bases de Datos 47 CREATE TABLE Artículo ( código ... PRIMARY KEY título ..., idioma ..., revista ... , fecha ... ) ; CREATE TABLE Libro ( código ... PRIMARY KEY título ..., idioma ..., edición ... editorial ... ); 7.2 Diseño lógico estándar Traducción de especialización/generalización (11) [MPM 1999] Ejemplo de transformación guiada por los subtipos código LIBROARTÍCULO título idioma edición editorial tipo revista fecha DOCUMENTO Tema 7. Diseño Lógico de Bases de Datos 48 Transformación guiada por los subtipos J Ventajas – Conviene si el concepto que representa el supertipo no se requiere en el esquema lógico de la base de datos – Acceso muy eficiente a toda la información de un subtipo: el esquema ya incluye la «reunión» de las tablas correspondientes a supertipo y subtipo – Válida para jerarquías E/G totales y exclusivas L Inconvenientes – Con jerarquías solapadas aparecen «repeticiones» – Con jerarquías parciales surgen problemas de «falta de representación» – Para obtener cierta instancia del supertipo, hay que buscar en todas las tablas correspondientes a los subtipos 7.2 Diseño lógico estándar Traducción de especialización/generalización (y 12)
25 Tema 7. Diseño Lógico de Bases de Datos 49 • Conocer el SGBD elegido para la implementación ¿Soporta el Modelo de Datos de Representación? ¿Hasta qué punto? ¿Cómo escribir el ELE con la sintaxis propia del modelo de datos del SGBD? • Estudiar la correspondencia entre los conceptos de los Modelos de Datos de Representación y del SGBD Pueden darse dos casos: – SGBD con soporte total del MLS sin restricciones § Transformación (casi) directa al SQL propio del SGBD – SGBD no soporta algunos conceptos o sí lo hace pero con limitaciones § 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 7.3 Diseño lógico específico Tema 7. Diseño Lógico de Bases de Datos 50 • Algunos productos comerciales ofrecen sintaxis de definición de dominios, pero no implementan la semántica asociada – Según Codd (1990) el uso de dominios incluye estas ventajas • 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, etc.), • Posibilidad de creación de operadores y características propias de los dominios, • Facilitar la definición de comprobaciones del SGBD (menor/mayor que), • Simplificar operaciones complejas sobre varias columnas, haciendolas directamente sobre el dominio • La mayoría de SGBD no ofrece soporte para dominios – Definir tipo de datos, longitud, restricciones para cada atributo – Tablas de Dominio y – Procedimientos de comprobación de valores correctos (integridad) 7.3 Diseño lógico específico Dominios
26 Tema 7. Diseño Lógico de Bases de Datos 51 • 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 no nulo – Asegurar que la combinación de todos los componentes de la PK tenga valores únicos (tras inserciones y actualizaciones) – Si el SGBD lo soporta, incluir la definición sintáctica de cada clave primaria en el esquema, y si no lo soporta, incluir la definición como comentario en el catálogo del SGBD Nota: en el estándar SQL-92 no es obligatorio especificar la PK de una relación, y en los productos comerciales tampoco (por compatibilidad con versiones anteriores) 7.3 Diseño lógico específico Claves primarias Tema 7. Diseño Lógico de Bases de Datos 52 • El mecanismo de integridad referencial puede penalizar los tiempos de respuesta del sistema – Borrados y actualizaciones propagados en cascada – importante en consultas interactivas, sobre todo ð implementación de la integridad referencial «en diferido» • Algunos SGBD soportan este concepto – Oracle7 y posteriores versiones • Pero otros lo incluyen sólo a nivel sintáctico y no implementan la semántica asociada (Oracle6) • Otros permiten crear un procedimiento (almacenado en el catálogo) que implementa cada clave ajena 7.3 Diseño lógico específico Claves externas
27 Tema 7. Diseño Lógico de Bases de Datos 53 • Si el SGBD elegido no soporta este concepto, entonces... – Introducir las restricciones de clave ajena como requisitos de especificación de los programas – Si el SGBD lo soporta, incluir la definición sintáctica de cada clave ajena en el esquema de BD, si no lo soporta, incluir la definición como comentario en el catálogo del SGBD – Utilizar mecanismos de seguridad (GRANT, REVOKE) para prohibir operaciones de actualización que pueden violar la RI referencial – Crear un procedimiento que periódicamente compruebe y notifique posibles violaciones de la RI referencial 7.3 Diseño lógico específico Claves externas (y 2) Tema 7. Diseño Lógico de Bases de Datos 54 • Será necesario crear procedimientos y/o disparadores (triggers) que verifiquen las restricciones de integridad definidas en la fase de Diseño Lógico Estándar • Si el SGBD lo permite, serán almacenados en el catálogo • Si no, serán parte de los programas de aplicación – Restricciones de integridad como especificaciones de procesos 7.3 Diseño lógico específico Otros conceptos del modelo relacional