Transformación MER a MR - linaSalinas/Wiki_Modelado GitHub Wiki
Usando el modelo resultante del ejemplo se explicará cómo pasar de MER a modelo relacional. Palabras clave: Llave Foránea, Llave Principal, Tupla, Relación, Dominio, Cardinalidad
MR significa Modelo Relacional, en este es donde se representan todas las relaciones que hemos encontrado hasta el momento, está regido por las Reglas de Identidad. En el MR percibimos las bases de datos como un conjunto de tablas, en este modelo cada relación y entidad está representada por una tabla, que contiene los atributos de las entidades, las relaciones y las tuplas, que son los valores correspondientes a cada atributo.
Para identificar la cardinalidad debemos tener en cuenta lo siguiente
Para identificar obligatoriedad debemos tener en cuenta
Una Entidad en MR se ve como lo muestra la imagen. P indica cual es la llave primaria, lo que esta en verde especifica el tipo de dato del atributo. Adicionalmente, en el apartado inferior indica cual es el atributo que se utiliza como llave primaria de la entidad PIZZA_PK(ID_PIZZA)
Una Relación 1:N en MR se representa como una tabla extra cuyos atributos son las llaves primarias de las entidades relacionadas, PF indica que el atributo es una llave foránea. Como podemos observar la llave primaria PEDIDO_TARJETA_PK(PEDIDO_ID_PEDIDO, TARJETA_TELEFONO) es una llave compuesta por las llaves foránes y en el ultimo apartado inferior presenta que atributos son llaves foráneas.
En el caso de las relaciones recursivas, en este ejemplo es Empleado, se puede observar que el ID del empleado es la llave principal y que hay un nuevo atributo EMPLEADO_ID_EMPLEADO que es una llave foránea la cual se agrega debido a la relación recursiva.
Para las relaciones N:M se crea una tabla como la de la siguiente imagen. Es igual a la Relación 1:N, la diferencia real esta en el código de SQL; pues una relación N:M podrá tener repetición de cualquiera de las llaves fonáreas en las tuplas, mientras que la relación 1:N solo podrá estar repetida la llave de la Entidad hacia la cual tiene 1. Pero, en ninguno de los dos casos puede existir una tupla exactamente igual; esto por las reglas de integridad.
En la "Entidad/Relación" REGISTRA se observa que tiene dos llaves foráneas que hacen referencia a Empleado y a Cliente, pero, no hay una con Pedido, esto es porque, Pedido es quien tiene la llave de Registra. Se debe modelar así, puesto que, si dejamos a Registra con las tres llaves foráneas, no será posible acceder a la información del Empleado y Cliente que corresponden a dicho Pedido desde la tabla Pedido. Nótese además, que la llave de Registra es compuesta.
Ahora en la tabla PEDIDO, puede notarse que tiene una llave foránea compuesta por las llaves de Empleado y Cliente que vienen desde la tabla Registra PEDIDO_REGISTRA_FK(REGISTRA_EMPLEADO_ID_EMPLEADO, REGISTRA_CLIENTE_TELEFONO).
MR de todas las entidades y relaciones.
