Del modelo conceptual al modelo relacional
Unidad 03. Del modelo conceptual al modelo relacional
IES Celia Viñas (Almería) - 2019/2020
1 Del modelo conceptual al modelo relacional
1.1 Entidades (Fuertes y Débiles)
Cada una de las entidades (fuertes y débiles) del diagrama E/R genera una tabla, donde cada uno de los atributos de la entidad pasa a ser una columna de la tabla.
Ejemplo:
En este ejemplo las entidades fuertes Alumno y Examen Teórico generan una tabla en el modelo relacional con las siguientes columnas.
- ALUMNO(id, nombre, apellido1, apellido2, nif, grupo)
- EXAMEN_TEÓRICO(id, título, número_preguntas, fecha)
1.2 Relaciones con cardinalidad 1:1
Las relaciones con cardinalidad 1:1 no generan una tabla, lo que haremos será que la clave primaria de una entidad pasará a formar parte de la tabla de la otra entidad, y pasará como un atributo.
La participación de cada una de las entidades será lo que nos ayude a decidir cuál será la entidad que pasará su clave primaria a la otra entidad.
Veamos los casos que pueden existir.
1.2.1 Participación (1,1)..(0,1)
Como la participación de Usuario es de (1,1) y la de Canal YouTube es de (0,1), la clave primaria de Usuario se almacena en la tabla de Canal YouTube como un atributo. Se dice que el atributo id_usuario que se añade en la tabla Canal_YouTube es una clave ajena o foreign key (FK) de la tabla Usuario.
Las tablas del modelo relacional quedarían así:
- USUARIO(id, email, password, nombre, apellido1, apellido2)
- CANAL_YOUTUBE(id, nombre, descripción, fecha_creación, id_usuario)
1.2.2 Participación (1,1)..(1,1)
En este caso, como la participación de las dos entidades es de (1,1) podemos resolverlo de tres formas.
- La clave primaria de Presidente se almacena en la tabla País como un atributo (id_presidente). Se dice que id_presidente es una clave ajena o foreign key (FK) de la tabla Presidente.
- PRESIDENTE(id, nombre, apellido1, apellido2)
- PAÍS(id, nombre, id_presidente)
- La clave primaria de País se almacena en la tabla Presidente como un atributo (id_pais). Se dice que id_pais es una clave ajena o foreign key (FK) de la tabla País.
- PRESIDENTE(id, nombre, apellido1, apellido2, id_país)
- PAÍS(id, nombre)
- Las claves primarias de ambas entidades se guardan en la tabla de la otra entidad. Es decir, la tabla Presidente guardaría la clave primaria de País y la tabla País guardaría también la clave primaria de Presidente. Esta solución puede presentar redundancia, pero puede ser interesante en algunas ocasiones, dependiendo de las consultas que se vayan a realizar sobre estas tablas a nivel de aplicación. En este caso los atributos id_país y id_presidente serían claves_ajenas o foreign key (FK).
- PRESIDENTE(id, nombre, apellido1, apellido2, id_país)
- PAÍS(id, nombre, id_presidente)
1.2.3 Relaciones reflexivas con cardinalidad 1:1
En este caso la clave primaria se almacena en la misma tabla como un nuevo atributo.
La tabla Alquiler vuelve a guardar su clave primaria como atributo haciendo referencia al id del alquiler que está renovando, le llamaremos id_alquiler_anterior.
Como la participación es de (0,1) pueden existir casos donde este nuevo atributo sea nulo, esto quiere decir que ese alquiler no es una renovación de ningún alquiler anterior.
El atributo id_alquiler_anterior será una clave_ajena o foreign key (FK) de la tabla Alquiler.
- ALQUILER(id, fecha_inicio, fecha_fin, importe, fianza, id_alquiler_anterior)
1.3 Relaciones con cardinalidad 1:N
Las relaciones con cardinalidad 1:N no generan una tabla, lo que haremos será que la clave primaria de la entidad que participa con cardinalidad 1 pasará a formar parte de la tabla de entidad que participa con cardinalidad N, y además pasará como un atributo.
Ejemplo:
En este caso la clave primaria de la entidad que participa en la relación con cardinalidad 1 se guarda en la tabla de la entidad que participa con cardinalidad N.
- USUSARIO(id, email, password, nombre, apellido1, apellido2)
- VÍDEO(id, nombre, descripción, duración, id_usuario)
1.3.1 Relaciones reflexivas con cardinalidad 1:N
En este caso la clave primaria se almacena en la misma tabla como atributo.
La tabla Empleado vuelve a guardar su clave primaria como atributo haciendo referencia al id del jefe, le llamaremos id_jefe.
- EMPLEADO(id, nombre, apellido1, apellido2, id_jefe)
1.4 Relaciones con cardinalidad N:N
Las relaciones con cardinalidad N:N son las únicas que van a generar una nueva tabla.
Ejemplo:
En este caso se crea una nueva tabla donde se almacenan las claves primarias de las dos entidades que participan en la relación. Las claves primarias de las entidades también serán claves primarias de la nueva tabla. Si la relación contiene algún atributo, se deberán añadir a la nueva tabla.
- ALUMNO(id, nombre, apellido1, apellido2, nif, grupo)
- EXAMEN_TEÓRICO(id, título, número_preguntas, fecha)
- ALUMNO_HACE_EXAMEN_TEÓRICO(id_alumno, id_examen, nota)
1.4.1 Relaciones reflexivas con cardinalidad N:N
En este caso tendremos dos tablas en el modelo relacional:
- VÍDEO(id, título, descripción, reproducciones)
- VÍDEOS_RELACIONADOS(id_video, id_video_relacionado)
1.5 Relaciones grado 3
1.5.1 Cardinalidad N:N:N
Creamos una tabla. Las tres claves participan como claves primarias.
1.5.2 Cardinalidad 1:N:N
Creamos una tabla. Sólo las claves que participan como N participan como clave primaria.
1.5.3 Cardinalidad 1:1:N
No es necesario crear tabla. La entidad que participa como N recibe las claves de las dos entidades que participan como 1.
1.6 Generalización y Especialización (Relaciones ISA)
Existen varias soluciones para realizar el el paso a tablas de una especialización. La solución que se elija en cada caso dependerá del tipo de especialización que estemos resolviendo: total, parcial, inclusiva o exclusiva.
Las 3 soluciones posibles que podemos aplicar son las siguientes:
Crear una tabla para cada una de las entidades, tanto para la superclase como las subclases. En este caso las subclases tendrían que guardar la clave de la primaria de la superclase.
Crear una tabla sólo para las subclases. En este caso los atributos de la superclase habría que guardarlos en cada una de las subclases.
Crear una única tabla para la superclase. En este caso todos los atributos de las subclases se guardarían en la superclase.
Ejemplo de especialización exclusiva/total
En este caso sería adecuado utilizar la solución 1 o 2. También sería posible utilizar la solución 3, pero al tratarse de una especialización exlusiva, tendríamos muchas columnas con valores NULL.
Solución 1: Crear una tabla para cada una de las entidades.
VÍDEO(id, título, sinopsis, imagen, archivo_vídeo, duración, tipo)
- EPISODIO(id, temporada, número)
- id: FK de VÍDEO(id)
- PELÍCULA(id, puntuación_imdb, director)
- id: FK de VÍDEO(id)
Solución 2: Crear una tabla sólo para las subclases.
EPISODIO(id, título, sinopsis, imagen, archivo_vídeo, duración temporada, número)
PELÍCULA(id, título, sinopsis, imagen, archivo_vídeo, duración puntuación_imdb, director)
Ejemplo de especialización inclusiva/total
En este caso sería adecuado utilizar la solución 3. Aunque también sería posible utilizar la solución 1 o 2.
Solución 3. Crear una única tabla para la superclase.
- LIBRO(id, título, isbn, año_publicación, descripción, tipo, lugar_impresión, fecha_impresión, precio_papel, tamaño_archivo, precio_ebook)
2 Licencia
El contenido de esta web está bajo una licencia de Creative Commons Reconocimiento-NoComercial-CompartirIgual 4.0 Internacional.
Comentarios
Publicar un comentario