Subido pordanielaruizcardona
PPT, PDF371 vistas

Tema3 (1)

El documento presenta los conceptos y notación del modelo conceptual de datos entidad-relación extendido. Explica que el modelo Entidad-Relación describe el mundo real como un conjunto de entidades y relaciones entre ellas. Define los conceptos básicos como entidades, atributos, tipos de entidades, relaciones e introduce conceptos como claves, cardinalidades y restricciones.

Incrustar presentación

Descargar para leer sin conexión
1 / 109
2 / 109
3 / 109
4 / 109
5 / 109
6 / 109
7 / 109
8 / 109
9 / 109
10 / 109
11 / 109
12 / 109
13 / 109
14 / 109
15 / 109
16 / 109
17 / 109
18 / 109
19 / 109
20 / 109
21 / 109
22 / 109
23 / 109
24 / 109
25 / 109
26 / 109
27 / 109
28 / 109
29 / 109
30 / 109
31 / 109
32 / 109
33 / 109
34 / 109
35 / 109
36 / 109
37 / 109
38 / 109
39 / 109
40 / 109
41 / 109
42 / 109
43 / 109
44 / 109
45 / 109
46 / 109
47 / 109
48 / 109
49 / 109
50 / 109
51 / 109
52 / 109
53 / 109
54 / 109
55 / 109
56 / 109
57 / 109
58 / 109
59 / 109
60 / 109
61 / 109
62 / 109
63 / 109
64 / 109
65 / 109
66 / 109
67 / 109
68 / 109
69 / 109
70 / 109
71 / 109
72 / 109
73 / 109
74 / 109
75 / 109
76 / 109
77 / 109
78 / 109
79 / 109
80 / 109
81 / 109
82 / 109
83 / 109
84 / 109
85 / 109
86 / 109
87 / 109
88 / 109
89 / 109
90 / 109
91 / 109
92 / 109
93 / 109
94 / 109
95 / 109
96 / 109
97 / 109
98 / 109
99 / 109
100 / 109
101 / 109
102 / 109
103 / 109
104 / 109
105 / 109
106 / 109
107 / 109
108 / 109
109 / 109
3. Modelo Entidad-Relación 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 1
3.1. Introducción e historia del modelo EntidadRelación • 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) 2
3.1. Introducción e historia del modelo Entidad-Relación Esquema conceptual • 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 3
3.2. Conceptos básicos del modelo • • • • Entidad ( entity ) Atributo ( attribute ) Dominio ( values set ) Relación ( relationship ) 4
3.2. Conceptos básicos del modelo 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) 5
3.2. Conceptos básicos del modelo ATRIBUTO • Propiedad o característica de una entidad • Una entidad particular es descrita por los valores de sus atributos: p1 e1 titulo = El alquimista impaciente genero = Thriller nacionalidad = España añoestreno = 2002 ... dni = 87654321 nss = 1122334455 nombre = Cristina Aliaga Gil nacionalidad = España ... 6
3.2. Conceptos básicos del modelo 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 PELICULA CLIENTE LOCAL VIDEOCLUB DIRECTOR ACTOR 7
3.2. Conceptos básicos del modelo Instancia de un tipo de entidad • También... – – – – Ocurrencia Realización Ejemplar Entidad concreta o individual p3 PELICULA p2 titulo = Amores perros genero = Drama nacionalidad = Méjico añoestreno = 1999 ... titulo = El señor de los anillos genero = Fantasía nacionalidad = EEUU añoestreno = 2001 ... p4 titulo = Amelie genero = Comedia nacionalidad = Francia añoestreno = 2001 ... 8
3.2. Conceptos básicos del modelo 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 • (87654321, 1122334455, “Cristina Aliaga Gil”, “Libertad, 2. Yecla. Murcia. 30510”, 968100200, 1’60, 28/07/1979, España, 23) e2 • (12345678, 6677889900, “Antonio Gil Sánchez”, “Paz, 5. Murcia. Murcia.30012”, 968111222, 1’76, 14/04/1944, España, 58) e3 • (11223344, 1234567890, “Julia Sauce”, “Justicia, 20. Yecla. Murcia. 30510”, 968000222, 1’59, 23/05/1947, España, 55) ... 9
3.2. Conceptos básicos del modelo Tipos de atributos • • • • Simples o Compuestos Almacenados o Derivados Monovalorados o Multivalorados Opcionales 10
3.2. Conceptos básicos del modelo Atributos Simples o Compuestos • Atributos compuestos – Pueden dividirse en otros con significado propio fechanacim direccion dia mes año calle ciudad provincia codpostal – Valor compuesto = concatenación de valores de componentes • Atributos simples – No divisibles. Atómicos genero 11
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] 12
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) 13
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)] 14
Notación para atributos [EN2002] ciudad provincia calle codpostal dirección fechanacim EMPLEADO nombre telefono (0,3) (0,1) altura (1,2) nss dni edad nacionalidad 15
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 dni [EN2002] 16
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) 17
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 IC’s – nss y (nombre, fechanacim) en EMPLEADO 18
Notación para atributos clave [EN2002] calle codpostal dirección fechanacim n-f nombre  provincia ciudad (0,3) (0,1) EMPLEADO nss (1,2) IP dni telefono altura nacionalidad edad En el MER es obligatorio que todo tipo de entidad tenga un identificador 19
DOMINIO (values set) • Conjunto de valores • Cada atributo simple está asociado a un dominio, que especifica sus valores válidos Atributo Dominio nombre NOMBRES Descripción Dominio cadenas de hasta 30 caracteres alfabéticos telefono TELEFONOS cadenas de hasta 9 caracteres numéricos altura números reales entre 0 y 2’5 (metros) ...  MEDIDAS ... ... No suele representarse, aunque una forma de EMPLEADO hacerlo sería: [MPM1999] nombre telefono altura 20 NOMBRES TELEFONOS MEDIDAS
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 87654321 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” 21
DIRECTOR HA_RODADO Instancia del tipo de relación J. Médem C. Saura PELICULA Vacas Tesis Belle Epoque F. Trueba Torrente S. Segura Tierra A. Amenábar Abre los ojos Los otros Tipo de Entidad: conjunto de instancias Tipo de Relación: conjunto de instancias 22
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 DIRECTOR HA_RODADO PELICULA 23
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 ACTOR ACTUA_EN CLIENTE CONTINUACION DE PELICULA PELICULA ALQUILA LOCAL_VIDEOCLUB 24 PELICULA
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 DIRECTOR realizador HA_RODADO film PELICULA • Los nombres de rol se deben usar, sobre todo, en los tipos de relación reflexivos, para evitar ambigüedad original VERSION_DE versión PELICULA 25
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 26
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” DIRECTOR 1 • 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” HA_RODADO N PELICULA 27
Razón de Cardinalidad (ii)[EN2002] • Razones de cardinalidad más comunes: – 1:1 (“uno a uno”) – 1:N (“uno a muchos”) – M:N (“muchos a muchos”) trabajador 1 TRABAJA_EN 1 lugar trabajo EMPLEADO encargado 1 SUPERVISA sucursal N LOCAL_VIDEOCLUB ACTOR personaje M ACTUA_EN N film PELICULA 28
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 29
Razón de Participación (ii)[EN2002] • Notación ACTOR DIRECTOR 1 – Líneas dobles o simples personaje M HA_ RODADO ACTUA_EN N N film PELICULA PELICULA trabajador 1 TRABAJA_EN 1 lugar trabajo EMPLEADO encargado 1 SUPERVISA sucursal N LOCAL_VIDEOCLUB 30
Cardinalidad de tipo de entidad • Otra forma de expresar las razones de cardinalidad y participación PERSONA EDIFICIO USA POSEE PERSONA EDIFICIO PERSONA USA p1  EDIFICIO POSEE  e1 p1   e1  e2  e2 p2  p2   e3 p3   e4  e3 p3   e4 31
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 (1,n) PERSONA (0,n) USA POSEE (0,m) EDIFICIO (1,1) 32
Cardinalidad de tipo de entidad (iii) [EN2002] EMPLEADO ACTOR 1 TRABAJA_EN 1 M SUPERVISA ACTUA_EN N N 1 PELICULA LOCAL_VIDEOCLUB (1,1) TRABAJA_EN (1,1) EMPLEADO (0,n) ACTOR SUPERVISA ACTUA_EN (1,n) (0,m) (1,1) LOCAL_VIDEOCLUB PELICULA 33
Cardinalidad de tipo de entidad (vii) • Cardinalidad de tipos de entidad recursivos [EN2002] superior (0,n) subalterno EMPLEADO (0,1) N 1 JEFE DE 34
Atributos de tipos de relación • Similares a los atributos de tipos de entidad [EN2002] horas 1 TRABAJA_EN 1 EMPLEADO 1 SUPERVISA N LOCAL_VIDEOCLUB 35 fechainicio
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 1 horas TRABAJA_EN SUPERVISA fechainicio N 1 [EN2002] horas EMPLEADO 1 LOCAL_VIDEOCLUB horas 36 fechainicio
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) COPIA • Notación 37
Tipo de entidad débil (ii) [EN2002] Tipo de nss Entidad Regular Tipo de Relación Identificador PACIENTE 1 ACUDE PELICULA TIENE N 1 N diahora VISITA_MEDICA titulo COPIA numcopia N Clave parcial o Discriminante ASISTIDA POR 1 MEDICO especialidad ncolegiado nombre Dependencia en existencia 38
Tipo de entidad débil (iii) [EN2002] • No toda participación total (o dependencia en existencia) implica un tipo de entidad débil EMPLEADO dni 1 POSEE N PERMISO CONDUCCION numlicencia tipo PERMISO_CONDUCCIÓN no es débil: depende en existencia de EMPLEADO, pero tiene clave primaria propia 39
Tipos de relación con grado superior a dos • Tipo de relación ternaria [EN2002] CLIENTE (0,n) ALQUILA fecha (0,m) (0,1) CINTA VIDEO LOCAL VIDEOCLUB • Cardinalidad de los tipos de entidad 40
Tipos de relación con grado superior a dos (ii) • Equivalencia ternaria – varias binarias [EN2002] fecha (0,n) CLIENTE (0,n) ALQUILA fecha (0,m) LOCAL VIDEOCLUB CLIENTE (0,1) (0,1) (1,m) CINTA VIDEO ALQUILA CINTA VIDEO ALQUILA_EN (1,n) LOCAL VIDEOCLUB (1,1) (1,n) 41 CONTIENE
Tipos de relación con grado superior a dos (iii) • Ternaria no equivalente a varias binarias [EN2002] PROVEEDOR cantidad (1,n) SUMINISTRA fecha idprov (1,n) codpr (0,m) PRODUCTO (1,p) TIENDA PROVEEDOR PUEDE SUMINISTRAR (1,m) (1,m) PRODUCTO PROVEE (1,n) (0,n) TIENDA VENDE (1,m) nombre • Pérdida de semántica... 42
Modelo Entidad-Relación Extendido, MERE Enhanced Entity-Relationship model, EER • Aportaciones de diversos autores al modelo Entidad-Relación «básico». • Permiten representar... – Relaciones exclusivas entre sí – Jerarquías de Especialización/Generalización 43
3.3. Extensiones del modelo Relaciones Exclusivas • 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 VEHÍCULO CONSUME GASTA GASOIL GASOLINA • CONSUME y GASTA son exclusivas respecto del tipo de entidad VEHICULO 44
3.3. Extensiones del modelo Especialización/Generalización (E/G) • 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 45
3.3. Extensiones del modelo E/G: Subtipo de un tipo de entidad • 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 ) 46
3.3. Extensiones del modelo E/G: Relación Supertipo/Subtipo • 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 SECRETARIO GERENTE [EN2002] COMERCIAL 47
3.3. Extensiones del modelo E/G: Relación Supertipo/Subtipo (ii) • 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 VEHÍCULO CAMIÓN TURISMO CICLOMOTOR 48
3.3. Extensiones del modelo E/G: Herencia de tipo • 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 numBastidor VEHÍCULO precio tonelaje numEjes FABRICA (1,1) N:1 FABRICANTE (1,n) (1,1) (0,1) CAMIÓN TURISMO numPuer MOTOCICLETA numPlazas LLEVA cilindrada 1:1 49 SIDECAR
3.3. Extensiones del modelo E/G: Especialización • 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 EMPLEADO actividad SECRETARIO GERENTE COMERCIAL 50
3.3. Extensiones del modelo E/G: Especialización (ii) • Varias especializaciones de un tipo de entidad, con base en diferentes discriminantes género DRAMA TERROR PELÍCULA COMEDIA color BLANCO_Y_NEGRO [EN2002] COLOR 51
3.3. Extensiones del modelo E/G: Especialización (iii) • 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 CELADOR (1,1) SUPERVISA (1,1) SECCIÓN_HOSPITAL 52
3.3. Extensiones del modelo E/G: Generalización • 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 CAMIÓN numEjes numBastidor precio numBastidor fechaFab VEHÍCULO fechaFab precio tonelaje G CAMIÓN TURISMO fechaFab numEjes TURISMO tonelaje numPuer numPuer [EN2002] 53
3.3. Extensiones del modelo E/G: Generalización vs. Especialización  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 54
3.3. Extensiones del modelo Restricciones sobre la E/G • 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? 55
3.3. Extensiones del modelo Restricciones sobre la E/G: Definición • 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 estadoLaboral=en_activo EMPLEADO [EN2002] matriculado=true ESTUDIANTE 56
3.3. Extensiones del modelo Restricciones sobre la E/G: Definición (ii) • 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 EMPLEADO_HOSPITAL PERSONA estadoLaboral en_activo EMPLEADO en_paro claseTrabajo médico PARADO MÉDICO celador enfermero CELADOR limpiador ENFERMERO [EN2002] 57 LIMPIADOR
3.3. Extensiones del modelo Restricciones sobre la E/G: Definición (iii) • 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 PROFESOR TITULAR AYUDANTE ASOCIADO 58
3.3. Extensiones del modelo Restricciones sobre la E/G: Disyunción/Solapamiento • Subtipos disjuntos si una instancia del supertipo puede ser miembro de, como máximo, uno de los subtipos • 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» VEHÍCULO PERSONA d TURISMO o CAMIÓN [EN2002] EMPLEADO ESTUDIANTE 59
3.3. Extensiones del modelo Restricciones sobre la E/G: Completitud/Parcialidad •Especialización parcial indica que • Especialización total es posible que alguna instancia del (completa) indica que supertipo no pertenezca a ninguno toda instancia del supertipo también debe de los subtipos •Es la opción «por defecto» ser instancia de algún •La unión de las extensiones de los subtipo subtipos no es la extensión del supertipo en su totalidad ANIMAL d MACHO ALIMENTO d HEMBRA HERMAFRODITA LACTEO FRUTA 60 VERDURA
3.3. Extensiones del modelo E/G: Tipos de Especialización • 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 61
3.3. Extensiones del modelo E/G: Especialización Disjunta y Total EMPLEADO d DOCENTE ESTUDIANTE claseTrabajo ADMON_Y_SERV BECARIO d BECARIO Especialización Disjunta y Parcial DOCENTE d AYUDANTE TITULAR cuerpoDocente CATEDRÁTICO 62 tipo NO_BECARIO
3.3. Extensiones del modelo E/G: Especialización Solapada y Total PERSONA O EMPLEADO ocupación ESTUDIANTE Especialización Solapada y Parcial EMPLEADO dedicación DOCENTE O INVESTIGADOR 63
3.3. Extensiones del modelo E/G: Reglas de inserción y eliminación • 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 64
3.3. Extensiones del modelo E/G: Reglas de inserción y eliminación (ii)  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) 65
3.4.1 Objetivos y fases del diseño lógico • • • 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 66
3.4.1 Objetivos y fases del diseño lógico Fases  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 67
3.4.1 Objetivos y fases del diseño lógico Fases (y 2)  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, ... 68
3.4.2 Diseño lógico estándar Reglas de traducción MERE  MR  Reglas para el modelo básico • Dominios • Atributos • Tipos de entidad • Tipos de relación MER Tipo de Entidad Tipo de Relación M:N Tipo de Relación 1:1, 1:N, N:1 RESUMEN MR (SQL-92) Tabla (relación) Tabla Propagación de clave o tabla  Reglas para las extensiones del modelo • Relaciones exclusivas • Jerarquías de Especialización/Generalización 69
3.4.2 Diseño lógico estándar Traducción de un dominio y un tipo de entidad • Dominio MERE ESTADO_CIVIL: {S, C, V, D} MR CREATE DOMAIN Estado_civil AS CHAR(1) CHECK VALUE IN (‘S’, ‘C’, ‘V’, ‘D’) ; • Tipo de entidad – Se traduce a una tabla (relación) – Se recomienda usar el mismo nombre o uno MERE PERSONA similar MR CREATE TABLE Persona ( ... ); 70
3.4.2 Diseño lógico estándar Traducción de un atributo • 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 MERE MR numSS nombre direccion telefono fechaNacim dni PERSONA nacionalidad altura CREATE TABLE Persona ( dni PRIMARY KEY, numSS UNIQUE NULL, nombre ..., direccion ..., telefono ..., fechaNacim ..., nacionalidad ..., altura ... ) ; 71
3.4.2 Diseño lógico estándar Traducción de un atributo (2) • 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 MERE MR (DED) ¿Cuándo será más adecuado utilizar una opción u otra? 72
3.4.2 Diseño lógico estándar Traducción de un atributo (3) • 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) MERE MR dni nombre fechaNa c direccion (1,n) PERSONA MR (DED) PERSONA tiene DIRECC_ PERSONA PERSONA (dni, nombre, fechaNac) FK DIRECC_PERSONA (dni, direccion) CREATE TABLE Direcc_Persona ( dni ... direccion ... PRIMARY KEY (dni, direccion) FOREIGN KEY (dni) REFERENCES Persona(dni) ON DELETE CASCADE ON UPDATE CASCADE ); 73
3.4.2 Diseño lógico estándar Traducción de un atributo (y 4) • 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 MR MERE dni PERSONA nombre fechaNa c edad PERSONA (dni, nombre, fechaNac, edad) 74
3.4.2 Diseño lógico estándar Traducción de una relación binaria M:N  Nueva tabla R, que incluye... V E1 E2 – claves ajenas hacia las claves primarias de R1 y de R2 R1 R2 R  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) nombre ACTOR papel Actua (1,m) en (1,n) caché [MPM 1999] paga código PELICULA ACTOR(nombre, ..., caché, ...) FK ACTUA_EN (actor, pelicula, papel, paga) FK título PELICULA(código, título, ...) 75
3.4.2 Diseño lógico estándar Traducción de una relación binaria M:N (3) codAutor AUTOR nomAutor isbn derechosAutor (1,n) Escribe LIBRO (1,4) numPaginas AUTOR(codAutor, nomAutor, ...) FK ESCRIBE (autor, libro, derAutor, numPag) FK titulo LIBRO(isbn, titulo, ...) – Pero la traducción, aunque lo parezca, no está completa... – ... pues falta especificar ciertos aspectos que tienen que ver con las reglas de integridad 76
3.4.2 Diseño lógico estándar Traducción de una relación binaria M:N (4) – 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 NUMERIC(2) DEFAULT 20 NOT NULL CHECK (derAutor≥0 AND derAutor<100), numPag NUMERIC(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 ); 77
3.4.2 Diseño lógico estándar Traducción de una relación binaria M:N (5) Especificación de restricciones 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) autor derAutor numPag NULL 0-201-65370-2 ... ... A001 – libro NULL ... ... Ambas cosas ya quedan aseguradas por la propia definición de la clave primaria de ESCRIBE: PRIMARY KEY(autor, libro) 78
3.4.2 Diseño lógico estándar Traducción de una relación binaria M:N (6) Especificación de restricciones 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)) ); 79
3.4.2 Diseño lógico estándar Traducción de una relación binaria M:N (y 7) Especificación de restricciones 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)) ); 80
3.4.2 Diseño lógico estándar Traducción de una relación binaria 1:N 1) Caso general  Propagación de clave – E1 1 V R1 N E2 R2 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 codProv nombreCiudad PROVINCIA contiene (1,1) (1,n) CIUDAD ... nomProv CIUDAD( nomCiudad, provincia, ... ) FK: NULOS NO PERMITIDOS PROVINCIA( codProv, nomProv, ... ) 81
3.4.2 Diseño lógico estándar Traducción de una relación binaria 1:N (2) 1.2) Participación parcial de E2 en V nomMuseo codCuadro PINACOTECA ciudad Expone (1,n) (0,1) CUADRO titulo pintor sala NULOS PERMITIDOS CUADRO(codCuadro, titulo, pintor, museo, sala...) FK PINACOTECA(nomMuseo, ciudad, ...) 82
3.4.2 Diseño lógico estándar Traducción de una relación binaria 1:N (3) 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) nif ESTUDIANTE nombre (0,n) 1:N Propietario_de (0,1) matricula COCHE ESTUDIANTE( nif, nombre, ... ) PROPIEDAD( coche, estudiante) FK NN FK COCHE( matricula, modelo, ... ) 83
3.4.2 Diseño lógico estándar Traducción de una relación binaria 1:1 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) nss nombre PACIENTE (1,1) Tiene HISTORIAL MEDICO (1,1) ... ... numHistoria fechaApertura centroSalud PACIENTE ( nss, nombre, numHisto, fechaApert, centroSalud,... ) PK AK, NN 84
3.4.2 Diseño lógico estándar Traducción de una relación binaria 1:1 (2) 2) Participación total de una entidad y parcial de la otra 2.1) Caso general E1 – E2 R1  Propagación de clave – V R2 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 codEmp numDep (0,1) (1,1) EMPLEADO DEPARTAMENTO Dirige Un empleado puede no dirigir ningún departamento, fechaInic nomEmp nomDep o bien ser el gerente de uno de ellos (desde cierta fecha, EMPLEADO(codEmp, nomEmp, ...) en la que fue nombrado FK como tal) DEPARTAMENTO(numDep,nomDep, codDir, fechInicDir...) AK, NN 85 NN
3.4.2 Diseño lógico estándar Traducción de una relación binaria 1:1 (3) 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, ...) FK DIRIGE (emp, dep, fechInic) AK,NN FK DEPARTAMENTO(numDep, nomDep,...) 86
3.4.2 Diseño lógico estándar Traducción de una relación binaria 1:1 (4) 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, Atributos de EMPLEADO nomEmp ... , ..., Atributos de numDepDir ... NULL UNIQUE, DEPARTAMENTO nomDepDir ... NULL, ..., fechInicDir ... NULL, Atributos de DIRIGE ... ); 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 87
3.4.2 Diseño lógico estándar Traducción de una relación binaria 1:1 (y 5) 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)) lugar nif nif HOMBRE Matrimonio (0,1) a la antigua (0,1) MUJER HOMBRE(nif, ...) FK MATRIMONIO(esposa, esposo, fecha, lugar) FK fecha AK, NN MUJER(nif, ...) Y... ¿qué acciones de mantenimiento de la integridad referencial debemos imponer para (todos los casos de) transformación de relaciones 1:1? 88 NN NN
3.4.2 Diseño lógico estándar Traducción de dependencia en existencia y en identificación  • V E1 E2 Caso particular de relación 1:1 R1 R2 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) 89
3.4.2 Diseño lógico estándar Traducción de dependencia en existencia y en identificación (y 2) nifEmp nomEmp 1:N EMPLEADO (0,n) FAMILIAR Tiene (1,1) EMPLEADO ( nifEmp, nomEmp, ...) FK FAMILIAR ( nifFam, emp, ... ) NOT NULL ON DELETE CASCADE ON UPDATE CASCADE fecha historial nombre 1:N PACIENTE (1,n) Acude nifFam (1,1) PACIENTE ( historial, nombre, ... ) FK VISITA_MEDICA ( historial, fecha, hora, ... ) hora observ VISITA MEDICA NOT NULL ON DELETE CASCADE ON UPDATE CASCADE 90
3.4.2 Diseño lógico estándar Traducción de una relación binaria reflexiva jefe nifEmp nomEmp Es jefe de EMPLEADO subordinado Caso 1:N EMPLEADO ( nifEmp, nomEmp, ..., jefe, ... ) FK NULL solución problemática si puede haber muchos empleados sin jefe ( demasiados nulos )  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 Caso M:N EMPLEADO ( nifEmp, nomEmp, ... ) FK FK JEFE_EMP ( jefe, subordinado, ... ) Otra posibilidad en el Caso 1:N EMPLEADO ( nifEmp, nomEmp, ...) FK FK JEFE_EMP ( jefe, subordinado, ... ) NN 91
3.4.2 Diseño lógico estándar Traducción de una relación n-aria  V Tabla R correspondiente a V, E1 E2 que incluye... R1 R2 E3 – claves ajenas hacia cada clave R3 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 92
3.4.2 Diseño lógico estándar Traducción de una relación n-aria (y 2) matricula nifCliente CLIENTE [EN 2002] COCHE fechaVenta (0,1) (0,n) Venta (0,m) nifVendedor VENDEDOR (0,p) BANCO cifBanco VENTA ( matricula, vendedor, cliente, banco, fechaVenta ) 1. 2. 3. 4. ¿Cuál es la superclave de esta relación? ¿y cuál es su clave primaria? ¿Cómo asegurar que no haya ventas sin cliente, sin coche, sin vendedor? ¿Puede reflejarse la existencia de ventas directas (sin banco)? 93
3.4.2 Diseño lógico estándar Traducción de exclusividad de relaciones  Añadir restricciones de tipo CHECK Ejemplo para relaciones de tipo 1:N PROFESOR (0,n) (0,n) CREATE TABLE Curso ( codcurso ... PRIMARY KEY, ORGANIZA IMPARTE nomcurso ..., ... (1,1) (1,1) director ... REFERENCES Profesor (idProf) CURSO 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) ) ) ... ); 94
3.4.2 Diseño lógico estándar Traducción de exclusividad de relaciones (2) Ejemplo para relaciones de tipo M:N ALUMNO (1,n) (1,n) CREATE TABLE Alumno_Estudia_Titulacion ( alu ... REFERENCES Alumno (numExp) estudia cursa ON DELETE CASCADE ON UPDATE CASCADE , titu ... REFERENCES Titulacion (idTit) (0,n) ON DELETE NO ACTION ON UPDATE CASCADE , (0,n) PRIMARY KEY (alu, titu), TITULACIÓN MASTER CONSTRAINT titulacion_xor_master CHECK ( alu NOT IN (SELECT alum FROM Alumno_Cursa_Master) ) ); [MPM 1999] 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) ) ); 95
3.4.2 Diseño lógico estándar Traducción de especialización/generalización 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 96
3.4.2 Diseño lógico estándar Traducción de especialización/generalización (2) Transformación guiada por el supertipo: Jerarquía disjunta total nif nombre EMPLEADO UNIVERSIDAD d PROFESOR BECARIO categoría tipoBeca [MPM 1999] tipo CREATE TABLE Empleado_Universidad ( nif ... PRIMARY KEY, nombre ... , tipo ... NOT NULL CHECK tipo IN (‘pro’, ‘bec’, ‘pas’), categ ... NULL, tipoBeca ... NULL, activ ... NULL, ... PAS CHECK ( ( tipo = ‘pro’ AND categ IS NOT NULL AND tipoBeca IS NULL AND activ IS NULL ) actividad OR ( tipo = ‘bec’ AND tipoBeca IS NOT NULL AND categ IS NULL AND activ IS NULL ) restricciones OR ( tipo = ‘pas’ AND activ IS NOT NULL AND categ IS NULL AND tipoBeca IS NULL ) ) semánticas ); 97 disjunta PARCIAL: PERMITE NULL EN TIPO
3.4.2 Diseño lógico estándar Traducción de especialización/generalización (3) Transformación guiada por el supertipo: Jerarquía solapada parcial Alternativa 1: CREATE TABLE Individuo ( nif ... PRIMARY KEY, nif nombre INDIVIDUO nombre ... , fechanac fechanac ... , estudia ... NOT NULL CHECK (estudia IN (‘T’, ‘F’)), actividad curra ... NOT NULL CHECK (curra IN (‘T’, ‘F’)), titulacion ... NULL, nss ... NULL UNIQUE, ESTUDIANTE CURRANTE salario ... NULL, ... titulacion nss salario CHECK ( (estudia = ‘T’ AND titulacion IS NOT NULL) OR (estudia = ‘F’ AND titulacion IS NULL) ) , Otra posibilidad: CHECK ( (curra = ‘T’ AND nss IS NOT NULL – Sólo una columna discriminante y AND salario IS NOT NULL) valor extra para solapamiento: OR (curra = ‘F’ AND nss IS NULL AND salario IS NULL) ) actividad ... NULL CHECK (actividad IN (‘estudia’, ‘trabaja’, ‘est_trab’)) ); 98
3.4.2 Diseño lógico estándar Traducción de especialización/generalización (4) Transformación guiada por el supertipo: Jerarquía solapada parcial Alternativa 2: – Un solo atributo discriminante, tratado como atributo multivalorado CREATE TABLE Individuo ( nif ... PRIMARY KEY, nombre ... , fechanac ... , titulación ... NULL, nss ... NULL UNIQUE, salario ... NULL, ... ); CREATE TABLE Actividad_Individuo ( nifIndiv ... REFERENCES Individuo( nif ) ON DELETE CASCADE ON UPDATE CASCADE, nomActiv ... , CHECK (nomActiv IN (‘estudiar’, ‘trabajar’)), PRIMARY KEY ( nifIndiv, nomActiv ) );  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 99
3.4.2 Diseño lógico estándar Traducción de especialización/generalización (6) Transformación guiada por el supertipo: Jerarquía solapada parcial Alternativa 2: (cont.) Restricciones de Integridad necesarias 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’))); 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 3.4.- 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 100
3.4.2 Diseño lógico estándar Traducción de especialización/generalización (7) Transformación guiada por el supertipo: Jerarquía solapada total nombre UNIVERSITARIO o ESTUDIANTE titulacion tipo CURRANTE nss titulacion salario salario 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 ) ) ); Otras opciones: – Una sola columna discriminante – Tratar discriminante como un atributo multivalorado 101
3.4.2 Diseño lógico estándar Traducción de especialización/generalización (8) 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 102
3.4.2 Diseño lógico estándar Traducción de especialización/generalización (9) 2. Transformación total • Los subtipos se diferencian en muchos atributos • Se desea mantener los atributos comunes en una tabla separada P d B1  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 Ri para cada subtipo Bi, que incluye...  columnas para los atributos del subtipo Bi  columna clave ajena hacia la clave primaria de R ( propagación en cascada)  la clave primaria es dicha clave ajena 103 B2
3.4.2 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 codigo DOCUMENTO tipo d ARTICULO revista fecha idioma titulo LIBRO edicion editorial  El atributo discriminante no aparece en ninguna de las tablas resultado de la traducción 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 ... ); 104
3.4.2 Diseño lógico estándar Traducción de especialización/generalización (11) 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é?) 105
3.4.2 Diseño lógico estándar Traducción de especialización/generalización (12) 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 tabla Ri para cada subtipo que contiene... – columnas para los atributos del subtipo Bi y – columnas para los atributos comunes (del supertipo) – la clave primaria de Ri es el identificador principal del supertipo 106
3.4.2 Diseño lógico estándar Traducción de especialización/generalización (13) Ejemplo de transformación guiada por los subtipos codigo DOCUMENTO tipo d ARTICULO revista fecha idioma titulo LIBRO edicion editorial  El atributo discriminante no aparece en ninguna de las tablas resultado de la traducción CREATE TABLE Articulo ( codigo ... PRIMARY KEY titulo ..., idioma ..., revista ... , fecha ... ); CREATE TABLE Libro ( codigo ... PRIMARY KEY titulo ..., idioma ..., edicion ... editorial ... ); 107
3.4.2 Diseño lógico estándar Traducción de especialización/generalización (y 14) 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 108
3.4.3 Diseño lógico específico • 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 109

Más contenido relacionado

PDF
Clase 3 - Modelo de Datos
porEddie Malca
 
PDF
02.modelo e r
porDina Espinoza Quinto
 
PDF
modelo entidad_relacion
porluis alvarez
 
PPTX
Modelos de objetos semanticos
porMarelvis_inf
 
PDF
Base de datos 2(tema 3)
porEdwin Arias
 
PPT
Tm08 modelo entidadrelacion_2
porJulio Pari
 
PPTX
Entidades
porelviscd_4
 
PPT
Modelado orientado a objetos de bd
porMaría Luisa Velasco
 
Clase 3 - Modelo de Datos
porEddie Malca
 
02.modelo e r
porDina Espinoza Quinto
 
modelo entidad_relacion
porluis alvarez
 
Modelos de objetos semanticos
porMarelvis_inf
 
Base de datos 2(tema 3)
porEdwin Arias
 
Tm08 modelo entidadrelacion_2
porJulio Pari
 
Entidades
porelviscd_4
 
Modelado orientado a objetos de bd
porMaría Luisa Velasco
 

Similar a Tema3 (1)

PDF
Modelo Entidad Relacion
porExtensión del Instituto Tecnológico de Tuxtla Gutiérrez sede Bochil
 
PPT
Mer
porMaría Luisa Velasco
 
PPTX
10-Unidad 3: Componente técnico profesional general de la Carrera -3.2 Tópico...
porLuis Fernando Aguas Bucheli
 
PPT
Modelo entidad relacion
porCarmen Sanchez
 
PDF
Modelo Entidad Relacion.pdf
porLuisAguilar802299
 
PPT
TEMA 2 MODELO RELACIONAL
porSara E. Alcántara R.
 
PDF
ingeniería de sistemas base de datos.pdf
porSALVADOR ALTEZ PALOMINO
 
PPTX
BASE DE DATOS_MER
porrgaby17
 
PPT
unidad-2-parte-1-modelo_entidad_relación
porManoloMan1
 
PPTX
Análisis de sistemas clase 3
porJose Ñacari Huarcaya
 
PPTX
Modelo entidad-relacion
porArmando_Mendoza
 
PPT
MODELANDO UNA BASE DE DATOS_CONCEPTOS.ppt
porDanval3
 
PPT
unidad-1-parte-1-mer.ppt
porjorgeecaiza
 
PPTX
Modelo entidad relación
porUTN
 
PPTX
modelo entidad relacion
porMarcos Leon
 
PPT
105876540-Modelo-ER-y-ERE.ppt
porJohnny Rodriguez
 
PPTX
Modelo de base de datos
porMora Marquez Luis Omar
 
PPT
entidad relacion.ppt
porWilliamBracho3
 
PPTX
Mentidadrelacion ojo
porBB
 
PPT
MER conceptos generales y descrippciones
porCesarJulioPeaSanchez
 
Modelo Entidad Relacion
porExtensión del Instituto Tecnológico de Tuxtla Gutiérrez sede Bochil
 
Mer
porMaría Luisa Velasco
 
10-Unidad 3: Componente técnico profesional general de la Carrera -3.2 Tópico...
porLuis Fernando Aguas Bucheli
 
Modelo entidad relacion
porCarmen Sanchez
 
Modelo Entidad Relacion.pdf
porLuisAguilar802299
 
TEMA 2 MODELO RELACIONAL
porSara E. Alcántara R.
 
ingeniería de sistemas base de datos.pdf
porSALVADOR ALTEZ PALOMINO
 
BASE DE DATOS_MER
porrgaby17
 
unidad-2-parte-1-modelo_entidad_relación
porManoloMan1
 
Análisis de sistemas clase 3
porJose Ñacari Huarcaya
 
Modelo entidad-relacion
porArmando_Mendoza
 
MODELANDO UNA BASE DE DATOS_CONCEPTOS.ppt
porDanval3
 
unidad-1-parte-1-mer.ppt
porjorgeecaiza
 
Modelo entidad relación
porUTN
 
modelo entidad relacion
porMarcos Leon
 
105876540-Modelo-ER-y-ERE.ppt
porJohnny Rodriguez
 
Modelo de base de datos
porMora Marquez Luis Omar
 
entidad relacion.ppt
porWilliamBracho3
 
Mentidadrelacion ojo
porBB
 
MER conceptos generales y descrippciones
porCesarJulioPeaSanchez
 

Tema3 (1)

  • 1.
    3. Modelo Entidad-Relación 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 1
  • 2.
    3.1. Introducción ehistoria del modelo EntidadRelación • 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) 2
  • 3.
    3.1. Introducción ehistoria del modelo Entidad-Relación Esquema conceptual • 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 3
  • 4.
    3.2. Conceptos básicosdel modelo • • • • Entidad ( entity ) Atributo ( attribute ) Dominio ( values set ) Relación ( relationship ) 4
  • 5.
    3.2. Conceptos básicosdel modelo 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) 5
  • 6.
    3.2. Conceptos básicosdel modelo ATRIBUTO • Propiedad o característica de una entidad • Una entidad particular es descrita por los valores de sus atributos: p1 e1 titulo = El alquimista impaciente genero = Thriller nacionalidad = España añoestreno = 2002 ... dni = 87654321 nss = 1122334455 nombre = Cristina Aliaga Gil nacionalidad = España ... 6
  • 7.
    3.2. Conceptos básicosdel modelo 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 PELICULA CLIENTE LOCAL VIDEOCLUB DIRECTOR ACTOR 7
  • 8.
    3.2. Conceptos básicosdel modelo Instancia de un tipo de entidad • También... – – – – Ocurrencia Realización Ejemplar Entidad concreta o individual p3 PELICULA p2 titulo = Amores perros genero = Drama nacionalidad = Méjico añoestreno = 1999 ... titulo = El señor de los anillos genero = Fantasía nacionalidad = EEUU añoestreno = 2001 ... p4 titulo = Amelie genero = Comedia nacionalidad = Francia añoestreno = 2001 ... 8
  • 9.
    3.2. Conceptos básicosdel modelo 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 • (87654321, 1122334455, “Cristina Aliaga Gil”, “Libertad, 2. Yecla. Murcia. 30510”, 968100200, 1’60, 28/07/1979, España, 23) e2 • (12345678, 6677889900, “Antonio Gil Sánchez”, “Paz, 5. Murcia. Murcia.30012”, 968111222, 1’76, 14/04/1944, España, 58) e3 • (11223344, 1234567890, “Julia Sauce”, “Justicia, 20. Yecla. Murcia. 30510”, 968000222, 1’59, 23/05/1947, España, 55) ... 9
  • 10.
    3.2. Conceptos básicosdel modelo Tipos de atributos • • • • Simples o Compuestos Almacenados o Derivados Monovalorados o Multivalorados Opcionales 10
  • 11.
    3.2. Conceptos básicosdel modelo Atributos Simples o Compuestos • Atributos compuestos – Pueden dividirse en otros con significado propio fechanacim direccion dia mes año calle ciudad provincia codpostal – Valor compuesto = concatenación de valores de componentes • Atributos simples – No divisibles. Atómicos genero 11
  • 12.
    Atributos Almacenados oDerivados • 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] 12
  • 13.
    Atributos Monovalorados oMultivalorados • 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) 13
  • 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)] 14
  • 15.
  • 16.
    Atributos Clave • Atributocon 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 dni [EN2002] 16
  • 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) 17
  • 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 IC’s – nss y (nombre, fechanacim) en EMPLEADO 18
  • 19.
    Notación para atributosclave [EN2002] calle codpostal dirección fechanacim n-f nombre  provincia ciudad (0,3) (0,1) EMPLEADO nss (1,2) IP dni telefono altura nacionalidad edad En el MER es obligatorio que todo tipo de entidad tenga un identificador 19
  • 20.
    DOMINIO (values set) •Conjunto de valores • Cada atributo simple está asociado a un dominio, que especifica sus valores válidos Atributo Dominio nombre NOMBRES Descripción Dominio cadenas de hasta 30 caracteres alfabéticos telefono TELEFONOS cadenas de hasta 9 caracteres numéricos altura números reales entre 0 y 2’5 (metros) ...  MEDIDAS ... ... No suele representarse, aunque una forma de EMPLEADO hacerlo sería: [MPM1999] nombre telefono altura 20 NOMBRES TELEFONOS MEDIDAS
  • 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 87654321 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” 21
  • 22.
    DIRECTOR HA_RODADO Instancia del tipo de relación J.Médem C. Saura PELICULA Vacas Tesis Belle Epoque F. Trueba Torrente S. Segura Tierra A. Amenábar Abre los ojos Los otros Tipo de Entidad: conjunto de instancias Tipo de Relación: conjunto de instancias 22
  • 23.
    TIPO DE RELACIÓN (relationshipset) • 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 DIRECTOR HA_RODADO PELICULA 23
  • 24.
    Grado de untipo 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 ACTOR ACTUA_EN CLIENTE CONTINUACION DE PELICULA PELICULA ALQUILA LOCAL_VIDEOCLUB 24 PELICULA
  • 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 DIRECTOR realizador HA_RODADO film PELICULA • Los nombres de rol se deben usar, sobre todo, en los tipos de relación reflexivos, para evitar ambigüedad original VERSION_DE versión PELICULA 25
  • 26.
    Restricciones estructurales sobretipos 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 26
  • 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” DIRECTOR 1 • 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” HA_RODADO N PELICULA 27
  • 28.
    Razón de Cardinalidad(ii)[EN2002] • Razones de cardinalidad más comunes: – 1:1 (“uno a uno”) – 1:N (“uno a muchos”) – M:N (“muchos a muchos”) trabajador 1 TRABAJA_EN 1 lugar trabajo EMPLEADO encargado 1 SUPERVISA sucursal N LOCAL_VIDEOCLUB ACTOR personaje M ACTUA_EN N film PELICULA 28
  • 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 29
  • 30.
    Razón de Participación(ii)[EN2002] • Notación ACTOR DIRECTOR 1 – Líneas dobles o simples personaje M HA_ RODADO ACTUA_EN N N film PELICULA PELICULA trabajador 1 TRABAJA_EN 1 lugar trabajo EMPLEADO encargado 1 SUPERVISA sucursal N LOCAL_VIDEOCLUB 30
  • 31.
    Cardinalidad de tipode entidad • Otra forma de expresar las razones de cardinalidad y participación PERSONA EDIFICIO USA POSEE PERSONA EDIFICIO PERSONA USA p1  EDIFICIO POSEE  e1 p1   e1  e2  e2 p2  p2   e3 p3   e4  e3 p3   e4 31
  • 32.
    Cardinalidad de tipode 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 (1,n) PERSONA (0,n) USA POSEE (0,m) EDIFICIO (1,1) 32
  • 33.
    Cardinalidad de tipode entidad (iii) [EN2002] EMPLEADO ACTOR 1 TRABAJA_EN 1 M SUPERVISA ACTUA_EN N N 1 PELICULA LOCAL_VIDEOCLUB (1,1) TRABAJA_EN (1,1) EMPLEADO (0,n) ACTOR SUPERVISA ACTUA_EN (1,n) (0,m) (1,1) LOCAL_VIDEOCLUB PELICULA 33
  • 34.
    Cardinalidad de tipode entidad (vii) • Cardinalidad de tipos de entidad recursivos [EN2002] superior (0,n) subalterno EMPLEADO (0,1) N 1 JEFE DE 34
  • 35.
    Atributos de tiposde relación • Similares a los atributos de tipos de entidad [EN2002] horas 1 TRABAJA_EN 1 EMPLEADO 1 SUPERVISA N LOCAL_VIDEOCLUB 35 fechainicio
  • 36.
    Atributos de tiposde 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 1 horas TRABAJA_EN SUPERVISA fechainicio N 1 [EN2002] horas EMPLEADO 1 LOCAL_VIDEOCLUB horas 36 fechainicio
  • 37.
    Tipo de EntidadDé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) COPIA • Notación 37
  • 38.
    Tipo de entidaddébil (ii) [EN2002] Tipo de nss Entidad Regular Tipo de Relación Identificador PACIENTE 1 ACUDE PELICULA TIENE N 1 N diahora VISITA_MEDICA titulo COPIA numcopia N Clave parcial o Discriminante ASISTIDA POR 1 MEDICO especialidad ncolegiado nombre Dependencia en existencia 38
  • 39.
    Tipo de entidaddébil (iii) [EN2002] • No toda participación total (o dependencia en existencia) implica un tipo de entidad débil EMPLEADO dni 1 POSEE N PERMISO CONDUCCION numlicencia tipo PERMISO_CONDUCCIÓN no es débil: depende en existencia de EMPLEADO, pero tiene clave primaria propia 39
  • 40.
    Tipos de relacióncon grado superior a dos • Tipo de relación ternaria [EN2002] CLIENTE (0,n) ALQUILA fecha (0,m) (0,1) CINTA VIDEO LOCAL VIDEOCLUB • Cardinalidad de los tipos de entidad 40
  • 41.
    Tipos de relacióncon grado superior a dos (ii) • Equivalencia ternaria – varias binarias [EN2002] fecha (0,n) CLIENTE (0,n) ALQUILA fecha (0,m) LOCAL VIDEOCLUB CLIENTE (0,1) (0,1) (1,m) CINTA VIDEO ALQUILA CINTA VIDEO ALQUILA_EN (1,n) LOCAL VIDEOCLUB (1,1) (1,n) 41 CONTIENE
  • 42.
    Tipos de relacióncon grado superior a dos (iii) • Ternaria no equivalente a varias binarias [EN2002] PROVEEDOR cantidad (1,n) SUMINISTRA fecha idprov (1,n) codpr (0,m) PRODUCTO (1,p) TIENDA PROVEEDOR PUEDE SUMINISTRAR (1,m) (1,m) PRODUCTO PROVEE (1,n) (0,n) TIENDA VENDE (1,m) nombre • Pérdida de semántica... 42
  • 43.
    Modelo Entidad-Relación Extendido,MERE Enhanced Entity-Relationship model, EER • Aportaciones de diversos autores al modelo Entidad-Relación «básico». • Permiten representar... – Relaciones exclusivas entre sí – Jerarquías de Especialización/Generalización 43
  • 44.
    3.3. Extensiones delmodelo Relaciones Exclusivas • 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 VEHÍCULO CONSUME GASTA GASOIL GASOLINA • CONSUME y GASTA son exclusivas respecto del tipo de entidad VEHICULO 44
  • 45.
    3.3. Extensiones delmodelo Especialización/Generalización (E/G) • 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 45
  • 46.
    3.3. Extensiones delmodelo E/G: Subtipo de un tipo de entidad • 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 ) 46
  • 47.
    3.3. Extensiones delmodelo E/G: Relación Supertipo/Subtipo • 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 SECRETARIO GERENTE [EN2002] COMERCIAL 47
  • 48.
    3.3. Extensiones delmodelo E/G: Relación Supertipo/Subtipo (ii) • 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 VEHÍCULO CAMIÓN TURISMO CICLOMOTOR 48
  • 49.
    3.3. Extensiones delmodelo E/G: Herencia de tipo • 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 numBastidor VEHÍCULO precio tonelaje numEjes FABRICA (1,1) N:1 FABRICANTE (1,n) (1,1) (0,1) CAMIÓN TURISMO numPuer MOTOCICLETA numPlazas LLEVA cilindrada 1:1 49 SIDECAR
  • 50.
    3.3. Extensiones delmodelo E/G: Especialización • 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 EMPLEADO actividad SECRETARIO GERENTE COMERCIAL 50
  • 51.
    3.3. Extensiones delmodelo E/G: Especialización (ii) • Varias especializaciones de un tipo de entidad, con base en diferentes discriminantes género DRAMA TERROR PELÍCULA COMEDIA color BLANCO_Y_NEGRO [EN2002] COLOR 51
  • 52.
    3.3. Extensiones delmodelo E/G: Especialización (iii) • 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 CELADOR (1,1) SUPERVISA (1,1) SECCIÓN_HOSPITAL 52
  • 53.
    3.3. Extensiones delmodelo E/G: Generalización • 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 CAMIÓN numEjes numBastidor precio numBastidor fechaFab VEHÍCULO fechaFab precio tonelaje G CAMIÓN TURISMO fechaFab numEjes TURISMO tonelaje numPuer numPuer [EN2002] 53
  • 54.
    3.3. Extensiones delmodelo E/G: Generalización vs. Especialización  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 54
  • 55.
    3.3. Extensiones delmodelo Restricciones sobre la E/G • 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? 55
  • 56.
    3.3. Extensiones delmodelo Restricciones sobre la E/G: Definición • 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 estadoLaboral=en_activo EMPLEADO [EN2002] matriculado=true ESTUDIANTE 56
  • 57.
    3.3. Extensiones delmodelo Restricciones sobre la E/G: Definición (ii) • 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 EMPLEADO_HOSPITAL PERSONA estadoLaboral en_activo EMPLEADO en_paro claseTrabajo médico PARADO MÉDICO celador enfermero CELADOR limpiador ENFERMERO [EN2002] 57 LIMPIADOR
  • 58.
    3.3. Extensiones delmodelo Restricciones sobre la E/G: Definición (iii) • 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 PROFESOR TITULAR AYUDANTE ASOCIADO 58
  • 59.
    3.3. Extensiones delmodelo Restricciones sobre la E/G: Disyunción/Solapamiento • Subtipos disjuntos si una instancia del supertipo puede ser miembro de, como máximo, uno de los subtipos • 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» VEHÍCULO PERSONA d TURISMO o CAMIÓN [EN2002] EMPLEADO ESTUDIANTE 59
  • 60.
    3.3. Extensiones delmodelo Restricciones sobre la E/G: Completitud/Parcialidad •Especialización parcial indica que • Especialización total es posible que alguna instancia del (completa) indica que supertipo no pertenezca a ninguno toda instancia del supertipo también debe de los subtipos •Es la opción «por defecto» ser instancia de algún •La unión de las extensiones de los subtipo subtipos no es la extensión del supertipo en su totalidad ANIMAL d MACHO ALIMENTO d HEMBRA HERMAFRODITA LACTEO FRUTA 60 VERDURA
  • 61.
    3.3. Extensiones delmodelo E/G: Tipos de Especialización • 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 61
  • 62.
    3.3. Extensiones delmodelo E/G: Especialización Disjunta y Total EMPLEADO d DOCENTE ESTUDIANTE claseTrabajo ADMON_Y_SERV BECARIO d BECARIO Especialización Disjunta y Parcial DOCENTE d AYUDANTE TITULAR cuerpoDocente CATEDRÁTICO 62 tipo NO_BECARIO
  • 63.
    3.3. Extensiones delmodelo E/G: Especialización Solapada y Total PERSONA O EMPLEADO ocupación ESTUDIANTE Especialización Solapada y Parcial EMPLEADO dedicación DOCENTE O INVESTIGADOR 63
  • 64.
    3.3. Extensiones delmodelo E/G: Reglas de inserción y eliminación • 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 64
  • 65.
    3.3. Extensiones delmodelo E/G: Reglas de inserción y eliminación (ii)  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) 65
  • 66.
    3.4.1 Objetivos yfases del diseño lógico • • • 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 66
  • 67.
    3.4.1 Objetivos yfases del diseño lógico Fases  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 67
  • 68.
    3.4.1 Objetivos yfases del diseño lógico Fases (y 2)  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, ... 68
  • 69.
    3.4.2 Diseño lógicoestándar Reglas de traducción MERE  MR  Reglas para el modelo básico • Dominios • Atributos • Tipos de entidad • Tipos de relación MER Tipo de Entidad Tipo de Relación M:N Tipo de Relación 1:1, 1:N, N:1 RESUMEN MR (SQL-92) Tabla (relación) Tabla Propagación de clave o tabla  Reglas para las extensiones del modelo • Relaciones exclusivas • Jerarquías de Especialización/Generalización 69
  • 70.
    3.4.2 Diseño lógicoestándar Traducción de un dominio y un tipo de entidad • Dominio MERE ESTADO_CIVIL: {S, C, V, D} MR CREATE DOMAIN Estado_civil AS CHAR(1) CHECK VALUE IN (‘S’, ‘C’, ‘V’, ‘D’) ; • Tipo de entidad – Se traduce a una tabla (relación) – Se recomienda usar el mismo nombre o uno MERE PERSONA similar MR CREATE TABLE Persona ( ... ); 70
  • 71.
    3.4.2 Diseño lógicoestándar Traducción de un atributo • 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 MERE MR numSS nombre direccion telefono fechaNacim dni PERSONA nacionalidad altura CREATE TABLE Persona ( dni PRIMARY KEY, numSS UNIQUE NULL, nombre ..., direccion ..., telefono ..., fechaNacim ..., nacionalidad ..., altura ... ) ; 71
  • 72.
    3.4.2 Diseño lógicoestándar Traducción de un atributo (2) • 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 MERE MR (DED) ¿Cuándo será más adecuado utilizar una opción u otra? 72
  • 73.
    3.4.2 Diseño lógicoestándar Traducción de un atributo (3) • 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) MERE MR dni nombre fechaNa c direccion (1,n) PERSONA MR (DED) PERSONA tiene DIRECC_ PERSONA PERSONA (dni, nombre, fechaNac) FK DIRECC_PERSONA (dni, direccion) CREATE TABLE Direcc_Persona ( dni ... direccion ... PRIMARY KEY (dni, direccion) FOREIGN KEY (dni) REFERENCES Persona(dni) ON DELETE CASCADE ON UPDATE CASCADE ); 73
  • 74.
    3.4.2 Diseño lógicoestándar Traducción de un atributo (y 4) • 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 MR MERE dni PERSONA nombre fechaNa c edad PERSONA (dni, nombre, fechaNac, edad) 74
  • 75.
    3.4.2 Diseño lógicoestándar Traducción de una relación binaria M:N  Nueva tabla R, que incluye... V E1 E2 – claves ajenas hacia las claves primarias de R1 y de R2 R1 R2 R  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) nombre ACTOR papel Actua (1,m) en (1,n) caché [MPM 1999] paga código PELICULA ACTOR(nombre, ..., caché, ...) FK ACTUA_EN (actor, pelicula, papel, paga) FK título PELICULA(código, título, ...) 75
  • 76.
    3.4.2 Diseño lógicoestándar Traducción de una relación binaria M:N (3) codAutor AUTOR nomAutor isbn derechosAutor (1,n) Escribe LIBRO (1,4) numPaginas AUTOR(codAutor, nomAutor, ...) FK ESCRIBE (autor, libro, derAutor, numPag) FK titulo LIBRO(isbn, titulo, ...) – Pero la traducción, aunque lo parezca, no está completa... – ... pues falta especificar ciertos aspectos que tienen que ver con las reglas de integridad 76
  • 77.
    3.4.2 Diseño lógicoestándar Traducción de una relación binaria M:N (4) – 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 NUMERIC(2) DEFAULT 20 NOT NULL CHECK (derAutor≥0 AND derAutor<100), numPag NUMERIC(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 ); 77
  • 78.
    3.4.2 Diseño lógicoestándar Traducción de una relación binaria M:N (5) Especificación de restricciones 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) autor derAutor numPag NULL 0-201-65370-2 ... ... A001 – libro NULL ... ... Ambas cosas ya quedan aseguradas por la propia definición de la clave primaria de ESCRIBE: PRIMARY KEY(autor, libro) 78
  • 79.
    3.4.2 Diseño lógicoestándar Traducción de una relación binaria M:N (6) Especificación de restricciones 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)) ); 79
  • 80.
    3.4.2 Diseño lógicoestándar Traducción de una relación binaria M:N (y 7) Especificación de restricciones 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)) ); 80
  • 81.
    3.4.2 Diseño lógicoestándar Traducción de una relación binaria 1:N 1) Caso general  Propagación de clave – E1 1 V R1 N E2 R2 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 codProv nombreCiudad PROVINCIA contiene (1,1) (1,n) CIUDAD ... nomProv CIUDAD( nomCiudad, provincia, ... ) FK: NULOS NO PERMITIDOS PROVINCIA( codProv, nomProv, ... ) 81
  • 82.
    3.4.2 Diseño lógicoestándar Traducción de una relación binaria 1:N (2) 1.2) Participación parcial de E2 en V nomMuseo codCuadro PINACOTECA ciudad Expone (1,n) (0,1) CUADRO titulo pintor sala NULOS PERMITIDOS CUADRO(codCuadro, titulo, pintor, museo, sala...) FK PINACOTECA(nomMuseo, ciudad, ...) 82
  • 83.
    3.4.2 Diseño lógicoestándar Traducción de una relación binaria 1:N (3) 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) nif ESTUDIANTE nombre (0,n) 1:N Propietario_de (0,1) matricula COCHE ESTUDIANTE( nif, nombre, ... ) PROPIEDAD( coche, estudiante) FK NN FK COCHE( matricula, modelo, ... ) 83
  • 84.
    3.4.2 Diseño lógicoestándar Traducción de una relación binaria 1:1 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) nss nombre PACIENTE (1,1) Tiene HISTORIAL MEDICO (1,1) ... ... numHistoria fechaApertura centroSalud PACIENTE ( nss, nombre, numHisto, fechaApert, centroSalud,... ) PK AK, NN 84
  • 85.
    3.4.2 Diseño lógicoestándar Traducción de una relación binaria 1:1 (2) 2) Participación total de una entidad y parcial de la otra 2.1) Caso general E1 – E2 R1  Propagación de clave – V R2 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 codEmp numDep (0,1) (1,1) EMPLEADO DEPARTAMENTO Dirige Un empleado puede no dirigir ningún departamento, fechaInic nomEmp nomDep o bien ser el gerente de uno de ellos (desde cierta fecha, EMPLEADO(codEmp, nomEmp, ...) en la que fue nombrado FK como tal) DEPARTAMENTO(numDep,nomDep, codDir, fechInicDir...) AK, NN 85 NN
  • 86.
    3.4.2 Diseño lógicoestándar Traducción de una relación binaria 1:1 (3) 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, ...) FK DIRIGE (emp, dep, fechInic) AK,NN FK DEPARTAMENTO(numDep, nomDep,...) 86
  • 87.
    3.4.2 Diseño lógicoestándar Traducción de una relación binaria 1:1 (4) 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, Atributos de EMPLEADO nomEmp ... , ..., Atributos de numDepDir ... NULL UNIQUE, DEPARTAMENTO nomDepDir ... NULL, ..., fechInicDir ... NULL, Atributos de DIRIGE ... ); 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 87
  • 88.
    3.4.2 Diseño lógicoestándar Traducción de una relación binaria 1:1 (y 5) 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)) lugar nif nif HOMBRE Matrimonio (0,1) a la antigua (0,1) MUJER HOMBRE(nif, ...) FK MATRIMONIO(esposa, esposo, fecha, lugar) FK fecha AK, NN MUJER(nif, ...) Y... ¿qué acciones de mantenimiento de la integridad referencial debemos imponer para (todos los casos de) transformación de relaciones 1:1? 88 NN NN
  • 89.
    3.4.2 Diseño lógicoestándar Traducción de dependencia en existencia y en identificación  • V E1 E2 Caso particular de relación 1:1 R1 R2 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) 89
  • 90.
    3.4.2 Diseño lógicoestándar Traducción de dependencia en existencia y en identificación (y 2) nifEmp nomEmp 1:N EMPLEADO (0,n) FAMILIAR Tiene (1,1) EMPLEADO ( nifEmp, nomEmp, ...) FK FAMILIAR ( nifFam, emp, ... ) NOT NULL ON DELETE CASCADE ON UPDATE CASCADE fecha historial nombre 1:N PACIENTE (1,n) Acude nifFam (1,1) PACIENTE ( historial, nombre, ... ) FK VISITA_MEDICA ( historial, fecha, hora, ... ) hora observ VISITA MEDICA NOT NULL ON DELETE CASCADE ON UPDATE CASCADE 90
  • 91.
    3.4.2 Diseño lógicoestándar Traducción de una relación binaria reflexiva jefe nifEmp nomEmp Es jefe de EMPLEADO subordinado Caso 1:N EMPLEADO ( nifEmp, nomEmp, ..., jefe, ... ) FK NULL solución problemática si puede haber muchos empleados sin jefe ( demasiados nulos )  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 Caso M:N EMPLEADO ( nifEmp, nomEmp, ... ) FK FK JEFE_EMP ( jefe, subordinado, ... ) Otra posibilidad en el Caso 1:N EMPLEADO ( nifEmp, nomEmp, ...) FK FK JEFE_EMP ( jefe, subordinado, ... ) NN 91
  • 92.
    3.4.2 Diseño lógicoestándar Traducción de una relación n-aria  V Tabla R correspondiente a V, E1 E2 que incluye... R1 R2 E3 – claves ajenas hacia cada clave R3 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 92
  • 93.
    3.4.2 Diseño lógicoestándar Traducción de una relación n-aria (y 2) matricula nifCliente CLIENTE [EN 2002] COCHE fechaVenta (0,1) (0,n) Venta (0,m) nifVendedor VENDEDOR (0,p) BANCO cifBanco VENTA ( matricula, vendedor, cliente, banco, fechaVenta ) 1. 2. 3. 4. ¿Cuál es la superclave de esta relación? ¿y cuál es su clave primaria? ¿Cómo asegurar que no haya ventas sin cliente, sin coche, sin vendedor? ¿Puede reflejarse la existencia de ventas directas (sin banco)? 93
  • 94.
    3.4.2 Diseño lógicoestándar Traducción de exclusividad de relaciones  Añadir restricciones de tipo CHECK Ejemplo para relaciones de tipo 1:N PROFESOR (0,n) (0,n) CREATE TABLE Curso ( codcurso ... PRIMARY KEY, ORGANIZA IMPARTE nomcurso ..., ... (1,1) (1,1) director ... REFERENCES Profesor (idProf) CURSO 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) ) ) ... ); 94
  • 95.
    3.4.2 Diseño lógicoestándar Traducción de exclusividad de relaciones (2) Ejemplo para relaciones de tipo M:N ALUMNO (1,n) (1,n) CREATE TABLE Alumno_Estudia_Titulacion ( alu ... REFERENCES Alumno (numExp) estudia cursa ON DELETE CASCADE ON UPDATE CASCADE , titu ... REFERENCES Titulacion (idTit) (0,n) ON DELETE NO ACTION ON UPDATE CASCADE , (0,n) PRIMARY KEY (alu, titu), TITULACIÓN MASTER CONSTRAINT titulacion_xor_master CHECK ( alu NOT IN (SELECT alum FROM Alumno_Cursa_Master) ) ); [MPM 1999] 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) ) ); 95
  • 96.
    3.4.2 Diseño lógicoestándar Traducción de especialización/generalización 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 96
  • 97.
    3.4.2 Diseño lógicoestándar Traducción de especialización/generalización (2) Transformación guiada por el supertipo: Jerarquía disjunta total nif nombre EMPLEADO UNIVERSIDAD d PROFESOR BECARIO categoría tipoBeca [MPM 1999] tipo CREATE TABLE Empleado_Universidad ( nif ... PRIMARY KEY, nombre ... , tipo ... NOT NULL CHECK tipo IN (‘pro’, ‘bec’, ‘pas’), categ ... NULL, tipoBeca ... NULL, activ ... NULL, ... PAS CHECK ( ( tipo = ‘pro’ AND categ IS NOT NULL AND tipoBeca IS NULL AND activ IS NULL ) actividad OR ( tipo = ‘bec’ AND tipoBeca IS NOT NULL AND categ IS NULL AND activ IS NULL ) restricciones OR ( tipo = ‘pas’ AND activ IS NOT NULL AND categ IS NULL AND tipoBeca IS NULL ) ) semánticas ); 97 disjunta PARCIAL: PERMITE NULL EN TIPO
  • 98.
    3.4.2 Diseño lógicoestándar Traducción de especialización/generalización (3) Transformación guiada por el supertipo: Jerarquía solapada parcial Alternativa 1: CREATE TABLE Individuo ( nif ... PRIMARY KEY, nif nombre INDIVIDUO nombre ... , fechanac fechanac ... , estudia ... NOT NULL CHECK (estudia IN (‘T’, ‘F’)), actividad curra ... NOT NULL CHECK (curra IN (‘T’, ‘F’)), titulacion ... NULL, nss ... NULL UNIQUE, ESTUDIANTE CURRANTE salario ... NULL, ... titulacion nss salario CHECK ( (estudia = ‘T’ AND titulacion IS NOT NULL) OR (estudia = ‘F’ AND titulacion IS NULL) ) , Otra posibilidad: CHECK ( (curra = ‘T’ AND nss IS NOT NULL – Sólo una columna discriminante y AND salario IS NOT NULL) valor extra para solapamiento: OR (curra = ‘F’ AND nss IS NULL AND salario IS NULL) ) actividad ... NULL CHECK (actividad IN (‘estudia’, ‘trabaja’, ‘est_trab’)) ); 98
  • 99.
    3.4.2 Diseño lógicoestándar Traducción de especialización/generalización (4) Transformación guiada por el supertipo: Jerarquía solapada parcial Alternativa 2: – Un solo atributo discriminante, tratado como atributo multivalorado CREATE TABLE Individuo ( nif ... PRIMARY KEY, nombre ... , fechanac ... , titulación ... NULL, nss ... NULL UNIQUE, salario ... NULL, ... ); CREATE TABLE Actividad_Individuo ( nifIndiv ... REFERENCES Individuo( nif ) ON DELETE CASCADE ON UPDATE CASCADE, nomActiv ... , CHECK (nomActiv IN (‘estudiar’, ‘trabajar’)), PRIMARY KEY ( nifIndiv, nomActiv ) );  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 99
  • 100.
    3.4.2 Diseño lógicoestándar Traducción de especialización/generalización (6) Transformación guiada por el supertipo: Jerarquía solapada parcial Alternativa 2: (cont.) Restricciones de Integridad necesarias 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’))); 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 3.4.- 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 100
  • 101.
    3.4.2 Diseño lógicoestándar Traducción de especialización/generalización (7) Transformación guiada por el supertipo: Jerarquía solapada total nombre UNIVERSITARIO o ESTUDIANTE titulacion tipo CURRANTE nss titulacion salario salario 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 ) ) ); Otras opciones: – Una sola columna discriminante – Tratar discriminante como un atributo multivalorado 101
  • 102.
    3.4.2 Diseño lógicoestándar Traducción de especialización/generalización (8) 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 102
  • 103.
    3.4.2 Diseño lógicoestándar Traducción de especialización/generalización (9) 2. Transformación total • Los subtipos se diferencian en muchos atributos • Se desea mantener los atributos comunes en una tabla separada P d B1  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 Ri para cada subtipo Bi, que incluye...  columnas para los atributos del subtipo Bi  columna clave ajena hacia la clave primaria de R ( propagación en cascada)  la clave primaria es dicha clave ajena 103 B2
  • 104.
    3.4.2 Diseño lógicoestándar Traducción de especialización/generalización (10) Ejemplo de transformación total con jerarquía disjunta y parcial codigo DOCUMENTO tipo d ARTICULO revista fecha idioma titulo LIBRO edicion editorial  El atributo discriminante no aparece en ninguna de las tablas resultado de la traducción 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 ... ); 104
  • 105.
    3.4.2 Diseño lógicoestándar Traducción de especialización/generalización (11) 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é?) 105
  • 106.
    3.4.2 Diseño lógicoestándar Traducción de especialización/generalización (12) 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 tabla Ri para cada subtipo que contiene... – columnas para los atributos del subtipo Bi y – columnas para los atributos comunes (del supertipo) – la clave primaria de Ri es el identificador principal del supertipo 106
  • 107.
    3.4.2 Diseño lógicoestándar Traducción de especialización/generalización (13) Ejemplo de transformación guiada por los subtipos codigo DOCUMENTO tipo d ARTICULO revista fecha idioma titulo LIBRO edicion editorial  El atributo discriminante no aparece en ninguna de las tablas resultado de la traducción CREATE TABLE Articulo ( codigo ... PRIMARY KEY titulo ..., idioma ..., revista ... , fecha ... ); CREATE TABLE Libro ( codigo ... PRIMARY KEY titulo ..., idioma ..., edicion ... editorial ... ); 107
  • 108.
    3.4.2 Diseño lógicoestándar Traducción de especialización/generalización (y 14) 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 108
  • 109.
    3.4.3 Diseño lógicoespecífico • 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 109

Notas del editor

  • #2 El objetivo principal de este tema es trasladar a los alumnos los conceptos del modelo entidad-relación extendido, y mostrar cómo representarlos gráficamente a través de varias notaciones. Tras introducir brevemente el modelo entidad-relación, describiremos algunos de los conceptos de modelado básicos que ofrece. Después, abordaremos algunas de las extensiones propuestas para el MER que permiten el modelado de requisitos de datos más complejos.
  • #4 Vehículo de comunicación adecuado entre los analistas/diseñadores y el usuario no técnico
  • #5 El término “Relationship” suele traducirse también por “Interrelación”
  • #6 El término OBJETO se utiliza en el sentido que tiene en el lenguaje común, y no con el que suele darse en el paradigma de la Orientación a Objetos. ANSI = American National Standards Institute, &amp;lt;http://www.ansi.org/&amp;gt; Instituto de estándares Americano ANSI (1977): The ANSI/X3/SPARC DBMS Framework. Report on the Study Group on Database Management Systems. D. Tsichiritzis y A. Klug (eds). Montvalle, N.J.: AFIP Press, 1977.
  • #7 Los valores de los atributos q describen cada entidad son una parte importante de los datos almacenados en la base de datos.
  • #8 Cada tipo de entidad es descrito por su nombre y la lista de nombres de sus atributos
  • #9 En realidad, utilizaremos el término ENTIDAD como sinónimo de TIPO DE ENTIDAD
  • #11 Los valores de los atributos q describen cada entidad son una parte importante de los datos almacenados en la base de datos.
  • #12 No explicar cuándo utilizar un atributo compuesto o bien varios atributos simples, pues esta norma de diseño se estudiará en el “Tema 4.- Diseño Conceptual”
  • #15 Nulo = Cardinalidad Mínima 0 Valor que existe, pero falta “fechanacim” [de un empleado] Valor no aplicable: “fechajubilacion” [de una persona que aún está en activo]
  • #16 Señalar que para representar gráficamente los conceptos de modelado que ofrece el MER vamos a emplear principalmente dos notaciones: la seguida en el libro [EN2002] y la empleada en el libro [MPM1999]. Indicar que la notación de [EN2002] es muy similar a la original definida por Chen en 1976. Las notaciones empleadas en las otras referencias: [CBS1998] y [SKS1998] coinciden con la de [EN2002], salvo que se indique otra cosa. A la vista de esta diapositiva, destacar: Atributos simples / compuestos Atributos monovalorados / multivalorados Atributos opcionales / obligatorios Atributos derivados / almacenados Los casos normales no se muestran en el diagrama: cardinalidad del atributo es (1,1) almacenado obligatorio CARDINALIDAD DE UN ATRIBUTO Nº mínimo y máximo de valores que puede tomar un atributo, en una instancia de un Tipo Entidad (o de Relación) Sean a atributo, E Tipo de Entidad card_min(a, E) = 0; a puede NO TOMAR VALOR; a PUEDE SER NULO. card_min(a, E) = 1; a DEBE TOMAR OBLIGATORIAMENTE UN VALOR. card_max(a, E) = 1; a TOMARÁ como mucho, UN VALOR individual a la vez. card_max(a, E) &amp;gt; 1; a puede TOMAR MÁS DE UN VALOR para la misma instancia de entidad (o de relación); a es MULTIVALUADO.
  • #17 La restricción de unicidad prohíbe que dos entidades tengan simultáneamente el mismo valor para el atributo clave. La notación [CBS1998] y [SKS1998] coincide con la de [EN2002].
  • #18 Una clave compuesta debe ser MINIMA, es decir, no debe contener atributos superfluos = que podrían quitarse y el resto seguiría siendo clave Ejemplo: la clave compuesta (nombre, telefono, fechanacim) no es mínima, sobra “telefono”. Otros ejemplos de claves candidatas: PROFESOR: (nif), (nombre, despacho, facultad) ALUMNO: (nif), (numexpediente), (fechanacim, nombre, telefono) NO COMMENT: Según [EN2002] una entidad puede no tener clave, en ese caso, es una entidad débil
  • #20 NO COMMENT: Lo de crear un nuevo atributo compuesto para la clave alternativa lo he sacado de [EN2002] p.47, lin. 7. NO COMMENT: lo de que sea obligatoria la clave lo he sacado de [MPM1999] p.56. Es una restricción inherente del MER. La notación [CBS1998] y [SKS1998] coincide con la de [EN2002].
  • #23 Cada instancia de la relación es una asociación entre entidades, en la que participa exactamente una entidad de cada tipo. Representa el hecho de que las entidades están relacionadas entre sí de alguna manera en la situación correspondiente del “mundo real”.
  • #24 Segunda restricción inherente al MER: sólo puede haber relaciones entre entidades. Es decir, está prohibido establecer una relación entre relaciones y entre una relación y una entidad.
  • #25 En una instancia de una relación SIEMPRE participa una instancia de cada tipo de entidad ligada a la relación. Por ejemplo, una instancia de AQUIA necesariamente consiste en una instancia de CIENTE, otra de PE ICUA, y otra deOCA_VIDEOClUB. No tiene sentido que vincule tan solo dos de ellas...
  • #26 Los nombres de rol ayudan a explicar el significado de la relación, por eso su uso es casi obligatorio en los tipos de relación reflexivas, para evitar la ambigüedad.
  • #27 Estas restricciones permiten expresar algunas de las Reglas del Negocio.
  • #28 Una instancia de director puede estar relacionada con muchas instancias de película (todas las que él ha rodado) Una instancia de película sólo puede relacionarse con una única instancia de director (justo aquél que la haya filmado) La notación [CBS1998] coincide con la de [EN2002].
  • #30 La DEPENDENCIA EN EXISTENCIA significa que una instancia de esa entidad sólo puede existir si participa en una instancia de la relación. La dependencia del tipo de entidad es con respecto al tipo de relación. No tiene el mismo significado que la dependencia en existencia de [MPM1999], puesto que se debe entender como que no tiene sentido que exista una entidad que no participe en la relación. Concepto coincidente con los incluidos en [CBS1998] y [SKS1998]
  • #31 Participación total Todo empleado trabaja en un local (sucursal) del vídeo-club. * Toda instancia de EMPLEADO DEBE estar relacionada con alguna instancia de LOCAL * NO tiene sentido que EXISTA un empleado que NO trabaje en algún local, es decir que NO participe en una relación de tipo TRABAJA_EN Participación parcial NO todo empleado es encargado de un local del vídeo-club, sino sólo algunos de ellos * NO NECESARIAMENTE TODAS las instancias EMPLEADO están relacionadas con instancias de LOCAL, sino las de un subconjunto del conjunto total de empleados
  • #33 Este concepto proporciona más información acerca de la relación. Se asocia (min,max) en cada participación del tipo de entidad en el tipo de relación Una instancia de la entidad debe participar al menos en min y como mucho en max instancias de la relación si min=1, toda instancia del tipo de entidad debe participar al menos en una instancia del tipo de relación, es decir: participación total de la entidad en la relación si min = 0, algunas instancias de e pueden no participar en el tipo relación: participación parcial de la entidad en la relación Coincide con [CBS1998]. Sin embargo, este concepto no aparece en [SKS1998].
  • #36 “salario” de un actor por participar en cierta película. “papel” que interpreta un actor en una película (protagonista, secundario, reparto, figuración...). PREGUNTA: ¿Qué pasaría si “salario” o “papel” estuvieran colocados en ACTOR o en PELICULA? Ojo: una relación puede tener atributos, pero nunca una clave.
  • #37 En el caso M:N, los atributos deben pertenecer a la relación, porque su valor está determinado por la combinación de las instancias participantes, y no por una sola de ellas. En el caso 1:N, sólo se puede llevar a la entidad que está en el lado N de la relación (la que participa una vez, que condiciona el valor del atributo)
  • #38 Coincide con el concepto en [CBS1998] y [SKS1998]
  • #39 Una entidad débil siempre tiene una restricción de participación total en la relación que la une a su entidad propietaria Dependencia en existencia en [EN2002] de toda entidad débil: una instancia de un tipo de entidad débil no puede existir si no está unida a una instancia de la entidad regular (si ésta desaparece, también deben desaparecer las débiles que dependen de ella) VISITA_MEDICA depende en existencia de PACIENTE y de MEDICO, pero sólo es débil de PACIENTE: ACUDE es la relación identificador
  • #41 CINTAVIDEO = copia concreta de cierta película. NO HISTÓRICO: la relación representa los alquileres ACTIVOS en cada momento (de ahí la cardinalidad (0,1) de CINTAVIDEO). [EN2002] y [CBS1998] Número mínimo y máximo de instancias de relación en la que puede participar una instancia del tipo de entidad E1.(coincide con la definición para relaciones binarias) [MPM1999] y [Luque, Gómez 97] La cardinalidad de una de las entidades (E1) con respecto a las otras dos (E2 y E3) es el número mínimo y máximo de instancias de E1 que están relacionadas con una de E2 y otra de E3 ya vinculadas en la relación. Los valores de las cardinalidades así definidas pueden ser distintos de los de las cardinalidades definidas por M. Tardieu (Conception d’un systéme d’information. Construction de les bases de données, 1979). Nota: no he encontrado ninguna ternaria con alguna entidad cuya cardinalidad mínima tuviera el valor 0 en la notación [MPM1999]. MÁS EJEMPLOS de relaciones ternarias: ASIGNATURA – ALUMNO – PROFESOR (relación DOCENCIA, con atributo “curso”) CLIENTE – COCHE – VENDEDOR (relación VENTA, con atributos “fecha” y “precio”) ASIGNATURA – EXAMEN (débil) – ALUMNO (relación EXAMINA, con atributo “nota”) ALUMNO – PFC – PROFESOR (relación REALIZA) AUTOBÚS – LUGAR – CONDUCTOR (relación TIENE PARADA, con atributos “fecha”, “hora”)
  • #42 DIBUJO DE LA DERECHA: Un cliente al menos habrá alquilado en un local (cuando se le dio de alta como cliente); un local puede no tener todavía ningún cliente, o haber dado de alta a muchos. La relación entre cliente y local_videoclub es redundante, por lo que puede quitarse. Es complicado decidir entre utilizar una relación ternaria o varias binarias. El diseñador debe basar sus decisiones en la semántica de la situación particular que se está modelando.
  • #43 La ternaria modela la REALIDAD La binaria PUEDE_SUMINISTRAR modela la POSIBILIDAD - Pérdida de semántica: no significan lo mismo!!
  • #44 Los elementos que hemos visto hasta ahora son suficientes para realizar el diseño conceptual de la mayoría de esquemas de base de datos para aplicaciones de base de datos tradicionales (administrativas). Sin embargo, desde los años 80 ha ido en aumento el desarrollo de nuevas aplicaciones de BD, como herramientas CAD, CAM y CASE y aplicaciones multimedia. Los requisitos de base de datos de este tipo de aplicaciones son mayores y más complejos que los de las tradicionales y los conceptos básicos del modelo ER no son suficientes para representarlos. Este hecho hizo que se añadieran nuevos conceptos semánticos de modelado al modelo ER original, dando lugar al modelo entidad-relación extendido (EER: enhanced Entity-Relationship model). CAD: Computer Aided Design CAM: Computer Aided Manufacturing CASE: Computer Aided Software Engineering
  • #45 Otro ejemplo sería el de un ARTÍCULO que pudiera publicarse en un PERIÓDICO o en una REVISTA, pero nunca en ambos. Un ejemplo más sería el de los domicilios de los estudiantes universitarios durante el curso académico. Un ESTUDIANTE se puede alojar en un DOMICILIO_FAMILIAR, una RESIDENCIA_ESTUDIANTES o en un PISO_COMPARTIDO. Las tres relaciones que unen a ESTUDIANTE con las tres entidades serían exclusivas entre sí.
  • #46 (*transparencia de introducción, todo lo que ella indica se trata con profundidad más adelante*) Especialización: Un ANIMAL es un FELINO Generalización: Un REPTIL es un tipo de ANIMAL; Un INSECTO es un tipo de ANIMAL
  • #50 La entidad del subtipo representa la misma entidad que el supertipo, luego debe poseer valores para los atributos como miembro del supertipo, además de valores para los atributos específicos.
  • #67 Hay que conseguir un equilibrio entre los requisitos exigidos al sistema: flexibilidad, confidencialidad, integridad, tiempo de respuesta, etc., estableciendo prioridades y adoptando una solución de compromiso. En [MPM 1999] (cap. 10, pág. 344) dice que el diseño lógico estándar se realiza “teniendo en cuenta los requisitos de proceso y entorno”. Los requisitos de proceso influyen en la elección adecuada de las acciones disparadas por la integridad referencial, y en la selección de la opción de diseño lógico más adecuada entre varias alternativas a la hora de transformar el esquema conceptual. Por ejemplo el uso de un atributo o una tabla, utilizar una o varias tablas al transformar una relación 1:1 o 1:N según el rendimiento deseado (join)... En cuanto al entorno, tiene que ver con el modelo de datos de representación soportado por el SGBD elegido para la implementación.
  • #68 Las actividades que han de realizarse en la etapa de Diseño Lógico serían las siguientes: Transformar cada entidad en una relación (tabla) Eliminar relaciones M:N Eliminar relaciones n-arias Eliminar relaciones con atributos Eliminar atributos multivalorados Reexaminar relaciones 1:1 Eliminar relaciones redundantes
  • #71 DOMINIOS El modelo relacional estándar y SQL-92 admiten los dominios como un elemento más del esquema (además de las relaciones y los asertos (restricciones de integridad 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.*)
  • #72 El atributo numSS puede ser NULL puesto que pueden existir personas que no hayan trabajado nunca. En general, es conveniente mantener los mismos nombres en el Esquema Lógico para los atributos, por legibilidad y facilidad de comprensión. Si es necesario utilizar nombres diferentes a los empleados en el Esquema Conceptual, por ser demasiado largos, por ejemplo, es necesario indicar la correspondencia de nombres en la documentación asociada a la fase de Diseño Lógico Estándar.
  • #73 ATRIBUTO COMPUESTO El modelo relacional sólo permite atributos simples, así que es necesario poner el esquema, y en particular cada una de las entidades, en la 1FN, de forma que todo atributo compuesto sea transformado en uno o varios atributos simples. (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 (único) 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 fechaNacim declarado sobre el dominio DATE, compuesto a su vez por YEAR, MONTH, DAY.
  • #74 ATRIBUTO MULTIVALORADO El modelo relacional sólo permite atributos (columnas) monovalorados, así que es necesario poner el esquema y en particular, cada una de las entidades, en la 1FN, de forma que todo atributo multivalorado de una entidad E sea transformado en otra entidad S vinculada a E mediante una relación 1:N. Si la clave primaria de la entidad E, transformada en la tabla R, era compuesta (varios atributos), todos ellos (como columnas simples) pasan a la nueva tabla S (correspondiente al atributo multivalorado), y todos ellos forman la clave ajena a la clave primaria de R. Ejemplo: LIBRO (isbn, título, ...) EJEMPLAR( isbn, numero, idioma, titulos_capítulos(1,n), ...) La transformación daría lugar a tres tablas: LIBRO (isbn, título, ...) EJEMPLAR( isbn, numero, idioma, ...) CAPITULO_EJEMPLAR( isbn, numero, tituloCapitulo) Nótese que en esta diapositiva se ha utilizado una notación para DIRECC_PERSONA en el DED que recuerda a las entidades débiles en los diagramas MERE. Se comentará este aspecto más adelante, cuando se estudie la transformación de Dependencia en Existencia e Identificación.
  • #76 Lectura del esquema del ejemplo: Un actor puede actuar en una o varias películas. En una película pueden participar uno o varios actores (no se consideran las películas de animación). Cada actor participa con cierto papel (protagonista, secundario, reparto, figuración, cameo) y recibe cierta cantidad de dinero en cada película en la que actúa.
  • #77 Lectura del diagrama del ejemplo: Un autor puede escribir uno o varios libros. Un libro puede tener un único autor o tener varios autores (no se consideran los anónimos), hasta un máximo de 3.4. Cada autor contribuye con cierto número de páginas en cada libro en el que participa (entero de 3 dígitos). Los derechos de autor son el porcentaje que el autor cobra por la venta de determinado libro; por tanto será un entero de dos dígitos (de 0 a 99 %)
  • #78 Nótese que las acciones disparadas por la Integridad Referencial, para las claves externas desde una tabla proveniente de una relación M:N, pueden ser diferentes: es necesario determinar la política adecuada de borrado o modificación (NO ACTION, CASCADE, SET NULL, SET DEFAULT) para cada clave externa, según la semántica de la misma. En el ejemplo, y en lo que a las reglas de borrado se refiere, no tiene sentido borrar un autor (de la tabla AUTOR) si en ESCRIBE existen filas indicando que hay libros escritos por él, pero si se elimina un libro (de la tabla LIBRO), ya no es necesario tener la indicación de quienes lo escribieron: deben borrarse también las filas de ESCRIBE que hacen referencia al libro (ojo: el autor no se eliminaría de su tabla). Importante: lo que se elimina/actualiza en cascada es “la anotación que indica un vínculo entre libro y autor” y no el autor en sí ni el libro en sí (las tablas AUTOR y LIBRO no se ven afectadas por la propagación). Los requisitos de proceso influyen en la elección adecuada de las acciones disparadas por la integridad referencial.
  • #80 IMPORTANTE: Si en lugar de la restricción del NOT EXISTS pusiéramos esto: 1&amp;lt;=(SELECT MIN(COUNT(*)) FROM Escribe GROUP BY libro) Estaríamos contando las filas de ESCRIBE en las que aparece el libro, pero ¡no tenemos en cuenta los libros no referenciados desde ESCRIBE! que son justamente los que violan la restricción ... o bien esto: NOT EXISTS (SELECT * FROM Escribe WHERE autor IS NULL) Tampoco estaríamos comprobando si todo libro -fila de LIBRO- tiene al menos una fila correspondiente en la relación ESCRIBE que lo vincule a un AUTOR. Además esto nunca sucede, por ser autor parte de la clave de ESCRIBE
  • #82 Es interesante pensar por qué la propagación en el otro sentido no es correcta. [EN 2002] E2 participa una vez en la relación V (es el caso de CIUDAD) E1 participa n veces (es el caso de PROVINCIA) Card(PROVINCIA) = 1,n Card(CIUDAD) = 1,1 [MPM 1999] Card(PROVINCIA) = 1,1 Card(CIUDAD) = 1,n
  • #83 Nota acerca del diagrama del ejemplo: Es posible la existencia de cuadros pertenecientes a colecciones situadas en casas particulares, en cuyo caso el cuadro no está en ninguna pinacoteca.
  • #84 En los requisitos encontraremos si se cumple alguno de los supuestos indicados. (ojo: la eficiencia es menor con esta solución, pues para obtener los datos habrá que hacer una reunión que se evitaría con la propagación de clave) Un estudiante o no posee coche, o tiene varios [MPM 1999] cardinalidad de coche: (0,n) ; [EN 2002] cardinalidad de estudiante: (0,n) Un coche es propiedad de un estudiante o no (propiedad de otra persona, no estudiante) [MPM 1999] cardinalidad de estudiante: (0,1) ; [EN 2002] cardinalidad de coche: (0,1) Es posible pensar que hay pocas instancias del tipo de relación, es decir, que hay pocos estudiantes que sean propietarios de coches. NOTA: Los coches que NO sean propiedad de un estudiante, no aparecerán en la tabla PROPIEDAD (correspondiente a PROPIETARIO_DE), sino que sólo aparecerán en la tabla COCHE. Los estudiantes que no posean ningún coche tampoco aparecerán en PROPIEDAD, sino sólo en ESTUDIANTE. Si las cardinalidades mínimas tuvieran valor 1, sería necesario incluir Restricciones de Integridad para asegurar su cumplimiento (*análogas a las que aparece en la última transparencia dedicada a la transformación de relaciones M:N*) En el ejemplo, ·E1 es ESTUDIANTE. Si su cardinalidad [EN 2002] 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é relacionada con al menos una instancia de COCHE. ·E2 es COCHE. Si su cardinalidad [EN 2002] fuera (1,1) significaría que todo coche siempre es propiedad de un estudiante. Hace falta una restricción de integridad para asegurar que toda instancia de COCHE esté relacionada con al menos una instancia de ESTUDIANTE.
  • #85 En el caso de que las claves primarias de ambas entidades sean equivalentes, sólo se mantiene una de ellas en la relación resultado, pues la otra no es necesaria.
  • #86 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 EMPLEADO (es decir, que todo departamento está dirigido por un (y sólo un) empleado). Si se propagara en el otro sentido (es decir, si cada empleado contuviera el número 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 codEmpnumDepDir (UNIQUE)fechaInicDir numDepnomDep 20NULL (#)NULL1Compras 10329/08/1972 2Contabilidad (*) 35NULL (#)NULL 3Informática 30NULL (#)NULL 15128/07/1979 (#) Empleado NO director (NULOS) (*) Departamento sin Gerente (error, pues cardMin = 1) Nota: explicar por qué numDepDir debe ser UNIQUE Esta sería la transformación correcta: EMPLEADODEPARTAMENTO codEmp...numDepnomDep codDir(+)fechInicDir 20...1Compras 15 28/07/1979 10...3Informática 10 29/08/1972 30...2Contabilidad 30 04/09/1972 35... 15... (+) Debe ser NOT NULL (cardMin(EMPLEADO, DIRIGE)=1) y UNIQUE (cardMax(EMPLEADO, DIRIGE)=1) OJO: La cardinalidad máxima 1 para la entidad DEPARTAMENTO (un empleado puede dirigir como mucho un departamento), NO se asegura haciendo PK=( numDep, codDir ), pues de este modo, 1 empleado podría dirigir varios departamentos, o 1 departamento podría tener varios gerentes (aunque la combinación de los dos valores sí es un valor único). Este problema se ve claramente con el siguiente ejemplo: DEPARTAMENTO numDepcodDirenomDep 115Compras SOLUCIÓN 215Contabilidad · emp 15 dirige DOS deptos!  UNIQUE(codDire) 210Contabilidad · dep 2 tiene DOS gerentes!  PK(numDep) 310Informática
  • #87 Si hay o no pocas instancias del tipo de relación, estará recogido en los requisitos.
  • #88 A la relación suele dársele el nombre de la entidad con participación parcial. EMPLEADO: codEmpnomEmpnumDepDirnomDepDirfechInicDir 20JuárezNULLNULLNULL 10Gómez3Informática29/08/72 35AranaNULLNULLNULL 15Santos1Compras28/07/79 El atributo numDepDir (departamento del cual el empleado es el director, no el departamento al que pertenece ese empleado) debe ser UNIQUE, para que cardMax(DEPARTAMENTO,DIRIGE)=1 (no es dirigido por nadie más). El inconveniente es que se pierde DEPARTAMENTO como entidad separada y autónoma. Un departamento sólo existe asociado al empleado que lo dirige, lo que puede provocar anomalías (se verá en el tema de normalización).
  • #89 El atributo “esposo” (correspondiente a la PK de la otra relación) debe ser UNIQUE y NOT NULL (clave alternativa).
  • #90 En un DED, las entidades resultado de transformar una relación M:N o las entidades resultado de transformar un atributo multivalorado (ya sea de una entidad o de una relación), suelen ser entidades débiles en identificación (pues hacia ellas se propagan las claves de las entidades originales) Aunque en METRICA no se indica nada acerca de la existencia de entidades débiles, en un DED sí puede representarse entidades débiles. Las entidades consideradas débiles en el DED dependerán 1) de la notación empleada durante el diseño conceptual ([EN 2002] iguala debilidad a dependencia en identificación, mientras que para [MPM 1999] basta con depender en existencia para que una entidad ya sea considerada débil). 2) del concepto de entidad débil definido en la herramienta CASE utilizada para pintar el DED. Por ejemplo System Architect 2001 define automáticamente como débil una entidad si a) es un subtipo de otra, b) está ligada mediante una asociación “identifying” con otra y c) está ligada mediante una asociación non-identifying con otra cuya participación es total (obligatoria) En cualquier caso, lo importante y fundamental es mantener esa semántica (debilidad) en el esquema lógico, pues de ello depende la determinación de la PK de la relación correspondiente a la entidad débil, así como las acciones referenciales con respecto a la relación correspondiente a la entidad fuerte. Por tanto, en el Modelo Relacional de datos NO HAY “relaciones débiles”, pues las entidades débiles de un diagrama MERE se habrán transformado en relaciones, cuya PK será compuesta en el caso de dependencia de identificación, y que tendrán una FK hacia la relación correspondiente a la entidad fuerte, y con política de borrado en cascada.
  • #93 Si en el esquema conceptual MERE, la relación V estuviera representada mediante una entidad, seguro que participaría de forma total en las relaciones con las demás entidades. Pero puede ser dependiente en identificación de todas ellas o tan solo de unas cuantas.
  • #94 Nota: fechaVenta no puede tomar NULL RESPUESTAS 1. La superclave de VENTA es (matricula, cliente, vendedor, banco). 2. La cardinalidad máxima de COCHE en VENTA es 1, lo que significa que un coche participa, como mucho, en una relació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. 3. 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 entidades COCHE, CLIENTE, VENDEDOR (claves primarias), nunca pudieran tomar NULL. 3.4. 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 uno de los tipos de entidad Ei que participan en V, 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 de relación V. NOTA: en [EN 2002] página 277 parece decir lo contrario “cuando una entidad tiene cardinalidad 1, su clave no tiene por qué aparecer en la clave de la tabla correspondiente a la relación n-aria”. Sin embargo es correcto, pues se refiere a la cardinalidad (o tipo) de la relación, no a la cardinalidad de cada entidad en la relación. En nuestro ejemplo, la cardinalidad de la relación venta es (N, 1, 1, 1) donde la N está situada en la conexión Venta-COCHE, puesto que los mismos cliente, vendedor y banco pueden firmar la venta de varios coches (independientemente de que un coche puede participar como mucho en una relación, pues sólo puede venderse una vez), por esto las claves de CLIENTE, VENDEDOR y BANCO no son necesarias en la PK de VENTA.
  • #95 Un profesor organiza cursos, o bien imparte cursos, pero no ambas cosas.
  • #96 Un alumno estudia (a la vez o no) varias titulaciones universitarias, o bien cursa (a la vez o no) varios masters, pero no ambas cosas.
  • #97 El discriminante indica el tipo al que pertenece cada instancia (fila de la única tabla resultante).
  • #98 Al ser atómico el (único) atributo discriminante, se asegura la disyunción: un empleado sólo puede ser uno de los tres subtipos (no pertenencia a varios a la vez). Al ser no nulo y tener la comprobación de dominio, se asegura la totalidad: no puede existir un empleado que no esté en alguno de los subtipos. Las instancias de DOCUMENTO que no sean ni ARTÍCULO ni LIBRO tendrán nulo en el atributo discriminante (tipo), así como en todos los atributos procedentes de los subtipos.
  • #99 El discriminante es modelado mediante un atributo “booleano” para cada subtipo: valores T (TRUE) y F (FALSE). Las restricciones semánticas que preguntan si el valor del atributo del discriminante es FALSE pueden obviarse, si se asegura que sólo se va a acceder a los atributos de un subtipo cuando el atributo discriminante correspondiente esté a TRUE. Parcialidad: los individuos que no estudian ni trabajan tendrán estudia=‘F’ y curra=‘F’. Otra opción es utilizar un único atributo discriminante, actividad, y crear un valor extra para los casos de solapamiento: actividad ... NULL CHECK (actividad IN (“estudia”, “trabaja”, “est_trab”) ) Junto con las restricciones de integridad correspondientes. Este atributo permite NULL para los casos de individuos que ni estudian ni trabajan (parcialidad). Esta última solución no parece adecuada cuando en la G/E hay más de 2 subtipos y una misma instancia del supertipo puede pertenecer, a la vez, a un subconjunto de subtipos. Ejemplo: PERSONA puede especializarse en ALUMNO, PROFESOR e INVESTIGADOR, de modo que una misma persona puede ser ALUMNO e INVESTIGADOR, ALUMNO y PROFESOR, PROFESOR e INVESTIGADOR, o ALUMNO y PROFESOR e INVESTIGADOR. Con la [Alternativa 1], no hay problema, puesto que existe un atributo booleano por cada subtipo, que contendrá TRUE o FALSE dependiendo de si la instancia PERSONA pertenece o no al subtipo. Con la [Otra Posibilidad] debería crearse un valor del atributo discriminante para cada posible combinación: “alumno”, “profesor”, “investigador”, “alu_prof”, “prof_inv”, “alu_inv”, “alu_prof_inv”… En casos como este, quizá la mejor opción es la [Alternativa 2] (siguiente diapositiva).
  • #100 El discriminante es modelado como un atributo multivalorado. Un INDIVIDUO realiza ninguna o varias actividades (en nuestro caso un máximo de 3). Las restricciones semánticas aseguran que el valor del atributo que contiene las posibles actividades de cada individuo corresponde a uno de los subtipos de la jerarquía original.
  • #102 Las restricciones semánticas aseguran que, si una instancia pertenece a uno o ambos subtipos, no sean nulos los atributos correspondientes a tales subtipos Además, también asegura la totalidad: todo universitario ha de ser estudiante o empleado o ambos. No es necesario incluir la restricción CHECK ( estudia = ‘T’ OR trabaja = ‘T’) Otra opción es utilizar un único atributo discriminante, tipo, y crear un valor extra para los casos de solapamiento: tipo ... NOT NULL CHECK (tipo IN (‘estudia’, ‘trabaja’, ‘est_trab’) ) Y otra opción es tratar el discriminante como un atributo multivalorado, creando una tabla en la que almacenar a qué tipos pertenece cada universitario: CREATE TABLE TIPO_UNIVERSITARIO ( nif... REFERENCES UNIVERSITARIO(nif) ON DELETE CASCADE ON UPDATE CASCADE, tipo... NOT NULL CHECK (tipo IN (‘estudiante’, ‘empleado’)), PRIMARY KEY( nif, tipo) ); Y habría que crear los asertos (RI Generales) necesarios, al estilo de la Alternativa 2 de la Traducción de Jerarquías solapadas y parciales.
  • #104 La propagación en cascada proviene de las REGLAS DE INSERCIÓN Y ELIMINACIÓN que estudiamos en el tema “Modelo Entidad-Relación” (en la parte de las extensiones del modelo, donde se trata la jerarquía de Especialización/Generalización)
  • #105 El discriminante NO aparece en ninguna de las tablas resultado de la traducción. En un DED en System Architect 2001 las entidades subtipo aparecerían como débiles del supertipo
  • #106 Se incrementa la eficiencia del acceso a sólo atributos comunes (los del supertipo) o a sólo atributos propios de un subtipo. Sin embargo, 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.
  • #108 El discriminante NO aparece en ninguna de las tablas resultado de la traducción.
  • #109 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!! (pues no hemos creado una relación donde meterlas) **el resto de transformaciones no tiene este problema** Es decir, 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. Extension(Documento) = EXTERN UNION (Articulo, Libro) -- pero no contiene las que sólo son Documento (y no son ni Articulo ni Libro) Además, para obtener una instancia determinada del supertipo, puesto que no existe ninguna tabla en la que estén almacenadas, hay que buscar en todas las tablas correspondientes a los subtipos, puesto que las instancias del supertipo están distribuidas entre todas ellas.
  • #110 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).