Modelo de datos relacional

2.2. MODELO DE DATOS RELACIONAL

En el modelo de datos relacional, propuesto por Codd, los datos se estructuran lógicamente en forma de  relaciones (tablas).  El  objetivo  fundamental  del  modelo  es  mantener  la  independencia  de  esta estructura lógica respecto al modo de almacenamiento y a cualquier característica de tipo físico.

Los objetivos que se persiguen con el modelo son:

Independencia física: Es decir, que el modo en el que se almacenan los datos no influya en su manipulación lógica y por tanto, los usuarios que acceden a los datos no tengan que modificar sus programas por cambios en el almacenamiento físico.

Independencia lógica: Esto es, que el añadir, eliminar o modificar objetos de la base de datos no repercuta en los programas y/o usuarios que están accediendo a la misma.

Flexibilidad:  En  el  sentido  de  poder  presentar  al  usuario  los  datos  de  la  forma  en  que  este prefiera.

2.2.1. METODOLOGÍA DE DISEÑO DE UNA BASE DE DATOS

El diseño de una base de datos se descompone en diseño conceptual, diseño lógico y diseño físico. 

En el diseño conceptual se parte de las especificaciones de usuario y se consigue una representación del mundo real. Esta imagen del mundo real se denomina modelo conceptual. En él se describen las entidades y sus propiedades, además de las relaciones entre ellos.

El diseño lógico consiste en transformar el modelo conceptual obtenido en otro esquema que puede procesar el SGBD concreto (Relacional, Jerárquico, red). Ejemplo (El modelo E/R -> modelo de datos).

En el diseño físico se parte del esquema lógico y da como resultado el esquema físico. Consiste en la implementación del modelo de datos,  dando lugar a estructuras de datos de almacenamiento en uno o varios soportes físicos.

2.2.2. VENTAJAS DEL MODELO

·         El  modelo  conceptual  aporta  claridad  y  evita  confusiones  que  surgen  de  intentar  definir  algo  tan complejo como la estructura de una organización utilizando únicamente el lenguaje natural. 

·         Una ventaja de la modelación conceptual de datos es que contribuye a detectar los posibles errores desde el principio, ya que permite al diseñador, una amplia visión de los datos y sus relaciones 

·         Otra ventaja es que mediante la modelización conceptual de datos se obtiene una representación  de datos independientes del entorno físico y. Lo que permite la fácil exportación del mismo a o diferentes SGBD o a versiones del mismo.

2.2.3. TÉCNICA DESCRIPTIVA: MODELO ENTIDAD / RELACIÓN

El modelo ER, propuesto por CHEN es, sin duda el modelo de datos conceptual más extendido en las metodologías de diseño de base de datos y en las herramientas CASE. 

Esta  técnica  descriptiva,  permite  representar,  en  lo  que  se  llama  diagrama  ER,  un  sistema  de  información, siguiendo una metodología gráfica basada en reglas, símbolos y métodos para diseñar bases de datos. 

El objetivo es obtener un modelo abstracto que represente la información obtenida del mundo real gráficamente.  Para ello hace uso, fundamentalmente, de tres conceptos: entidad, atributo y relación. 

Además,  para  aumentar  la  capacidad  expresiva  del  modelo  también  se  contempla  la  definición  de  objetos compuestos mediante la agregación de entidades y la definición de objetos especializados (o generalizados). 

ELEMENTOS DEL MODELO ENTIDAD-RELACIÓN

ENTIDAD

Las entidades representan cosas u objetos, que se diferencian claramente entre sí.

Para poder seguir un ejemplo durante el artículo añadiré ejemplos sobre un taller mecánico, donde se podría crear las siguientes entidades:

·         Coches (objeto físico): contiene la información de cada taller.

·         Empleado (objeto físico): información de los trabajadores.

·         Cargo del empleado (cosa abstracta): información de la función del empleado.

Estas entidades se representan en un diagrama con un rectángulo, como los siguientes.

ATRIBUTOS

Los atributos definen o identifican las características de entidad (es el contenido de esta entidad). Cada entidad contiene distintos atributos, que dan información sobre esta entidad. Estos atributos pueden ser de distintos tipos (numéricos, texto, fecha…).

Siguiendo el ejemplo de antes podemos analizar los atributos de nuestra entidad “Coches“, que nos darán información sobre los coches de nuestro supuesto taller.

Unos posibles atributos serían los siguientes: número de chasis, matrícula, DNI del propietario, marca, modelo y muchos otros que complementen la información de cada coche.

Los atributos se representan como círculos que descienden de una entidad, y no es necesario representarlos todos, sino los más significativos, como a continuación.

En un modelo relacional (ya implementado en una base de datos) un ejemplo de tabla dentro de una BD podría ser el siguiente:

Número de chasis	Matrícula	DNI del propietario
5tfem5f10ax007210	4817 BFK	45338600L
6hsen2j98as001982	8810 CLM	02405068K
5rgsb7a19js001982	0019 GGL	40588860J

Este ejemplo es con tres atributos, pero un coche podría tener cientos (si fuese necesario) y seguirían la misma estructura de columnas, tras implementarlo en una BD.

RELACIÓN

Es un vínculo que nos permite definir una dependencia entre varias entidades, es decir, nos permiten exigir que varias entidades compartan ciertos atributos de forma indispensable.

Por ejemplo, los empleados del taller (de la entidad “Empleados“) tienen un cargo (según la entidad “Cargo del empleado“). Es decir, un atributo de la entidad “Empleados“ especificará que cargo tiene en el taller, y tiene que ser idéntico al que ya existe en la entidad “Cargo del empleado“.

Las relaciones se muestran en los diagramas como rombos, que se unen a las entidades mediante líneas.

 Empleados

Nombre	DNI	Cargo
Carlos Sánchez	45338600L	001
Pepe Sánchez	02405068K	002
Juan Sánchez	40588860J	002

Cargo del empleado

ID del cargo	Descripción
001	Jefe de taller
002	Mecánico

RELACIONES DE CARDINALIDAD

Podemos encontrar distintos tipos de relaciones según como participen en ellas las entidades. Es decir, en el caso anterior cada empleado puede tener un cargo, pero un mismo cargo lo pueden compartir varios empleados.

Esto complementa a las representaciones de las relaciones, mediante un intervalo en cada extremo de la relación que especifica cuantos objetos o cosas (de cada entidad) pueden intervenir en esa relación.

UNO A UNO: Una entidad se relaciona únicamente con otra y viceversa. Por ejemplo, si tuviésemos una entidad con distintos chasis y otra con matrículas deberíamos de determinar que cada chasis solo puede tener una matrícula (y cada matrícula un chasis, ni más en ningún caso).

UNO A VARIOS O VARIOS A UNO: determina que un registro de una entidad puede estar relacionado con varios de otra entidad, pero en esta entidad existir solo una vez. Como ha sido en el caso anterior del trabajador del taller.

VARIOS A VARIOS: determina que una entidad puede relacionarse con otra con ninguno o varios registros y viceversa. Por ejemplo, en el taller un coche puede ser reparado por varios mecánicos distintos y esos mecánicos pueden reparar varios coches distintos.

CLAVES

Es el atributo de una entidad, al que le aplicamos una restricción que lo distingue de los demás registros (no permitiendo que el atributo específico se repita en la entidad) o le aplica un vínculo (exactamente como comentábamos en las relaciones). Estos son los distintos tipos:

Superclave: aplica una clave o restricción a varios atributos de la entidad, para así asegurarse que en su conjunto no se repitan varias veces y así no poder entrar en dudas al querer identificar un registro.

Clave primaria: identifica inequívocamente un solo atributo no permitiendo que se repita en la misma entidad. Como sería la matrícula o el número de chasis de un coche (no puede existir dos veces el mismo).

Clave externa o clave foránea: este campo tiene que estar estrictamente relacionado con la clave primaria de otra entidad, para así exigir que exista previamente ese clave. Anteriormente hemos hablado de ello cuando comentábamos que un empleado indispensablemente tiene que tener un cargo (que lo hemos representado numéricamente), por lo cual si intentásemos darle un cargo inexistente el gestor de bases de datos nos devolvería un error.

2.2.4. CONSTRUCCIÓN DEL MODELO CONCEPTUAL DE DATOS

El  objetivo  de  este  apartado  es  exponer  cómo  se  puede  abordar  la  tarea  del  diseño  conceptual  de bases de datos utilizando el modelo ER presentado, es decir, proponer una metodología de diseño.

Para obtener un diagrama adecuado y fiable a partir del análisis de la realidad y de los requerimientos de la organización hay que realizar las siguientes actividades:

·         Identificar tipos de entidad y atributos

·         Identificar generalizaciones/especializaciones

·         Identificar tipos de relación entre entidades

·         Identificar tipos de entidad débiles

Estas  actividades  se  realizan  de  forma  iterativa  hasta  conseguir  definir  un  diagrama  ER  lo  más  fiel posible a la realidad. 

Ø  RECOPILACIÓN DE INFORMACIÓN

El  primer  paso  para  obtener  un  modelo  conceptual  de  datos  es  proceder  a  recoger  la  información relevante del universo que se quiere representar. 

La forma de llevar a cabo esta tarea es mediante la elaboración de un diccionario de datos. En realidad, con  las  herramientas  CASE  se  trabaja  con  un  depósito  CASE,  donde  se  guarda  toda  la  información relevante del modelo.

Ø  IDENTIFICAR ENTIDADES Y ATRIBUTOS

Una  vez  concretada  la  información  descriptiva  que  se  desea  almacenar,  se  define  una  entidad  en  el diagrama, por cada tipo de objeto (personas, actividades, etc.) de la realidad. Una entidad viene definida por  un  conjunto  de  atributos  que  representan  la  información  que  se  desea  conocer  de  cada  tipo  de objeto.

Hay que tener en cuenta que:

·  En un diagrama ER todas las entidades tienen identificador o bien son débiles o especializaciones.

·         No puede haber entidades con el mismo nombre que otra entidad o que otra relación.

·      No hay que pensar en que antes de avanzar en el diseño hay que definir un conjunto de entidades que sea fijo, sino que éste puede cambiar a medida que se tomen ciertas decisiones de diseño. Por ejemplo es  posible  que  algunos  atributos  inicialmente  considerados  desaparezcan  luego  y  se  conviertan  en entidades

Ø  IDENTIFICAR GENERALIZACIONES/ESPECIALIZACIONES

La  especialización  es  el  proceso  por  el  que  se  clasifica  una  clase  de  objetos  en  subclases  más especializadas.  La  generalización  es  el  proceso  inverso  por  el  que  se  generalizan  varias  clases  para obtener una abstracta de más alto nivel que incluya los objetos de todas estas clases. 

En  cualquiera  de  estos  casos  generalización/especialización  los  atributos  identificadores  y  los descriptores  que  son  comunes  a  todas  las  entidades  estén  en  la  entidad  general,  quedándose  los atributos específicos y las relaciones específicas en cada una de las entidades especializadas.

Ø  IDENTIFICAR LAS RELACIONES ENTRE ENTIDADES

Una  vez  definido  un  conjunto  inicial  de  entidades  que,  como  ya  se  ha  comentado,  podrá  ser reconsiderado a lo largo del todo el diseño, hay que estudiar las relaciones existentes entre el as, ya que  raramente  existirán  entidades  sin  conexiones  con  otras. 

Para  definir  una    relación  hay  que especificar:

·         Entidades implicadas

·         Cardinalidades máximas y mínimas y Atributos propios de la relación (con sus restricciones si las tienen).

Las relaciones redundantes deben ser eliminadas. Dos o más relaciones se consideran redundantes si representan  el  mismo  concepto;  sin  embargo,  es  posible  que  entre  las  mismas  entidades  se  pueden definir más de una relación siempre que tengan significados diferentes.

Ø  IDENTIFICAR ENTIDADES DÉBILES

Una entidad débil sufre dependencia de identificación, ya que no puede identificarse con sus propios atributos, por este motivo sus ocurrencias son distinguibles gracias a su relación con otras entidades.

Cuando en el diagrama ER aparezcan entidades de este tipo, hay que especificar con qué relaciones se identifica (pueden ser una o más de una).  

Ø  DOCUMENTACIÓN

Toda la información recopilada durante esta fase de análisis queda definida en un diccionario de datos. En él, el diseñador debe incluir el modelo gráfico utilizado (por ejemplo E/R) para la representación del esquema de base de datos y una descripción de cada elemento del modelo, que incluye:

Ø  Catálogo de requisitos

Ø  Especificación detallada del problema

Ø  Nombres de las relaciones y sus atributos indicando las claves

Ø  Dominios de los atributos

Ø  Nombres y definiciones de las vistas

Ø  Todo tipo de documentación adicional, como por ejemplo restricciones entre entidades y comentarios que se consideren oportunos

En el caso de utilizar una herramienta CASE, existe un repositorio donde se guarda toda la información relevante del modelo.

2.2.5. EJERCICIOS PRÁCTICOS

Objetivo: Comprender  los  conceptos  de  la  modelación  de  datos,  utilizando  la  técnica  descriptiva Entidad / Relación.

BASE DE DATOS HOSPITAL.

Un paciente puede acudir al  médico muchas veces en la vida. En cada visita que realiza el paciente le puede atender un médico distinto por motivos distintos. Un médico a su vez atiende a muchos pacientes. Cada médico tiene una especialidad. De los pacientes se quiere almacenar un código que los identifique, el nombre del paciente, fecha de nacimiento, dirección y  teléfono. De los médicos  un código que los identifique, nombre,  dirección, y teléfono. De las especialidades un Código identificador y la Descripción de la especialidad

BASE DE DATOS ENTIDAD BANCARIA.

Crear un modelo E/R para controlar los datos de un banco, en el que necesitamos: El banco tiene sucursales por todo el país. Se quiere almacenar un número que las identifique, teléfono y dirección. El nombre, apellidos, DNI, dirección y calle de los clientes del banco. Número de cuenta y el saldo de cada cliente y la fecha en la que se creó la cuenta. En  el  banco  trabajan  empleados  de  los  cuales  uno  de  ellos  es  el  director  del  banco.  Se  desea almacenar el DNI, nombre, dirección, nómina y cargo

BASE DE DATOS RECETAS DE COCINA.

Crear un modelo entidad / relación para controlar una base de datos de recetas de cocina. Debe incluir Información  sobre  los  platos,  tipos  de  plato,  ingredientes,  cantidades,  etc.  Hacer  el  primer  paso  de establecimiento de atributos utilizando los atributos más apropiados.  Añadir información sobre vinos recomendados en los platos (incluidas las denominaciones de origen).

BASE DE DATOS GESTIÓN DE UN TEATRO.

En el teatro se venden entradas, la entrada se refiere a una butaca y un día concreto. La base de datos debe  almacenar  todas  las  entradas  vendidas.  Almacenar  y  relacionar  también  la  información concerniente a las obras de teatro representadas (título, sinopsis,..) y las fechas en las que se realizan.  En obras trabajan actores, se desea almacenar su nombre, DNI y fecha de nacimiento. Una obra puede ser  escrita  por  uno  o  más  autores,  de  los  cuales  se  desea  almacenar  su  fecha  de  nacimiento  y nacionalidad.