TRANSFORMACIN DEL MODELO ENTIDAD AL MODELO RELACIONAL

En el proceso de diseo de una base de datos el primer paso consista en realizar el diseo conceptual para, posteriormente, abordar
el diseo lgico que generaba el esquema de la base de datos en el modelo lgico elegido (relacional, jerrquico, de redes u
orientado a objetos).

Este apartado presenta un procedimiento sistemtico para transformar el esquema conceptual resultante de aplicar el modelo
entidad-relacin al problema de diseo de una base de datos en un esquema relacional.

Para poder llevar a cabo esta transformacin, es necesario realizar previamente determinadas conversiones que eliminen elementos
del modelo entidad-relacin no representables en el modelo relacional.

Antes de pasar al modelo relacional, es conveniente analizar el diagrama entidad-relacin y comprobar que no existen elementos que
no puedan ser representados directamente en el modelo relacional. Para ello pueden seguirse los siguientes pasos:

Preparacin de los esquemas conceptuales

a) Eliminacin de atributos mltiples o multivaluados

Todos los atributos mltiples; es decir, los atributos que pueden tomar ms de un valor en el dominio en el cual estn
definidos, se transformarn en un tipo de entidad dbil por existencia en la cual mantendr relacin

Editorial
Paginas
Edicin Fecha
IdLibro

Autor

LIBRO

b) Eliminacin de atributos compuestos

Todos los atributos compuestos asociados con los tipos de entidad y los tipos de interrelacin
deben ser descompuestos en los atributos simples que formen parte o intervengan en los atributos
compuestos correspondientes. En este proceso se eliminar el atributo compuesto correspondiente,
quedando los atributos

Ing. Domingo Lizana Chauca

 c) Eliminacin de jerarquas de generalizacin.
Al hacerlo hay que tener en cuenta que no debe existir prdida de informacin. Existen tres posibilidades para
realizar la conversin:

c.1 Englobar todos los atributos de la entidad y subtipos en una sola relacin. En general se adoptar esta
solucin cuando los subtipos se diferencien en muy pocos atributos y las interrelaciones que los asocian
con el resto de las entidades del esquema sean las mismas para todos (o casi todos los subtipos), lo cual
implica que los subtipos no sean excluyentes

Esta alternativa presenta el inconveniente de generar demasiados valores nulos en los atributos
opcionales. Tambin ralentiza el proceso de bsqueda al tener en cuenta todas las tuplas en vez de las
que pertenecen a la subentidad deseada. Su nica ventaja es que el acceso a una fila que refleje toda la
informacin de una determinada entidad es mucho ms rpido (no hace falta combinar varias relaciones).

c.2 Considerar cada subentidad como entidad. Para ello, se aaden los atributos de la entidad genrica a la
subentidad; y la clave primaria de la genrica pasa a serlo de las nuevas entidades creadas. Esta opcin
es adecuada en el caso de que existan muchos atributos distintos entre los subtipos, adems los
subtipos sean excluyentes

Sus inconvenientes son varios:

a) Se pierde el concepto de la entidad genrica.

b) Los accesos a la entidad genrica deben convertirse en accesos a todas las subentidades.
c) Los atributos de la entidad genrica son repetidos en cada subentidad.
d) Slo es vlida para jerarquas totales y exclusivas.
e) Si la entidad genrica tiene alguna relacin, sta debe propagarse a cada subentidad.
f) En consecuencia, esta alternativa es vlida cuando la jerarqua es total o exclusiva, no importa
el concepto de la entidad genrica en las operaciones y no hay relacin entre la entidad
genrica y otras entidades.

c.3 Considerar relaciones distintas para cada subtipo, que contengan, adems de los atributos propios, los
atributos comunes. Se elegira esta opcin en el caso de que existan muchos atributos distintos entre los
subtipos

Ing. Domingo Lizana Chauca

 PROFESOR IdProf

(1,1)
Tipo

(0,1) (0,1)
Ao_doc
DOCTOR NO DOCTOR
Materia doc

c.1 PROFESOR (IdProf, Nombre, , Tipo, Ao_doc, Materia_doc)

c.2 PROFESOR ( IdProf, Nombre, )

DOCTOR (IdProf, , Ao_doc,Materia_doc)

Transformacin de los esquemas conceptuales

1. Transformacin de atributos de entidades

Cada atributo de una entidad se transforma en una columna de la relacin a la que ha dado lugar la
entidad. Pero teniendo en cuenta que tenemos atributos identificador principal, otros que son
identificadores alternativos y el resto de atributos que no son identificadores

1.1 Atributos identificadores PRIMARIOS

Los identificadores principales pasan a ser la clave primaria de la relacin.
Ejemplo: La relacin PROFESOR, fruto de la transformacin de la entidad del mismo nombre, con
su identificador principal (Cod_prof) que pasa a ser la clave primaria

Esquema
PROFESOR (Cd_prof, Nombre, DNI, direccin, Telfono, Materia)
Cd_prof Direccin relacional
Nombre PROFESOR Telfono
DNI Materia Diagrama PROFESOR
relacional
DNI Nombre Direccin

1.2 Atributos identificadores alternativos SECUNDARIOS

Respecto a los identificadores alternativos, recoge por medio de la clusula UNIQUE estos objetos, los
cuales son soportados por el modelo relacional
1.3 Atributos no identificadores FORANEOS
Estos atributos pasan a ser columnas, como los anteriores, de la relacin, las cuales tienen
permitido tomar valores nulos a no ser que se indique lo contrario

Aplicando la regla 1.1 y 1.2, la transformacin de la entidad PROFESOR es la siguiente:

CREATE TABLE profesor (Cd_Profesor, Nombre, DNI NOT NULL ,

Direccin, Telfono, Materia, PRIMARY KEY (Cd_Profesor), UNIQUE (DNI))
Ing. Domingo Lizana Chauca
 2. Transformacin de interrelaciones

2.1 Interrelaciones N:M

Este tipo de interrelacin se transforma en una relacin que tendr como clave primaria la
concatenacin de los Identificadores principales de los tipos de entidad que asocia

Cd_prof Direccin
Nombre PROFESOR Telfono PROFESOR ( Cd_prof, Nombre, DNI, direccin, Telfono, Materia )
DNI Materia
PROFESOR_CURSO
(1,n)
IMPARTE ( Cd_curso, Cd_prof )
imparte

(1,n)
Cd_curso CURSO ( Cd_curso, Nombre_curso )
Nombre_curso CURSO

ME/R MR

En SQL obtendramos:

CREATE TABLE Imparte

(Cd_Profesor ,
Cd_curso,
primary key(Cd_Profesor,Cd_curso),
foreign key (Cd_Profesor) references Profesor
ON DELETE CASCADE
ON UPDATE CASCADE,
foreign key(Cd_curso) references Curso
ON DELETE CASCADE
ON UPDATE CASCADE
)

2.2 Interrelaciones 1:N

Existen dos soluciones para la transformacin de una interrelacin 1:N

a) Obligatorio - Obligatorio
Se propaga los identificadores principales del tipo de entidad que tiene de cardinalidad mxima
1 a la que tiene N, desapareciendo el nombre de la interrelacin. Este caso se da en la relacin
es del tipo
Cd_prof Direccin
Nombre PROFESOR Telfono
DNI
PROFESOR ( Cd_prof, Nombre, , Cd_dpto)
(1,n)
No admite
valores 1:N
pertenece
nulos (1,1)
Fecha DEPARTAMENTO ( Cd_dpto, Nombre_dpto, fecha)
(1,1)
Cd_dpto
Nombre_dpto DEPARTAMENTO

ME/R MR

Ing. Domingo Lizana Chauca

 b) Obligatorio - Opcional
Se transforma en una relacin, como si se tratara de una interrelacin N:M ; sin embargo en
este caso, la clave primaria de la relacin creada es slo la clave primaria de la tabla a la que
le corresponde la cardinalidad N.

Cd_prof Direccin
Nombre PROFESOR Telfono
DNI Materia
PROFESOR ( Cd_prof, Nombre, DNI, direccin, Telfono, Materia )
( 1, n )

Fecha DEPARTAMENTO_ PROFESOR ( Cd_dpto, Cod_prof, fecha )

pertenece 1:N
DEPARTAMENTO ( Cd_dpto, Nombre_dpto)
( 0, 1 )
Cd_dpto
Nombre_dpto DEPARTAMENTO
Admite valores nulos,
la clasula NOT NULL
ME/R resuelve el problema MR

Es recomendable esta opcin si el nmero de departamentos es de gran cantidad y no se

admitan valores nulos

c) Opcional-opcional: Este caso se reduce al de relacin obligatoria-opcional.

2.3 Interrelacin 1:1

Una interrelacin de tipo 1:1 es un caso particular de una N:M o tambin de una 1:N, por lo que no
hay regla fija para la transformacin de este tipo de interrelacin al modelo relacional, pudindose
aplicar la regla 2.1 ( con lo que crearamos una relacin) o aplicar la regla 2.2 (esto es, propagar la
clave correspondiente) En este ltimo caso, la propagacin de la clave puede efectuarse en ambos
sentidos.

Los criterios para aplicar una u otra regla se basan en la cardinalidades mnimas:

a) Obligatoria Obligatoria
Se integran las dos entidades en una tabla que contiene los atributos y la clave primaria es
cualquiera de las de E1 y E2. Si coincidiera, slo se incluira una vez en la nueva relacin.

ESTUDIANTE DNI
Nombre
(1,1)
ME/R REALIZA 1:1

(1,1)
PROYECTO DNI
Denominacin

MR ESTUDIANTE ( DNI, Nombre, Denominacin )

b) Obligatoria Opcional
Ing. Domingo Lizana Chauca
 Cada entidad se convierte en una relacin representada por una tabla, y a la que tiene
participacin obligatoria se aadira la clave primaria de la opcional. Las claves primarias de
ambas relaciones se mantienen. Suponiendo ESTUDIANTE opcional, el ejemplo resultara:

PROFESOR Cod_prof
Nombre_prof
(1,1)
ME/R responsable 1:1

(0,1)
Cod_dpto
DEPARTAMENTO
nombre_dpto

PROFESOR ( Cd_prof, Nombre )

MR
DEPARTAMENTO ( Cod_dpto, nombre_dpto, Cod_prof)

c) Opcional-opcional
En este caso, se generarn tres relaciones: una para cada entidad y otra para la
correspondencia entre ambas. Las entidades no sufrira cambios y la nueva relacin incluir las
claves primarias de E1 y E2, as como los atributos de R, si los hubiera. La clave primaria de
esta relacin recin creada ser cualquiera de las de E1 o E2. El ejemplo, sera:

HOMBRE Cod_hombre
Nombre
(0,1)
ME/R matrimoni 1:1
fecha

(0,1)
MUJER Cod_mujer
nombre

HOMBRE ( Cod_hombre, Nombre)

MR
MATRIMONIO ( Cod_mujer, Cod_hombre, fecha )

MUJER ( Cod_mujer, Nombre)

Ing. Domingo Lizana Chauca

 3. Transformacin de dependencias en identificacin y en existencia
N_orden
CORRIDA NombrePlaza
Feria
Ao
( 0, 1 )

estoqueado

( 6, n ) CORRIDA ( N_orden, Feria, Ao, NombrePlaza )

IdGanadera NombreToro
Ao_nac TORO Color TORO ( IdGanadera, Ao_nac, Nmero , NombreToro, Color, N_orden, Feria, Ao)
Numero
( 1, n ) GANADERA (IdGanadera, NombreGan)

pertenece

( 1, 1 )

IdGanadera GANADERA NombreGan MR

ME/R

4. Transformacin de tipos y subtipos

En lo que respecta a los tipos y subtipo, no son objetos que se puedan representar explcitamente en el
modelo relacional. Ante un tipo de entidad y subtipos caben varias soluciones de transformacin al
modelo relacional.

5. Transformacin de relaciones recursivas

5.1 Relaciones Reflexivas 1:N

DNI
(1,1) 1:N
Empleado (dni, nombre, dni_supervisor)
EMPLEADO supervisa

(1,N)

dni_supervisor es una clave fornea de dni (de

nombre
la misma tabla), refleja quien es el jefe y no admite
NULL.

Ing. Domingo Lizana Chauca

 DNI Empleado (dni, nombre)
(1,1) 1:N
EMPLEADO supervisa

(1,N) Supervisa (dni, dni_supervisor)

nombre

5.2 Relaciones Reflexivas M:N

DNI
(1,N) M:N
Empleado (dni, nombre)
EMPLEADO supervisa

(1,N)

Supervisa (dni, dni_supervisor)

nombre

6. Relaciones n-arias.
Tienen el mismo tratamiento que las relaciones N:M. Cada entidad se transforma en tabla y se aade
una tabla para la asociacin que incluya las claves primarias de las entidades participantes en la
correspondencia y los atributos de la asociacin. La composicin de las claves primarias de las
entidades es la clave primaria de la nueva relacin. Por ejemplo, la siguiente relacin ternaria quedara
del modo que muestra la figura:
Provincia
Distrito
actividad

LUGAR
( 1, n )

Fecha ( 1, n ) Matricula
conduce
AUTOBUS
N:N:N Licencia
( 1, n )
NCarnet
Nombre CONDUCTOR
experiencia

Ing. Domingo Lizana Chauca

 CONDUCTOR (NCarnet, Nombre, experiencia)

AUTOBUS (matricula, licencia, categoria)

LUGAR ( Provincia, Distrito, actividad)

CON_AUT_LUG ( NCarnet, Matricula, Provincia, Distrito, Fecha)

CASOS

GESTIN DE UNA BIBLIOTECA

Desarrolle el modelo Entidad Relacin que permita la gestin de una biblioteca con las siguientes caractersticas:
El prstamo slo considera libros ( no incluye: CDS, revistas, o cualquier otro medio)
Para efectos del prstamos todos los libros son iguales
De un mismo libro pueden existir varios ejemplares
Los ejemplares de un libro pueden ser de diferentes ediciones (por ejemplo: del libro Fundamentos de Bases de datos de
Korth, pueden existir cinco ejemplares, uno de la segunda edicin y cuatro de la tercera edicin)
Todos los libros estn en espaol
Un libro puede tener varios autores
Todos los usuarios son iguales y se identifican con un cdigo
Cada usuario tiene derecho a tener prestados hasta 5 libros
Todos los libros prestados deben ser entregados como mximo dos das despus del prstamo. Los usuarios que incumplan
esta regla, quedan suspendidos por una semana
Un libro puede tratar de varios temas (Ejemplo: Base de datos, programacin orientada a objetos, SQL, etc.)

Las consultas ms comunes son:

Cules libros tienen un usuario, y cuando deben regresarlos
Quien tiene un libro determinado
Libros por tema (Ejemplo: Satlites, microondas, telefona celular, etc.)
Historia de los libros prestados por un usuario
Historia de los usuarios que prestan un libro
Informacin general de un libro

Desarrolle el esquema conceptual (Modelo Entidad Relacin) , y el esquema lgico (Modelo Relacional)

ALQUILER Y COMPRA DE INMUEBLES

Se trata de disear una base de datos para una red de agencias franquiciadas a TECHNOHOUSE, empresa especializada en el
alquiler y compra de inmuebles
Cada agencia tiene un titular propio y un conjunto de vendedores. Tanto el titular como los vendedores slo pueden pertenecer
a una agencia. Sobre las agencias interesa almacenar su direccin, telfonos (que pueden ser varios), fax, etc. Adems, cada
agencia tiene asignada una zona de actuacin que es nica
Las agencias disponen de inmuebles tanto para alquilar como para comprar (incluso ambas cosas), en el primer caso figurar
el precio de alquiler y la fianza a depositar, mientras que en el segundo caso, adems del precio de venta, se indica si el
inmuebles est o no hipotecado
Por otro lado, los inmuebles pueden ser locales comerciales, o pisos. En ambos casos se identifican por un cdigo, e interesa
conocer el propietario, la direccin en m2.
Adems, en el caso de pisos interesa conocer el nmero de habitaciones (incluyendo el saln), el nmero de cuartos de bao,

Ing. Domingo Lizana Chauca

 el tipo de gas (natural, butano), y si es interior o exterior. Para los locales comerciales se debe conocer si dispone de licencia
de apertura
Un cliente puede acudir a varias agencias, en cada una se le asigna un vendedor, que es el encargado de seleccionar los
inmuebles que cumplen las caractersticas deseadas, y en caso de estar interesado, el cliente debe dar una seal para reservar
el inmueble ( o los inmuebles) que desea

Complete los atributos que faltan del modelo Entidad / Relacin y transforme al esquema Lgico empleando el Modelo Relacional

GIMNASIO Siempre en forma

En el gimnasio se quiere implantar una base de datos para llevar el control de los socios, recursos utilizados, etc. Las
especificaciones son las siguientes:
Existen varias salas, de las cuales se quiere guardar informacin, como los metros cuadrados que ocupa, ubicacin y el tipo de
sala (cardio, general, muscular). Cada sala se identifica por un nmero
Hay salas que tienen aparatos y salas que no. En las salas se pueden o no impartir clases
Cada aparato est asignado a una nica sala, y de cada uno de ellos se quiere tener almacenado su cdigo, descripcin y
estado de conservacin
Tambin se quiere mantener informacin relacionada con las clases que se imparten (descripcin y da / hora en la que se
imparten); cada clase se identifica por un cdigo de clase. Cada clase tiene asignada una sala en la que se imparte y un monitor
De cada monitor se quiere conocer el DNI, nombre, telfono, si tienen o no titulacin y experiencia profesional, as como las
clases que pueden impartir (preparacin como monitor de aerobic, step, streching, etc.)
De cada socio se quiere conocer el nmero de socio, nombre, direccin, telfono, profesin y datos bancarios, as como las
clases a las que asiste
El gimnasio dispone tambin de pistas de squash, de las que se quiere conocer el nmero de pistas, ubicacin y estado. Las
pistas de squash pueden ser utilizadas por socios, y existe un servicio de reserva de pista ( en una fecha y a una hora)

Complete los atributos que faltan del modelo Entidad / Relacin y transforme al esquema Lgico empleando el Modelo Relacional

Ing. Domingo Lizana Chauca

 CASOS DE DESARROLLO
Realizar el esquema relacional en base a los siguientes modelos de Entidad Relacin
1. El Gimnasio Siempre en forma del caso anterior impone las siguientes restricciones:
Las pistas de Squash se consideran salas
Las clases slo se imparten en salas sin aparatos. Las salas con aparatos siguen clasificndose en sala de cardio,
general, etc,

Ing. Domingo Lizana Chauca

 2. Colecciones de Mariposas

3. - Gestin de Biblioteca

4.- Gestin de CDS

Desarrollar un modelo E-R que permita representar el siguiente enunciado

El Seor Juan Prez tiene en su discoteca privada una cantidad considerable de CDS y tiene problemas al acceder a una cancin
en particular dado que emplea mucho tiempo en la bsqueda de esta. A continuacin una serie de preguntas y respuestas que
entregan ms informacin acerca del problema.

Cuntas canciones tiene un CD?

Cada CD puede tener una o ms canciones
Una cancin puede aparecer en varios CDs
S, adems puede ser interpretada por varios artistas (Grupos o Solistas)

Ing. Domingo Lizana Chauca

 Un CD puede tener canciones de varios artistas?
Si, existen CD variados.
A cuntos gneros puede pertenecer una cancin?
Un solo gnero Por ejemplo: Balada, Rock, Latinoamericanos, etc.
Cmo se identifican los CDs?
Cada CD tiene un nombre nico que lo identifica de los dems CDs. En el caso de un lbum con varios CDs,
suponga que el lbum tiene un nombre y cada CD se referencia como Vol1, Vol2, VOl3, etc. Cada CD
pertenece a una casa disquera.
En el caso de CDs variados cmo se maneja?
Cada cancin tiene su intrprete, duracin y gnero

Otros datos:
Una cancin, por ejemplo Valio la pena puede existir en varios CDs interpretada por varios
artistas. Una cancin tiene un solo autor , y para efectos del ejercicio es una sola persona
No hay prestamos de CDs
Todos los CDs son nicamente de msica
Un CD puede tener la misma cancin interpretada por diferentes artistas
Caso extremo: Un CD donde aparezca dos o ms veces la misma cancin interpretada por el mismo artista, Ejemplo: una
versin grabada en estudio, otra grabada en vivo y otra un desconec

Ing. Domingo Lizana Chauca