Home Bases de Datos El Modelo Relacional Transformación del modelo entidad-relación extendido al modelo relacional

PostHeaderIcon Transformación del modelo entidad-relación extendido al modelo relacional

Usar puntuación: / 10
MaloBueno 

En el capítulo anterior hemos visto la transformación del modelo entidad-relación básico en el modelo relacional. En él estuvimos trabajando los elementos principales del modelo entidad-relación. Sin embargo quedaron algunos aspectos pendientes del mismo, aquellos que son considerados dentro del modelo entidad-relación extendido.

Para trabajar con ellos debemos tener en cuenta varios aspectos. En primer lugar que no siempre se puede establecer una correspondencia directa entre el modelo entidad-relación y el modelo relacion. Esto se debe a que el modelo entidad-relación es un modelo conceptual, por decirlo de alguna manera, es un modelo teórico, por lo que a la hora de implementarlo pueden haber aspectos que no los recoja el Sistema Gestor de Bases de Datos que es quién en el fondo va a sostener los datos. Por otro lado hay que tener en cuenta que una base de datos podemos complicarla tanto como queramos, pero al final va a estar almacenada en un medio de almacenamiento físico, con lo que conviene simplificar el diseño de la base de datos aunque con ello compliquemos la labor de las aplicaciones que accederán a ella. 

Vamos a empezar con las relaciones reflexivas. Recordemos que eran aquellas en las que una entidad tenía una relación consigo misma. En el fondo no difiere mucho de lo visto hasta ahora. La entidad en sí genera una tabla. Si la relación es M:N ó la participación es obligatoria (ver cuadro de equivalencias) generará otra tabla mientras que si la relación no es M:M o la participación en la relación no es obligatoria agregaremos la clave principal a la misma tabla.

Veamos un primer ejemplo:

Como no se trata de una relación obligatoria creamos dos tablas

EMPLEADOS:{(COD.EMP: numérico), (NOMBRE: texto)}

PAREJA:{(EMPLEADO1: Numérico),(EMPLEADO2: Numérico)}

PAREJA  --> EMPLEADO1 --> EMPLEADOS

PAREJA  --> EMPLEADO2 --> EMPLEADOS

Veamos otro ejemplo:

Se trata de una relación 1:M en la que la relación es obligatoria: todos los alumnos tienen un delegado (podemos asumir que los delegados son delegados de sí mismos también)

Bastaría con una única tabla:

ALUMNOS:{(DNI: Numérico),(NOMBRE: Texto),(DELEGADO: Numérico)}

ALUMNOS --> DELEGADO --> ALUMNOS

Otro ejemplo: Controlamos las luchas correspondientes entre los luchadores

Al tratarse de una relación M:M se construye una nueva tabla

LUCHADORES: {(FICHA: Numérico),(NOMBRE: Texto)}

LUCHAN{_CP____(LUCHADOR1:Numérico),(LUCHADOR2: Numérico)____CP_}

Ejercicios propuestos: Ver solución

  • Consideremos la relación Empleado-Dirige-Empleado de forma que un empleado puede dirigir a varios empleados pero solo puede ser dirigido por uno (director) o por ninguno si él es el director:

  • Queremos informatizar los proyectos de una empresa. Una encuadernación puede ser índice de muchas encuadernaciones, pero solo puede tener un índice. Además pueden existir índices de índices.

Consideremos la relación: una pieza se puede componer de muchas piezas y a su vez estar compuesta por muchas piezas.

Supongamos la relación entre proyectos de una empresa. Un proyecto puede estar compuesto de muchos proyectos y a su vez cada proyecto puede formar parte de varios proyectos.

A continuación vamos a ver como convertir una Generalización o jerarquías del modelo entidad-relación 

  •  

En el modelo relacional no existe el concepto de jerarquía, por lo que no existe ninguna forma de expresarla tal cual está concebida. En su lugar, lo que haremos será buscar la manera de transformarla en algún otro tipo de relación. Hay que tener en cuenta los siguientes aspectos antes de transformarla:

  • Subtipos y supertipos.
  • Especialización total-parcial exclusiva y total- parcial solapada.
  • Forma de acceso a la información.

Las soluciones que se proponen son las siguientes:

Integrar todas las entidades en una única (eliminar subtipos). Se mantienen las relaciones. La nueva relación tendrá todos los atributos del tipo y de los subtipos.

Eliminación del supertipo transfiriendo los atributos del tipo a los subtipos. Sólo para jerarquías totales y exclusivas. Este método tiene dos limitaciones:
  • Redundancia de datos (es decir que un dato puede aparecer más de una vez).
  • Aumenta el número de relaciones.
Insertar una relación 1:1 entre tipos y subtipos.

Ejemplo 11:

  • Consideremos los profesores que imparten clases en dos tipos de centros: públicos y privados. Un profesor puede impartir clase en varios centros, ya sean públicos o privados. Consideramos la asignatura como atributo de la relación entre profesor imparte en el centro. Los centros solo pueden ser de estos dos tipos y no pueden ser de los dos a la vez. De los centros públicos interesa saber el presupuesto y los servicios y de los privados la organización y la cuota.

Se ve claramente como se trata de una jerarquía de los centros dividiéndose entre públicos y privados. Sin embargo, la alternativa propuesta es la siguiente

Modelo Entidad-Relación:

PROFESORES :{(NOMBRE: texto), (COD_PROFESORES: numérico)}

CENTRO PÚBLICO :{(NOMBRE: texto), (COD_CPUBLICO: numérico)}

CENTRO PRIVADO :{(NOMBRE: texto), (COD_CPRIVADO: numérico)}

IMPARTE_PÚBLICO: {_CP____(PROF: Numérico),(C_PUBL: Numérico)____CP_,(ASIGNATURA: Texto)}

IMPARTE_PRIVADO: {_CP____(PROF: Numérico),(C_PRIV: Numérico)____CP_,(ASIGNATURA: Texto)}

IMPARTE_PÚBLICO --> PROF --> PROFESORES

IMPARTE_PÚBLICO --> C_PUBL --> CENTRO_PÚBLICO

IMPARTE_PRIVADO --> PROF --> PROFESORES

IMPARTE_PRIVADO --> C_PRIV --> CENTRO_PRIVADO

Vamos a ver ahora las relaciones n-arias, que eran aquellas en las que participan más de dos entidades. Si la relación es 1:1:1 ó 1:1:M se podría agregar las claves principales de las participantes en 1 en la de muchos. En mi opinión personal, esto complica la base de datos, por lo que no lo recomiendo. Yo recomiendo la creación siempre de una nueva tabla. De todas formas veremos los casos. Cada entidad será una tabla y la relación hemos visto que otra. Las claves principales de la nueva tabla sería la siguiente:

M: M: M: si todas las entidades participan con una cardinalidad de muchos, la clave de la tabla que queda como resultado es la unión de las claves de las entidades que la relaciona.

1:M:M: Si hay una de las entidades que participa con 1, la clave primaria será la combinación de las claves de las dos entidades que participan con M.

1:1:M: Si hay una única relación que participa con muchas  podemos propagar la clave principal de las entidades que participan con 1 en la que participa con M siempre que la participación sea obligatoria. En caso contrario se creará una nueva tabla. 

1:1:1: Si todas participan con 1 la propuesta es la misma que la anterior: Propagar si la participación es obligatoria o crear una nueva tabla si no lo es.

Veamos un ejemplo

Suponemos una relación ternaria entre Profesores- Cursos- Asignaturas en la que un profesor imparte en varios cursos varias asignaturas y pueden haber asignaturas impartidas por más de un profesor en varios cursos.

Modelo Entidad- Relación:

Modelo Relacional:

PROFESORES :{(NOMBRE: texto), (COD_PROFESOR: numérico)}

ASIGNATURAS :{(NOMBRE: texto), (COD_ASIGNATURA: numérico)}

CURSOS :{(NOMBRE: texto), (DESCRIPCIÓN: texto), (COD_CURSOS: numérico)}

RELACIÓN :{_CP____(CA_COD_PROFESOR: numérico), (CA_COD_ASIGNATURA: numérico), (CA_COD_CURSOS: numérico)____CP_}

RELACIÓN --> CA_COD_PROFESOR --> PROFESORES

RELACIÓN --> CA_COD_ASIGNATURA --> ASIGNATURAS

RELACIÓN --> CA_COD_CURSOS  --> CURSOS  

Veamos otro ejemplo

Una tienda de coches en la que un empleado puede vender muchos coches a varios clientes pero los coches solo son vendidos por un empleado. En la venta hay que tener en cuenta la forma de pago y la fecha. Realizar modelo entidad/relación y modelo relacional

Modelo Relacional:

A continuación exponemos el modelo Relacional.

COCHES :{(COD.C: numérico), (MARCA: texto), (MODELO:texto)}

CLIENTES :{(COD.CLIENTES: numérico), (NOMBRE: texto)}

EMPLEADO :{(COD.E: numérico), (NOMBRE_EM: texto)}

VENDE :{_CP____(C.A.COD.: numérico), (C.A.COD.CLIENTES: numérico)____CP_, (C.A.COD.E: numérico), (PAGO: texto), (FECHA: fecha)}

VENDE --> C.A.COD.C --> COCHES

VENDE --> C.A.COD.CLIENTES --> CLIENTES

VENDE --> C.A.COD.E --> EMPLEADOS

Veamos otro ejemplo—

 Un equipo de fútbol participa en una o varias ligas con varios jugadores. Un jugador no puede participar en dos ligas. En la Base de Datos no hay jugadores sin equipo y por tanto sin liga. Realizar modelo entidad/relación y modelo relacional.

Modelo Entidad-Relación:

Modelo Relacional:

Aquí a continuación expondremos como en todos los ejemplos anteriores el modelo relacional basado en el modelo Entidad-Relación.

E.D.F. :{(COD.E.D.F.: numérico), (NOMBRE: texto), (PAÍS: texto)}

LIGAS :{(COD.LIGA: numérico), (NOMBRE_L: texto)}

JUGADORES :{_CP____(COD.JUGADOR: texto)____CP_, (NOMBRE_J: texto), (C.A.COD.E.D.F.: numérico), (C.A.COD.LIGAS: numérico)}

JUGADORES --> C.A.COD.E.D.F. --> E.D.F.

JUGADORES --> C.A.COD.LIGAS --> LIGAS

Pérdida de semántica en la transformación:

Como se comentó antes, el modelo entidad-relación es un modelo conceptual, que en la práctica solo se usa para definir y aclarar el esqueleto de la base de datos, pero su aplicación práctica depende del SGBD que usemos. Por ello algunas restricciones son necesarias controlarlas con mecanismos externos al modelo relacional, dado que muchos SGBD no implementan el modelo relacional completo y ninguna el modelo entidad-relación. Los mecanismos CHECK y ASSERTION no suelen estar disponibles en todos los SGBD, por lo que hay que recurrir a otros medios como pueden ser disparadores, procedimientos almacenados o aplicaciones externas.

Además con respecto al modelo entidad-relación hay algunas pérdidas:

  • Cardinalidades mínimas de 1 en relaciones M:M y 1:M.
  • Cardinalidades máximas conocidas en relaciones binarias M:M y 1:M y relaciones ternarias.
  • Exclusividad en las generalizaciones.
  • Inserciones y borrado en las generalizaciones.
  • Restricciones que no figuran en el enunciado original, pero que puedan ser adecuadas o convenientes.

El modelo relacional es un modelo conceptual que nos puede ayudar (en mi opinión mucho) a la creación de la base de datos como primer paso, para en un segundo momento crear el modelo relacional. Sin embargo, la simple creación del modelo relacional no nos asegura una completitud y optimización del diseño. Podemos encontrarnos en el caso en que es más sencillo intentar crear el modelo relacional directamente sin pasar previamente por el modelo entidad--relación. Si se nos diera este caso es más que probable que la base de datos creada sea bastante ineficiente y que el trabajo con ella nos lleve a situaciones no deseables y que intenta evitar el modelo relacional, tales como la complicación de las inserciones o la aparición de la redundancia. Para evitar estas situaciones que chocan con la intención del modelo relacional el mecanismo que se utiliza es el que veremos en el siguiente artículo: las normalizaciones

 

 

Comentarios   

 
0 #4 Administrator 26-09-2017 08:12
Cito a julinspi:
en el ejemplo de los equipos en la relacion jugador, el codigo de liga no debe pertenecer a la llave ...


Depende del caso. En este caso hablamos de una relación ternaria, en la que un jugador participa en una liga con un equipo, pudiendo participar en la liga siguiente con el mismo equipo u otro. Por tanto hay que diferencia entre la participación en una liga u otra.

Saludos
Citar
 
 
0 #3 julinspi 25-03-2017 16:37
en el ejemplo de los equipos en la relacion jugador, el codigo de liga no debe pertenecer a la llave ...
Citar
 
 
+1 #2 Administrator 07-02-2017 11:18
Cito a Sevilla:
Hola:

En el artículo se explica como pasar el MER al MR, pero falta explicar (como dice en el título) como convertir el modelo relacional extendido al modelo relacional.

Un saludo.

El MER extendido es el modelo Entidad Relación con los elementos que se ven aquí: Jerarquías o generalizacione s, relaciones n-arias y relaciones unarias. En todo caso, como se explica en el artículo, el pasar de un modelo teórico a uno práctico se pierde semántica
Te invito a ser más concreto en tu pregunta
Gracias y un saludo
Citar
 
 
0 #1 Sevilla 06-02-2017 20:39
Hola:

En el artículo se explica como pasar el MER al MR, pero falta explicar (como dice en el título) como convertir el modelo relacional extendido al modelo relacional.

Un saludo.
Citar
 

Escribir un comentario


Código de seguridad
Refescar

PostHeaderIcon Más Comentado

PostHeaderIcon Últimos Comentarios

mod_vvisit_countermod_vvisit_countermod_vvisit_countermod_vvisit_countermod_vvisit_countermod_vvisit_countermod_vvisit_counter
mod_vvisit_counterHoy1495
mod_vvisit_counterAyer1493
mod_vvisit_counterEsta semana10794
mod_vvisit_counterLa semana pasada10142
mod_vvisit_counterEste mes27352
mod_vvisit_counterEl mes pasado44972
mod_vvisit_counterTodos los días1432922

We have: 153 guests online
Hoy es: Dic 16, 2017