Este documento detalla las reglas para transformar un modelo entidad-interrelación (e-i) en un modelo relacional, usando un ejemplo de gestión bibliotecaria para ilustrar la conversión de entidades, relaciones y atributos. Se explican las tablas que se crean para entidades y relaciones, así como el tratamiento de atributos multivaluados, compuestos y jerárquicos. Asimismo, se abordan las entidades débiles y su correspondencia con las relaciones dentro del modelo.

1. REGLAS TRANSFORMACION
MODELO CONCEPTUAL A MODELO LOGICO
MODELO ENTIDAD-INTERRELACIÓN ------> MODELO RELACIONAL
En este documento se resumirán las diferentes reglas a aplicar para convertir
un modelo Entidad-Interrelación a modelo Relacional. Para ello usaremos
como ejemplo un sencillo caso de gestión bibliotecaria en la que podemos
encontrar todos los tipos de elementos (entidades, entidades débiles,
relaciones, atributos y jerarquías) así como las diferentes cardinalidades y
correspondencias.
Para cada ejemplo se mencionará el elemento con su nomenclatura en el
modelo E-I y seguido se detallará la cabecera de ese elemento en el modelo
relacional.
• Entidades:
Se crea una tabla por cada entidad del modelo E-I.
Ejemplo:
Entidad “Autores” – Tabla → Autores (id(pk), nombre). Si hubiera otro
atributo como el NIF, este sería clave candidata porque lleva asociada dos
restricciones: unique y not-null.

2. • Relaciones:
◦ Correspondencia N:M.
Ejemplo:
Relación Libros-Autores – Tabla → RLA (idLibros,idAutores(pk)).
Ambos son primary key (pk en adelante) de la tabla siendo cada una por
individual foreign key (fk en adelante). Si la relación tuviera atributos estos
aparecerían también mencionados en esa cabecera.
◦ Correspondencia 1:N.
Ejemplo:
Relación Editorial-Libros – Tabla → Libros (idLibros,idEditorial(fk-apunta
Editorial), título, páginas). Propagación de clave: un libro pertenece a solo
una editorial, por lo que la clave que se propaga es el 1, no el n. Así en la
tabla Libros se añade otra clave llamada idEditorial, que a su vez es una
fk que apunta a Editorial. También se propagarían los atributos que tuviera
la relación.
◦ Correspondencia 1:1.
En este tipo de correspondencias, aunque en este ejemplo no se da, la
clave también se propaga como en el caso anterior. Si las cardinalidades
son (1,1) y (1,1) es indiferente la que se propaga y habrá que a la
semántica para saber cual se propaga. Ejemplo: Relación entrenador-
equipo, si suponemos que un equipo siempre tiene un entrenador y un
entrenador siempre un equipo decidiríamos propagar la idEntrenador a la
tabla Equipos por simple semántica (en una competición son más
relevantes los equipos que los entrenadores). Sin embargo si las
cardinalidades son (1,0) y (1,1), caso de que supongamos que un
entrenador puede no tener equipo, está claro que se propaga la
idEntrenador al Equipo.
• Atributos:
Son las columnas de las tablas. Ej: id, nombre, grupo (refiriéndonos a una
tabla de Alumnos). En todos los ejemplos anteriores aparecían encerados
entre paréntesis ().
El atributo identificador principal pasa a ser clave primaria y el atributo
identificador alternativo pasa a ser clave candidata, que sabemos tiene
que ser not-null y unique.
Los atributos en el modelo E-I pueden ser:
◦ Multivaluados: en la conversión hay dos posibilidades.
1. Puede pasar a ser un atributo con restricción de dominio. En este
caso con "create domain values sexo: 1DAW / 2DAW / 1ASIR /
2ASIR" llevaríamos a modelo relacional el atributo multivaluado de
la entidad Alumnos de la jerarquía. Se suele aplicar para atributos
con dominios pequeños (pocos valores, como por ejemplo notas de
alumnos, entre 1 y 10), dominios booleanos (si/no),

3. 2. O bien, crear una tabla con el LDD. Tabla de solo lectura que
contendrá todos los valores posibles para ese atributo multivaluado.
Por ejemplo la tabla "Ciclos" con el atributo ciclo y en grupos una
foreign key que apunte a ciclos (la fk puede ser en lugar de una
cadena de caracteres, como 1DAW, el idCiclo, de esta manera es
más fácil de operar con ellos). Es la opción más recomendable para
todos aquellos casos no comentados en el punto anterior.
◦ Compuestos: O se transforman en uno solo (convirtiendo entidad,
sucursal, DC, y nº cuenta a simplemente cuenta bancaria como un
atributo simple), o se trabajaría con cuatro simples.
◦ Derivados: se calculan a partir de otros, es decir, el sistema calcula
la información que guarda este atributo a partir de la información de
otros atributos.
• Jerarquías:
Caso de lectores (con id, nombre, tfno, y mail) jerarquizados en alumnos y
profesores.
1. Caso genérico:
• Se hace una tabla para el supertipo (lectores) con su id como pk.
• Otra para los subtipos, en este caso alumnos con su id como fk, que
apunta a la pk de la tabla supertipo; y profesores, también con su id
como fk apuntando a la del supertipo.
2. Caso que el atributo identificador primaria en la E-I de los subtipos
no coincide con el del supertipo, es decir el id de alumnos es el NIE,
y el de los profesores es el NRP (Nuestro caso):
• Se crea una tabla lectores con id como pk.
• Se crea una tabla para alumnos con NIE como pk, e idLector como
fk apuntando a la id de Lectores.
• Se crea una tabla para profesores con NRP como pk, e idLector
como fk apuntando a la id de Lectores.
Ejemplo:
Tabla → Lectores (idLector(pk), nombre, tfno, mail).
Tabla → Alumnos (NIE(pk), idLector(fk-apunta supertipo),
grupo).
Tabla → Profesores (NRP(pk), idLector(fk-apunta supertipo)).
Supongamos que en el modelo E-I no existe ninguna relación con otra
entidad aparte de con sus subtipos, en ese caso no se crea tabla del
supertipo, y los atributos de este lo heredan las tablas subtipos (tabla
Alumnos con NIE como pk y nombre; y tabla Profesores con NRP como pk
y nombre.
Otra posibilidad es que los subtipos no tengan atributos ni relaciones
distintas a las que tienen con el supertipo, Seria el caso de deshacer la
jerarquía en el modelo E-I y convertir esa info en un atributo más de la
entidad supertipo quedando así una tabla Lector con id como pk, nombre y

4. tipo. Optándose así por incluir un atributo discriminador (tabla Lector con id
como pk, nombre, y tipo que es una foreign key que apunta a otra tabla
llamada TipoLector con tipo como pk).
• Entidades débiles:
◦ Por existencia:
Se tratan igual que las relaciones 1:N.
◦ Por identificación:
Relación Libros-Ejemplar – Tabla → Ejemplar (idEjemplar,idLibro(fk-
apunta a Libro), N_registro, estanteria, estado).