1.4. Módelo Lógico de Datos.

1.4.1 ETAPAS DEL DISEÑO LÓGICO.

La fase de diseño lógico de una base de datos consiste en dos etapas:

  • Etapa de estructuración: donde el objetivo primordial es encontrar un esquema que sea una representación fidedigna del mundo real. La forma de lograrlo es mediante el particionamiento horizontal, para evitar valores nulos, y el proceso de normalización.
  • Etapa de reestructuración: donde se tienen en cuenta aspectos más ligados con el nivel físico, y que consiste el modificar el esquema obtenido en la fase anterior para adaptarlo a las consideraciones de eficiencia. Esta etapa, que debería ser ajena al diseño lógico, se considera aquí debido a la falta de flexibilidad de los SGBD, obligando a trasladar a esta etapa aspectos más relacionados con el nivel físico. La forma de lograrlo es mediante la desnormalización, y el particionamiento, bien sea horizontal, vertical o mixto.

dml1

 

1.4.2 TRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL AL LÓGICO

El objetivo del diseño lógico es convertir los esquemas conceptuales locales en un esquema lógico global que se ajuste al modelo de SGBD sobre el que se vaya a implementar el sistema. Mientras que el objetivo fundamental del diseño conceptual es la compleción y expresividad de los esquemas conceptuales locales, el objetivo del diseño lógico es obtener una representación que use, del modo más eficiente posible, los recursos que el modelo de SGBD posee para estructurar los datos y para modelar las restricciones.

1.4.3 REGLAS DE TRANSFORMACIÓN

Lo primero que hay que realizar en la fase de diseño lógico, es obtener el esquema lógico estándar, a partir del esquema conceptual obtenido en la primera fase. Las reglas que permiten pasar del modelo E/R al esquema lógico, son las que a continuación se explican:

  1. Cada entidad se transforma en una tabla y los atributos de dicha entidad en atributos de la tabla. Esto es, cada entidad genera una tabla, con sus mismos atributos, incluyendo las claves.
  2. Las relaciones de muchos a muchos se transforman en tablas cuya clave estará formada por la clave primaria de las entidades relacionadas, convirtiéndose esta en una relación de muchos a muchos o de muchos a uno.
  3. Las relaciones de uno a muchos propagan la clave principal de la entidad cuya cardinalidad es uno a la entidad de cardinalidad n.
Ejemplo

EJEMPLO.

Veamos el paso a tabla de una entidad SOCIO que tiene 6 atributos. Observe que la entidad se convierte en una tabla cuyos atributos forman  las columnas de dicha tabla. Las filas de la tabla se llaman registros.

  dml
  dml

 

Ejemplo

EJEMPLO.

Supongamos el siguiente modelo entidad-relación para una relación de muchos a muchos:

  dml
 

En este caso la relación “compra” se transforma en una nueva tabla cuya clave primaria estará formada por los atributos DUI que es la clave primaria de cliente y CODIGO que es la clave primaria de producto. Además tendrá como campo fecha compra, ya que este atributo forma parte de la relación.

El modelo relacional quedaría de la siguiente forma:
 

dml

 

Ejemplo

EJEMPLO.

Supongamos el siguiente modelo entidad-relación para una relación de uno a muchos. Un empleado pertenece a un único departamento (debe pertenecer a uno obligatoriamente), y un departamento tiene uno o más empleados.

  dml
 

En este caso se propaga el atributo código de departamento a la tabla EMPLEADO. El modelo relacional quedaría de la siguiente manera:

  • EMPLEADO (DUI, nombre, salario, código_ departamento)
  • DEPARTAMENTO (código, nombre, localización)

Imaginemos ahora que pudiera darse el caso de que hubiera empleados que no pertenecieran a ningún departamento. En este caso la entidad que participa con cardinalidad máxima 1, DEPARTAMENTO, también lo hace con cardinalidad mínima 0, ya que puede haber empleados que no pertenezcan a ningún departamento. Así pues, se crea una nueva tabla formada por DUI de EMPLEADO y código de DEPARTAMENTO. En esta nueva tabla, DUI de EMPLEADO será la llave primaria. El modelo relacional nos quedará de la siguiente forma:

 
  • EMPLEADO (DUI, nombre, salario)
  • DEPARTAMENTO (código, nombre, localización)
  • PERTENECE (DUI_empleado, código_ departamento)