La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

1 Objetivos: –Conocer los conceptos y notación del modelo conceptual de datos entidad-relación extendido. –Comprender los significados del concepto de.

Presentaciones similares


Presentación del tema: "1 Objetivos: –Conocer los conceptos y notación del modelo conceptual de datos entidad-relación extendido. –Comprender los significados del concepto de."— Transcripción de la presentación:

1 1 Objetivos: –Conocer los conceptos y notación del modelo conceptual de datos entidad-relación extendido. –Comprender los significados del concepto de nulo en el modelo entidad-relación extendido. Contenidos: 1. Introducción e historia del modelo 2. Conceptos básicos del modelo 3. Extensiones del modelo 3. Modelo Entidad-Relación

2 2 Modelo de datos conceptual de alto nivel Propuesto por Peter P. Chen en 1976 –Extensiones/aportaciones de muchos otros autores »No existe un único MER, sino una FAMILIA DE MODELOS Es un modelo semántico, surge por la necesidad de tener un modelo más cercano al usuario Describe el mundo real como un conjunto de ENTIDADES y de RELACIONES entre ellas Gran difusión –Muy extendido en los métodos de diseño de bases de datos –Soportado por herramientas software de diseño (CASE) 3.1. Introducción e historia del modelo Entidad- Relación

3 3 Descripción concisa de los requisitos de información de los usuarios –Descripciones detalladas de TIPOS DE DATOS RELACIONES ENTRE DATOS RESTRICCIONES que los DATOS deben cumplir Sin detalles de implementación –Más fácil de entender –Comunicación con el usuario no técnico Esquema conceptual 3.1. Introducción e historia del modelo Entidad-Relación

4 Conceptos básicos del modelo Entidad ( entity ) Atributo ( attribute ) Dominio ( values set ) Relación ( relationship )

5 5 ENTIDAD Cosa u objeto del mundo real con existencia propia y distinguible del resto Objeto con existencia... –física o real (una persona, un libro, un empleado ) –abstracta o conceptual (una asignatura, un viaje ) Persona, lugar, cosa, concepto o suceso, real o abstracto, de interés para la empresa (ANSI, 1977) 3.2. Conceptos básicos del modelo

6 6 ATRIBUTO Propiedad o característica de una entidad Una entidad particular es descrita por los valores de sus atributos: titulo = El alquimista impaciente genero = Thriller nacionalidad = España añoestreno = 2002 p1... nss = dni = nombre = Cristina Aliaga Gil nacionalidad = España e Conceptos básicos del modelo

7 7 TIPO DE ENTIDAD (entity set) Define un conjunto de entidades que poseen los mismos atributos PELICULA : titulo, genero, nacionalidad, añoestreno,numcopias EMPLEADO : dni, nss, nombre, fechanacim, direccion, telefono, altura, nacionalidad, edad Notación EMPLEADO LOCAL VIDEOCLUB PELICULADIRECTOR ACTOR CLIENTE 3.2. Conceptos básicos del modelo

8 8 Instancia de un tipo de entidad También... –Ocurrencia –Realización –Ejemplar –Entidad concreta o individual PELICULA titulo = El señor de los anillos genero = Fantasía nacionalidad = EEUU añoestreno = 2001 p2... titulo = Amelie genero = Comedia nacionalidad = Francia añoestreno = 2001 p4... titulo = Amores perros genero = Drama nacionalidad = Méjico añoestreno = 1999 p Conceptos básicos del modelo

9 9 Intensión y Extensión Un tipo de entidad describe el esquema o intensión para un conjunto de entidades que poseen la misma estructura EMPLEADO: dni, nss, nombre, dirección, telefono, altura, fechanacim, nacionalidad, edad Las instancias del tipo de entidad se agrupan en un conjunto de entidades o extensión e1 ( , , Cristina Aliaga Gil, Libertad, 2. Yecla. Murcia , , 160, 28/07/1979, España, 23) e2 ( , , Antonio Gil Sánchez, Paz, 5. Murcia. Murcia.30012, , 176, 14/04/1944, España, 58) e3 ( , , Julia Sauce, Justicia, 20. Yecla. Murcia , , 159, 23/05/1947, España, 55) Conceptos básicos del modelo

10 10 Tipos de atributos Simples o Compuestos Almacenados o Derivados Monovalorados o Multivalorados Opcionales 3.2. Conceptos básicos del modelo

11 11 Atributos Simples o Compuestos Atributos compuestos –Pueden dividirse en otros con significado propio –Valor compuesto = concatenación de valores de componentes Atributos simples –No divisibles. Atómicos fechanacim diamesaño direccion calleciudadprovinciacodpostal genero 3.2. Conceptos básicos del modelo

12 12 Atributos Almacenados o Derivados Atributos derivados –Valor calculado a partir de otra información ya existente (atributos, entidades relacionadas) –Son información redundante... edad [de EMPLEADO ], cálculo a partir de fechanacim »atributo derivado del valor de otro atributo numcopias [de una PELICULA ], cuenta del número de entidades COPIA relacionadas con cada película concreta »atributo derivado de entidades relacionadas Atributos almacenados fechanacim [de cada EMPLEADO ] nacionalidad [de una PELICULA ]

13 13 Atributos Monovalorados o Multivalorados Atributos monovalorados (monovaluados) –sólo un valor para cada entidad fechanacim [de un EMPLEADO particular] añoestreno [de cada PELICULA concreta] Atributos multivalorados (multivaluados) –más de un valor para la misma entidad nacionalidad [ PELICULA coproducida por varios países ] telefono [ EMPLEADO con varios teléfonos de contacto] –pueden tener límites superior e inferior del número de valores por entidad nacionalidad (1-2) telefono (0-3)

14 14 Atributos Opcionales (nulos) El nulo ( null value ) es usado cuando... –Se desconoce el valor de un atributo para cierta entidad El valor existe pero falta altura [de un EMPLEADO ] No se sabe si el valor existe o no telefono [de un EMPLEADO ] –La entidad no tiene ningún valor aplicable para el atributo: fechaalquiler [ PELICULA sólo en vídeo-venta (no alquiler)]

15 15 Notación para atributos [EN2002] (0,3) dirección (1,2) (0,1) EMPLEADO nombre fechanacim telefono calle provincia ciudad codpostal edad nss dni altura nacionalidad

16 16 Atributos Clave Atributo con valor distinto para cada instancia de un tipo de entidad dni en EMPLEADO Una clave identifica de forma única cada entidad concreta atributo identificador Notación EMPLEADO [EN2002] dni

17 17 Atributos Clave (ii) Una clave puede estar formada por varios atributos clave compuesta –Combinación de valores distinta para cada instancia (nombre, fechanacim) en el tipo de entidad EMPLEADO –Una clave compuesta debe ser mínima Un tipo de entidad puede tener más de una clave claves candidatas Claves o Identificadores Candidatos de EMPLEADO : – dni – nss – (nombre, fechanacim)

18 18 Atributos Clave (iii) Atributo identificador principal ( IP ) –Clave Principal –Elegido (por el diseñador) de entre los identificadores candidatos (IC), para ser el medio principal de identificación de las instancias del tipo de entidad – dni en EMPLEADO Atributos identificadores alternativos ( IA ) –Claves Alternativas –El resto de ICs – nss y (nombre, fechanacim) en EMPLEADO

19 19 Notación para atributos clave [EN2002] En el MER es obligatorio que todo tipo de entidad tenga un identificador (0,3) (1,2) (0,1) EMPLEADO nombre fechanacim telefono calle provincia ciudad codpostal edad nss dni altura nacionalidad n-f dirección IP

20 20 No suele representarse, aunque una forma de hacerlo sería: [MPM1999] DOMINIO (values set) Conjunto de valores Cada atributo simple está asociado a un dominio, que especifica sus valores válidos AtributoDominioDescripción Dominio nombre NOMBREScadenas de hasta 30 caracteres alfabéticos telefono TELEFONOScadenas de hasta 9 caracteres numéricos altura MEDIDASnúmeros reales entre 0 y 25 (metros)... TELEFONOS NOMBRES telefono nombre MEDIDAS altura EMPLEADO

21 21 RELACIÓN (relationship) También interrelación Asociación, vínculo o correspondencia entre instancias de entidades relacionadas de alguna manera en el mundo real –el director Alejandro Amenábar ha rodado la película Mar adentro –el empleado trabaja en el local de videoclub principal –la película El imperio contraataca es una continuación de la película La guerra de las galaxias

22 22 DIRECTORHA_RODADOPELICULA J. Médem C. Saura F. Trueba S. Segura A. Amenábar Vacas Tesis Belle Epoque Torrente Tierra n Abre los ojos n Los otros Tipo de Relación: conjunto de instancias Tipo de Entidad: conjunto de instancias Instancia del tipo de relación

23 23 TIPO DE RELACIÓN (relationship set) Estructura genérica o abstracción del conjunto de relaciones existentes entre dos o más tipos de entidad un DIRECTOR ha rodado PELICULA s Notación DIRECTORPELICULA HA_RODADO

24 24 ACTOR PELICULA ACTUA_EN CLIENTE PELICULA LOCAL_VIDEOCLUB ALQUILA Grado de un tipo de relación Número de tipos de entidad que participan en el tipo de relación –Binaria: grado 2 (el más frecuente) –Ternaria: grado 3 –Reflexiva (o recursiva): grado 1 PELICULA CONTINUACION DE

25 25 Nombres de Rol (papel) Todo tipo de entidad que participa en un tipo de relación juega un papel específico en la relación Los nombres de rol se deben usar, sobre todo, en los tipos de relación reflexivos, para evitar ambigüedad original versión PELICULA VERSION_DE DIRECTOR PELICULA HA_RODADO realizadorfilm

26 26 Restricciones estructurales sobre tipos de relación Limitan las posibles combinaciones de entidades que pueden participar en las relaciones Extraídas de la situación real que se modela Una película debe haber sido dirigida por uno y sólo un director Un director ha dirigido al menos una película y puede haber dirigido muchas Clases de restricciones estructurales: –Razón de cardinalidad (o tipo de correspondencia) –Razón de participación

27 27 Razón de Cardinalidad Notación [EN2002] Número máximo de instancias de tipo de relación en las que puede participar una misma instancia de tipo de entidad –la cardinalidad de HA_RODADO es 1 a N –HA_RODADO es de tipo 1 a N Notación –etiqueta en la línea que une entidad y relación –Ojo: da la sensación de que se representa al revés 1 N DIRECTOR PELICULA HA_RODADO

28 28 Razones de cardinalidad más comunes: –1:1 ( uno a uno ) –1:N ( uno a muchos ) –M:N ( muchos a muchos ) Razón de Cardinalidad (ii) [EN2002] ACTOR PELICULA personaje film M ACTUA_EN N EMPLEADO LOCAL_VIDEOCLUB encargado sucursal 1 trabajador lugar trabajo 1 TRABAJA_ENSUPERVISA N 1

29 29 Razón de Participación Notación [EN2002] Especifica si toda la extensión de un tipo de entidad participa en un tipo de relación, o sólo parte de la extensión Indica si hay dependencia en existencia de un tipo de entidad respecto de un tipo de relación Clases de participación: –Participación total (dependencia en existencia) –Participación parcial

30 30 Razón de Participación (ii) [EN2002] Notación –Líneas dobles o simples EMPLEADO LOCAL_VIDEOCLUB encargado sucursal 1 trabajador lugar trabajo 1 TRABAJA_ENSUPERVISA N 1 DIRECTOR PELICULA HA_ RODADO 1 N PELICULA personaje film M ACTUA_EN N ACTOR

31 31 Cardinalidad de tipo de entidad Otra forma de expresar las razones de cardinalidad y participación PERSONA EDIFICIO p1 p2 p3 e1 e2 e3 e4 USA p1 p2 p3 e1 e2 e3 e4 POSEE PERSONA EDIFICIO POSEE PERSONA USA EDIFICIO

32 32 Cardinalidad de tipo de entidad (ii) Notación [EN2002] Números mínimo y máximo de instancias del tipo de relación en las que puede intervenir una instancia del tipo de entidad Notación – (min, max) en la línea que une entidad y relación POSEE PERSONA USA EDIFICIO (1,n)(0,m) (1,1) (0,n)

33 33 Cardinalidad de tipo de entidad (iii) [EN2002] EMPLEADO LOCAL_VIDEOCLUB 1 1 TRABAJA_ENSUPERVISA N 1 (0,n) (1,1) EMPLEADO LOCAL_VIDEOCLUB TRABAJA_ENSUPERVISA PELICULA M ACTUA_EN N ACTOR PELICULA (1,n) ACTUA_EN (0,m) ACTOR

34 34 Cardinalidad de tipo de entidad (vii) [ EN2002 ] N 1 subalterno superior (0,1) (0,n) EMPLEADO JEFE DE Cardinalidad de tipos de entidad recursivos

35 35 Atributos de tipos de relación Similares a los atributos de tipos de entidad [EN2002] EMPLEADO LOCAL_VIDEOCLUB 1 1 TRABAJA_ENSUPERVISA N 1 horasfechainicio

36 36 Atributos de tipos de relación (ii) Conceptualmente pertenecen a la relación –Un atributo de una M:N es propio de la relación –Un atributo de una 1:1 o 1:N se puede llevar a uno de los tipos de entidad participantes horasfechainicio [EN2002] horas fechainicio EMPLEADO 1 1 TRABAJA_ENSUPERVISA N 1 LOCAL_VIDEOCLUB

37 37 Tipo de Entidad Débil Notación [EN2002] No tiene atributos clave propios Una instancia se identifica por su relación con una instancia de otro tipo de entidad –Tipo de relación identificador Relaciona un tipo de entidad débil y un tipo de entidad regular (fuerte, dominante, padre, propietaria) –Clave parcial (o discriminante) Atributos de la entidad débil, que identifican de forma única cada instancia, siempre que esté relacionada con una instancia del tipo de entidad regular –Clave = (clave_entidad_regular, clave_parcial) Notación COPIA

38 38 Tipo de entidad débil (ii) [EN2002] PELICULA numcopia titulo 1 N COPIA TIENE PACIENTE VISITA_MEDICA diahora 1 nss N MEDICO ncolegiado nombre N 1 especialidad ACUDE ASISTIDA POR Tipo de Relación Identificador Clave parcial o Discriminante Tipo de Entidad Regular Dependencia en existencia

39 39 EMPLEADO numlicencia dni 1 N PERMISO CONDUCCION POSEE tipo Tipo de entidad débil (iii) [EN2002] No toda participación total (o dependencia en existencia) implica un tipo de entidad débil PERMISO_CONDUCCIÓN no es débil: depende en existencia de EMPLEADO, pero tiene clave primaria propia

40 40 Tipos de relación con grado superior a dos Tipo de relación ternaria [EN2002] CLIENTE CINTA VIDEO LOCAL VIDEOCLUB ALQUILA (0,1) (0,n) (0,m) Cardinalidad de los tipos de entidad fecha

41 41 Tipos de relación con grado superior a dos (ii) Equivalencia ternaria – varias binarias [EN2002] CLIENTE CINTA VIDEO LOCAL VIDEOCLUB ALQUILA (0,1) (0,n) (0,m) fecha LOCAL VIDEOCLUB ALQUILA (1,m) (0,1) (1,n) (0,n) (1,1) (1,n) CONTIENE fecha ALQUILA_EN CINTA VIDEO CLIENTE

42 42 Tipos de relación con grado superior a dos (iii) Ternaria no equivalente a varias binarias [EN2002] TIENDA (1,m) (1,n) (0,n) (1,m) VENDE PROVEE PUEDE SUMINISTRAR PRODUCTO PROVEEDOR PRODUCTO TIENDA (0,m) (1,n) (1,p) SUMINISTRA idprov codpr nombre cantidad fecha PROVEEDOR Pérdida de semántica...

43 43 Aportaciones de diversos autores al modelo Entidad-Relación «básico». Permiten representar... –Relaciones exclusivas entre sí –Jerarquías de Especialización/Generalización Modelo Entidad-Relación Extendido, MERE Enhanced Entity-Relationship model, EER

44 44 Dos (o más) tipos de relación son exclusivos, respecto de un tipo de entidad que participa en ambos, si cada instancia del tipo de entidad sólo puede participar en uno de los tipos de relación GASOLINA GASTA CONSUME GASOIL Relaciones Exclusivas 3.3. Extensiones del modelo CONSUME y GASTA son exclusivas respecto del tipo de entidad VEHICULO VEHÍCULO

45 45 Caso especial de relación entre un tipo de entidad y varios otros tipos de entidad La jerarquía o relación que se establece entre uno y otros corresponde a la noción de es_un o de es_un_tipo_de Estas jerarquías pueden formarse por especialización o bien por generalización Especialización/Generalización (E/G) 3.3. Extensiones del modelo

46 46 Agrupación de instancias dentro de un tipo de entidad, que debe representarse explícitamente debido a su importancia para el diseño o aplicación –Subtipos del tipo de entidad VEHÍCULO : CAMIÓN TURISMO AUTOBÚS CICLOMOTOR –Subtipos del tipo de entidad EMPLEADO : SECRETARIO GERENTE COMERCIAL El tipo de entidad que se especializa en otros se llama supertipo ( VEHICULO, EMPLEADO ) E/G: Subtipo de un tipo de entidad 3.3. Extensiones del modelo

47 47 Es la relación que se establece entre un supertipo y cada uno de sus subtipos (noción es_un o es_un_tipo_de ) Notación: EMPLEADO [EN2002] E/G: Relación Supertipo/Subtipo 3.3. Extensiones del modelo SECRETARIOGERENTECOMERCIAL

48 48 La extensión de un subtipo es un subconjunto de la extensión del supertipo –Una instancia de subtipo también es instancia del supertipo y es la misma instancia, pero con un papel específico distinto –Una instancia no puede existir sólo por ser miembro de un subtipo: también debe ser miembro del supertipo –Una instancia del supertipo puede no ser miembro de ningún subtipo E/G: Relación Supertipo/Subtipo (ii) 3.3. Extensiones del modelo VEHÍCULO CICLOMOTORCAMIÓN TURISMO

49 49 Un subtipo puede tener atributos propios (específicos) y participar en relaciones por separado Un subtipo hereda todos los atributos del supertipo, y toda relación en la que participa el supertipo –Un subtipo, con sus atributos y relaciones específicos, más los atributos y relaciones que hereda del supertipo, es un tipo de entidad por derecho propio VEHÍCULO CAMIÓN FABRICANTE SIDECAR FABRICA LLEVA numBastidor precio numEjes tonelaje numPuer numPlazascilindrada (1,1)(1,n) (1,1) (0,1) TURISMO N:1 1:1 MOTOCICLETA E/G: Herencia de tipo 3.3. Extensiones del modelo

50 50 Proceso de definición de un conjunto de subtipos de un tipo de entidad (» supertipo) Subtipos suelen estar definidos según característica distintiva de las entidades del supertipo –Discriminante de la especialización E/G: Especialización 3.3. Extensiones del modelo EMPLEADO actividad SECRETARIOGERENTECOMERCIAL

51 51 Varias especializaciones de un tipo de entidad, con base en diferentes discriminantes PELÍCULA color género [EN2002] E/G: Especialización (ii) 3.3. Extensiones del modelo COLORBLANCO_Y_NEGROCOMEDIADRAMATERROR

52 52 Conviene incluir relaciones subtipo/supertipo si hay... –Atributos que sólo tienen sentido para algunas instancias de un tipo y no para todas (atributos específicos) especialidadMédica «no es aplicable» a CELADOR –Tipos de relación en los que sólo participan algunas entidades de un tipo y no todas (relaciones específicas) Relación SUPERVISA entre CELADOR y SECCIÓN_HOSPITAL SUPERVISA (1,1) E/G: Especialización (iii) 3.3. Extensiones del modelo CELADORSECCIÓN_HOSPITAL

53 53 Proceso inverso de la especialización Suprimir diferencias entre varios tipos de entidad: identificar atributos y relaciones comunes, y formar un supertipo que los incluya numBastidor precio numEjes TURISMO fechaFab numBastidor precio numEjestonelaje numPuer fechaFab numBastidor precio fechaFab CAMIÓN TURISMO CAMIÓN numPuer tonelaje VEHÍCULO [EN2002] G E/G: Generalización 3.3. Extensiones del modelo

54 54 Generalización Énfasis en las similitudes Cada instancia del supertipo es también una instancia de alguno de los subtipos Especialización Énfasis en las diferencias Alguna instancia del supertipo puede no ser instancia de ningún subtipo E/G: Generalización vs. Especialización 3.3. Extensiones del modelo

55 55 Definición ¿Qué instancias del supertipo pertenecen a cada subtipo? Disyunción/Solapamiento ¿A cuántos subtipos puede pertenecer (a la vez) una instancia del supertipo? Completitud/Parcialidad ¿Debe toda instancia del supertipo pertenecer a algún subtipo? Restricciones sobre la E/G 3.3. Extensiones del modelo

56 56 Subtipos definidos por predicado o condición –Condición de pertenencia a cada subtipo con base en el valor de algún atributo del supertipo –Restricción que especifica que... Las instancias del subtipo deben satisfacer la condición Todas las instancias del supertipo que cumplen la condición, deben pertenecer al subtipo PERSONA EMPLEADO ESTUDIANTE estadoLaboral=en_activo matriculado=true [EN2002] Restricciones sobre la E/G: Definición 3.3. Extensiones del modelo

57 57 Subtipos definidos por atributo –Todas las subclases definen la condición de pertenencia en términos del mismo atributo –... es el discriminante de la especialización en_activo en_paro estadoLaboral claseTrabajo médico celador limpiadorenfermero [EN2002] Restricciones sobre la E/G: Definición (ii) 3.3. Extensiones del modelo PERSONA EMPLEADO PARADO EMPLEADO_HOSPITAL ENFERMERO MÉDICO CELADOR LIMPIADOR

58 58 Subtipos definidos por el usuario –No existe (o no interesa definir) ninguna condición de pertenencia a los subtipos –El usuario, al insertar una instancia, elige a qué subtipo pertenece Restricciones sobre la E/G: Definición (iii) 3.3. Extensiones del modelo PROFESOR TITULARAYUDANTEASOCIADO

59 59 Subtipos disjuntos si una instancia del supertipo puede ser miembro de, como máximo, uno de los subtipos VEHÍCULO TURISMO CAMIÓN d [EN2002] Restricciones sobre la E/G: Disyunción/Solapamiento 3.3. Extensiones del modelo Subtipos solapados si una instancia del supertipo puede ser, a la vez, miembro de más de un subtipo Es la opción «por defecto» PERSONA EMPLEADO ESTUDIANTE o

60 60 Especialización total (completa) indica que toda instancia del supertipo también debe ser instancia de algún subtipo ANIMAL d Restricciones sobre la E/G: Completitud/Parcialidad 3.3. Extensiones del modelo MACHOHEMBRAHERMAFRODITA Especialización parcial indica que es posible que alguna instancia del supertipo no pertenezca a ninguno de los subtipos Es la opción «por defecto» La unión de las extensiones de los subtipos no es la extensión del supertipo en su totalidad ALIMENTO d LACTEOFRUTAVERDURA

61 61 Las restricciones de disyunción y completitud son independientes entre sí Dan lugar a 4 tipos de especialización: –Disjunta y Total –Disjunta y Parcial –Solapada y Total –Solapada y Parcial Lo veremos con un ejemplo de una base de datos de una Universidad 3.3. Extensiones del modelo E/G: Tipos de Especialización

62 62 EMPLEADO claseTrabajo ESTUDIANTE tipo 3.3. Extensiones del modelo E/G: Especialización Disjunta y Total DOCENTEBECARIO NO_BECARIOADMON_Y_SERV Especialización Disjunta y Parcial DOCENTE TITULAR AYUDANTE CATEDRÁTICO cuerpoDocente d d d

63 Extensiones del modelo E/G: Especialización Solapada y Total Especialización Solapada y Parcial EMPLEADO ocupación ESTUDIANTE PERSONA EMPLEADO DOCENTEINVESTIGADOR dedicación O O

64 64 Deben aplicarse a la Especialización y la Generalización, debido a las restricciones definidas Insertar una instancia en un supertipo implica insertarla en todos los subtipos definidos por predicado o por atributo, para los cuales satisface el predicado de definición Insertar una instancia en un supertipo de una especialización total implica insertarla en, al menos, un subtipo Y si la especialización es disjunta, entonces la instancia se insertará en un único subtipo 3.3. Extensiones del modelo E/G: Reglas de inserción y eliminación

65 65 Eliminar una instancia de un supertipo implica eliminarla de todos los subtipos a los que pertenece Eliminar una instancia de un subtipo implica eliminarla del supertipo si la especialización es... –disjunta y total, o bien –solapada y total, y la instancia ya sólo pertenece al subtipo (se eliminó del resto) En el resto de casos, la instancia sólo se elimina del subtipo –No del supertipo ( lo haría el usuario, si fuese necesario) 3.3. Extensiones del modelo E/G: Reglas de inserción y eliminación (ii)

66 66 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 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 Objetivos y fases del diseño lógico

67 67 Diseño Lógico Estándar (DLS) –Se elige el modelo de datos de representación, aún 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 Objetivos y fases del diseño lógico Fases

68 68 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, Postgress, Sybase... Se describe el ELE mediante el LDD propio del SGBD específico SQL de Oracle, Objetivos y fases del diseño lógico Fases (y 2)

69 69 Reglas de traducción MERE MR Reglas para el modelo básico Dominios Atributos Tipos de entidad Tipos de relación Reglas para las extensiones del modelo Relaciones exclusivas Jerarquías de Especialización/Generalización Diseño lógico estándar MER MR (SQL-92) Tipo de Entidad Tabla (relación) Tipo de Relación M:N Tabla Tipo de Relación 1:1, 1:N, N:1 Propagación de clave o tabla RESUMEN

70 70 Dominio Tipo de entidad –Se traduce a una tabla (relación) –Se recomienda usar el mismo nombre o uno similar PERSONA CREATE TABLE Persona (... ) ; MERE MR 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) ;

71 71 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 Diseño lógico estándar Traducción de un atributo PERSONA direccion telefono dni numSS fechaNacim nombre nacionalidad altura CREATE TABLE Persona ( dni PRIMARY KEY, numSS UNIQUE NULL, nombre..., direccion..., telefono..., fechaNacim..., nacionalidad..., altura... ) ; MERE MR

72 72 Atributo compuesto.- Dos alternativas: a)«Eliminar» atributo compuesto y considerar todos sus componentes como columnas simples de la tabla resultante b)«Eliminar» los componentes y considerar el atributo compuesto como una sola columna de la tabla ¿Cuándo será más adecuado utilizar una opción u otra? Diseño lógico estándar Traducción de un atributo (2) MERE MR (DED)

73 73 DIRECC_ PERSONA Atributo multivalorado –Nueva tabla S, en la que el atributo multivalorado se representa como una columna simple A –S contendrá una nueva columna F, clave ajena a la clave primaria de la tabla correspondiente a la entidad –La clave primaria de S es la combinación (F, A) PERSONA (dni, nombre, fechaNac) DIRECC_PERSONA ( dni, direccion ) FK Diseño lógico estándar Traducción de un atributo (3) PERSONA MR (DED) tiene PERSONA fechaNac dni direccion (1,n) nombre MERE MR CREATE TABLE Direcc_Persona ( dni... direccion... PRIMARY KEY (dni, direccion) FOREIGN KEY (dni) REFERENCES Persona(dni) ON DELETE CASCADE ON UPDATE CASCADE );

74 74 Atributo derivado –Es necesario decidir si se almacena o no 1.Si se almacena, será una columna de la tabla que corresponda y deberá crearse un disparador que calcule su valor y lo mantenga actualizado 2.Si no se almacena, deberá crearse un procedimiento que calcule su valor cada vez que se solicita PERSONA (dni, nombre, fechaNac, edad ) Diseño lógico estándar Traducción de un atributo (y 4) MERE MR PERSONA fechaNac dni edad nombre

75 75 Nueva tabla 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 – columnas correspondientes a los atributos de la relación V (simples o componentes simples de atributos compuestos) ACTOR(nombre,..., caché,...) ACTUA_EN ( actor, pelicula, papel, paga ) PELICULA(código, título,...) FK E1E2 V R1R2 R Diseño lógico estándar Traducción de una relación binaria M:N ACTORPELICULA paga (1,m)(1,n) título caché nombre código papel Actua en [MPM 1999]

76 76 AUTOR(codAutor, nomAutor,...) ESCRIBE ( autor, libro, derAutor, numPag ) LIBRO(isbn, titulo,...) FK Diseño lógico estándar Traducción de una relación binaria M:N (3) AUTORLIBRO numPaginas (1,4) (1,n) titulo nomAutor codAutor isbn derechosAutor Escribe – Pero la traducción, aunque lo parezca, no está completa... –... pues falta especificar ciertos aspectos que tienen que ver con las reglas de integridad

77 77 – Especificación de acciones de mantenimiento de la integridad referencial ( NO ACTION, CASCADE, SET NULL, SET DEFAULT ) CREATE TABLE Escribe ( autorAutores, libroCodigos, derAutorNUMERIC(2) DEFAULT 20 NOT NULL CHECK (derAutor0 AND derAutor<100), numPagNUMERIC(2) NOT NULL CHECK (numPag0), 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 ); Diseño lógico estándar Traducción de una relación binaria M:N (4)

78 78 a) Datos coherentes: evitar que ESCRIBE contenga un libro con autor desconocido (fila con autor NULL ) o un autor de un libro inexistente (fila con libro NULL ) Diseño lógico estándar Traducción de una relación binaria M:N (5) Especificación de restricciones autorlibroderAutornumPag NULL A001 NULL... – Ambas cosas ya quedan aseguradas por la propia definición de la clave primaria de ESCRIBE : PRIMARY KEY(autor, libro)

79 79 b) Cardinalidad mínima 1: todo libro tiene al menos un autor c) Cardinalidad máxima 4: evitar que un libro haya sido escrito por más de 4 autores – CREATE ASSERTION autores_de_libro CHECK ( ( NOT EXISTS (SELECT * FROM LIBRO WHERE isbn NOT IN (SELECT libro FROM ESCRIBE))) AND ( 4 >= (SELECT MAX (COUNT(*)) FROM ESCRIBE GROUP BY libro)) ); Diseño lógico estándar Traducción de una relación binaria M:N (6) Especificación de restricciones

80 80 d) Cardinalidad mínima 1: todo autor ha escrito al menos un libro – Evitar que en AUTOR exista una fila tal que NO haya ninguna tupla en ESCRIBE que le haga referencia (autor sin libros). – Es necesario crear una RI General o Aserto: CREATE ASSERTION libros_de_autor CHECK ( NOT EXISTS (SELECT * FROM AUTOR WHERE codAutor NOT IN (SELECT autor FROM ESCRIBE)) ); Diseño lógico estándar Traducción de una relación binaria M:N (y 7) Especificación de restricciones

81 81 1)Caso general Propagación de clave –En R2 se incluyen nuevas columnas... clave externa hacia la clave primaria de R1 columnas para los 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 E1E2 V R1R2 1 N PROVINCIACIUDAD (1,1) (1,n) nomProv codProv nombreCiudad contiene Diseño lógico estándar Traducción de una relación binaria 1:N...

82 82 1.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 Diseño lógico estándar Traducción de una relación binaria 1:N (2)

83 83 2)Se cumple uno o varios de estos supuestos: La relación V tiene varios atributos propios Hay pocas ocurrencias de la relación V Es probable que en el futuro V se transforme en una M:N Añadir una nueva tabla 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 columnas para los atributos de V (simples o componentes simples de atributos compuestos) ESTUDIANTE COCHE (0,1) (0,n) nif matricula Propietario_de modelo nombre 1 : N Diseño lógico estándar Traducción de una relación binaria 1:N (3) ESTUDIANTE( nif, nombre,... ) PROPIEDAD ( coche, estudiante ) COCHE( matricula, modelo,... ) FK FK NN

84 84 1)Participación total de ambas entidades –Si las entidades no participan en otras relaciones... una única tabla R, que incluye... –columnas para todos los atributos de ambas entidades –claves de R : Clave primaria = clave primaria de R1 o de R2 (es indiferente) La otra ( si es distinta ) será alternativa ( UNIQUE ) y además NOT NULL –columnas para atributos de la relación V (simples o componentes simples de atributos compuestos) PACIENTE ( nss, nombre, numHisto, fechaApert, centroSalud,... ) AK, NNPK Diseño lógico estándar Traducción de una relación binaria 1:1 nombre centroSalud (1,1) fechaApertura nss numHistoria... MEDICO HISTORIAL PACIENTE... Tiene

85 85 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) E1E2 V R1R2 EMPLEADO(codEmp, nomEmp,...) DEPARTAMENTO(numDep,nomDep, codDir, fechInicDir...) FK AK, NN Diseño lógico estándar Traducción de una relación binaria 1:1 (2) (1,1) (0,1) DEPARTAMENTO EMPLEADO codEmp nomEmpnomDep numDep Dirige fechaInic NN

86 86 2.2) Hay pocas instancias del tipo de relación Añadir una nueva tabla 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 –columnas para los atributos de V (simples o componentes simples de atributos compuestos) EMPLEADO(codEmp, nomEmp,...) DIRIGE ( emp, dep, fechInic ) DEPARTAMENTO(numDep, nomDep,...) FK AK,NN Diseño lógico estándar Traducción de una relación binaria 1:1 (3)

87 87 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,... ); 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 monovalorados aseguran que un empleado pueda dirigir como mucho un departamento Atributos de EMPLEADO Atributos de DEPARTAMENTO Atributos de DIRIGE

88 88 3)Participación parcial de ambas entidades Añadir una nueva tabla R La tabla 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) MUJER HOMBRE nif Matrimonio a la antigua fecha lugar HOMBRE(nif,...) MATRIMONIO ( esposa, esposo, fecha, lugar) MUJER(nif,...) 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? Diseño lógico estándar Traducción de una relación binaria 1:1 (y 5) NN

89 89 Caso particular de relación 1:1 o 1:N con propagación de clave y participación total de E2 Si V es 1:1 caso 2.1 ; Si V es 1:N caso 1.1 –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 E2 V R1R Diseño lógico estándar Traducción de dependencia en existencia y en identificación

90 90 EMPLEADO ( nifEmp, nomEmp,...) FAMILIAR ( nifFam, emp,... ) FK NOT NULL ON DELETE CASCADE ON UPDATE CASCADE 1:N FAMILIAR EMPLEADO (1,1) (0,n) nifFam nifEmp nomEmp Tiene Diseño lógico estándar Traducción de dependencia en existencia y en identificación (y 2) PACIENTE ( historial, nombre,... ) VISITA_MEDICA ( historial, fecha, hora,... ) FK NOT NULL ON DELETE CASCADE ON UPDATE CASCADE VISITA MEDICA PACIENTE 1:N (1,1) (1,n) fecha historial nombre observ Acude hora

91 91 EMPLEADO Es jefe de subordinado jefe nifEmp nomEmp 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 EMPLEADO ( nifEmp, nomEmp,... ) JEFE_EMP ( jefe, subordinado,... ) Caso M:N FK 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 )

92 92 Tabla R correspondiente a V, que incluye... –claves ajenas hacia cada clave primaria de R1, R2, R3, etc. –columnas para los 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 dicha clave E1E2 V R1R2 E3 R Diseño lógico estándar Traducción de una relación n-aria

93 93 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, sin coche, sin vendedor? 4.¿Puede reflejarse la existencia de ventas directas (sin banco)? 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]

94 94 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_xor_imparte CHECK ( ( director NOT IN (SELECT profesor FROM Curso) ) AND ( profesor NOT IN (SELECT director FROM Curso) ) )... ); Diseño lógico estándar Traducción de exclusividad de relaciones CURSO IMPARTE ORGANIZA PROFESOR (0,n) (1,1)

95 95 Ejemplo para relaciones de tipo M:N CREATE TABLE Alumno_Estudia_Titulacion ( alu... REFERENCES Alumno (numExp) ON DELETE CASCADE ON UPDATE CASCADE, titu... REFERENCES Titulacion (idTit) ON DELETE NO ACTION ON UPDATE CASCADE, PRIMARY KEY (alu, titu), CONSTRAINT titulacion_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_titulacion CHECK ( alum NOT IN (SELECT alu FROM Alumno_Estudia_Titulacion) ) ); Diseño lógico estándar Traducción de exclusividad de relaciones (2) [MPM 1999] cursa estudia ALUMNO (0,n) (1,n) TITULACIÓNMASTER

96 96 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 tabla R que contiene... –columnas para los atributos del supertipo P y los subtipos B1 y B2 –columna para 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 Diseño lógico estándar Traducción de especialización/generalización

97 97 CREATE TABLE Empleado_Universidad ( nif... PRIMARY KEY, nombre..., tipo... NOT NULL CHECK tipo IN (pro, bec, pas), categ... NULL, tipoBeca... NULL, activ... NULL,... ); 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 disjunta PARCIAL: PERMITE NULL EN TIPO d

98 98 CREATE TABLE Individuo ( nif... PRIMARY KEY, nombre..., fechanac..., estudia... NOT NULL CHECK (estudia IN (T, F)), curra... NOT NULL CHECK (curra IN (T, F)), titulacion... NULL, nss... NULL UNIQUE, salario... NULL,... CHECK ( (estudia = T AND titulacion IS NOT NULL) OR (estudia = F AND titulacion IS NULL) ), CHECK ( (curra = T AND nss IS NOT NULL AND salario IS NOT NULL) OR (curra = F AND nss IS NULL AND salario IS NULL) ) ); Diseño lógico estándar Traducción de especialización/generalización (3) Transformación guiada por el supertipo: Jerarquía solapada parcial Otra posibilidad: –Sólo una columna discriminante y valor extra para solapamiento: actividad... NULL CHECK (actividad IN (estudia, trabaja, est_trab)) Alternativa 1: INDIVIDUO nif CURRANTE ESTUDIANTE fechanac nombre nss salario actividad titulacion

99 99 CREATE TABLE Actividad_Individuo ( nifIndiv... REFERENCES Individuo( nif ) ON DELETE CASCADE ON UPDATE CASCADE, nomActiv..., CHECK (nomActiv IN (estudiar, trabajar)), PRIMARY KEY ( nifIndiv, nomActiv ) ); Diseño lógico estándar Traducción de especialización/generalización (4) Transformación guiada por el supertipo: Jerarquía solapada parcial –Un solo atributo discriminante, tratado como atributo multivalorado CREATE TABLE Individuo ( nif... PRIMARY KEY, nombre..., fechanac..., titulación... NULL, nss... NULL UNIQUE, salario... NULL,... ); Las restricciones semánticas son algo más complejas (asertos), como veremos a continuación Es más extensible que la Alternativa 1: introducir un nuevo subtipo no requiere alterar la tabla INDIVIDUO para añadir una columna, sino ajustar el CHECK de ACTIVIDAD_INDIVIDUO y añadir los asertos correspondientes Alternativa 2:

100 Diseño lógico estándar Traducción de especialización/generalización (6) Transformación guiada por el supertipo: Jerarquía solapada parcial 1.- Si es estudiante, titulacion no debe ser NULL CREATE ASSERTION Individuo_Estudiante_Ok CHECK (NOT EXISTS (SELECT * FROM Individuo WHERE titulacion IS NULL AND nif IN (SELECT nifIndiv FROM Actividad_Individuo WHERE nomActiv=estudiar))); (cont.) Restricciones de Integridad necesarias 2.- Si es trabajador, nss y salario no deben ser NULL CREATE ASSERTION Individuo_Trabajador_Ok CHECK (NOT EXISTS (SELECT * FROM Individuo WHERE nss IS NULL OR salario IS NULL AND nif IN (SELECT nifIndiv FROM Actividad_Individuo WHERE nomActiv=trabajar))); 3.- Puesto que la jerarquía es solapada, no hacen falta asertos que aseguren que si es trabajador, titulacion debe ser NULL ; ni que si es estudiante, nss y salario deben ser NULL Puesto que la jerarquía es parcial, no hace falta un aserto que asegure que todo individuo tiene actividad, es decir, que todo nif de INDIVIDUO aparece en la tabla ACTIVIDAD_INDIVIDUO Alternativa 2:

101 101 CREATE TABLE Universitario ( nif... PRIMARY KEY, nombre..., estudia... NOT NULL CHECK estudia IN (T, F), trabaja... NOT NULL CHECK trabaja IN (T, F), titulación... NULL, salario... NULL,... CHECK ( ( estudia = T AND titulacion IS NOT NULL ) OR ( trabaja = T AND salario IS NOT NULL ) ) ); Diseño lógico estándar Traducción de especialización/generalización (7) Transformación guiada por el supertipo: Jerarquía solapada total salariotitulacion Otras opciones: –Una sola columna discriminante –Tratar discriminante como un atributo multivalorado UNIVERSITARIO nombre CURRANTE ESTUDIANTE nss salario tipo titulacion o

102 102 Transformación guiada por el supertipo Ventajas –Acceso eficiente a toda la información sobre instancias de una entidad concreta: acceso a una sola tabla Inconvenientes – Aparición de nulos en columnas correspondientes a 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): acceso a toda la tabla con base en el valor de la columna correspondiente al discriminante Diseño lógico estándar Traducción de especialización/generalización (8)

103 103 2.Transformación total Los subtipos se diferencian en muchos atributos Se desea mantener los atributos comunes en una tabla separada Una tabla para cada entidad –una tabla R para el supertipo P, que incluye... columnas para los atributos de P la clave primaria es el identificador principal del supertipo –una tabla R i para cada subtipo B i, que incluye... columnas para los atributos del subtipo B i columna clave ajena hacia la clave primaria de R ( propagación en cascada ) la clave primaria es dicha clave ajena P B2 B1 d Diseño lógico estándar Traducción de especialización/generalización (9)

104 104 CREATE TABLE Documento ( codigo... PRIMARY KEY, idioma..., titulo... ) ; CREATE TABLE Articulo ( codigo...PRIMARY KEY REFERENCES Documento (codigo) ON DELETE CASCADE ON UPDATE CASCADE revista..., fecha... ) ; CREATE TABLE Libro ( codigo... PRIMARY KEY REFERENCES Documento (codigo) ON DELETE CASCADE ON UPDATE CASCADE, edicion..., editorial... ); Diseño lógico estándar Traducción de especialización/generalización (10) Ejemplo de transformación total con jerarquía disjunta y parcial El atributo discriminante no aparece en ninguna de las tablas resultado de la traducción codigo LIBRO ARTICULO titulo idioma editorial tipo DOCUMENTO d fecha revista edicion

105 105 Transformación total 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 subtipos y supertipo Inconvenientes –Menos eficiente en el acceso a todos los atributos (propios y heredados) de las instancias de un subtipo (¿Por qué?) Diseño lógico estándar Traducción de especialización/generalización (11)

106 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 tabla R i para cada subtipo que contiene... –columnas para los atributos del subtipo B i y –columnas para los atributos comunes (del supertipo) –la clave primaria de R i es el identificador principal del supertipo Diseño lógico estándar Traducción de especialización/generalización (12 )

107 107 CREATE TABLE Articulo ( codigo...PRIMARY KEY titulo..., idioma..., revista..., fecha... ) ; CREATE TABLE Libro ( codigo... PRIMARY KEY titulo..., idioma..., edicion... editorial... ); Diseño lógico estándar Traducción de especialización/generalización (13) Ejemplo de transformación guiada por los subtipos El atributo discriminante no aparece en ninguna de las tablas resultado de la traducción codigo LIBRO ARTICULO titulo idioma editorial tipo DOCUMENTO d fecha revista edicion

108 108 Transformación guiada por los subtipos 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 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 Diseño lógico estándar Traducción de especialización/generalización (y 14)

109 109 Conocer el SGBD elegido para la implementación ¿Soporta el Modelo de Datos de Representación? ¿Hasta qué punto? ¿Cómo escribir el ELS con la sintaxis propia del modelo de datos particular del SGBD comercial elegido? 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 algunos aspectos que necesitan transformaciones adicionales Diseño lógico específico


Descargar ppt "1 Objetivos: –Conocer los conceptos y notación del modelo conceptual de datos entidad-relación extendido. –Comprender los significados del concepto de."

Presentaciones similares


Anuncios Google