7.2 Diseño lógico estándar

7. Diseño lógico de bases de datos
Objetivos
• Comprender la conveniencia y ventajas de disponer de un
esquema lógico de BD independiente de un SGBD comercial
particular
• Conocer las reglas de transformación de un esquema
conceptual en el MERE en un esquema lógico en el MR
• Conocer cómo evitar la posible pérdida de semántica al
traducir elementos del MERE a elementos del MR
• Conocer estrategias de elección de la opción de diseño
lógico más adecuada entre varias alternativas posibles
• Conocer guías y recomendaciones para trasladar un
esquema en el MR a un esquema en el modelo de datos
específico soportado por el SGBD de implementación
Tema 7. Diseño Lógico de Bases de Datos
1
7. Diseño lógico de bases de datos
Contenidos
7.1. Objetivos y fases del diseño lógico
7.2. Diseño lógico estándar
7.3. Diseño lógico específico
Bibliografía
[EN 2002]
Elmasri, R.; Navathe, S.B.: Fundamentos de Sistemas de
Bases de Datos. 3ª Ed. Addison-Wesley. (Cap. 9 y 16)
[EN 1997]
Elmasri, R.; Navathe, S.B.: Sistemas de bases de datos.
Conceptos fundamentales. 2ª Ed. Addison-Wesley
Iberoamericana. (Cap. 6, 14 y 21)
[MPM 1999] de Miguel, A.; Piattini, M.; Marcos, E.: Diseño de bases de
datos relacionales. Ra-Ma (Cap. 10 y 11)
[CBS 1998] Connolly; Begg; Strachan: Database Systems: A Practical
Approach to Design, Implementation and Management. 2 nd
Ed. Addison-Wesley (Cap. 8, 11, 9 y 12)
Tema 7. Diseño Lógico de Bases de Datos
2
1
7.1 Objetivos y fases del diseño lógico
Objetivos
• 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
I 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
Tema 7. Diseño Lógico de Bases de Datos
3
7.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, y 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
Tema 7. Diseño Lógico de Bases de Datos
4
2
7.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, Ingres, Sybase ...
» Se describe el ELE mediante el LDD propio del SGBD específico
• SQL de Oracle, ...
5
Tema 7. Diseño Lógico de Bases de Datos
7.2 Diseño lógico estándar
Reglas de traducción MERE ð MR
q 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
Relación (tabla)
Relación
Propagación de clave o relación
q Reglas para las extensiones del modelo
• Relaciones exclusivas
• Jerarquías de Especialización/Generalización
Tema 7. Diseño Lógico de Bases de Datos
6
3
7.2 Diseño lógico estándar
Ejemplo de traducción
L Pérdida de semántica:
J Solución:
– Una relación (tabla)
puede provenir de
una entidad o de una
relación MERE
– Si una relación 1:1,
1:N, N:1 se traduce
con propagación de
clave, «desaparece»
el nombre de la
relación
– Anotación en la documentación asociada
– Impedir pérdida de integridad, definiendo reglas de integridad
apropiadas
Tema 7. Diseño Lógico de Bases de Datos
7
7.2 Diseño lógico estándar
Diagrama de Estructura de Datos, DED
• Técnica de representación gráfica de los esquemas
lógicos de datos en los modelos convencionales, en
particular, el modelo relacional
• Notación «a medio camino» entre el modelo
Entidad-Relación y el Relacional
• Soportados por herramientas CASE (ej. System Architect)
• Uso del DED en la metodología METRICA
– Fase 1:
• ARS 3.2: Diseño del Esquema Lógico Actual de Datos
• EFS 2.1: Construcción del Esquema Lógico de Datos
• EFS 2.2: Normalización del Esquema Lógico de Datos
Tema 7. Diseño Lógico de Bases de Datos
8
4
7.2 Diseño lógico estándar
Características de un DED
• Sólo relaciones binarias (dos entidades)
• Sólo permitidas las relaciones 1:N
– Transformación de relaciones 1:1
§ Fusionar en una única entidad, o mantener la relación
– Transformación de relaciones M:N
§ Creación de una entidad auxiliar + dos relaciones 1:N
Ejemplo de relación N:1
EMPLEADO
Pertenece a
DEPARTAMENTO
Tema 7. Diseño Lógico de Bases de Datos
9
7.2 Diseño lógico estándar
Normalización de un DED
• 1FN: todo atributo con valor atómico
– Evitar atributos multivalorados
– Evitar atributos compuestos
• 2FN: en toda entidad E, los atributos no identificadores
dependen de manera total del identificador principal de E
– Ningún atributo (no identificador) de E depende sólo de una parte
de cualquier identificador (principal, alternativo) de E
• 3FN: No existen dependencias funcionales transitivas entre
los atributos de la entidad E
– Todo atributo no identificador de E sólo depende directamente de
los identificadores de E
Tema 7. Diseño Lógico de Bases de Datos
10
5
7.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 relación (tabla)
– Se recomienda usar el mismo nombre o uno similar
MR
MERE
CREATE TABLE Persona
(
...
);
PERSONA
11
Tema 7. Diseño Lógico de Bases de Datos
7.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
MR
MERE
dni
numSS
nombre
dirección
PERSONA
nacionalidad
teléfono
fechaNacim
altura
Tema 7. Diseño Lógico de Bases de Datos
CREATE TABLE Persona
( dni
PRIMARY KEY,
numSS
UNIQUE NOT NULL,
nombre ...,
dirección ...,
teléfono ...,
fechaNacim ...,
nacionalidad ...,
altura ... ) ;
12
6
7.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 atributos simples de la relación resultante
b) «Eliminar» los componentes y considerar el atributo
compuesto como un solo atributo de la relación
MERE
MR (DED)
¿Cuándo será más
adecuado utilizar
una opción u otra?
13
Tema 7. Diseño Lógico de Bases de Datos
7.2 Diseño lógico estándar
Traducción de un atributo (3)
• Atributo multivalorado
– Nueva relación S, en la que el atributo multivalorado se
representa como un atributo simple A
– S contendrá un nuevo atributo F, clave ajena a la clave primaria
de la relación correspondiente a la entidad
– La clave primaria de S es la combinación (F, A)
MERE
[MPM 1999]
nombre
dni
fechaNac
dirección (1,n)
PERSONA
MR (DED)
PERSONA
tiene
DIRECC_
PERSONA
Tema 7. Diseño Lógico de Bases de Datos
MR
PERSONA (dni, nombre, fechaNac)
FK
DIRECC_PERSONA (dni, dirección)
CREATE TABLE Direcc_Persona (
dni ...
dirección ...
PRIMARY KEY (dni, dirección)
FOREIGN KEY (dni) REFERENCES Persona(dni)
ON DELETE CASCADE
ON UPDATE CASCADE );
14
7
7.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á un atributo de la relación que corresponda y
deberá crearse un disparador que calcule su valor
2. Si no se almacena, deberá crearse un procedimiento que calcule su
valor cada vez que se solicita
MR
MERE
dni
PERSONA (dni, nombre, fechaNac, edad)
nombre
fechaNac
edad
PERSONA
[MPM 1999]
15
Tema 7. Diseño Lógico de Bases de Datos
7.2 Diseño lógico estándar
Traducción de una relación binaria M:N
ð Nueva relación R, que incluye...
– claves ajenas hacia las
claves primarias de R1 y de R2
V
E1
§ Su combinación (concatenación) forma
la clave primaria de R
R1
E2
R2
R
– atributos del tipo de relación V (simples o componentes simples de
atributos compuestos)
codAutor
isbn
derechosAutor
Escribe
AUTOR
(1,n)
nomAutor
LIBRO
(1,m)
numPaginas
titulo
AUTOR(codAutor, nomAutor, ...)
FK
ESCRIBE (autor, libro, derAutor, numPag)
FK
LIBRO(isbn, titulo, ...)
[MPM 1999]
Tema 7. Diseño Lógico de Bases de Datos
16
8
7.2 Diseño lógico estándar
Traducción de una relación binaria M:N (2)
– 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 NUMBER(2) DEFAULT 20 CHECK (derAutor>0 AND derAutor<100),
numPag NUMBER(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
);
Tema 7. Diseño Lógico de Bases de Datos
17
7.2 Diseño lógico estándar
Traducción de una relación binaria M:N (y 3)
– Especificación de restricciones o asertos para especificar las
cardinalidades mínima y máxima
Un libro debe tener entre 1 y 4 autores
CREATE ASSERTION num_autores_por_libro
CHECK (
(NOT EXISTS (SELECT * FROM Libro
WHERE isbn NOT IN (SELECT libro
FROM Escribe)))
AND
(4 >= (SELECT MAX(ocurrencias)
FROM (SELECT COUNT(*) AS ocurrencias
FROM Escribe
GROUP BY libro)))
);
Tema 7. Diseño Lógico de Bases de Datos
18
9
7.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
N
R1
– En R2 se incluyen nuevos atributos...
§
§
E2
R2
clave externa hacia la clave primaria de R1
atributos de la relación V (simples o componentes simples de
atributos compuestos)
card(E2)=( 1, 1)
[MPM 1999] card(E1)=( 1, 1)
[EN 2002]
1.1) Participación total de E2 en V
codProv
1:N
PROVINCIA
contiene
(1,1)
(1,n)
CIUDAD
nombreCiudad
...
nomProv
CIUDAD( nomCiudad, provincia, ... )
FK: NULOS NO PERMITIDOS
[MPM 1999]
PROVINCIA( codProv, nomProv, ... )
Tema 7. Diseño Lógico de Bases de Datos
19
7.2 Diseño lógico estándar
Traducción de una relación binaria 1:N (2)
2.2) Participación parcial de E2 en V
card(E2)=( 0, 1)
[MPM 1999] card(E1)=( 0, 1)
[EN 2002]
[MPM 1999]
nomMuseo
Expone
PINACOTECA
titulo
(1,n)
(0,1)
ciudad
codCuadro
CUADRO
pintor
sala
NULOS PERMITIDOS
CUADRO(codCuadro, titulo, pintor, museo, sala...)
FK
PINACOTECA(nomMuseo, ciudad, ...)
Tema 7. Diseño Lógico de Bases de Datos
20
10
7.2 Diseño lógico estándar
Traducción de una relación binaria 1:N (y 3)
2) Se cumple uno o varios de estos supuestos:
q
La relación V tiene varios atributos propios
§
y no se desea propagarlos, para conservar la semántica
q
Hay pocas ocurrencias de la relación V
q
Es probable que en el futuro V se transforme en una M:N
§ se tendrían demasiados nulos en la clave y atributos propagados
[MPM 1999]
nif
ESTUDIANTE
nombre
(0,1)
1:N
matricula
modelo
Propietario_de
(0,n)
COCHE
21
Tema 7. Diseño Lógico de Bases de Datos
7.2 Diseño lógico estándar
Traducción de una relación binaria 1:N (y 3)
2) (continuación)
ð Añadir una nueva relación 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
– atributos de V (simples o componentes simples de atributos compuestos)
nif
ESTUDIANTE
nombre
(0,1)
1:N
matricula
modelo
Propietario_de
(0,n)
COCHE
ESTUDIANTE( nif, nombre, ... )
PROPIEDAD( coche, estudiante)
FK
FK NN
COCHE( matricula, modelo, ... )
[MPM 1999]
Tema 7. Diseño Lógico de Bases de Datos
22
11
7.2 Diseño lógico estándar
Traducción de una relación binaria 1:1
1) Participación total de ambas entidades
– Las entidades no participan en otras relaciones
ð una única relación R, que incluye...
– Todos los atributos de ambas entidades
– Claves de R:
§ Clave primaria = clave primaria de R1 o de R2 (es indiferente)
§ La otra (N si es distinta) será alternativa (UNIQUE) y además NOT NULL
– Atributos de la relación V (simples o componentes simples de atributos
compuestos)
nss
PACIENTE
nombre
(1,1)
Tiene
numHistoria
HISTORIAL
MEDICO
(1,1)
...
...
fechaApertura
[MPM 1999]
centroSalud
PACIENTE ( nss, nombre, numHisto, fechaApert, centroSalud,... )
PK
AK, NN
23
Tema 7. Diseño Lógico de Bases de Datos
7.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
ð Propagación de clave
E2
V
R1
– 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
[MPM 1999]
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)
EMPLEADO
nomEmp
R2
numDep
(1,1)
Dirige
(0,1)
DEPARTAMENTO
fechaInic
nomDep
EMPLEADO(codEmp, nomEmp, ...)
FK
DEPARTAMENTO(numDep,nomDep, codDir, fechInicDir...)
AK, NN
Tema 7. Diseño Lógico de Bases de Datos
NN
24
12
7.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 relación 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
– atributos (simples o componentes simples de atributos compuestos) de V
• Esta alternativa evita los NULL que aparecerían en los atributos
propagados si se propagara la clave (caso general (2.1))
EMPLEADO(codEmp, nomEmp, ...)
FK
DIRIGE (emp, dep, fechInic)
AK,NN
FK
DEPARTAMENTO(numDep, nomDep,...)
25
Tema 7. Diseño Lógico de Bases de Datos
7.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,
nomEmp ... ,
...,
Atributos de numDepDir ... NULL UNIQUE,
DEPARTAMENTO
nomDepDir ... NULL,
...,
Atributos de
fechInicDir ... NULL,
DIRIGE
... );
Atributos de
EMPLEADO
Tema 7. Diseño Lógico de Bases de Datos
NULL permite representar
empleados que no dirigen
ningún departamento
UNIQUE asegura que un
departamento sólo es
dirigido por un empleado
Los atributos monovaluados
aseguran que un empleado
pueda dirigir como mucho un
departamento
26
13
7.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 relación R
• 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) Estándar (0,1)
MUJER
fecha
HOMBRE(nif, ...)
FK
MATRIMONIO(esposa, esposo, fecha, lugar)
MUJER(nif, ...)
FK
AK, NN
Y... ¿qué acciones de mantenimiento de
la integridad referencial debemos
imponer para (todos los casos de)
transformación de relaciones 1:1?
NN
NN
[MPM 1999]
27
Tema 7. Diseño Lógico de Bases de Datos
7.2 Diseño lógico estándar
Traducción de dependencia en existencia y
en identificación
ð Caso particular de relación 1:1
o 1:N con propagación de clave
y participación total de E2
E1
V
R1
E2
R2
I Si V es 1:1 ð caso 2.1 ; Si V es 1:N ð caso 1.1 I
– 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)
Tema 7. Diseño Lógico de Bases de Datos
28
14
7.2 Diseño lógico estándar
Traducción de dependencia en existencia y
en identificación (y 2)
nifEmp
nomEmp
EMPLEADO
1:N
E
Tiene
(1,1)
nifFam
FAMILIAR
(0,n)
EMPLEADO ( nifEmp, nomEmp, ...)
NOT NULL
ON DELETE CASCADE
ON UPDATE CASCADE
FK
FAMILIAR ( nifFam, emp, ... )
1:N
historial
nombre
PACIENTE
ID
Acude
(1,1)
fecha
VISITA
MEDICA
(1,n)
[MPM 1999]
hora
observ
PACIENTE ( historial, nombre, ... )
FK
VISITA_MEDICA ( historial, fecha, hora, ... )
NOT NULL
ON DELETE CASCADE
ON UPDATE CASCADE
29
Tema 7. Diseño Lógico de Bases de Datos
7.2 Diseño lógico estándar
Traducción de una relación binaria reflexiva
ð Relación (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
nifEmp
nomEmp
jefe
Es jefe de
EMPLEADO
[MPM 1999]
subordinado
Caso 1:N
EMPLEADO ( nifEmp, nomEmp, ..., jefe, ... )
FK
NULL
Otra posibilidad en el Caso 1:N
EMPLEADO ( nifEmp, nomEmp, ...)
FK
solución problemática
si puede haber muchos
empleados sin jefe
( demasiados nulos )
Caso M:N
EMPLEADO ( nifEmp, nomEmp, ... )
FK
FK
JEFE_EMP ( jefe, subordinado, ... )
NN
Tema 7. Diseño Lógico de Bases de Datos
FK
JEFE_EMP ( jefe, subordinado, ... )
30
15
7.2 Diseño lógico estándar
Traducción de una relación binaria reflexiva (y 2)
código
(0,n)
PRODUCTO
[EN 2002]
agregado
1
(0,1)
N
componente
un producto o no
es componente de
ningún producto,
o lo es de solo uno
Compuesto_por
descripción
PRODUCTO( código, descripción, ... )
FK
FK
COMPOSICIÓN( agregado, componente )
NN
al producto compuesto
FK NULL
PRODUCTO( código, descripción, agregado, ... )
Producto o Componente
31
Tema 7. Diseño Lógico de Bases de Datos
7.2 Diseño lógico estándar
Traducción de una relación n-aria
ð Añadir una nueva relación R
correspondiente a V, que incluye...
– Claves ajenas hacia cada clave
primaria de R1, R2, R3, etc.
– Atributos de la relación V (simples o
E1
V
E2
R1
E3
R2
componentes simples de atributos compuestos)
R3
– 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 esa superclave
Tema 7. Diseño Lógico de Bases de Datos
32
16
7.2 Diseño lógico estándar
Traducción de una relación n-aria (y 2)
matricula
nifCliente
[EN 2002]
COCHE
fechaVenta
(0,1)
CLIENTE
(0,n)
Venta
nifVendedor
VENDEDOR
(0,m)
(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, o sin coche, o sin vendedor?
¿Puede reflejarse la existencia de ventas directas (sin banco)?
33
Tema 7. Diseño Lógico de Bases de Datos
7.2 Diseño lógico estándar
Traducción de exclusividad de relaciones
ð Añadir restricciones de tipo CHECK
[MPM 1999]
Ejemplo para relaciones de tipo 1:N
PROFESOR
(1,1)
CREATE TABLE Curso (
codcurso ... PRIMARY KEY,
ORGANIZA
IMPARTE
nomcurso ...,
...
(0,n)
(0,n)
director ... REFERENCES Profesor (idProf)
ON UPDATE CASCADE ,
CURSO
profesor ... REFERENCES Profesor (idProf)
ON UPDATE CASCADE ,
CONSTRAINT organiza_exclusiva_imparte
CHECK ( ( director NOT IN (SELECT profesor FROM Curso) )
AND ( profesor NOT IN (SELECT director FROM Curso) ) )
...
);
(1,1)
Tema 7. Diseño Lógico de Bases de Datos
34
17
7.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_Titulación (
(1,n)
(1,n)
alu ... REFERENCES Alumno (numExp)
ON DELETE CASCADE ON UPDATE CASCADE ,
estudia
cursa
titu ... REFERENCES Titulación (idTit)
(0,n)
(0,n)
ON DELETE NO ACTION ON UPDATE CASCADE ,
PRIMARY KEY (alu, titu),
TITULACIÓN
MASTER
CONSTRAINT titulación_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_titulación
CHECK ( alum NOT IN (SELECT alu FROM Alumno_Estudia_Titulación) ) );
35
Tema 7. Diseño Lógico de Bases de Datos
7.2 Diseño lógico estándar
Traducción de exclusividad de relaciones ( y 3)
Ejemplo para relaciones de tipo 1:1
CREATE TABLE Departamento (
codDep ... PRIMARY KEY ,
... ,
jefe
... REFERENCES Empleado (codEmp)
ON DELETE NO ACTION
ON UPDATE CASCADE ,
CONSTRAINT jefe_ok
CHECK ( jefe NOT IN (SELECT director
FROM Sucursal) ) );
EMPLEADO
(1,1)
Jefe_de
(0,1)
DEPARTAMENTO
(1,1)
Director_de
(0,1)
SUCURSAL
[MPM 1999]
CREATE TABLE Sucursal (
codSuc ... PRIMARY KEY ,
... ,
director ... REFERENCES Empleado (codEmp)
ON DELETE NO ACTION ON UPDATE CASCADE ,
CONSTRAINT director_ok
CHECK ( director NOT IN (SELECT jefe FROM Departamento) ) );
Tema 7. Diseño Lógico de Bases de Datos
36
18
7.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
B1
• Las relaciones con otras entidades son
las mismas para todos (o casi) los subtipos
P
d
B2
[MPM 1999]
ð Una única relación R que contiene...
–
–
–
–
Todos los atributos del supertipo P y de los subtipos B1 y B2
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
37
Tema 7. Diseño Lógico de Bases de Datos
7.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
nombre
nif
EMPLEADO
UNIVERSIDAD
tipo
PROFESOR
categoría
BECARIO
tipoBeca
[MPM 1999]
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 )
OR ( tipo = “bec” AND tipoBeca IS NOT NULL
actividad
AND categ IS NULL AND activ IS NULL )
restricciones
OR ( tipo = “pas” AND activ IS NOT NULL
semánticas
AND categ IS NULL AND tipoBeca IS NULL ) )
);
Tema 7. Diseño Lógico de Bases de Datos
38
19
7.2 Diseño lógico estándar
Traducción de especialización/generalización (3)
Transformación guiada por el supertipo: Jerarquía disjunta parcial
CREATE TABLE Documento (
código
... PRIMARY KEY,
código
idioma
título
... ,
DOCUMENTO
título
idioma
... ,
tipo
... NULL CHECK tipo IN (“artículo”, “libro”),
tipo
nomRevista ... NULL,
nomEditorial ... NULL,
añoEdicion ... NULL,
...
LIBRO
ARTÍCULO
CHECK ( (tipo = “artículo” AND nomRevista IS NOT NULL
AND añoEdicion IS NULL
AND nomEditorial IS NULL)
nomRevista
añoEdicion nomEditorial
OR (tipo = “libro” AND nomRevista IS NULL
AND añoEdicion IS NOT NULL
[MPM 1999]
AND nomEditorial IS NOT NULL) )
);
39
Tema 7. Diseño Lógico de Bases de Datos
7.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
[MPM 1999]
nif
INDIVIDUO
nombre
fechanac
actividad
ESTUDIANTE
CURRANTE
titulación
nss
salario
Otras opciones:
– Un solo atributo discriminante
– Tratar discriminante como
atributo multivalorado
Tema 7. Diseño Lógico de Bases de Datos
CREATE TABLE Individuo (
dni
... PRIMARY KEY,
nombre
... ,
fechanac ... ,
estudia
... NOT NULL CHECK (estudia IN (‘Y’, ‘N’)),
curra
... NOT NULL CHECK (trabaja IN (‘Y’, ‘N’)),
titulación ... NULL,
nss
... NULL UNIQUE,
salario
... NULL,
...
CHECK ( (estudia = ‘Y’ AND titulación IS NOT NULL)
OR (estudia = ‘F’ AND titulación IS NULL) ) ,
CHECK ( (curra = ‘Y’ AND nss IS NOT NULL
AND salario IS NOT NULL)
OR (curra = ‘F’ AND nss IS NULL
AND salario IS NULL) )
);
40
20
7.2 Diseño lógico estándar
Traducción de especialización/generalización (5)
Transformación guiada por el supertipo: Jerarquía solapada total
[MPM 1999]
nif
nombre
UNIVERSITARIO
tipo
ESTUDIANTE
EMPLEADO
titulación
salario
CREATE TABLE Universitario (
nif
... PRIMARY KEY,
nombre ... ,
estudia ... NOT NULL CHECK tipo IN (“Y”, “N”),
trabaja ... NOT NULL CHECK tipo IN (“Y”, “N”),
titulación ... NULL,
salario ... NULL,
...
CHECK ( ( estudia = “Y” AND titulación IS NOT NULL )
OR ( trabaja = “Y” AND salario IS NOT NULL ) )
);
Otras opciones:
– Un solo atributo discriminante
– Tratar discriminante como
atributo multivalorado
Tema 7. Diseño Lógico de Bases de Datos
41
7.2 Diseño lógico estándar
Traducción de especialización/generalización (6)
Transformación guiada por el supertipo
J Ventajas
– Acceso eficiente a toda la información sobre instancias de una
entidad concreta (acceso a una sola tabla)
L Inconvenientes
– Aparición de nulos en los 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)
Tema 7. Diseño Lógico de Bases de Datos
42
21
7.2 Diseño lógico estándar
Traducción de especialización/generalización (7)
2. Transformación total
• Los subtipos se diferencian en muchos
atributos
• Se desea mantener los atributos comunes
en una relación separada
P
d
B1
B2
ð Una relación para cada entidad
– una relación R para el supertipo P, que incluye...
§ atributos de P
§ la clave primaria es el identificador principal del supertipo
– una relación Ri para cada subtipo Bi, que incluye...
§ atributos del subtipo Bi
§ clave ajena hacia la PK de R ( N propagación en cascada)
§ la clave primaria es la clave ajena a la clave primaria de R
43
Tema 7. Diseño Lógico de Bases de Datos
7.2 Diseño lógico estándar
Traducción de especialización/generalización (8)
Ejemplo de transformación total con jerarquía disjunta y parcial
[MPM 1999]
código
idioma
DOCUMENTO
título
tipo
ARTÍCULO
revista
fecha
LIBRO
edición editorial
Tema 7. Diseño Lógico de Bases de Datos
CREATE TABLE Documento (
código ... PRIMARY KEY,
idioma ... ,
título ... ) ;
CREATE TABLE Artículo (
código ... PRIMARY KEY
REFERENCES Documento (código)
ON DELETE CASCADE
ON UPDATE CASCADE
revista ... ,
fecha ... ) ;
CREATE TABLE Libro (
código ... PRIMARY KEY
REFERENCES Documento (código)
ON DELETE CASCADE
ON UPDATE CASCADE,
edición ... ,
editorial ... );
44
22
7.2 Diseño lógico estándar
Traducción de especialización/generalización (9)
Transformación total
J 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 subtipo y supertipo
L Inconvenientes
– Menos eficiente en el acceso a todos los atributos (propios y
heredados) de las instancias de un subtipo (¿Por qué?)
45
Tema 7. Diseño Lógico de Bases de Datos
7.2 Diseño lógico estándar
Traducción de especialización/generalización (10)
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
B1
comunes
P
d
B2
ð Una relación Ri para cada subtipo que contiene...
– atributos del subtipo Bi y
– atributos comunes (del supertipo)
– La clave primaria de Ri es el identificador principal del supertipo
Tema 7. Diseño Lógico de Bases de Datos
46
23
7.2 Diseño lógico estándar
Traducción de especialización/generalización (11)
Ejemplo de transformación guiada por los subtipos
[MPM 1999]
código
idioma
DOCUMENTO
título
tipo
ARTÍCULO
revista
fecha
LIBRO
edición editorial
CREATE TABLE Artículo (
código ... PRIMARY KEY
título ...,
idioma ...,
revista ... ,
fecha ...
);
CREATE TABLE Libro (
código ... PRIMARY KEY
título ...,
idioma ...,
edición ...
editorial ...
);
Tema 7. Diseño Lógico de Bases de Datos
47
7.2 Diseño lógico estándar
Traducción de especialización/generalización (y 12)
Transformación guiada por los subtipos
J 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
L 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
Tema 7. Diseño Lógico de Bases de Datos
48
24
7.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 ELE con la sintaxis propia del modelo de datos del SGBD?
• 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
veremos los aspectos que necesitan transformaciones
adicionales
Tema 7. Diseño Lógico de Bases de Datos
49
7.3 Diseño lógico específico
Dominios
• Algunos productos comerciales ofrecen sintaxis de definición
de dominios, pero no implementan la semántica asociada
– Según Codd (1990) el uso de dominios incluye estas ventajas
• Declaración única de cada tipo de datos permitido en el esquema,
• Soporte de integridad y coherencia entre dominios
(operaciones compatibles como la UNION, INTERSECCION, etc.),
• Posibilidad de creación de operadores y características propias de los
dominios,
• Facilitar la definición de comprobaciones del SGBD (menor/mayor que),
• Simplificar operaciones complejas sobre varias columnas, haciendolas
directamente sobre el dominio
• La mayoría de SGBD no ofrece soporte para dominios
– Definir tipo de datos, longitud, restricciones para cada atributo
– Tablas de Dominio y
– Procedimientos de comprobación de valores correctos (integridad)
Tema 7. Diseño Lógico de Bases de Datos
50
25
7.3 Diseño lógico específico
Claves primarias
• Si el SGBD no dispone de sintaxis para definición de PK o
sólo ofrece la sintaxis para hacerlo, pero no implementa
su semántica (como Oracle6)...
– Especificar cada atributo componente de la PK como no nulo
– Asegurar que la combinación de todos los componentes de la PK
tenga valores únicos (tras inserciones y actualizaciones)
– Si el SGBD lo soporta, incluir la definición sintáctica de cada clave
primaria en el esquema, y si no lo soporta, incluir la definición como
comentario en el catálogo del SGBD
Nota: en el estándar SQL-92 no es obligatorio especificar la PK de
una relación, y en los productos comerciales tampoco (por
compatibilidad con versiones anteriores)
Tema 7. Diseño Lógico de Bases de Datos
51
7.3 Diseño lógico específico
Claves externas
• El mecanismo de integridad referencial puede penalizar los
tiempos de respuesta del sistema
– Borrados y actualizaciones propagados en cascada
– importante en consultas interactivas, sobre todo
ð implementación de la integridad referencial «en diferido»
• Algunos SGBD soportan este concepto
– Oracle7 y posteriores versiones
• Pero otros lo incluyen sólo a nivel sintáctico y no
implementan la semántica asociada (Oracle6)
• Otros permiten crear un procedimiento (almacenado en el
catálogo) que implementa cada clave ajena
Tema 7. Diseño Lógico de Bases de Datos
52
26
7.3 Diseño lógico específico
Claves externas (y 2)
• Si el SGBD elegido no soporta este concepto, entonces...
– Introducir las restricciones de clave ajena como requisitos de
especificación de los programas
– Si el SGBD lo soporta, incluir la definición sintáctica de cada clave
ajena en el esquema de BD, si no lo soporta, incluir la definición
como comentario en el catálogo del SGBD
– Utilizar mecanismos de seguridad (GRANT, REVOKE) para prohibir
operaciones de actualización que pueden violar la RI referencial
– Crear un procedimiento que periódicamente compruebe y
notifique posibles violaciones de la RI referencial
Tema 7. Diseño Lógico de Bases de Datos
53
7.3 Diseño lógico específico
Otros conceptos del modelo relacional
• Será necesario crear procedimientos y/o disparadores
(triggers) que verifiquen las restricciones de
integridad definidas en la fase de Diseño Lógico Estándar
• Si el SGBD lo permite, serán almacenados en el catálogo
• Si no, serán parte de los programas de aplicación
– Restricciones de integridad como especificaciones de procesos
Tema 7. Diseño Lógico de Bases de Datos
54
27