MODELO RELACIONAL DE DATOS

MODELO RELACIONAL DE DATOS

El Modelo Entidad Relación nos ofrece una vista conceptual del mundo real, transmitiendo un alto grado de semántica del sistema que se desea modelar, además de proveer una metodología estándar que permite a todos los involucrados en el sistema entender que entes esenciales lo componen y cuáles son las relaciones entre ellos. Pero este modelo debe sufrir un proceso de transformación de forma tal que el modelo resultante sea la documentación previa a la implementación en un DMBS, a este último modelo lógico se le conoce con el nombre de Modelo Relacional de Datos (MRD).

COMPONENTES DEL MRD

La construcción del MRD se basa en el MER, razón por la cual se debe establecer una correspondencia de cada uno de los elementos que componen estos dos modelos.

Los componentes básicos del MRD son:

£ Tablas: Las tablas se definen, basándose en las entidades del MER. Para especificar una tabla en el MRD, se toma cada una de las entidades del MER y se les asigna por estándar el mismo nombre de la entidad pero en plural.

£ Campos: El campo representa lo que en el MER se ha denominado hasta ahora atributo. Los campos pueden tomar el mismo nombre de los atributos del MER, pero tenga en cuenta que aunque el DBMS admite nombres largos, con espacios e incluso con acentos, no es recomendado el uso de estas utilidades.

 El nombre del campo en lo posible debe ser relativamente corto, si hace uso de abreviaturas estas deben ser consistentes para todo el modelo y el nombre mismo debe dar claridad sobre su significado.

Para cada campo se debe especificar: Tipo de dato y su longitud, Función dentro de la tabla, Obligatoriedad, Dominio.

PASOS PARA CONSTRUIR EL MRD

Tome las entidades del MER y conviértalas en tablas tomando el mismo nombre de la entidad en plural (siempre y cuando considere el nombre adecuado). Las entidades por las que recomienda iniciar este proceso son las denominadas entidades dominantes  (Fuertes), es decir, aquellas entidades en las que su existencia no depende de ninguna otra entidad (como se explicó con anterioridad), aplique para cada una de ellas todos los pasos aquí mencionados. Posteriormente aplique el mismo proceso para las entidades que dependen de otras, pero tenga ahora en cuenta las claves foráneas.

Asigne a cada tabla los campos que la componen. Estos se derivan de los atributos de las entidades.

Determine las características de cada campo en la tabla:

Tipo de Dato: Los tipos básicos posibles son Numérico, Caracter y Fecha. Recuerde que para la mayoría de los DBMS un campo tipo fecha puede incluir la hora.

Longitud del campo: Determina el tamaño del campo, medido en el número de dígitos o caracteres que este ocupa. Si el campo es de tipo numérico, una posible longitud es (3), en este caso el valor máximo que puede contener este campo es 999. Para un campo que contiene valores con cifras decimales, una posible longitud es (3,1), indicando que se requieren tres dígitos para la parte entera y un dígito para la parte decimal, en este caso el valor máximo que puede contener este campo es 999.9. Para los campos de tipo caracter, la longitud indica el número máximo de caracteres que lo componen, un ejemplo para este caso es que un campo que almacene el nombre de una persona y se halla determinado que se requieren como máximo 40 caracteres para tal efecto

Obligatoriedad del campo: Se refiere a si el campo puede tomar un valor nulo que se denota por la letra N. Si por el contrario no puede tomar valores nulos se denota por la abreviatura NN. Esta caracterización se deriva de la obligatoriedad del atributo en el modelo entidad relación, donde un valor nulo equivale a un atributo opcional, y el valor no nulo equivale a un atributo obligatorio.

 Función del campo: En este caso se indica que papel juega el campo en la tabla. Los posibles estados son:

- Clave Primaria: El campo que forme la clave primaria, será el atributo que se identificó como clave primaria en el MER, se denota por la abreviatura PK.

- Clave Secundaria: Los campos que son clave secundaria son aquellos que también pueden ser claves primarias, pero que no se escogieron como claves primarias por razones de operación del sistema. Se denota con las abreviaturas : AK1.... AKn. (Nota: La A significa alterna y la K key) .

- Clave foránea: Cuando en el MER se establece una relación entre dos entidades, en realidad se están compartiendo atributos. Este atributo que se comparte se convierte en un campo en el MRD, pero este campo en muchos casos es clave primaria en una de las dos  tablas involucradas en la relación. Este campo que es clave primaria en una tabla externa se denomina clave foránea y se denotará con la abreviatura es FK, documentando adicionalmente en que tabla es clave primaria de la siguiente forma: FK ( tabla en la que es clave primaria).

Dominio y restricciones: Se determinan los posibles valores u ocurrencias que el atributo puede tomar. Las restricciones se refieren a las reglas de validación que estos campos deben cumplir. Por ejemplo: un campo numérico cuyo contenido se refiere al peso de un producto no puede incluir valores negativos, luego una posible restricción sería que el dato que se almacene en este campo sea mayor a 0.

Un ejemplo para el caso de dominio se da para campos en los que es posible especificar un conjunto finito de datos, por ejemplo un campo que almacene los días de la semana o los meses del año.

TRANSICIÓN EL MER AL MRD

Definida las equivalencias entre el MER y el MRD se da inicio a la transición de un modelo a otro. Para efectuar esta labor se define una tabla que documenta cada una de entidades que se convierten en tablas que se muestra en la siguiente figura:

[pic 1]

Se dará inicio a la elaboración del MRD tomando como punto de partida las entidades  de usuarios y ciudades

Tabla: CIUDADES

COMPROMISO EN CLASE:

Realizar el MR a la tabla de usuarios

Tabla: USUARIOS

SOLUCIÒN

Tabla: USUARIOS

...