Modelo relacional

Las interrelaciones son las relaciones que existen entre varias tablas del sistema (Clientes y Pedidos, por ejemplo). Existen tres formas de interrelaciones dependiendo de la cardinalidad con la que se combinan los elementos de ambas tablas.

�Interrelaciones uno a uno

Una interrelaci�n es de uno a uno entre la tabla A y la tabla B cuando a cada elemento de la clave de A se le asigna un �nico elemento de la tabla B y para cada elemento de la clave de la tabla B contiene un �nico elemento en la tabla A. Un ejemplo de interrelaci�n de este tipo es la formada por las tablas Datos Generales de Clientes y Datos Contables de Clientes. En esta relaci�n cada cliente tiene una �nica direcci�n y una direcci�n en cada una de las tablas. Representamos la relaci�n como A 1: 1 B.

Ante la presencia de este tipo de relaci�n nos podemos plantear el caso de unificar todos los datos en �nica tabla pues no es necesario mantener ambas tablas a la misma vez.

Este tipo de relaci�n se genera cuando aparecen tablas muy grandes, con gran cantidad de campos, disgregando la tabla principal en dos para evitar tener una tabla muy grande. Tambi�n surge cuando los diferentes grupos de usuario cumplimentan una informaci�n diferente para un mismo registros; en este caso se crean tantas tablas como registros, evitando as� tener que acceder a informaci�n que el usuario del grupo actual no necesita.

�Interrelaciones uno a varios

Una interrelaci�n es de uno a varios entre las tablas A y B cuando una clave de la tabla A posee varios elementos relacionados en la tabla B y cuando una clave de la tabla B posee un �nico elemento relacionado en la tabla A.

Estudiemos la relaci�n entre la tabla de clientes y la tabla de pedidos. Un cliente puede realizar varios pedidos pero un pedido pertenece a un �nico cliente, por tanto se trata de una relaci�n uno a varios y la representamos A 1: n B.

Estas relaciones suelen surgir de aplicar la 1NF a una tabla.

�Interrelaciones varios a varios

Una interrelaci�n es de varios a varios entre las tablas A y B cuando una clave de la tabla A posee varios elementos relacionados en la tabla B y cuando una clave de la tabla B posee varios elementos relacionados en la tabla A.

Un caso muy caracter�stico de esta interrelaci�n es la que surge entre las tablas de Puestos de Trabajo y Empleados de una empresa. Un Empleado puede desempe�ar realizar varias funciones dentro de una empresa (desempe�ar varios puestos de trabajo), y un puesto de trabajo puede estar ocupado por varios empleados a la misma vez. Esta interrelaci�n la representamos como A n: n B.

No se deben definir relaciones de este tipo en un sistema de bases de datos, debido a su complejidad a la hora de su mantenimiento, por este motivo se debe transformar este tipo de relaci�n es dos interrelaciones de tipo 1: n, empleando para ello una tabla que denominaremos puente y que estar� formada por las claves de ambas tablas. Esta tabla puente debe contener una �nica clave compuesta formada por los campos clave de las tablas primeras.

Ahora existe una relaci�n 1: n entre Empleados y Tabla Puente y otra relaci�n 1: n entre Puestos y Tabla Puente ya que un empleado posee varios c�digos de empleado en la tabla puente pero cada elemento de la tabla puente pertenece a un �nico empleado.

Por otro la un puesto de trabajo posee varios elementos relacionados en la tabla puente, pero cada elemento de la tabla puente est� relacionado con un �nico elemento de la tabla puestos.

�Problemas con las interrelaciones

A la hora de establecer las interrelaciones existentes en un sistema de bases de datos nos podemos encontrar dos problemas:

1. Interrelaciones recursivas: un elemento se relaciona consigo mismo directamente.
2. Interrelaciones circulares o c�clicas: A se relaciona con B, B se relaciona con C y C se relaciona con A.

Ambos casos pueden suponer un grabe problema si definimos una relaci�n con integridad referencial y decimos eliminar en cascada (al eliminar una clave de la tabla A se eliminan los elementos relacionados en la tabla B). Supongamos la relaci�n recursiva existen en la relaci�n Empleado y Supervisor (ambos son empleados de la empresa). Est� claro que un empleado est� supervisado por otro empleado. Veamos la forma de solucionarlo:

Para solucionar la relaci�n debemos crear una tabla formada por dos campos. Ambos campos deben ser el c�digo del empleado pero como no podemos tener dos campos con el mismo nombre a uno de ellos le llamaremos c�digo supervisor.

Para terminar de resolver la interrelaci�n recursiva basta con definir dos interrelaciones entre la tabla empleados y la tabla puente de tipo 1: n. La primera relaci�n se crea utilizando las claves Empleados[C�digo] y Tabla Puente[C�digo Empleado]. La segunda entre Empleados[C�digo] y Tabla Puente [C�digo Supervisor].

Las interrelaciones c�clicas o circulares no son muy frecuentes y no existe una metodolog�a est�ndar para su eliminaci�n, normalmente son debidas a errores de dise�o en la base de datos, principalmente en el dise�o conceptual del sistema de datos. Por tanto si llegamos a este punto hay que volver a replantearse todo el dise�o de la base de datos.

�Atributos de las interrelaciones

En la mayor�a de las interrelaciones definidas ser� conveniente exigir integridad relacional entre las claves. Exigiendo la integridad referencial se consigue que en una relaci�n de tipo 1: n o de tipo 1: 1, no se puede a�adir ning�n valor en la tabla destino si no existe en la tabla origen. Dicho con un ejemplo: en la relaci�n Clientes y Pedidos la tabla Pedidos contiene un campo que se corresponde con el c�digo del Cliente, si se exige la integridad referencia no se podr� escribir un c�digo de cliente en la tabla Pedidos que no exista en la tabla Clientes; de no exigir la integridad referencial se podr�n crear pedidos con c�digos de clientes que no existen, generando incongruencia de datos en la base de datos.

Definida la integridad referencial (siempre necesaria) podemos exigir la actualizaci�n en cascada (siempre necesaria); esta actualizaci�n implica que si cambiamos el c�digo a un cliente, debemos actualizar dicho c�digo en la tabla de pedidos, de no ser as�, al cambiar el c�digo a un cliente, perderemos los pedidos que ten�a realizados.

Para concluir debemos hablar de la eliminaci�n en cascada (NO siempre necesaria), la eliminaci�n en cascada consiste en eliminar todos los datos dependientes de una clave. En nuestro ejemplo implica que al borrar un cliente hay que eliminar todos los pendidos que ha realizado. En muchas ocasiones no interesa realizar esta operaci�n de eliminaci�n en cascada por motivos diversos. Si en el caso de clientes y pedidos no se exige eliminaci�n en cascada no se podr� borrar ning�n cliente en tanto en cuanto tenga realizado alg�n pedido (de lo contrario tendr�amos incongruencia de datos).