diapositivas

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

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

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

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

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

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

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

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

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

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

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

16. Atributos Clave
• Atributo con valor distinto para cada instancia
de un tipo de entidad
dni en EMPLEADO
• Una clave identifica de forma única cada entidad
concreta  atributo identificador
• Notación
EMPLEADO
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 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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