Transformacin del

modelo Entidad/Relacin
al modelo relacional
TEMA 4

Paso del modelo E/R al

relacional

Hay que seguir una serie de tcnicas para

transformar las distintas entidades y
asociaciones del modelo E/R en las
correspondientes tablas y relaciones del
modelo relacional.
No olvidemos que el modelo E/R opera con
conceptos, necesitamos obtener las tablas
finales que implementaremos en la BD y
stas las proporciona el modelo relacional

Paso de M.E/R a M.R.

Toda entidad se transforma en una

relacin (tabla)
Las interrelaciones N:M se
transforman en una relacin
(tabla)
Las interrelaciones 1:N dan lugar o
bien a una propagacin de clave
o bien a una relacin(tabla).

Transformacin de
entidades

Cada tipo de entidad se convierte en una

relacin o tabla. La tabla se llamar igual
que el tipo de entidad de donde proviene.
Cada atributo de una entidad se transforma
en una columna de la relacin. El atributo
identificativo principal pasa a ser la clave
primaria de la relacin, subrayada (PRIMARY
KEY). Los atributos identificadores
alternativos, deben ser valores nicos
(UNIQUE), tambin se podr indicar si se
desea que no puedan ser valores nulos
(NOT NULL).

Transformacin de
entidades

A cada entidad del modelo E/R le

corresponder una tabla en el modelo
relacional y se mantendrn tanto los
atributos como la clave primaria.
PRODUCTOS

GUARDADOS

Productos (cod_prod, nombre, precio, stock)

Almacenes (cod_alm nombre, calle, portal, tfno)

ALMACENES

Transformacin de
atributos de entidades

Atributos univaluados dan lugar a un

atributo de la relacin
Atributos multivaluados dan lugar a
una nueva tabla cuya clave es la clave
primaria de la entidad junto con el
nombre del atributo.
Atributos compuestos se transforman
en los atributos que los componen

Ejemplo
Un usuario de una
aplicacin informtica
utiliza varios terminalesUSUARIO(DNI, nombre,)

TERMINAL(DNI, terminal)

Transformacin de
interrelaciones N:M
Se transforma en una tabla que tendr como
clave primaria la concatenacin de los atributos
identificadores principales de las entidades que
relaciona.
Cada uno de los atributos que forman la clave
primaria son claves ajenas que referencian a
las claves primarias de las entidades
interrelacionadas (FOREIGN KEY)
Si la interrelacin posee atributos, stos pasan a
formar parte de la nueva tabla

Ejemplo
N:M
Clientes

compra
n

Productos

cantidad

clientes (cdigo_cliente, nombre, apellidos...)

productos (cdigo_producto, nombre, precio...)
FK (Foreign Key)

compran (cdigo_cliente, cdigo_producto, cantidad,...)

Transformacin de interrelaciones
1:N

Existen dos soluciones:

Propagar la clave del tipo de entidad que tiene de
cardinalidad mxima 1 a la que tiene N,
desapareciendo el nombre de la interrelacin. Esta
clave ser ajena. Admitir nulos si la cardinalidad es
(0,1). Si existen atributos en la interrelacin, stos
tambin se propagarn.
Transformarlo en una relacin, como si se tratase 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. Lo normal es el primer caso pero puede
ser apropiado en los casos siguientes:

Cuando el nmero de valores interrelacionados de la entidad que

propaga su clave es muy pequeo y por tanto existiran muchos
valores nulos en la clave propagada.
Cuando se prev que dicha interrelacin en un futuro se convertir en

Ejemplo
1:M
#cdigo_vende
dor
nombre
apellidos

Vendedor

Atie
nde

Cliente

#cdigo_clien
te
nombre
apellidos

FK, NN

vendedor (cdigo_vendedor, nombre, apellidos, ...)

cliente (cdigo_cliente, nombre, apellidos, ...cdigo_vendedor)

Transformacin de Interrelacin
1:1

Es un caso particular de una N:M o

tambin de una 1:N, por lo tanto se
puede aplicar la regla de crear una
relacin o aplicar la de propagar la
clave correspondiente. En este
ltimo caso hay que observar que en
una interrelacin 1:1, la propagacin
de la clave puede efectuarse en
ambos sentidos

Transformacin de
Interrelacin 1:1

Los criterios para aplicar una u otra regla se

basan en las cardinalidades mnimas.

Si las entidades que se asocian poseen

cardinalidades (0,1), puede ser conveniente
transformar la interrelacin 1:1 en una relacin
Si una de las entidades que participa en la
interrelacin posee cardinalidades (0,1), mientras
que la otra son (1,1), conviene propagar la clave de
la entidad con cardinalidades (1,1) a la tabla
resultante de la entidad de cardinalidades (0,1).
En el caso de que ambas entidades presenten
cardinalidades (1,1), se puede propagar la clave de
cualquiera de ellas a la tabla resultante de la otra.

Ejemplo del primer caso:

Ejemplo del segundo caso:

Ejemplo del tercer caso:

Transformacin de
atributos de
interrelaciones.
Si la interrelacin se transforma en una
relacin, todos sus atributos pasan a
ser columnas de la relacin. En caso
de que la interrelacin se transforme
mediante propagacin de clave, sus
atributos migran junto a la clave a la
relacin que corresponda.

N:M
PRODUCTO

compr
a

PROVEEDOR

precio

Transformacin entidades:
Producto(cod_prod, nombre)
Proveedor (id_prov, nombre,.)

Transformacin de relaciones:
Compra N:N se crea una nueva tabla compra(cod_prod, id_prov, precio)

dependencias en
identificacin y en
existencia.

Se propaga la clave, creando una

clave ajena, con nulos no permitidos ,
en la relacin de la entidad
dependiente.
En el caso de dependencia en
identificacin la clave primaria de la
relacin en la que se ha transformado
la entidad dbil debe estar formada
por la concatenacin de las claves de
las dos entidades participantes en la

Transformacin de relaciones N-arias:

En este tipo de relaciones se agrupan 3 o ms entidades, y para pasar al modelo
relacional cada entidad se convierte en tabla, as como la relacin, que va a contener los
atributos propios de ella ms las claves de todas las entidades. La clave de la tabla
resultante ser la concatenacin de las claves de las entidades. Hay que tener en cuenta:

Si la relacin es N:N:N, es decir, si todas las entidades participan con

cardinalidad mxima N, la clave de la tabla resultante es la unin de las claves
de las entidades que relaciona. Esta tabla incluir los atributos de la relacin si
los hubiera.
Si la relacin es 1:N:N, es decir, una de las entidades participa con cardinalidad
mxima 1, la clave de esta entidad no pasa a formar parte de la clave de la tabla
resultante, pero forma parte de la relacin como un atributo ms.
Si la relacin es 1:1:N, la relacin que se consigue de su transformacin tiene
como clave primaria los atributos que forman la clave primaria de la entidad del
lado N y los atributos que forman la clave primaria de cualquiera de las dos
entidades que estn conectadas con 1. As pues, hay dos posibles claves para la
relacin que se obtiene. Son dos claves candidatas entre las cuales el diseador
deber escoger la primaria.
Si la relacin es 1:1:1 la relacin que se obtiene de su transformacin tiene como
clave primaria los atributos que forman la clave primaria de dos entidades
cualesquiera de las tres interrelacionadas. As pues, hay tres claves candidatas
para la relacin.

Ejemplo1: Suponemos una relacin ternaria entre las entidades Profesores-CursosAsignaturas, en las que un profesor imparte en varios cursos varias asignaturas, y
adems las asignaturas son impartidas por varios profesores en varios cursos.
Transforma el esquema E-R al modelo relacional.

Ejemplo 2: Tenemos un concesionario, en el que un empleado vende muchos coches a

muchos clientes, y los coches son vendidos por un solo empleado. En la venta hay que
tener e cuenta la forma de pago y la fecha de venta.

Ejemplo 3:

Ejemplo 4: Esta interrelacin registra informacin de defensas de proyectos de fin de

carrera. Intervienen en ella el estudiante que presenta el proyecto, el proyecto
presentado y el tribunal evaluador. Si dos estudiantes presentan el mismo proyecto el
tribunal ser diferente para cada uno de ellos, es decir, cada estudiante lo defender por
separado.

Transformacin de relaciones jerrquicas:

Existen ocasiones en las que se desaconseja el uso de la primera y la segunda opcin.

Sin embargo, el uso de la tercera soluciona cualquier tipo de problema que pueda existir
entre los dos primero mtodos.

Opcin 1 (eliminar el padre e insertar en los hijos sus atributos):

HERRAMIENTA (codigo, nombre, costo)
VEHCULO(matrcula, marca, modelo, capacidad, autonoma)
INGENIERO(codigo, nombre, apellidos, email, salario, ftitulacion, capmando)
INSTALADOR(codigo, nombre, apellidos, email, salario, fcarnecond, nivelprof)
UTILIZA(codigoHerramienta*, codigoIngeniero*)
ASIGNADO(matricula*, codigoInstalador*)
Eliminar al padre, para este caso no supondra ningn problema aadido a los que se
han sealado anteriormente.

Opcin 2 (eliminar a los hijos, insertando sus atributos en el padre):

HERRAMIENTA (codigo, nombre, costo)
VEHCULO(matrcula, marca, modelo, capacidad, autonoma)
EMPLEADO(codigo, nombre, apellidos, email, salario, ftitulacion, capmando,
fcarnecond, nivelprof)
UTILIZA(codigoHerramienta*, codigoEmpleado*)
ASIGNADO(matricula*, codigoEmpleado*)
Adems de los problemas descritos anteriormente, en caso de que las claves de
Herramienta y Vehculo se propagaran a Empleado, podra darse el caso de empleados
con vehculos o con herramientas a nulo porque no les correspondan esos atributos.
Opcin 3 (establecer los hijos como entidades dbiles en identidad del padre):
HERRAMIENTA (codigo, nombre, costo)
VEHCULO(matrcula, marca, modelo, capacidad, autonoma)
EMPLEADO(codigo, nombre, apellidos, email, salario)
INGENIERO(codigoEmpleado*, ftitulacion, capmando)
INSTALADOR(codigoEmpleado*, fcarnecond, nivelprof)
UTILIZA(codigoHerramienta*, codigoIngeniero*)
ASIGNADO(matricula*, codigoInstalador*)
Esta opcin no ofrece nada ms que ventajas, sigue siendo la mejor.