ESTRUCTURACIÓN DE LA BASE DE DATOS EN TABLAS

ir a tratamiento no estadístico de la información

Utilizando el modelo relacional, cada una de las entidades-tipo puede ser representada por una tabla, donde cada columna       (campo) sería cada uno de los atributos considerados y cada fila sería cada uno de los individuos, instancias a casos particulares de la entidad tipo considerada.

En nuestro ejemplo, podríamos utilizar una tabla de Clientes, otra de Empleados, otra de Proveedores, etc., en las que se detallaría la información relativa a los atributos considerados para cada uno de los clientes, empleados, proveedores, etc.

La tabla correspondiente a la entidad-tipo de empleados podría incluir la información que aparece en esta tabla:

Para garantizar la individualidad de cada una de las filas debe haber siempre un campo identificativo de cada uno de los individuos al que se le suele dar el nombre de clave principal o primaria ( primary key ).Debe ser un campo que no pueda repetirse en dos individuos distintos, en el ejemplo anterior podría ser el número de identificación de empleado, o su número de la seguridad social.

Llegados hasta aquí, parece simple cómo representar las entidades-tipo, sus atributos y todas las realizaciones individuales de ellas ( todos los individuos), pero nos queda especificar un procedimiento para poder dar una adecuada representación a las relaciones.

Las relaciones también debe representarse mediante tablas. Con carácter general una relación se representaría mediante una tabla que tuviera por clave primaria una combinación de las claves primarias de los objetos relacionados. Sin embargo, en algunos casos representar una relación no exige necesariamente, crear un nueva tabla; especialmente si la relación no tiene propiedades propias más allá de las de los individuos que la componen.

Debemos empezar por distinguir entre dos posibilidades de relación: relación de uno a muchos (1-a-n ) y relación de muchos a muchos ( m-a-n):

Una relación de 1-a-n es aquella en la que cada elemento del conjunto A puede estar relacionado con muchos elementos del conjunto B, pero cada elemento de B sólo esta relacionado con un elemento de A.

En cambio en una relación de m-a-n cada uno de los elementos del conjunto A puede estar en relación con muchos del conjunto B y, también cada uno de los de B puede estar en relación con muchos de los de A.

En el ejemplo que estamos considerando, podemos estar interesados en representar la relación existente entre el conjunto de clientes y el conjunto de posibles procedimientos de facturación de los servicios, ( pago por servicio, cuota anual, iguala mensual, etc.).Obviamente, esta relación es una relación de uno a muchos, ya que, si bien una misma forma de pago puede aplicarse a muchos clientes, cada cliente sólo pagará sus servicios de única forma.

Este tipo de relaciones son muy fáciles de representar, sin necesidad de introducir una nueva tabla. En efecto, como cada empresa cliente, que está representada por una fila distinta de la tabla de clientes sólo presenta un tipo de forma de pago, basta con añadir un nuevo campo en la tabla de clientes para incluir en la base de datos esta relación.

Sin embargo si consideramos la relación entre los clientes y el conjunto de los servicios de asesoría prestados; la relación sería , en principio, de muchos a muchos ya que se puede prestar un mismo servicio a varios clientes y un único cliente puede requerirnos varios servicios de asesoría ( contable, financiera, fiscal, legal, laboral).Ello exigiría, introducir una nueva tabla, para representar la relación. Sin embargo, en algunos casos, haciendo una adecuada partición de uno de los dos conjuntos relacionados, podemos convertir una relación de m-a-n en varias relaciones distintas del tipo 1-a-n.

Veámoslo en nuestro ejemplo:Si consideramos que el conjunto de servicios que se prestan esta formado exclusivamente por los servicios de asesoría contable, financiera, fiscal, legal y laboral; podemos sustituir la relación "clientes/ servicios" por cinco relaciones "clientes/ cada uno de los servicios". Para cada una de éstas nuevas relaciones cada uno de los cinco conjuntos consta de dos elementos ( verdadero/falso, o si/no, o 1/0) según si para ese cliente se presta ese servicio o no ; y, de esta forma, hemos convertido la relación original en cinco relaciones del tipo 1-a-n; fácilmente representable, añadiendo cinco nuevos campos a la tabla de clientes, tal y como se muestra en el siguiente cuadro:

Sin embargo, si nos encontramos ante la necesidad de representar una relación de muchos a muchos, que no permite, esta estrategia, la solución al no problema no es tan simple. Si, por ejemplo, el conjunto de servicios ofrecido no fuera limitado  (cinco en nuestro caso), sino que pudiera modificarse repetidas veces con el tiempo, no hubiera sido conveniente esta forma de representación, ya que necesitaría, no sólo de una constante actualización de los datos ( lo que es siempre inevitable) sino también de una constante actualización de la estructura de la base de datos (lo que no es nada conveniente).

Para tales casos, y para casos de relación m-a-n más compleja, en la que la relación de muchos a muchos tiene características ( atributos) propias, no queda más remedio que introducir una nueva tabla para representar la relación. Una tabla en la que cada fila incluirá cada una de las parejas de elementos (de ambos conjuntos) que realmente se relacionan.

Por ilustrarlo con un ejemplo, si en el caso de la relación anterior, queremos para cada servicio prestado a cada empresa cliente, constatar cuál de nuestros empleados asesores lo ha llevado a cabo, o cuál ha sido el importe del servicio; esto no puede hacerse por el procedimiento anterior. Deberemos crear una nueva tabla en la que para cada empresa y servicio prestado, se detallen los demás atributos de interés, tal y como se muestra en la siguiente tabla:

Después de ver la forma de representar las relaciones a través de tablas señalemos dos condiciones de coherencia que debe cumplir toda representación de datos mediante tablas (Date, 1983):

Cada tabla debe incluir una clave primaria: una columna o combinación de columnas que sirve de identificador de cada una de las filas. Todos los valores de la clave primaria deben estar definidos (unívocamente).

Cuando en una tabla T2, alguno de los campos es la clave primaria de otra tabla T1, los valores de ese atributo en T2 debe ser valores de la clave primaria de T1 , o bien deben estar indefinidos.

Por último nos queda señalar, que junto con la componente estructural, el modelo tabular de representación de entidades, atributos y relaciones, un gestor de bases de datos debe incorporar una componente funcional que permitan operar con la información adecuadamente, facilitando, al menos las siguientes operaciones:

Crear la base de datos: crear y nombrar tablas, especificar sus estructuras de campos, con sus propiedades.

Introducir los datos

Mantener la base de datos, facilitando procedimientos de actualización y automatismos para la modificación de los distintos ítems en todas las tablas en las que aparezcan

Recuperar la información, permitiendo seleccionar determinada información según distintos criterios, realizar informes que detallen las partes requeridas del conjunto de datos, pero no su totalidad, etc.