Modelado de Datos

Fase 1 del diseño.

 

Diseño Conceptual: Modelo Entidad/Relación (E/R)

 

Habitualmente quien realiza la modelización, es un analista de sistemas que no tiene porqué ser un experto en el problema que pretende resolver (Contabilidad, Gestión de Reservas hoteleras, medicina, economía, etc.). Es por esto que es imprescindible contar con la experiencia de un futuro usuario de la Base de datos que conozca a fondo todos los detalles del negocio, y que, a su vez, no tienen porqué tener ningún conocimiento de informática.

 

El objetivo de esta fase del diseño consiste es representar la información obtenida del usuario final y concretada en el Diagrama de Entidad Relación del Sistema mediante estándares para que el resto de la comunidad informática pueda entender y comprender el modelo realizado.

 

El modelo que se utiliza en esta primera fase del diseño tiene un gran poder expresivo para poder comunicarse con el usuario que no es experto en informática y se denomina Modelo Conceptual. El modelo conceptual que utilizaremos es el Modelo Entidad/Relación e iremos profundizando en él a lo largo de esta unidad

 

 

Fase 2 del diseño.

 

Diseño Lógico: Modelo Relacional

 

Este modelo es más técnico que el anterior porque está orientado al personal informático y generalmente tiene traducción directa al al modelo físico que entiende el Sistema Gestor de Base de Datos (SGBD). Se obtienen a partir del modelo conceptual y dependerá de la implementación de la Base de Datos. Así, no es lo mismo implementar una base de datos jerárquica u orientada a objetos que una Base de Datos relacional. El modelo que se usará en este módulo es el Modelo Relacional

 

 

Fase 3 del diseño.

 

Diseño Físico: Modelo Físico

 

Es el resultado de aplicar el modelo lógico a un SGBD concreto. Generalmente está expresado en un lenguaje de programación de Base de DTOS tipo SQL. En la proxima Unidad, transformaremos el Modelo Relacional en el modelo físico mediante el sublenguaje DDL de SQL.

MODELO ENTIDAD/RELACIÓN

El modelo Entidad-Relación es el modelo más utilizado para el diseño conceptual de bases de datos. Fue introducido por Peter Chen en 1976 y se basa en la existencia de objetos a los que se les da el nombre de entidades, y asociaciones entre ellos, llamadas relaciones. Sus símbolos principales se representan en el cuadro siguiente.

 

MODELO E/R EXTENDIDO

 

El modelo Entidad/Relación extendido incluye todo lo visto en el modelo Entidad/Relación pero además las Relaciones de Jerarquía. Una relación de jerarquía se produce cuando una entidad se puede relacionar con otras a través de una relación cuyo rol sería «Es un tipo de».

Por ejemplo, imaginemos la siguiente situación.

Queremos hacer una BD sobre los animales de un Zoo. Tenemos las entidades ANIMAL, FELINO, AVE, REPTIL, INSECTO. FELINO, AVE, REPTIL e INSECTO tendrían el mismo tipo de relación con ANIMAL: «son un tipo de». Ahora bien, su representación mediante el E/R clásico sería bastante engorrosa:

Para evitar tener que repetir tantas veces el rombo de la misma relación, se utilizan unos símbolos especiales para estos casos y se sustituyen todos los rombos de relación «es un tipo de» por un triángulo invertido, donde la entidades de abajo son siempre un tipo de la entidad de arriba y se llaman subtipo e entidades hijas. La de arriba se denominará supertipo o entidad padre. Las relaciones jerárquicas siempre se hacen en función de un atributo que se coloca al lado de la relación «es_un». En la figura siguiente sería «tipo». El ejemplo anterior quedaría del modo siguiente utilizando símbolos del E/R extendido.

Relaciones de Jerarquía

Vamos a ver los distintos tipos de relaciones de jerarquía existentes:

 

• Total: Subdividimos la entidad Empleado en: Ingeniero, Secretario y Técnico y en nuestra BD no hay ningún otro empleado que no pertenezca a uno de estos tres tipos.

• Parcial: Subdividimos la entidad Empleado en: Ingeniero, Secretario y Técnico pero en nuestra BD puede haber empleados que no pertenezcan a ninguno de estos tres tipos.

• Solapada: Subdividimos la entidad Empleado, en: Ingeniero, Secretario y Técnico y en nuestra BD puede haber empleados que sean a la vez Ingenieros y secretarios, o secretarios y técnicos, etc.

• Exclusiva: Subdividimos la entidad Empleado en: Ingeniero, Secretario y Técnico. En nuestra BD ningún empleado pertenece a más de una subentidad.

Ejemplos:

Jerarquía solapada y parcial

En esta BD un empleado podría ser simultáneamente técnico, científico y astronauta o técnico y astronauta, etc. (solapada). Además puede ser técnico, astronauta, científico o desempeñar otro empleo diferente (parcial).

Jerarquía solapada y total

En esta BD un empleado podría ser simultáneamente técnico, científico y astronauta o técnico y astronauta, etc. (solapada). Además puede ser solamente técnico, astronauta o científico (total).

Jerarquía exclusiva y parcial

En esta BD un empleado sólo puede desempeñar una de las tres ocupaciones (exclusiva) . Además puede ser técnico, o ser astronauta, o ser científico o también desempeñar otro empleo diferente, por ejemplo, podría ser FÍSICO (parcial).

Jerarquía exclusiva y total

Un empleado puede ser solamente técnico, astronauta o científico (total) y no ocupar más de un puesto (exclusiva)

 

 

MODELO RELACIONAL

 

Los SGBD se pueden clasificar de acuerdo con el modelo lógico que soportan, el número de usuarios, el número de puestos, el coste… La clasificación más importante de los SGBD se basa en el modelo lógico, siendo los principales modelos que se utilizan en el mercado los siguientes: Jerárquico, en Red, Relacional y Orientado a Objetos.

 

La mayoría de los SGBD comerciales actuales están basados en el modelo relacional, en el que nos vamos a centrar, mientras que los sistemas más antiguos estaban basados en el modelo de red o el modelo jerárquico.

 

Los motivos del éxito del modelo relacional son fundamentalmente dos:

 

- Se basan en el álgebra relacional que es un modelo matemático con sólidos fundamentos. En esta sección se presenta el modelo relacional. Realizaremos la descripción de los principios básicos del modelo relacional: la estructura de datos relacional y las reglas de integridad. Ofrecen sistemas simples y eficaces para representar y manipular los datos.

 

- La estructura fundamental del modelo relacional es precisamente esa, la «relación», es decir una tabla bidimensional constituida por filas (registros o tuplas) y columnas (atributos o campos). Las relaciones o tablas representan las entidades del modelo E/R, mientras que los atributos de la relación representarán las propiedades o atributos de dichas entidades.

 

Por ejemplo, si en la base de datos se tienen que representar la entidad PERSONA, está pasará a ser una relación o tabla llamada «PERSONAS», cuyos atributos describen las características de las personas (tabla siguiente). Cada tupla o registro de la relación «PERSONAS» representará una persona concreta.

Estructura de datos relacional

PERSONAS

D.N.I.	Nombre	Apellido	Nacimiento	Sexo	Estado civil
52.768.987	Juan	Loza	15/06/1976	H	Soltero
06.876.983	Isabel	Gálvez	23/12/1969	M	Casada
34.678.987	Micaela	Ruiz	02/10/1985	M	Soltera

 

En realidad, siendo rigurosos, una RELACIÓN del MODELO RELACIONAL es sólo la definición de la estructura de la tabla, es decir su nombre y la lista de los atributos que la componen. Una representación de la definición de esa relación podría ser la siguiente:

Para distinguir un registro de otro, se usa la «clave primaria o clave principal».

 

En una relación puede haber más combinaciones de atributos que permitan identificar unívocamente una fila (estos se llamarán «llaves o claves candidatas»), pero entre éstas se elegirá una sola para utilizar como llave primaria. Los atributos de la llave primaria no pueden asumir el valor nulo.

Elementos y propiedades del modelo relacional

• Relación (tabla): Representan las entidades de las que se quiere almacenar información en la BD. Esta formada por:

   

  • Filas (Registros o Tuplas): Corresponden a cada ocurrencia de la entidad.

  • Columnas (Atributos o campos): Corresponden a las propiedades de la entidad. Siendo rigurosos una relación está constituida sólo por los atributos, sin las tuplas.

• Las relaciones tienen las siguientes propiedades:

   

  • Cada relación tiene un nombre y éste es distinto del nombre de todas las demás relaciones de la misma BD.

  • No hay dos atributos que se llamen igual en la misma relación.

  • El orden de los atributos no importa: los atributos no están ordenados.

  • Cada tupla es distinta de las demás: no hay tuplas duplicadas. (Como mínimo se diferenciarán en la clave principal)

  • El orden de las tuplas no importa: las tuplas no están ordenadas.

• Clave candidata: atributo que identifica unívocamente una tupla. Cualquiera de las claves candidatas se podría elegir como clave principal.

• Clave Principal: Clave candidata que elegimos como identificador de la tuplas.

• Clave Alternativa: Toda clave candidata que no es clave primaria (las que no hayamos elegido como clave principal)

• Una clave principal no puede asumir el valor nulo (Integridad de la entidad).

• Dominio de un atributo: Conjunto de valores que pueden ser asumidos por dicho atributo.

• Clave Externa o foránea o ajena: el atributo o conjunto de atributos que forman la clave principal de otra relación. Que un atributo sea clave ajena en una tabla significa que para introducir datos en ese atributo, previamente han debido introducirse en la tabla de origen. Es decir, los valores presentes en la clave externa tienen que corresponder a valores presentes en la clave principal correspondiente (Integridad Referencial).

Transformación de un esquema E/R a esquema relacional

Pasamos ya a enumerar las normas para traducir del Modelo E/R al modelo relacional, ayudándonos del siguiente ejemplo:

Nota

Al pasar del esquema E/R al esquema Relacional deberemos añadir las claves foráneas necesarias para establecer las interrelaciones entre las tablas. Dichas claves foráneas no aparecen representadas en el esquema E/R

 

Importante

Se deben elaborar los diagramas relacionales de tal forma que, posteriormente al introducir datos, no quede ninguna clave foránea a valor nulo (NULL). Para ello se siguen las reglas que se muestran a continuación

Entidades

Cada entidad se transforma en una tabla. El identificador (o identificadores) de la entidad pasa a ser la clave principal de la relación y aparece subrayada o con la indicación: PK (Primary Key). Si hay clave alternativa esta se pone en «negrita».

Ejemplo: Todas las entidades del ejemplo anterior generan tabla. En concreto, la entidad AULA genera la siguiente tabla:

Relaciones binarias (de grado 2)

Relaciones N:M: Es el caso más sencillo. Siempre generan tabla. Se crea una tabla que incorpora como claves ajenas o foráneas FK (Foreign Key) cada una de las claves de las entidades que participan en la relación. La clave principal de esta nueva tabla está compuesta por dichos campos. Es importante resaltar que no se trata de 2 claves primarias, sino de una clave primaria compuesta por 2 campos. Si hay atributos propios, pasan a la tabla de la relación. Se haría exactamente igual si hubiera participaciones mínimas 0.

 

Orden de los atributos en las claves compuestas: Se deben poner a la izquierda todos los atributos que forman la clave. El orden de los atributos que forman la clave vendrá determinado por las consultas que se vayan a realizar. Las tuplas de la tabla suelen estar ordenadas siguiendo como índice la clave. Por tanto, conviene poner primero aquel/los atributos por los que se va a realizar la consulta.

 

Ejemplo: Realicemos el paso a tablas de la relación N:M entre MÓDULO (1,n) y ALUMNO (1,n). Este tipo de relación siempre genera tabla y los atributos de la relación, pasan a la tabla que ésta genera.

Relaciones 1:N: Por lo general no generan tabla. Se dan 2 casos:

• Caso 1: Si la entidad del lado «1» presenta participación (0,1), entonces se crea una nueva tabla para la relación que incorpora como claves ajenas las claves de ambas entidades. La clave principal de la relación será sólo la clave de la entidad del lado «N».

• Caso 2: Para el resto de situaciones, la entidad del lado «N» recibe como clave ajena la clave de la entidad del lado «1». Los atributos propios de la relación pasan a la tabla donde se ha incorporado la clave ajena.

Ejemplo de caso 1: Realicemos el paso a tablas de la relación 1:N entre PROFESOR (1,n) y EMPRESA (0,1). Como en el lado «1» encontramos participación mínima 0, se generará una nueva tabla.

Ejemplo de caso 2: Realicemos el paso a tablas de la relación 1:N entre MÓDULO (1,1) y TEMA (1,n). Como no hay participación mínima «0» en el lado 1, no genera tabla y la clave principal del lado «1» pasa como foránea al lado «n».

 

Relaciones 1:1: Por lo general no generan tabla. Se dan 3 casos:

 

• Caso 1: Si las dos entidades participan con participación (0,1), entonces se crea una nueva tabla para la relación.

• Caso 2: Si alguna entidad, pero no las dos, participa con participación mínima 0 (0,1), entonces se pone la clave ajena en dicha entidad, para evitar en lo posible, los valores nulos.

• Caso 3: Si tenemos una relación 1:1 y ninguna tiene participación mínima 0, elegimos la clave principal de una de ellas y la introducimos como clave clave ajena en la otra tabla. Se elegirá una u otra forma en función de como se quiera organizar la información para facilitar las consultas. Los atributos propios de la relación pasan a la tabla donde se introduce la clave ajena.

Ejemplo de caso 1: No se presenta ninguna situación así en el esquema estudiado. Una situación donde puede darse este caso es en HOMBRE (0,1) se casa con MUJER (0,1). Es similar al caso 1 del apartado anterior en relaciones 1:N, aunque en este caso debemos establecer una restricción de valor único para FK2.

Ejemplo de caso 2 (y 3): Realicemos el paso a tablas de la relación 1:1 entre ALUMNO (1,1) y BECA (0,1). Como BECA tiene participación mínima 0, incorporamos en ella, como clave foránea, la clave de ALUMNO. Esta forma de proceder también es válida para el caso 3, pudiendo acoger la clave foránea cualquiera de las entidades.

 

Truco

A continuación se muestra un resumen de los casos disponibles en relaciones N:M, 1:N y 1:1.