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

1
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 2
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, ...
3
3.4.2 Diseño lógico estándar
Reglas de traducción MERE  MR
 Reglas para el modelo básico
• Dominios
• Atributos RESUMEN
• Tipos de entidad
• Tipos de relación

MER MR (SQL-92)
Tipo de Entidad Tabla (relación)
Tipo de Relación M:N Tabla
Tipo de Relación 1:1, 1:N, N:1 Propagación de clave o tabla

 Reglas para las extensiones del modelo

• Relaciones exclusivas
• Jerarquías de Especialización/Generalización 4
3.4.2 Diseño lógico estándar
Traducción de un dominio y un tipo de entidad

• Dominio
MR
CREATE DOMAIN Estado_civil AS CHAR(1)
MERE CHECK VALUE IN (‘S’, ‘C’, ‘V’, ‘D’) ;
ESTADO_CIVIL: {S, C, V, D}

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

MERE MR
CREATE TABLE Persona
PERSONA (
...
); 5
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
dni nombre CREATE TABLE Persona
direccion ( dni PRIMARY KEY,
telefono numSS UNIQUE NULL,
PERSONA nombre ...,
fechaNacim
direccion ...,
nacionalidad altura telefono ...,
fechaNacim ...,
nacionalidad ...,
altura ... ) ; 6
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?

7
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 PERSONA (dni, nombre, fechaNac)

FK
dni nombre
fechaNac DIRECC_PERSONA (dni, direccion)

PERSONA direccion (1,n) CREATE TABLE Direcc_Persona (

dni ...
direccion ...
PRIMARY KEY (dni, direccion)
MR (DED) FOREIGN KEY (dni) REFERENCES Persona(dni)
tiene DIRECC_ ON DELETE CASCADE
PERSONA
PERSONA ON UPDATE CASCADE ); 8
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

MERE MR
dni nombre PERSONA (dni, nombre, fechaNac, edad)
fechaNac

PERSONA edad

9
3.4.2 Diseño lógico estándar
Traducción de una relación binaria M:N

 Nueva tabla R, que incluye...

– claves ajenas hacia las E1 V E2
claves primarias de R1 y de R2 R1 R2
 Su combinación (concatenación) forma R
la clave primaria de R
– columnas correspondientes a los atributos de la relación V (simples o
componentes simples de atributos compuestos)
nombre papel código
ACTOR(nombre, ..., caché, ...)
FK
ACTOR Actua PELICULA
(1,m) en (1,n) ACTUA_EN (actor, pelicula, papel, paga)
FK
caché paga título PELICULA(código, título, ...)

[MPM 1999]
10
3.4.2 Diseño lógico estándar
Traducción de una relación binaria M:N (3)

codAutor derechosAutor isbn

AUTOR(codAutor, nomAutor, ...)
FK
AUTOR Escribe LIBRO
(1,n) (1,4)
ESCRIBE (autor, libro, derAutor, numPag)
FK
nomAutor numPaginas 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 11
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
);
12
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 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)
13
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))
);
14
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))
);
15
3.4.2 Diseño lógico estándar
Traducción de una relación binaria 1:N
1) Caso general E1
1
V
N
E2

 Propagación de clave R1 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 CIUDAD
...
(1,1) (1,n)
nomProv
CIUDAD( nomCiudad, provincia, ... )
FK: NULOS NO PERMITIDOS

PROVINCIA( codProv, nomProv, ... ) 16

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 Expone CUADRO
(1,n)
titulo
(0,1)
pintor
ciudad
sala

NULOS PERMITIDOS

CUADRO(codCuadro, titulo, pintor, museo, sala...)

FK

PINACOTECA(nomMuseo, ciudad, ...)

17
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)
DNI
ESTUDIANTE
ESTUDIANTE( DNI, nombre, ... )
nombre
(0,1)
1:N Propietario_de PROPIEDAD( coche, estudiante)
FK FK NN
(0,n)
matricula COCHE( matricula, modelo, ... )
COCHE 18
modelo
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 numHistoria
PACIENTE Tiene HISTORIAL
MEDICO fechaApertura
(1,1) (1,1)

nombre ... ... centroSalud

PACIENTE ( nss, nombre, numHisto, fechaApert, centroSalud,... )

PK AK, NN 19
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 V E2

R1 R2
 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 EMPLEADO Dirige DEPARTAMENTO
dirigir ningún departamento,
o bien ser el gerente de uno nomEmp fechaInic nomDep
de ellos (desde cierta fecha, EMPLEADO(codEmp, nomEmp, ...)
en la que fue nombrado FK
como tal) DEPARTAMENTO(numDep,nomDep, codDir, fechInicDir...)
AK, NN NN
20
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,...)
21
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(
Atributos de codEmp ... PRIMARY KEY, NULL permite representar empleados
EMPLEADO nomEmp ... , que no dirigen ningún
..., departamento
UNIQUE asegura que un
Atributos de numDepDir ... NULL UNIQUE, departamento sólo es dirigido por
DEPARTAMENTO nomDepDir ... NULL,
un empleado
..., Los atributos monovalorados
Atributos de fechInicDir ... NULL, aseguran que un empleado pueda
DIRIGE ... ); dirigir como mucho un
departamento 22
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 HOMBRE(dni, ...)
dni
FK
Matrimonio
HOMBRE MUJER MATRIMONIO(esposa, esposo, fecha, lugar)
(0,1) a la antigua (0,1)
AK, NN NN NN
FK
fecha MUJER(nif, ...)
Y... ¿qué acciones de mantenimiento
de la integridad referencial debemos
imponer para (todos los casos de)
transformación de relaciones 1:1?
23
3.4.2 Diseño lógico estándar
Traducción de dependencia en existencia y
en identificación

 Caso particular de relación 1:1 E1 V E2

o 1:N con propagación de clave R1 R2

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)
24
3.4.2 Diseño lógico estándar
Traducción de dependencia en existencia y
en identificación (y 2)

1:N
nifEmp nifFam
EMPLEADO Tiene FAMILIAR
nomEmp (0,n) (1,1)

EMPLEADO ( nifEmp, nomEmp, ...)

NOT NULL
FK ON DELETE CASCADE
FAMILIAR ( nifFam, emp, ... ) ON UPDATE CASCADE

fecha hora

1:N observ
historial VISITA
nombre PACIENTE Acude
(1,n) (1,1) MEDICA

PACIENTE ( historial, nombre, ... ) NOT NULL

FK
ON DELETE CASCADE
VISITA_MEDICA ( historial, fecha, hora, ... ) ON UPDATE CASCADE
25
3.4.2 Diseño lógico estándar
Traducción de una relación binaria reflexiva
jefe
nifEmp
EMPLEADO Es jefe de
nomEmp
subordinado

Caso 1:N solución problemática si

puede haber muchos
EMPLEADO ( nifEmp, nomEmp, ..., jefe, ... ) empleados sin jefe
FK
( demasiados nulos )
NULL

 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 Otra posibilidad en el Caso 1:N

EMPLEADO ( nifEmp, nomEmp, ... ) EMPLEADO ( nifEmp, nomEmp, ...)
FK FK FK
FK
JEFE_EMP ( jefe, subordinado, ... ) JEFE_EMP ( jefe, subordinado, ... )
NN 26
3.4.2 Diseño lógico estándar
Traducción de una relación n-aria
 Tabla R correspondiente a V, E1 V E2
que incluye...
R1 E3 R2
– claves ajenas hacia cada clave
primaria de R1, R2, R3, etc. R3

– 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
27
3.4.2 Diseño lógico estándar
Traducción de una relación n-aria (y 2)

matricula [EN 2002]

COCHE
nifCliente (0,1) fechaVenta
nifVendedor
CLIENTE Venta VENDEDOR
(0,n) (0,m)

(0,p)
cifBanco
BANCO

VENTA ( matricula, vendedor, cliente, banco, fechaVenta )

1. ¿Cuál es la superclave de esta relación?
2. ¿y cuál es su clave primaria?
3. ¿Cómo asegurar que no haya ventas sin cliente, sin coche, sin vendedor?
4. ¿Puede reflejarse la existencia de ventas directas (sin banco)?
28
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 (

ORGANIZA IMPARTE
codcurso... PRIMARY KEY,
nomcurso ..., (1,1) (1,1)
... CURSO
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) ) ) 29
3.4.2 Diseño lógico estándar
Traducción de exclusividad de relaciones (2)

Ejemplo para relaciones de tipo M:N ALUMNO

CREATE TABLE Alumno_Estudia_Titulacion ( (1,n) (1,n)
alu ... REFERENCES Alumno (numExp)
ON DELETE CASCADE ON UPDATE CASCADE , estudia cursa
titu ... REFERENCES Titulacion (idTit)
ON DELETE NO ACTION ON UPDATE CASCADE , (0,n) (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) ) ); 30
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

31
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 nombre nif ... PRIMARY KEY,
EMPLEADO
UNIVERSIDAD nombre ... ,
tipo ... NOT NULL CHECK tipo IN (‘pro’, ‘bec’, ‘pas’),
tipo categ ... NULL,
d tipoBeca ... NULL,
activ ... NULL,
...
PROFESOR BECARIO PAS CHECK ( ( tipo = ‘pro’ AND categ IS NOT NULL
actividad
AND tipoBeca IS NULL AND activ IS NULL )
categoría tipoBeca
OR ( tipo = ‘bec’ AND tipoBeca IS NOT NULL
AND categ IS NULL AND activ IS NULL )
[MPM 1999] restricciones OR ( tipo = ‘pas’ AND activ IS NOT NULL
semánticas AND categ IS NULL AND tipoBeca IS NULL ) )
);
32
disjunta PARCIAL: PERMITE NULL EN TIPO
3.4.2 Diseño lógico estándar
Traducción de especialización/generalización (3)
Transformación guiada por el supertipo: Jerarquía solapada parcial

Alternativa 1: CREATE TABLE Individuo (

nif nif ... PRIMARY KEY,
INDIVIDUO nombre
nombre ... ,
fechanac fechanac ... ,
actividad estudia ... NOT NULL CHECK (estudia IN (‘T’, ‘F’)),
curra ... NOT NULL CHECK (curra IN (‘T’, ‘F’)),
titulacion ... NULL,
ESTUDIANTE CURRANTE nss ... NULL UNIQUE,
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
actividad ... NULL CHECK (actividad AND salario IS NULL) )
IN (‘estudia’, ‘trabaja’, ‘est_trab’)) );
33
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 ( CREATE TABLE Actividad_Individuo (

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

nombre UNIVERSITARIO nif ... PRIMARY KEY,
nombre ... ,
estudia ... NOT NULL CHECK estudia IN (‘T’, ‘F’),
o tipo trabaja ... NOT NULL CHECK trabaja IN (‘T’, ‘F’),
titulación ... NULL,
salario ... NULL,
ESTUDIANTE CURRANTE
...
titulacion
CHECK ( ( estudia = ‘T’ AND titulacion IS NOT NULL )
nss salario
OR ( trabaja = ‘T’ AND salario IS NOT NULL ) )
);
titulacion salario

Otras opciones:
– Una sola columna discriminante
– Tratar discriminante como un
atributo multivalorado 36
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

37
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 P
atributos
d
• Se desea mantener los atributos comunes
en una tabla separada
B1 B2
 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

38
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,
codigo idioma idioma ... ,
DOCUMENTO titulo ... ) ;
titulo
CREATE TABLE Articulo (
d tipo codigo ... PRIMARY KEY
REFERENCES Documento (codigo)
ON DELETE CASCADE
ARTICULO LIBRO ON UPDATE CASCADE
revista ... ,
revista edicion editorial
fecha ... ) ;
fecha
CREATE TABLE Libro (
codigo ... PRIMARY KEY
 El atributo discriminante REFERENCES Documento (codigo)
no aparece en ninguna de ON DELETE CASCADE
las tablas resultado de la ON UPDATE CASCADE,
traducción edicion ... ,
editorial ... ); 39
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é?)

40
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

41
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 idioma codigo ... PRIMARY KEY
DOCUMENTO titulo ...,
titulo idioma ...,
d tipo revista ... ,
fecha ...
);
ARTICULO LIBRO CREATE TABLE Libro (
edicion
codigo ... PRIMARY KEY
revista fecha editorial
titulo ...,
idioma ...,
edicion ...
 El atributo discriminante
no aparece en ninguna de editorial ...
las tablas resultado de la );
traducción
42
 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

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