Transformar un E-R a modelo relacional

Principios de transformación.

La transformación de un diagrama E/R al Modelo Relacional está basado en los siguientes principios:

• Toda entidad se convierte en una relación (tabla).
• Toda interrelación (relación) N:M se transforma en una relación (tabla)
• Toda interrelación (relación) 1:N se traduce en el fenómeno de “propagación de clave” (se crea una clave ajena).

Después de analizar los principios anteriores podemos pensar que en el paso del diseño conceptual(diagrama ER) al diseño lógico (esquema relacional) se pierde información semántica, ya que tanto las entidades como las relaciones se transforman en tablas, sin que haya una diferencia entre las tablas que provienen de entidades y las que provienen de relaciones. Pero la realidad es diferente, ya que gracias a la definición de las restricciones de integridad necesarias, nos aseguramos la conservación de la integridad de la base de datos, es decir que toda la semántica del universo del discurso quede reflejada en el esquema relacional.

Transformación de las Entidades

Cada entidad que aparezca en el diagrama E/R se convierte en una tabla.

• Transformación de Entidades Débiles.

Las entidades débiles se transforman en una tabla, propagando la clave de la entidad fuerte, que pasa a formar parte de la clave primaria de la entidad débil.

Transformación de los Atributos de las entidades

Cada atributo de una entidad se transforma en una columna en la relación a la que ha dado lugar la

entidad. 

• El, o los atributos principales de una entidad (es decir, la clave primaria de la entidad) pasan a ser la clave primaria de la relación. Se debe especificar que no son nulos.
• El resto de atributos pasan a ser columnas de la tabla, pudiendo tomar valores nulos, a no ser que se indique lo contrario por restricciones de nuestro sistema de información.

Transformación de Atributos Compuestos

El modelo relacional no permite representar atributos compuestos, por lo que se busca una alternativa,

como:

• Considerar el atributo compuesto como un atributo simple.
• Eliminar el atributo compuesto y considerar cada uno de sus atributos como atributo simple de la entidad.

Transformación de las relaciones (interrelaciones)

Dependiendo del tipo de relación y de la cardinalidad que tenga, existen diversas maneras de transformarlas:

• Relaciones N:M. Se crea una nueva tabla que incluye los atributos de la propia relación (si los tuviera) y las claves primarias de las dos entidades, que forman la clave primaria de la nueva relación.
• Relaciones 1:N. Estas interrelaciones se pueden transformar de dos maneras diferentes:
• Propagar la clave principal de la entidad que tiene cardinalidad máxima 1 a la que tiene N, y hacer desaparecer la tabla de la relación como tal.
• Transformarla en una nueva tabla como si fuese de una relación de tipo N:M, es decir, incluyendo los atributos de la relación y las claves primarias de las dos entidades.Esta acción es recomendable sólo:cuando es posible que aparezcan muchos nulos porque existen pocos elementos relacionados,o cuando se preveé que dicha relación pasará en un futuro a ser de tipo N:M, o cuando la relación tiene atributos propios.Cuando la cardinalidad mínima de la entidad uno es igual a uno, se suele utilizar la primera opción. En cambio si la cardinalidad mínima fuera cero, se suele utilizar la segunda opción.
• Relaciones 1:1. Este es un caso particular de cualquiera de los dos anteriores, por lo que se podrían aplicar las reglas ya mencionadas. De todas formas es recomendable tener en cuenta las siguientes consideraciones:
• Si la relación es entre entidades con cardinalidades (0,1) y (0,1), es mejor crear una relación para evitar tener muchos nulos como propagación de alguna de las claves a la otra.
• Si la relación es entre entidades con cardinalidades (0,1) y (1,1), es mejor propagar la clave de la entidad (1,1) a la (0,1).
• Si la relación es entre entidades con cardinalidades (1,1) y (1,1), la propagación es indiferente, y se hará atendiendo a los criterios de frecuencia de acceso (consulta, modificación, inserción, etc.) a cada una de las tablas en cuestión.

Transformación de los atributos de relaciones

Si la relación se transforma en una tabla, todos sus atributos pasan a ser columnas de la tabla. En el caso en que alguno de los atributos de la relación sea clave primaria, deberá ser incluido como parte de la clave primaria en dicha tabla.

Transformación de relaciones exclusivas

Para soportar relaciones exclusivas debemos definir las restricciones pertinentes en cada caso. Por ejemplo, en el caso en que exista una exclusividad en la edición de un libro por parte de una editorial o de una universidad, estas dos relaciones se resuelven mediante el mecanismo de propagación de la clave, llevando las claves primarias de editorial y universidad a libro.

Transformación de relaciones ternarias (grado 3)

• Relaciones muchos a muchos a muchos: Este tipo de relación se transforma en una tabla cuya clave primaria es la concatenación de las claves primarias de las tablas surgidas al transformar las entidades que forman parte de la relación. Junto a estos atributos se incluyen los atributos propios de la relación. Cada uno de los atributos que forman la clave primaria de esta tabla son a la vez claves ajenas respecto a cada una de las tablas donde dicho atributo es clave primaria.
• Relaciones muchos a muchos a uno: Este tipo de relación se transforma en una tabla cuya clave primaria es la concatenación de las claves primarias de las tablas que corresponden a la cardinalidad M surgidas al transformar las entidades que forman parte de la relación. Junto a estos atributos se incluyen los atributos propios de la relación más la clave primaria de la tabla que corresponde a la cardinalidad 1. Cada uno de los atributos que forman la clave primaria de esta tabla (y los atributos añadidos de la relación de cardinalidad 1) son claves ajenas respecto a cada una de las tablas donde dicho atributo es clave primaria.

Transformación de la generalización (tipos y subtipos)

Los tipos y subtipos no son objetos que se puedan representar en el modelo relacional estándar.

Existen pues, varias posibilidades para su transformación:

• Englobar todos los atributos de una entidad y sus subtipos en una sola tabla, añadiendo el atributo que permite distinguir los subtipos. También habrá que especificar las restricciones semánticas adecuadas.
• Crear una tabla para el supertipo, y tantas tablas como subtipos existan. Ésta es la mejor opción desde el punto de vista semántico, pero es menos eficiente que la opción anterior.
• Crear sólo tablas para los subtipos, añadiendo en cada una de ellas los atributos pertenecientes al supertipo. Habitualmente ésta es la opción más utilizada.

Transformación de la agregación

Se trata de transformar primero el nivel más alto de la agregación (aplicando las reglas adecuadas) y trataremos la relación resultante como si fuera “una nueva entidad a relacionar” con el nivel más bajo (aplicando las normas anteriores).

¿Qué es el modelo relacional?

Es un modelo propuesto por Codd donde los datos se estructuran lógicamente en forma de relaciones. Éste presentaba los siguientes objetivos:

• Independencia física: El modo en el que se almacenan los datos no debe influir en su manipulación lógica y es así que los usuarios que acceden a los datos no han de modificar sus programas por cambios en el almacenamiento físico.
• Independencia lógica: Añadir, eliminar o modificar cualquier elemento de la base de datos no debe repercutir en los programas y usuarios que están accediendo a los subconjuntos parciales de los mismos. 
• Flexibilidad: Poder ofrecer a cada usuario los datos de la forma más adecuada a su aplicación.
• Uniformidad: Las estructuras lógicas de los datos presentan un aspecto uniforme, lo que facilita la concepción y la manipulación de la base de datos por parte de los usuarios. 
• Sencillez.

La relación es el elemento básico de este modelo y se representa como una tabla. 

En esta imagen podemos apreciar que cada tabla posee diversos atributos de un objeto con su respectivo nombre. Las columnas son atributos y las filas se denominan tuplas, que contienen los valores que toma cada uno de los atributos para cada elemento. 

Un dominio es un conjunto finito de valores homogéneos y atómicos caracterizado por un nombre. Los valores son homogéneos porque son todos del mismo tipo y atómicos porque son indivisibles en el modelo, pues si se descomponen pierden la semántica asociada a los mismos. 

Un valor nulo es una señal utilizada para representar información desconocida, inaplicable, inexistente, no válida, etc. Su necesidad en las bases de datos es evidente por diversas razones, como para crear tuplas con atributos desconocidos o añadir un nuevo atributo a una relación existente.

En este modelo están las llaves relacionales. Existen las llaves primarias y foráneas. 

• Llaves primarias:
• Llave: Atributo o conjunto de atributos cuyo valor es único y diferente para cada tupla.
• Llave compuesta: es una llave conformada por más de un atributo. 
• Llaves alternas: Las llaves candidatas que no fueron escogidas como llave primaria. 
• Llaves foráneas: Atributo de una relación A que hace referencia a otra relación B, donde A y B pueden ser la misma relación.

Regla de integridad de entidades: Se aplica a las llaves primarias de las relaciones base en el que ninguno de los atributos que componen la clave primaria puede ser nulo. Esta regla se aplica solo a las relaciones base y a las claves primarias, no a las alternativas. 

Regla de integridad referencial:  Esta aplica a las claves ajenas. Si en una relación hay alguna clave ajena, sus valores deben coincidir con valores de la clave primaria a la que hace referencia, o bien, deben ser completamente nulos, 

Introducción

La teoría del modelo de datos relacional es obra del investigador de IBM Edgar Codd en 1970, la cual goza de una fuerte base matemática. En este blog expondremos el concepto general del modelo relacional, analizando su estructura, el concepto de valor nulo y la lógica trivaluada y cuatrivaluada del modelo relacional, además de la álgebra relacional y los operadores. 

Primero, un modelo de datos es un conjunto de conceptos que permiten describir, la estructura de una base de datos a la cual se le conoce como esquema. Según el nivel de abstracción en el que se encuentre la estructura descrita, el modelo que permite su descripción será un modelo externo, modelo global o modelo interno. 

Los modelos externos nos permiten representar los datos que necesita cada usuario en particular con las estructuras propias del lenguaje de programación que va a emplear. Los modelos globales ayudan a describir los datos para el conjunto de usuarios, podríamos decir que es la información a nivel de empresa; y, por último, los modelos internos están orientados a la máquina, siendo sus elementos de descripción punteros, índices, agrupamientos, etc.

Los modelos globales asimismo, se clasifican en modelos conceptuales y convencionales. 

• Los modelos conceptuales se denominan también de alto nivel, y facilitan la descripción global del conjunto de información de la empresa con independencia de la máquina, por lo que sus conceptos son cercanos al mundo real. Son modelos de análisis, no de implementación.
• Los modelos convencionales se encuentran soportados por los SGBD y están orientados a describir los datos a nivel lógico para el SGBD, por lo que sus conceptos son propios de cada SGBD. 

Entendemos como esquema la descripción de la estructura de la base de datos. Entonces definimos el modelo de datos como un conjunto de conceptos, reglas y convenciones que nos permiten describir y manipular los datos de cierto mundo real que se almacenarán en la base de datos.