Sistemas Operativos

Tema III: Transformación del
esquema conceptual al relacional

3.1 Introducción. Etapas del diseño lógico
Diseño lógico estándar
Diseño lógico específico
3.2 Transformación elementos básicos
3.3 Reglas concernientes a las extensiones del modelo E/R

Transformación de dependencias en identificación y en existencia
Transformación de interrelaciones exclusivas
Transformación de tipos y subtipos
Transformación de la dimensión temporal
Transformación de atributos derivados
Transformación de interrelaciones de grado superior a dos
Tema 3.1: Introducción.

Etapas del diseño Lógico
Recordando
Estructura
de Datos
E/R
© LABDA Tema III: Transformación del esquema conceptual al relacional -2
1
A) Diseño lógico estándar
Ø Elaboración del Esquema Lógico Estándar que se apoya en el

modelo lógico estándar -Relacional, Codasyl, Jerárquico-
Ø El Esquema Lógico Estándar se describirá utilizando el lenguaje

estándar, si existe, del modelo de datos correspondiente (v.g. el
SQL92)
B) Diseño lógico específico
Ø Con el Esquema Lógico Estándar, y teniendo en cuenta el

modelo lógico específico propio del SGBD, se elabora el
esquema lógico específico, que será descrito en el lenguaje del
producto comercial que estemos utilizando (p. e. Oracle)

ENTRADAS
REQUISITOS
DE LOS
ESQUEMA
CONCEPTUAL PROCESOS Y
EL ENTORNO
MODELO
LÓGICO
ESTANDAR
ESQUEMA
Diseño LÓGICO
ESTANDAR
lógico
MODELO
LÓGICO
ESPECÍFICO
ESQUEMA
ESPECIFICACIONES LÓGICO
PARA LOS PROCESOS ESPECÍFICO
* Imagen inspirada en [5], página 345
2
diagrama
Modelo Conceptual
E/R
grafo
Modelo Lógico (estándar)
Relacional
Script Modelo Lógico (específico)

SQL
Tema 3.2: Transformación

Elementos Básicos
tipo_nombre • Los dominios en E/R se mantienen

como dominios en Relacional
PERSONA • Las entidades en E/R se traducen en

relaciones del modelo Relacional
• Las interrelaciones en E/R se traducen en

confía - relaciones del modelo Relacional
- propagación de claves (clave ajena) *
Nota *: aunque una clave ajena parece recoger menos semántica que una relación E/R,
esta semántica se complementa con la que aporta la restricción referencial.
3
Elementos Básicos
Los ATRIBUTOS de una entidad serán atributos de la relación
correspondiente, con ciertas salvedades:
• Los atributos ‘no obligatorios’ serán
marcados como atributos opcionales (*)
• Los atributos identificadores principales
PERSONA serán marcados como clave primaria
• Los atributos identificadores alternativos
serán marcados como claves alternativas
• Un atributo multivaluado origina una nueva relación que
contiene dicho atributo y la clave primaria de la entidad
(que será clave ajena sobre la relación a la que esta dé lugar).
La clave de esta relación será todo el esquema de relación.

Elementos Básicos
Interrelaciones N:M
Se traducen en una relación.
DNI veces Título
nombre
director
apellidos PERSONA ha visto PELÍCULA
N:M
• Esta relación contendrá las claves de las relaciones asociadas,

que en conjunto serán clave de la nueva relación.
• También incluirá los atributos de la interrelación original.
• Las opciones de borrado y modificación dependerán del cada caso
particular (si bien, en general, se escogerá en ambas la opción cascada)
4
Elementos Básicos
Interrelaciones N:M
Ejemplo:
DNI veces Título
nombre
director
apellidos PERSONA ha visto PELÍCULA
N:M
DC / UC
Persona (DNI, Nombre, Apellidos,...)
ha_visto (DNI, Título, veces)
DC / UC Película (Título, Director,...)

Elementos Básicos
Interrelaciones 1:N
Dos posibilidades:
DNI fecha Nº_Factura
nombre
importe
apellidos PERSONA paga FACTURA
1:N
• Propagar la clave de la entidad que interviene con cardinalidad 1

(en la relación correspondiente a la otra entidad aparecerá esta clave como
clave ajena; junto a ella, irán los atributos de la interrelación si los hubiera)
• Transformarla en una nueva relación
Dicha relación tendría como atributos las claves de ambas entidades (y los
atributos propios de la interrelación). Su clave sería la clave de la entidad
que interviene en la interrelación con N ocurrencias).
© LABDA Tema III: Transformación del esquema conceptual al relacional - 10
5
Elementos Básicos
Interrelaciones 1:N
Ejemplo: propagar clave
DNI fecha Nº_factura
nombre
importe
1:N

D? / UC
Factura (Nº_factura, DNI, importe,...)

Elementos Básicos
Interrelaciones 1:N
Ejemplo: crear nueva relación
DNI fecha Nº_factura
nombre
importe
1:N
D? / UC
paga (Nº_factura, DNI, fecha)
DC / UC
Factura (Nº_factura, importe,...)
6
Elementos Básicos
Interrelaciones 1:N
¿Qué hacer con las cardinalidades mínimas ‘cero’?
nombre
(0,1) (0,n) importe
1:N
• (0,1): la entidad que interviene con una ocurrencia es opcional
(pueden existir ocurrencias de la otra entidad no relacionadas).
Resultado:
- si se propaga, la clave ajena propagada será opcional (*)
(habrá ocurrencias de la otra entidad cuya clave ajena sea NULL)
- si se crea una nueva relación, habrá identificadores de la entidad
opcional que no aparezcan en ninguna ocurrencia de esta relación.
(no hay que hacer nada)

Elementos Básicos
Interrelaciones 1:N
¿Qué hacer con las cardinalidades mínimas ‘cero’?
nombre
(0,1) (0,n) importe
1:N
• (0,n): la entidad que interviene con varias ocurrencias es opcional.
(pueden existir ocurrencias de la otra entidad no relacionadas).
Resultado: no hay que tomar ninguna medida especial
- si se propaga, habrá ocurrencias de la clave de identificación
propagada que no aparezcan en ninguna tupla de la otra relación.
- si se crea una nueva relación, habrá identificadores de la entidad
opcional que no aparezcan en ninguna ocurrencia de esta relación.
7
Elementos Básicos
Interrelaciones 1:N
¿Qué hacer con las cardinalidades mínimas ‘uno?
nombre
(1,1) (1,n) importe
1:N
• (1,1): la entidad interviene con una y solo una ocurrencia.
Resultado:
- si se propaga, la clave ajena tomará siempre un valor (obligatoriedad).
- si se crea una nueva relación, en ella debería haber una tupla por
cada ocurrencia de la relación que interviene con N (pero esto no
quedará garantizado a priori; habría una pérdida de semántica).
Nota: estas pérdidas de semántica se suplirán con la inclusión de restricciones semánticas;
en concreto, se añadirán aserciones que vigilen que estas condiciones se cumplen.

Elementos Básicos
Interrelaciones 1:N
¿Qué hacer con las cardinalidades mínimas ‘uno?
nombre
(1,1) (1,n) importe
1:N
• (1,n): la entidad interviene con una o varias ocurrencias.
Resultado: no se toma ninguna medida especial (pérdida de semántica).
- si se propaga, toda valor de la clave propagada debería aparecer
en alguna ocurrencia de la otra relación (pero no se garantiza)
- si se crea una nueva relación, en ella debería haber al menos una
tupla por cada ocurrencia de la relación que interviene con una
ocurrencia (pero tampoco esto está garantizado a priori)
8
Elementos Básicos
Interrelaciones 1:N
¿Cuál de las opciones es más conveniente?
nombre
importe
1:N
• En general, es preferible propagar la clave

• Se creará una nueva relación si:
a) la interrelación tiene caracterización propia (atributos propios)
b) se prevé que la interrelación podría ser N:M en el futuro
c) la cardinalidad mínima de la interrelación para la entidad que
propaga es 0 (opcional), y en la otra entidad el número de
ocurrencias no relacionadas es elevado (la clave ajena sería NULL)

Elementos Básicos
Interrelaciones 1:1
Se puede considerar un caso particular de las anteriores, y por tanto
las soluciones anteriores son válidas también en este caso.
DNI fecha_apertura nº_historial
nombre
localización
apellidos PERSONA tiene HISTORIAL
MÉDICO
1:1
Las soluciones aplicables son:

a) crear una nueva relación
b) propagar una de las claves
c) propagar las claves de las dos entidades (mutuamente)
d) fusionar ambas entidades (interrelacionadas) en una sola relación
9
Elementos Básicos
Interrelaciones 1:1
Crear una nueva relación: (justificación similar al caso 1:n)

a) si las cardinalidades mínimas son cero (ambas), esto evitará
valores nulos en las claves ajenas y mantendrá la simetría
natural (entidades mantienen su independencia en relaciones
separadas)
b) si la interrelación tiene caracterización propia (atributos) o
c) si se prevé que posteriormente puedan variarse las
cardinalidades
DNI horario nº_serie
nombre
(0,1) (0,1) memoria
apellidos EMPLEADO utiliza ORDENADOR
1:1

Elementos Básicos
Interrelaciones 1:1
Ejemplo: (crear una nueva relación)
DNI horario nº_serie
nombre
(0,1) (0,1) memoria
apellidos EMPLEADO utiliza ORDENADOR
1:1
DC / UC
Empleado (DNI, Nombre, Apellidos,...)
utiliza (nº_serie, DNI, horario)
DC / UC
Ordenador (nº_serie, memoria,...)
Nota: observar la pérdida de eficiencia, ya que muchos consultas implican combinar dos
relaciones, e incluso hay consultas que implican combinar las tres relaciones.
10
Elementos Básicos
Interrelaciones 1:1
Propagar una clave: (justificación similar a la anterior)
• si una de las cardinalidades mínimas es cero y la otra no (será 1,1),
conviene propagar la clave de esta última (la obligatoria).
Ejemplo:
DNI fecha_inicio nº_sucursal
nombre
(1,1) (0,1) dirección
apellidos EMPLEADO dirige SUCURSAL
1:1
Empleado (DNI, Nombre, Apellidos,...)

DNA / UC
Sucursal (nº_sucursal, DNI_director, dirección,...)

Elementos Básicos
Interrelaciones 1:1
Propagar una clave:
• Inconvenientes:
• se pierde la simetría
• consultas a la información de la entidad que interviene con (1,1) suponen
combinación natural (por ejemplo, empleados que no dirigen sucursal)
• Ventajas:
• no pierde semántica (sobre la cardinalidad mínima 1)
• se evitan valores nulos
• algunas consultas no precisan combinación de relaciones
• NOTA: observar que la opción de borrado debe ser restringido o en cascada
11
Elementos Básicos
Interrelaciones con atributos:
• si se crea una nueva relación, esos atributos se incluyen en esta relación.
• si se propaga una clave, los atributos acompañan a la clave.
• si se propagan ambas claves, los atributos se incluyen en una de las
entidades interralacionadas.
• si se fusionan en una relación, esta también contendrá esos atributos.
Interrelaciones con un atributo multivaluado:

• la interrelación habrá de transformarse en una relación, y su clave
deberá contener ese atributo (además de la clave de una de las entidades
o las dos)

Elementos Básicos
Ejemplo Interrelación con atributo
%
Cod_persona Posee Cod_casa
(0,N) N:M (0,N)

PERSONA CASA
POSEE(Cod_persona, cod_casa, participación_% )
PERSONA (Cod_persona, .........)
CASA (Cod_casa, .........)
12
Elementos Básicos
Ejemplo Interrelación con atributos multivaluados
Cod_Ejemplar Fecha_i. Fecha_f Cod_Persona
EJEMPLAR_DVD (1,N) (0,N) PERSONA

presta
N:M
EJEMPLAR _DVD( Cod ejem, título, ...)
PERSONA(Cod _persona, nombre, apellidos,

) ...)
PRESTA ( Cod_ejem, cod

cod_pers., Fecha_i, Fecha_f )

de las extensiones del E/R
5.3.1 Dependencias en Existencia/Identificación

5.3.2 Interrelaciones Exclusivas
5.3.2 Generalizaciones
5.3.4 Dimensión Temporal
5.3.5Atributos Derivados
5.3.6 Interrelaciones de grado superior a 2
13
Tema 3.3.1: Dependencias en
Existencia/Identificación
Se transforman de la misma forma que las interrelaciones 1:N
N_orden
Cod_dvd
Cod_Ejemplar
ID
DVD tiene EJEMPLAR
(1,1) (0,n)
1:N
M E/R
MR
DVD (Cod_dvd, …)
DC/UC ¿Restricciones
EJEMPLAR (Cod_dvd, N_orden, …) de Integridad?
Tema 3.3.2: Interrelaciones

Exclusivas
(0,1)
(1,n) publica REVISTA
ARTÍCULO
(1,n) ACTAS
aparece (0,1) CONGRESO
M E/R
MR
DC/UC
¿QUÉ FALTA? ACTAS_CONGRESO(Cod_A., …)
REVISTA(Cod_Rv, …) DC/UC
CHECK ARTICULO(Cod_articulo, …, Cod_Rv, Cod_Actas)

CHECK ((Cod_Rv IS NULL AND Cod_Ac IS NOT NULL)
OR
(Cod_Rv IS NOT NULL AND Cod_Ac IS NULL))
14
Tema 3.3.3: Generalizaciones
w El Modelo Relacional no dispone de instrumentos que

permitan representar tipos y subtipos.
w Se definen distintos métodos de transformación,
dependiendo de los objetivos perseguidos:
n Información semántica representada en el modelo
n Eficiencia de acceso a los datos
TIPO
SUBTIPO 1 SUBTIPO 2

w Método 1
Utilizar una única relación para representar un tipo y todos
sus subtipos, añadiendo un atributo que indique el tipo de
entidad al que se hace referencia.
Puede hacerse cuando:
n los atributos de los subtipos son similares
n las interrelaciones que involucran a los subtipos son las mismas (o
no existen)
Será necesario implementar las restricciones semánticas
necesarias a través de CHECKS o DISPARADORES.
15
w Método 1
Según los parámetros de la jerarquía, ¿qué restricciones hay
que definir?
Solapamiento
Sí ? El atributo discriminante puede tomar varios valores
combinados.
No ? Verificar que sólo los atributos adecuados al subtipo toman
valores.
Totalidad
Sí (Total) ? El atributo discriminante no puede tomar valores nulos.
No (Parcial) ? El atributo discriminante debe admitir valores nulos.

w Método 1. Ejemplo, jerarquía parcial con solapamiento
DNI nombre dirección
PERSONA
(1,1) ¿Totalidad?
El tipo admite valores
es_un
TIPO nulos
tfno Curso Nota_media
sueldo
(0,1) (0,1)
EMPLEADO ESTUDIANTE
M E/R
MR
PERSONA (DNI, nombre, dirección, tipo*, sueldo*, teléfono*, Curso*, Nota_media*)
16
w Método 1. Ejemplo, Restricción exclusividad
Check (( Tipo= ‘Emp’
AND curso IS NULL
AND nota_media IS NULL
AND sueldo IS NOT NULL
AND tfno IS NOT NULL
OR
( Tipo = ‘Est’
AND sueldo IS NULL
AND tfno IS NULL
AND curso IS NOT NULL
AND nota_media IS NOT NULL ))

w Método 2
Utilizar una relación para representar al supertipo y tantas
relaciones como subtipos haya. Como antes habrá que
añadir un atributo que indique el tipo de entidad al que se
hace referencia.
n los subtipos tienen atributos dispares y/o interrelaciones
diferentes
n Incorporar mayor semántica en el grafo relacional
17
w Método 2
que definir?
Solapamiento
Sí ? El atributo discriminante puede tomar varios valores combinados.
No ? Verificar que sólo aparecen entradas en la relación del subtipo
correspondiente.
Totalidad
Sí (Total) ? El atributo discriminante no puede tomar valores nulos y es
necesario verificar que hay entradas para todas las tuplas del tipo.
No (Parcial) ? El atributo discriminante debe admitir valores nulos.


PERSONA (DNI, nombre, dir, tipo*)
PERSONA
DC/UC
(1,1) EMPLEADO (DNI,sueldo, tfno)

DC/UC
es_un TIPO ESTUD.(DNI,curso, nota_media)
sueldo
(0,1) (0,1)
EMPLEADO ESTUDIANTE
M E/R MR
18
w Método 3
Se emplea una relación para cada subtipo; cada una de ellas
incluye los atributos comunes asociados al tipo.
n los subtipos tienen atributos dispares y/o interrelaciones
diferentes
n La mayoría de los accesos a los datos de los subtipos involucran en
mayor medida a los atributos comunes ? Eficiencia

w Método 3
que definir?
Solapamiento
Sí ? Nada que controlar.
No ? Verificar que sólo aparecen entradas en la relación del subtipo
correspondiente.
Totalidad
Sí (Total) ? Nada que controlar.
No (Parcial) ? NO PUEDE UTILIZARSE ESTA TRANSFORMACIÓN
19
PERSONA EMP(DNI, nombre, dir, sueldo, tfno)

(1,1)
EST(DNI, nombre, dir, curso, nota_media)
es_un TIPO
sueldo
(0,1) (0,1)
EMPLEADO ESTUDIANTE
M E/R MR

EJEMPLOS
w Una empresa de estudios forestales desea almacenar en una base de
datos información sobre sus empleados, que pueden ser administrativos
u operarios de campo. Estos datos serán DNI, nombre, apellidos, fecha
de contrato y fecha de baja. Además, para el caso de los operarios es
necesario almacenar el coste por hora, así como el número de horas
trabajadas.
w Los operarios de campo tienen la misión de tomar medidas sobre

determinadas parcelas y los administrativos serán los encargados de
grabar los datos de los formularios rellenados por los operarios de
campo.
20
Tema 3.3.4: Dimensión Temporal
Se emplean las reglas de transformación de atributos multivaluados.
DNI f_inicio f_fin Cod_DVD
PERSONA presta DVD

(0,n) (0,n)
N:M
M E/R
MR
PERSONA (DNI, ……….) DVD (Cod_DVD, ……….)
DC/UC DC/UC
PRESTA (DNI, Cod_DVD, f_inicio, f_fin, ……….)
Tema 3.3.5: Atributos Derivados

Atributos cuyo valor se obtiene a través de una expresión.
N_orden
Cod_DVD
Cod_Ejemplar
ID
DVD tiene EJEMPLAR_DVD
(1,1) (0,n)
D1 N_ejemplares 1:N
M E/R
MR
DVD (Cod_DVD, Título, N_ejemplares)
Será necesario incluir un disparador para el cálculo del atributo
21
Ternarias
En el modelo E/R se permiten interrelaciones entre más de dos
entidades.
INVESTIGADOR
N:M:P habla CONFERENCIA
TEMA

Ternarias
Siempre que sea posible, este tipo de interrelaciones se
representarán a través de varias interrelaciones binarias.
(1,N)
INVESTIGADOR ¿Semántica
(1,N) equivalente?
(1,N)
investiga publica participa
(1,N) (1,N) (1,N)

(1,N)
TEMA abarca CONFERENCIA NO

(1,N) (1,N)
22
Ternarias
Otro ejemplo:
(1,N)
INVESTIGADOR
(1,N) ¿Semántica
equivalente?
(1,N)
escribe publica participa
(1,N) (1,1) (1,N)

(1,N)
ARTÍCULO acepta CONFERENCIA

(1,N) (1,1)
SI

Ternarias
¿Cómo se transforma al Modelo Relacional este tipo de
interrelaciones?
M E/R M R
wRegla General:
A ( C_A, ...........)
A C_A
C_B B ( C_B, .............)
Atrib.
C ( C_C, .............)
I B
I (C_A, C_B, C_C, Atrib)
DC/UC
C C_B DC/UC
DC/UC
23
Ternarias
wEs necesario un análisis más profundo teniendo en cuenta las
cardinalidades de la interrelación.
wCaso 1. Cardinalidad máxima n y mínima 1 en todas las

ramas de la interrelación:
Es aplicable la regla general.

Ternarias
w Caso 2. Cardinalidad máxima n y mínima 0 en una rama:
M E/R M R
C_A A ( C_A, ...........)
(0,n)
A I1 B ( C_B, .............)
Atrib. (1,n)
(0,n) C ( C_C, .............)
(1,n)
I B I (C_A, C_B, C_C, Atrib)
(0,n) DC/UC
DC/UC
C C_B DC/UC
C_C I1 (C_A, C_B)
24
Ternarias
w Caso 3. Cardinalidad máxima n en dos ramas y máxima 1 en
la otra: M E/R M R
C_A
A ( C_A, ...........)
A
B ( C_B, .............)
Atrib. (1,n)
(1,n)
C ( C_C, .............)
I B
I (C_A, C_B, C_C, Atrib)
(0,1)
DC/UC
C C_B DC/UC
C_C DC/UC
Bibliografía
w BÁSICA:
[1] D. Cuadra, E. Castro, A. Iglesias, P. Martínez, F.J. Calle, C. de Pablo, H. Al-Jumaily y L.
Moreno. Desarrollo de Bases de Datos: casos prácticos desde el análisis a la
implementación. Capítulo 2. RA-MA. 2007.
[2] M. Piattini, E. Marcos, C. Calero y B. Vela. Tecnología y Diseño de Bases de Datos.
Capítulos 6 y16. RA-MA 2006.
w RECOMENDADA:
[3] A. Silberschatz, H. Korth & S. Sudarskhan. Fundamentos de Bases de Datos. 5ª Edición.
Capítulo 7. McGraw Hill. 2006.
[4] R. Elmasri and S.B. Navathe. Fundamentos de Sistemas de Bases de Datos. Capítulo 3.
Addison Wesley. 2007.
[5] A. de Miguel, M. Piattini y E. Marcos. Diseño de Bases de Datos Relacionales. Capítulo 3.
RA-MA. 1999.
[6] A. de Miguel, P. Martínez, E. Castro, J.M. Cavero, D. Cuadra, A. Iglesias y C. Nieto.
Diseño de Bases de Datos: Problemas Resueltos. Capítulo 2. RA-MA. 1999.
25

Sistemas Operativos

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Sistemas Operativos

Cargado por

Copyright:

Formatos disponibles

Tema III: Transformación del

esquema conceptual al relacional

3.2 Transformación elementos básicos

3.3 Reglas concernientes a las extensiones del modelo E/R

Tema 3.1: Introducción.

© LABDA Tema III: Transformación del esquema conceptual al relacional -2

Ø Elaboración del Esquema Lógico Estándar que se apoya en el

Ø El Esquema Lógico Estándar se describirá utilizando el lenguaje

Ø Con el Esquema Lógico Estándar, y teniendo en cuenta el

© LABDA Tema III: Transformación del esquema conceptual al relacional -3

Tema 3.1: Introducción.

* Imagen inspirada en [5], página 345

© LABDA Tema III: Transformación del esquema conceptual al relacional -4

Script Modelo Lógico (específico)

© LABDA Tema III: Transformación del esquema conceptual al relacional -5

Tema 3.2: Transformación

tipo_nombre • Los dominios en E/R se mantienen

PERSONA • Las entidades en E/R se traducen en

• Las interrelaciones en E/R se traducen en

© LABDA Tema III: Transformación del esquema conceptual al relacional -6

Tema 3.2: Transformación

• Esta relación contendrá las claves de las relaciones asociadas,

© LABDA Tema III: Transformación del esquema conceptual al relacional -8

© LABDA Tema III: Transformación del esquema conceptual al relacional -9

Tema 3.2: Transformación

• Propagar la clave de la entidad que interviene con cardinalidad 1

Persona (DNI, Nombre, Apellidos,...)

Factura (Nº_factura, DNI, importe,...)

© LABDA Tema III: Transformación del esquema conceptual al relacional - 11

Tema 3.2: Transformación

© LABDA Tema III: Transformación del esquema conceptual al relacional - 12

Tema 3.2: Transformación

© LABDA Tema III: Transformación del esquema conceptual al relacional - 15

Tema 3.2: Transformación

© LABDA Tema III: Transformación del esquema conceptual al relacional - 16

• En general, es preferible propagar la clave

© LABDA Tema III: Transformación del esquema conceptual al relacional - 17

Tema 3.2: Transformación

Las soluciones aplicables son:

© LABDA Tema III: Transformación del esquema conceptual al relacional - 18

Crear una nueva relación: (justificación similar al caso 1:n)

© LABDA Tema III: Transformación del esquema conceptual al relacional - 19

Tema 3.2: Transformación

© LABDA Tema III: Transformación del esquema conceptual al relacional - 20

Empleado (DNI, Nombre, Apellidos,...)

Sucursal (nº_sucursal, DNI_director, dirección,...)

© LABDA Tema III: Transformación del esquema conceptual al relacional - 21

Tema 3.2: Transformación

• NOTA: observar que la opción de borrado debe ser restringido o en cascada

© LABDA Tema III: Transformación del esquema conceptual al relacional - 22

Interrelaciones con un atributo multivaluado:

© LABDA Tema III: Transformación del esquema conceptual al relacional - 23

Tema 3.2: Transformación

Cod_persona Posee Cod_casa

(0,N) N:M (0,N)

POSEE(Cod_persona, cod_casa, participación_% )

PERSONA (Cod_persona, .........)

CASA (Cod_casa, .........)

© LABDA Tema III: Transformación del esquema conceptual al relacional - 24

EJEMPLAR_DVD (1,N) (0,N) PERSONA

EJEMPLAR _DVD( Cod ejem, título, ...)

PERSONA(Cod _persona, nombre, apellidos,

PRESTA ( Cod_ejem, cod

PERSONA (DNI, nombre, dirección, tipo, sueldo, teléfono, Curso, Nota_media*)