Objetivos:

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

2
3.1. Introducción e historia del modelo
Entidad-Relació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)

3
Esquema conceptual
3.1. Introducción e historia del modelo
Entidad-Relación

• 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

4
3.2. Conceptos básicos del modelo

• Entidad ( entity )
• Atributo ( attribute )
• Dominio ( values set )
• Relación ( relationship )

5
ENTIDAD
3.2. Conceptos básicos del modelo

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

6
ATRIBUTO
3.2. Conceptos básicos del modelo

• Propiedad o característica de una entidad
• Una entidad particular es descrita por los
  valores de sus atributos

7
TIPO DE ENTIDAD (entity set)
3.2. Conceptos básicos del modelo

• 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
DIRECTOR
LOCALVIDEOCLUB
ACTOR
CLIENTE
8
Instancia de un tipo de entidad
3.2. Conceptos básicos del modelo
PELICULA

• También...
• Ocurrencia
• Realización
• Ejemplar
• Entidad concreta o individual

9
Intensión y Extensión
3.2. Conceptos básicos del modelo

• 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, 160, 28/07/1979, España, 23) e2 ?
(12345678, 6677889900, Antonio Gil Sánchez,
Paz, 5. Murcia. Murcia.30012, 968111222, 176,
14/04/1944, España, 58) e3 ? (11223344,
1234567890, Julia Sauce, Justicia, 20. Yecla.
Murcia. 30510, 968000222, 159, 23/05/1947,
España, 55) ...
10
Tipos de atributos
3.2. Conceptos básicos del modelo

• Simples o Compuestos
• Almacenados o Derivados
• Monovalorados o Multivalorados
• Opcionales

11
Atributos Simples o Compuestos
3.2. Conceptos básicos del modelo

• Atributos compuestos
• Pueden dividirse en otros con significado propio
• Valor compuesto concatenación de valores de
  componentes
• Atributos simples
• No divisibles. Atómicos

genero
12
Atributos Almacenados o Derivados

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

13
Atributos Monovalorados o Multivalorados

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

14
Atributos Opcionales (nulos)

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

15
Notación para atributos
EN2002
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
17
Atributos Clave (ii)

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

18
Atributos Clave (iii)

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

19
Notación para atributos clave
EN2002

• En el MER es obligatorio que todo tipo de entidad
  tenga un identificador

20
DOMINIO (values set)

• Conjunto de valores
• Cada atributo simple está asociado a un dominio,
  que especifica sus valores válidos

Atributo Dominio Descripción Dominio
nombre NOMBRES cadenas de hasta 30 caracteres alfabéticos
telefono TELEFONOS cadenas de hasta 9 caracteres numéricos
altura MEDIDAS números reales entre 0 y 25 (metros)
... ... ...

• No suele representarse, aunque una forma de
  hacerlo sería

MPM1999
21
RELACIÓN (relationship)

• También interrelación
• Asociación, vínculo o correspondenciaentre
  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

22
DIRECTOR HA_RODADO PELICULA

• ? Vacas
• ? Tesis
• ? Belle Epoque
• ? Torrente
• ? Tierra
• Abre los ojos
• Los otros

Instancia del tipo de relación
? ? ? ? ? ? ?
J. Médem ? C. Saura ? F. Trueba ? S. Segura
? A. Amenábar ?
Tipo de Entidad conjunto de instancias
Tipo de Relación conjunto de instancias
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 PELICULAs
• Notación

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

25
Nombres de Rol (papel)

• Todo tipo de entidad que participa en un tipo de
  relación juega un papel específico en la relación
• Los nombres de rol se deben usar, sobre todo, en
  los tipos de relación reflexivos, para evitar
  ambigüedad

26
Restricciones estructurales sobre tipos de
relación

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

27
Razón de Cardinalidad Notación EN2002

• Número máximo de instancias de tipo de relación
  en las que puede participar una misma instancia
  de tipo de entidad
• la cardinalidad de HA_RODADO es 1 a N
• HA_RODADO es de tipo 1 a N
• Notación
• etiqueta en la línea que une entidad y relación
• Ojo da la sensación de que se representa al
  revés

28
Razón de Cardinalidad (ii) EN2002

• Razones de cardinalidad más comunes
• 11 (uno a uno)
• 1N (uno a muchos)
• MN (muchos a muchos)

trabajador
ACTOR
EMPLEADO
personaje
M
encargado
1
1
ACTUA_EN
TRABAJA_EN
SUPERVISA
N
sucursal
N
1
film
LOCAL_VIDEOCLUB
PELICULA
lugar trabajo
29
Razón de Participación Notación EN2002

• Especifica si toda la extensión de un tipo de
  entidad participa en un tipo de relación, o sólo
  parte de la extensión
• Indica si hay dependencia en existencia de un
  tipo de entidad respecto de un tipo de relación
• Clases de participación
• Participación total (dependencia en existencia)
• Participación parcial

30
Razón de Participación (ii) EN2002

• Notación
• Líneas dobles o simples

31
Cardinalidad de tipo de entidad

• Otra forma de expresar las razones de
  cardinalidad y participación

PERSONA EDIFICIO
USA
p1 ? p2 ? p3 ?
? e1 ? e2 ? e3 ? e4
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)
(0,m)
USA
EDIFICIO
PERSONA
(0,n)
(1,1)
POSEE
33
Cardinalidad de tipo de entidad (iii) EN2002
34
Cardinalidad de tipo de entidad (vii)

• Cardinalidad de tipos de entidad recursivos

EN2002
35
Atributos de tipos de relación

• Similares a los atributos de tipos de entidad

EN2002
36
Atributos de tipos de relación (ii)

• Conceptualmente pertenecen a la relación
• Un atributo de una MN es propio de la relación
• Un atributo de una 11 o 1N se puede llevar a
  uno de los tipos de entidad participantes

EN2002
37
Tipo de Entidad DébilNotación EN2002

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

COPIA
38
Tipo de entidad débil (ii) EN2002
39
Tipo de entidad débil (iii) EN2002

• No toda participación total (o dependencia en
  existencia) implica un tipo de entidad débil

dni
EMPLEADO
1

POSEE
N
numlicencia
PERMISOCONDUCCION
tipo
PERMISO_CONDUCCIÓN no es débil depende en
existencia de EMPLEADO, pero tiene clave primaria
propia
40
Tipos de relación con grado superior a dos

• Tipo de relación ternaria

EN2002
fecha

• Cardinalidad de los tipos de entidad

41
Tipos de relación con grado superior a dos (ii)

• Equivalencia ternaria varias binarias

EN2002
42
Tipos de relación con grado superior a dos (iii)

• Ternaria no equivalente a varias binarias

EN2002

• Pérdida de semántica...

43
Modelo Entidad-Relación Extendido, MERE Enhanced
Entity-Relationship model, EER

• Aportaciones de diversos autores al
  modeloEntidad-Relación básico.
• Permiten representar...
• Relaciones exclusivas entre sí
• Jerarquías de Especialización/Generalización

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
GASTA
CONSUME
GASOLINA
GASOIL

• CONSUME y GASTA son exclusivas respecto del tipo
  de entidad VEHICULO

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

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 )

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

EN2002
EMPLEADO
SECRETARIO
GERENTE
COMERCIAL
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
TURISMO
CICLOMOTOR
CAMIÓN
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
FABRICA
VEHÍCULO
FABRICANTE
precio
(1,1)
(1,n)
N1
(1,1)
(0,1)
LLEVA
tonelaje
CAMIÓN
SIDECAR
TURISMO
MOTOCICLETA
numPuer
numEjes
numPlazas
cilindrada
11
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
51
3.3. Extensiones del modelo
E/G Especialización (ii)

• Varias especializaciones de un tipo de
  entidad,con base en diferentes discriminantes

EN2002
PELÍCULA
color
género
COLOR
BLANCO_Y_NEGRO
COMEDIA
DRAMA
TERROR
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

SUPERVISA
CELADOR
SECCIÓN_HOSPITAL
(1,1)
(1,1)
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
numBastidor
fechaFab
VEHÍCULO
precio
fechaFab
CAMIÓN
precio
numEjes
tonelaje
G
CAMIÓN
TURISMO
fechaFab
numBastidor
numEjes
numPuer
tonelaje
numPuer
precio
TURISMO
EN2002
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

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?

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

EN2002
PERSONA
matriculadotrue
estadoLaboralen_activo
EMPLEADO
ESTUDIANTE
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

PERSONA
EMPLEADO_HOSPITAL
estadoLaboral
claseTrabajo
en_activo
en_paro
médico
celador
limpiador
enfermero
EMPLEADO
PARADO
ENFERMERO
MÉDICO
LIMPIADOR
CELADOR
EN2002
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
59
3.3. Extensiones del modelo
Restricciones sobre la E/G Disyunción/Solapamient
o

• 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
o
TURISMO
CAMIÓN
EMPLEADO
ESTUDIANTE
EN2002
60
3.3. Extensiones del modelo
Restricciones sobre la E/G Completitud/Parcialida
d

• Especialización parcial indica que es posible que
  alguna instancia del supertipo no pertenezca a
  ninguno de los subtipos
• Es la opción por defecto
• La unión de las extensiones de los subtipos no es
  la extensión del supertipo en su totalidad

• Especialización total (completa) indica que toda
  instancia del supertipo también debe ser
  instancia de algún subtipo

ANIMAL
ALIMENTO
d
d
MACHO
HEMBRA
HERMAFRODITA
LACTEO
FRUTA
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

62
3.3. Extensiones del modelo
E/G Especialización Disjunta y Total
EMPLEADO
ESTUDIANTE
claseTrabajo
tipo
d
d
DOCENTE
BECARIO
BECARIO
NO_BECARIO
ADMON_Y_SERV
Especialización Disjunta y Parcial
DOCENTE
cuerpoDocente
d
AYUDANTE
TITULAR
CATEDRÁTICO
63
3.3. Extensiones del modelo
E/G Especialización Solapada y Total
PERSONA
ocupación
O
EMPLEADO
ESTUDIANTE
Especialización Solapada y Parcial
EMPLEADO
O
dedicación
DOCENTE
INVESTIGADOR
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
  unaespecialización total implica insertarla en,
  al menos, un subtipoY si la especialización es
  disjunta, entonces la instancia se insertará en
  un único subtipo

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)

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

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

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

69
Reglas de traducción MERE ? MR
3.4.2 Diseño lógico estándar

• Reglas para el modelo básico
• Dominios
• Atributos
• Tipos de entidad
• Tipos de relación
• Reglas para las extensiones del modelo
• Relaciones exclusivas
• Jerarquías de Especialización/Generalización

RESUMEN
MER MR (SQL-92)
Tipo de Entidad Tabla (relación)
Tipo de Relación MN Tabla
Tipo de Relación 11, 1N, N1 Propagación de clave o tabla
70
Traducción de un dominio y un tipo de entidad
3.4.2 Diseño lógico estándar

• Dominio
• Tipo de entidad
• Se traduce a una tabla (relación)
• Se recomienda usar el mismo nombre o uno similar

MR CREATE DOMAIN Estado_civil AS CHAR(1) CHECK
VALUE IN (S, C, V, D)
MERE ESTADO_CIVIL S, C, V, D
71
Traducción de un atributo
3.4.2 Diseño lógico estándar

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

• Atributo compuesto.- Dos alternativas
• Eliminar atributo compuesto y considerar todos
  sus componentes como columnas simples de la tabla
  resultante
• 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?
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
nombre
dni
fechaNac
PERSONA
direccion (1,n)
CREATE TABLE Direcc_Persona ( dni ...
direccion ... PRIMARY KEY (dni, direccion)
FOREIGN KEY (dni) REFERENCES Persona(dni) ON
DELETE CASCADE ON UPDATE CASCADE )
MR (DED)
tiene
DIRECC_ PERSONA
PERSONA
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
• Si se almacena, será una columna de la tabla que
  corresponda y deberá crearse un disparador que
  calcule su valor y lo mantenga actualizado
• Si no se almacena, deberá crearse un
  procedimiento que calcule su valor cada vez que
  se solicita

MERE
MR
PERSONA (dni, nombre, fechaNac, edad)
75
3.4.2 Diseño lógico estándar
Traducción de una relación binaria MN

• ? Nueva tabla R, que incluye...
• claves ajenas hacia las claves primarias de R1 y
  de R2
• Su combinación (concatenación) forma la clave
  primaria de R
• columnas correspondientes a los atributos de la
  relación V (simples o componentes simples de
  atributos compuestos)

nombre
código
papel
ACTOR
PELICULA
Actuaen
(1,m)
(1,n)
paga
caché
título
MPM 1999
76
3.4.2 Diseño lógico estándar
Traducción de una relación binaria MN (3)
codAutor
isbn
derechosAutor
AUTOR
LIBRO
Escribe
(1,n)
(1,4)
nomAutor
numPaginas
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

77
3.4.2 Diseño lógico estándar
Traducción de una relación binaria MN (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
  (derAutor0 AND derAutorlt100),
• numPag NUMERIC(2) NOT NULL CHECK (numPag0),
• PRIMARY KEY (autor, libro),
• FOREIGN KEY (autor) REFERENCES AUTOR(codAutor)
• ON DELETE NO ACTION
• ON UPDATE CASCADE,
• FOREIGN KEY (libro) REFERENCES LIBRO(isbn)
• ON DELETE CASCADE
• ON UPDATE CASCADE
• )

78
3.4.2 Diseño lógico estándar
Traducción de una relación binaria MN (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 libro derAutor numPag
NULL 0-201-65370-2 ... ...
A001 NULL ... ...

• Ambas cosas ya quedan aseguradas por la propia
  definición de la clave primaria de ESCRIBE
• PRIMARY KEY(autor, libro)

79
3.4.2 Diseño lógico estándar
Traducción de una relación binaria MN (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 gt (SELECT MAX(COUNT())
• FROM ESCRIBE
• GROUP BY libro))
• )

80
3.4.2 Diseño lógico estándar
Traducción de una relación binaria MN (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))
• )

81
3.4.2 Diseño lógico estándar
Traducción de una relación binaria 1N

• Caso general
• ? Propagación de clave
• En R2 se incluyen nuevas columnas...
• clave externa hacia la clave primaria de R1
• columnas para los atributos de la relación V
  (simples ocomponentes simples de atributos
  compuestos)
• 1.1) Participación total de E2 en V

codProv
nombreCiudad
PROVINCIA
CIUDAD
contiene
(1,1)
(1,n)
...
nomProv
CIUDAD( nomCiudad, provincia, ... ) PROVINCIA(
codProv, nomProv, ... )
FK NULOS NO PERMITIDOS
82
3.4.2 Diseño lógico estándar
Traducción de una relación binaria 1N (2)
1.2) Participación parcial de E2 en V
nomMuseo
codCuadro
CUADRO
PINACOTECA
Expone
titulo
(0,1)
(1,n)
pintor
ciudad
sala
NULOS PERMITIDOS
CUADRO(codCuadro, titulo, pintor, museo,
sala...) PINACOTECA(nomMuseo, ciudad, ...)
FK
83
3.4.2 Diseño lógico estándar
Traducción de una relación binaria 1N (3)

• 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 MN
• ? 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)

84
3.4.2 Diseño lógico estándar
Traducción de una relación binaria 11

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

numHistoria
nss
HISTORIAL
PACIENTE
Tiene
fechaApertura
MEDICO
(1,1)
(1,1)
...
centroSalud
...
nombre
85
3.4.2 Diseño lógico estándar
Traducción de una relación binaria 11 (2)

• Participación total de una entidad y parcial de
  la otra
• 2.1) Caso general
• ? Propagación de clave
• La clave de la entidad con participación parcial
  se propaga hacia la entidad con participación
  total ? clave ajena
• Los atributos de la relación V siguen a la
  clave propagada

codEmp
numDep
(0,1)
(1,1)
Un empleado puede no dirigir ningún departamento,
o bien ser el gerente de uno de ellos (desde
cierta fecha, en la que fue nombrado como tal)
DEPARTAMENTO
EMPLEADO
Dirige
fechaInic
nomEmp
nomDep
NN
86
3.4.2 Diseño lógico estándar
Traducción de una relación binaria 11 (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, ...)
• DIRIGE (emp, dep, fechInic)
• DEPARTAMENTO(numDep, nomDep,...)

FK
AK,NN
FK
87
3.4.2 Diseño lógico estándar
Traducción de una relación binaria 11 (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,
• nomEmp ... ,
• ...,
• numDepDir ... NULL UNIQUE,
• nomDepDir ... NULL,
• ...,
• fechInicDir ... NULL,
• ... )

Atributos de EMPLEADO
Atributos de DEPARTAMENTO
Atributos de DIRIGE
88
3.4.2 Diseño lógico estándar
Traducción de una relación binaria 11 (y 5)

• 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
HOMBRE(nif, ...) MATRIMONIO(esposa, esposo,
fecha, lugar) MUJER(nif, ...)
nif
nif
FK
Matrimonio a la antigua
MUJER
HOMBRE
(0,1)
(0,1)
AK, NN
NN
NN
FK
fecha
89
3.4.2 Diseño lógico estándar
Traducción de dependencia en existencia y en
identificación

• ? Caso particular de relación 11 o 1N con
  propagación de clavey participación total de E2
• ?Si V es 11 ? caso 2.1 Si V es 1N ? 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)

90
3.4.2 Diseño lógico estándar
Traducción de dependencia en existencia y en
identificación (y 2)
1N
nifFam
nifEmp
FAMILIAR
EMPLEADO
Tiene
nomEmp
(0,n)
(1,1)
EMPLEADO ( nifEmp, nomEmp, ...)
FK
FAMILIAR ( nifFam, emp, ... )
fecha
hora
1N
observ
historial
VISITAMEDICA
PACIENTE
Acude
nombre
(1,n)
(1,1)
PACIENTE ( historial, nombre, ... )
FK
VISITA_MEDICA ( historial, fecha, hora, ... )
91
3.4.2 Diseño lógico estándar
Traducción de una relación binaria reflexiva
jefe
nifEmp
Es jefe de
EMPLEADO
nomEmp
subordinado
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

92
3.4.2 Diseño lógico estándar
Traducción de una relación n-aria

• ? Tabla R correspondiente a V, que incluye...
• claves ajenas hacia cada clave primaria de R1,
  R2, R3, etc.
• columnas para los atributos de la relación V
  (simples o componentes simples de atributos
  compuestos)
• la clave primaria de R
• En general, es la combinación de todas las claves
  externas hacia R1, R2, R3, etc.
• Pero es posible que sea un subconjunto de dicha
  clave

93
3.4.2 Diseño lógico estándar
Traducción de una relación n-aria (y 2)

• VENTA ( matricula, vendedor, cliente, banco,
  fechaVenta )
• 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)?

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 1N CREATE TABLE Curso
( codcurso ... PRIMARY KEY, nomcurso ..., ...
director ... REFERENCES Profesor (idProf) ON
UPDATE CASCADE , profesor ... REFERENCES
Profesor (idProf) ON UPDATE CASCADE ,
CONSTRAINT organiza_xor_imparte CHECK ( (
director NOT IN (SELECT profesor FROM Curso) )
AND ( profesor NOT IN (SELECT director
FROM Curso) ) ) ... )
PROFESOR
(0,n)
(0,n)
IMPARTE
ORGANIZA
(1,1)
(1,1)
CURSO
95
3.4.2 Diseño lógico estándar
Traducción de exclusividad de relaciones (2)
Ejemplo para relaciones de tipo MN CREATE TABLE
Alumno_Estudia_Titulacion ( alu ... REFERENCES
Alumno (numExp) ON DELETE CASCADE ON UPDATE
CASCADE , titu ... REFERENCES Titulacion
(idTit) ON DELETE NO ACTION ON UPDATE CASCADE
, PRIMARY KEY (alu, titu), CONSTRAINT
titulacion_xor_master CHECK ( alu NOT IN
(SELECT alum FROM Alumno_Cursa_Master) )
) CREATE TABLE Alumno_Cursa_Master ( alu m
... 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) ) )
MPM 1999
96
3.4.2 Diseño lógico estándar
Traducción de especialización/generalización

• 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

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
CREATE TABLE Empleado_Universidad ( nif ...
PRIMARY KEY, nombre ... , tipo ... NOT NULL
CHECK tipo IN (pro, bec, pas), categ ...
NULL, tipoBeca ... NULL, activ ...
NULL, ... )
nombre
nif
EMPLEADO UNIVERSIDAD
tipo
d
PAS
PROFESOR
BECARIO
actividad
tipoBeca
categoría
MPM 1999
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, nombre ... , fechanac ... , estudia ...
NOT NULL CHECK (estudia IN (T,
F)), curra ... NOT NULL CHECK (curra IN (T,
F)), titulacion ... NULL, nss ... NULL
UNIQUE, salario ... NULL, ... CHECK ( (estudia
T AND titulacion IS NOT NULL) OR
(estudia F AND titulacion IS NULL) ) ,
CHECK ( (curra T AND nss IS NOT NULL AND
salario IS NOT NULL) OR (curra F
AND nss IS NULL AND salario IS NULL) ) )

• Otra posibilidad
• Sólo una columna discriminante y valor extra para
  solapamiento
• actividad ... NULL CHECK (actividad IN
  (estudia, trabaja, est_trab))

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 Actividad_Individuo ( nifIndiv ...
REFERENCES Individuo( nif ) ON DELETE
CASCADE ON UPDATE CASCADE,
nomActiv ... , CHECK (nomActiv IN (estudiar,
trabajar)), PRIMARY KEY ( nifIndiv, nomActiv
) )
CREATE TABLE Individuo ( nif ... PRIMARY
KEY, nombre ... , fechanac ...
, titulación ... NULL, nss ... NULL
UNIQUE, salario ... NULL, ... )

• Las restricciones semánticas son algo más
  complejas (asertos), como veremos a continuación
• Es más extensible que la Alternativa 1
  introducir un nuevo subtipo no requiere alterar
  la tabla INDIVIDUO para añadir una columna, sino
  ajustar el CHECK de ACTIVIDAD_INDIVIDUO y añadir
  los asertos correspondientes

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 nomActivestudiar
)))
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
nomActivtrabajar)))
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
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
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 ) ) )
UNIVERSITARIO
nombre
o
tipo
ESTUDIANTE
CURRANTE
titulacion
nss
salario
salario
titulacion

• Otras opciones
• Una sola columna discriminante
• Tratar discriminante como un atributo
  multivalorado

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

103
3.4.2 Diseño lógico estándar
Traducción de especialización/generalización (9)

• Transformación total
• Los subtipos se diferencian en muchos atributos
• Se desea mantener los atributos comunesen una
  tabla separada
• ? Una tabla para cada entidad
• una tabla R para el supertipo P, que incluye...
• columnas para los atributos de P
• la clave primaria es el identificador principal
  del supertipo
• una tabla 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

P

d
B2
B1
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
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 ... )

• El atributo discriminante no aparece en ninguna
  de las tablas resultado de la traducción

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é?)

106
3.4.2 Diseño lógico estándar
Traducción de especialización/generalización (12)

• 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

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
CREATE TABLE Articulo ( codigo ... PRIMARY
KEY titulo ..., idioma ..., revista ...
, fecha ... ) CREATE TABLE Libro ( codigo
... PRIMARY KEY titulo ..., idioma
..., edicion ... editorial ... )

• El atributo discriminante no aparece en ninguna
  de las tablas resultado de la traducción

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

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