REGLAS TRANSFORMACIONMODELO CONCEPTUAL A MODELO LOGICO

MODELO ENTIDAD-INTERRELACIÓN ------> MODELO RELACIONAL

En este documento se resumirán las diferentes reglas a aplicar para convertirun modelo Entidad-Interrelación a modelo Relacional. Para ello usaremoscomo ejemplo un sencillo caso de gestión bibliotecaria en la que podemosencontrar todos los tipos de elementos (entidades, entidades débiles,relaciones, atributos y jerarquías) así como las diferentes cardinalidades ycorrespondencias.

Para cada ejemplo se mencionará el elemento con su nomenclatura en elmodelo E-I y seguido se detallará la cabecera de ese elemento en el modelorelacional.

• 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 dosrestricciones: unique y not-null.

• 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 estosaparecerí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 solouna 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 tuvierala relación.

◦ Correspondencia 1:1.En este tipo de correspondencias, aunque en este ejemplo no se da, laclave también se propaga como en el caso anterior. Si las cardinalidadesson (1,1) y (1,1) es indiferente la que se propaga y habrá que a lasemántica para saber cual se propaga. Ejemplo: Relación entrenador-equipo, si suponemos que un equipo siempre tiene un entrenador y unentrenador siempre un equipo decidiríamos propagar la idEntrenador a latabla Equipos por simple semántica (en una competición son másrelevantes los equipos que los entrenadores). Sin embargo si lascardinalidades son (1,0) y (1,1), caso de que supongamos que unentrenador puede no tener equipo, está claro que se propaga laidEntrenador al Equipo.

• Atributos:Son las columnas de las tablas. Ej: id, nombre, grupo (refiriéndonos a unatabla de Alumnos). En todos los ejemplos anteriores aparecían enceradosentre paréntesis ().El atributo identificador principal pasa a ser clave primaria y el atributoidentificador alternativo pasa a ser clave candidata, que sabemos tieneque 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 estecaso con "create domain values sexo: 1DAW / 2DAW / 1ASIR /2ASIR" llevaríamos a modelo relacional el atributo multivaluado dela entidad Alumnos de la jerarquía. Se suele aplicar para atributoscon dominios pequeños (pocos valores, como por ejemplo notas dealumnos, entre 1 y 10), dominios booleanos (si/no),

2. O bien, crear una tabla con el LDD. Tabla de solo lectura quecontendrá todos los valores posibles para ese atributo multivaluado.Por ejemplo la tabla "Ciclos" con el atributo ciclo y en grupos unaforeign key que apunte a ciclos (la fk puede ser en lugar de unacadena de caracteres, como 1DAW, el idCiclo, de esta manera esmás fácil de operar con ellos). Es la opción más recomendable paratodos 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 unatributo simple), o se trabajaría con cuatro simples.

◦ Derivados: se calculan a partir de otros, es decir, el sistema calculala información que guarda este atributo a partir de la información deotros 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 pky 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

tipo. Optándose así por incluir un atributo discriminador (tabla Lector con idcomo 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).