Modelamiento Logico de una base de datos

Los modelos  se  utilizan  en  todo  tipo  de  ciencias.  Su  finalidad  es  la  de  simbolizar  una
parte del mundo real de forma que sea más fácilmente manipulable. En definitiva es un
esquema mental (conceptual) en el que se intentan reproducir las características de una
realidad específica.
En el caso de los modelos de datos, lo que intentan reproducir es una información
real que deseamos almacenar en un sistema informático.
Se denomina  esquema  a  una  descripción  específica  en  términos  de  un  modelo  de
datos. El conjunto de datos representados por el esquema forma la base de datos.




clasificación de los modelos de datos
Esquema
Conceptual
Mundo
real Esquema
canónico
Esquema
interno BD
Físical
Modelo
Conceptual
Modelo
Lógico
Modelo
Interno
DBMS
Ilustración 5, Clasificación de los modelos de datos
En la ilustración anterior aparecen los distintos esquemas que llevan desde el mundo real
a la base de datos física. Como se ve aparecen varios esquemas intermedios. Los que están
más a la izquierda se alejan más de las características físicas. Los elementos de ese
esquema son:
€ Mundo real. Contiene la información tal cual la percibimos como seres humanos.
Es el punto de partida
€ Esquema conceptual. Representa el modelo de datos de forma independiente del
DBMS que se utilizará.
€ Esquema canónico (o de base de datos). Representa los datos en un formato
más cercano al del ordenador
€ Esquema interno. Representa los datos según el modelo concreto de un sistema
gestor de bases de datos (por ejemplo Oracle)
€ Base de datos física. Los datos tal cual son almacenados en disco. Diseño conceptual de bases de datos
modelado de datos
<16>
Para conseguir estos esquemas se utilizan modelos de datos. El paso entre cada esquema
se sigue con unas directrices concretas. Estas directrices permiten adaptar un esquema
hacia otro.
Los dos modelos fundamentales de datos son el conceptual y el lógico. Ambos son
conceptuales en el sentido de que convierten parámetros del mundo real en abstracciones
que permiten entender los datos sin tener en cuenta la física de los mismos.
diferencias entre el modelo lógico y el conceptual
€ El  modelo  conceptual  es  independiente del DBMS que se  vaya a utilizar. El lógico
depende de un tipo de SGBD en particular
€ El modelo lógico es más cercano al ordenador
€ Es más cercano al usuario el modelo conceptual, el lógico forma el paso entre el
informático y el sistema.
Algunos ejemplos de modelos conceptuales son:
€ Modelo E/R
€ Modelo RM/T
€ Modelos semántico
Ejemplos de modelos lógicos son:
€ Modelo relacional
€ Codasyl
€ Jerárquic

1- ETAPAS DE UNA METODOLOGÍA DE DISEÑO

En los últimos años venimos asistiendo, gracias al avance tecnológico, a una gran difusión de los SGBDR, cuyos productos se soportan en cualquier plataforma, desde los superordenadores a los ordenadores personales. Sin embargo, y a pesar del esfuerzo realizado por numerosos investigadores y estudiosos del tema, la concepción de una BD sigue siendo una tarea larga y costosa.

Estas dificultades inherentes al diseño de una base de datos han de afrontarse con procedimientos ordenados y metódicos en el marco de una metodología de diseño de bases de datos.

En el proceso de diseño de una base de datos hemos de distinguir tres grandes fases:

-          Diseño conceptual: cuyo objetivo es obtener una buena representación de los recursos de información de la empresa, con independencia de usuarios o aplicaciones en particular, y fuera de consideraciones sobre eficiencia del ordenador.

-          Diseño lógico: cuyo objetivo es transformar el esquema conceptual obtenido en la etapa anterior, adaptándolo al modelo de datos en el que se apoya el SGBD que se va a utilizar. Nosotros nos vamos a referir al modelo relacional, pero de forma análoga se podría adaptar esta etapa de diseño lógico a otros modelos de datos, como el Jerárquico o el Codasyl.

-          Diseño físico: cuyo objetivo es conseguir una instrumentación, lo más eficiente posible, del esquema lógico.

Cuando estudiamos el papel de los modelos de datos en el diseño de las bases de datos, ya señalamos las ventajas de obtener, en una primera fase del diseño, un esquema conceptual independiente de las características de los modelos convencionales, como el modelo relacional, y que recogiese la semántica del mundo real.

Un problema que se suele presentar en el diseño de bases de datos es la comunicación entre el diseñador y el usuario; este último conoce bien el dominio de aplicación, lo que en general no ocurre con el diseñador, pero muchas veces no sabe expresarlo de forma correcta y, menos aun, precisa. La utilización del modelo E/R, en una primera fase del diseño, facilita el dialogo entre el informático, conocedor de las técnicas de estructuración de los datos pero ajeno al dominio de la aplicación, y el usuario, que suele conocer bien su mundo real pero que no es capaz de describirlo bajo las premisas que impone un modelo convencional.

El modelo E/R sencillo, pero a la vez suficientemente potente, permite entablar un diálogo entre el usuario y el diseñador que facilitara que se despejen dudas y aclaren aspectos del universo del discurso a modelar. Se facilita así la colaboración de los especialistas con los usuarios, de manera que estos últimos pueden participar activamente, e incluso ser protagonistas, en el diseño.

Podemos representar esquemáticamente las dos primeras fases (diseño conceptual y diseño lógico) de la metodología, en este ejemplo, en el cual aparece el proceso de diseño de una biblioteca; el diseñador observa el mundo real bajo unos ciertos objetivos (universo del discurso) y, apoyándose en una primera etapa en el modelo E/R, llega a un esquema conceptual, al cual se le aplicara un conjunto de reglas a fin de transformarlo en una estructura relacional (conjunto de tablas).

2- TRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL AL RELACIONAL

El paso de un esquema en el modelo E/R al relacional está basado en los tres principios siguientes:

-          Todo tipo de entidad se convierte en una relación.

-          Todo tipo de interrelación N:M se transforma en una relación.

-          Todo tipo de interrelación 1:N se traduce en el fenómeno de propagación de clave o bien se crea una nueva relación.

A primera vista se puede observar que en el paso del modelo E/R al relacional pierde semántica, puesto que tanto las entidades como las interrelaciones se transforman en relaciones, de forma que ya no es posible distinguir entre unas y otras (en el modelo relacional) solo existe la relación para presentar ambos tipos de objetos).

También se constata que la perdida de semántica es aún mayor en el caso de la propagación de clave, donde desaparece incluso el nombre de la interrelación. Es preciso destacar que la perdida de semántica no implica, necesariamente, un peligro para la integridad de la base de datos, ya que, si la transformación se ha realizado correctamente, se habrán definido las necesarias restricciones (muy en especial las claves ajenas con sus opciones) que aseguraran la consistencia de los datos.

En el ejemplo, puede observarse que las tres entidades EDITORIAL, LIBRO y AUTOR se transforman en otras tantas relaciones. La interrelación N:M Escribe da lugar a una nueva relación ESCRIBE cuya clave primaria es la concatenación de los atributos identificadores de las entidades que participan en ella (nombre de AUTOR y código de LIBRO), siendo además estos claves ajenas de ESCRIBE que referencian a las relaciones AUTOR yLIBRO, respectivamente. La interrelación 1:N edita se transforma en la relación LIBRO la clave de la relaciónEDITORIAL (  a la que llamamos Editorial); atributo que será clave ajena de la relación LIBRO referenciando aEDITORIAL.

Las opciones de clave ajena en la transformación del ME/R al relacional

Si bien, insistimos, el paso del ME/R al relacional implica una cierta pérdida de semántica, se debe procurar que está perdida sea lo menor posible, además de asegurar al máximo la consistencia de los datos, es decir, la integridad de la base de datos en las operaciones de actualización. Las opciones de clave ajena, cuando se borran o modifican ocurrencias de la relación referenciada (“NO ACTION”,”SET NULL”,”CASCADE, y “SET DEFAULT”), nos pueden ayudar a cumplir este objetivo de mantener la integridad. Seguidamente analizaremos las posibles opciones de borrado y modificación asociada a las claves ajenas en los casos de propagación de clave y de creación de una nueva relación.