El modelo relacional.

El objetivo principal del modelo relacional es proteger al usuario de la obligación de conocer las estructuras de datos con las que se representan las informaciones en una BBDD.

Al realizar la conversión al modelo relacional, los datos del anterior modelo entidad - relación pueden ser tratados por un sistema gestor de BBDD.

En este capítulo hablaremos sobre las características fundamentales del modelo relacional y aprenderemos a transformar el anterior modelo.

Conceptos básicos.
El modelo de datos relacional se almacena en tablas, que también se denominan relaciones. Una tabla es la forma en la que el usuario ve sus datos. Se divide horizontalmente en filas y verticalmente en columnas.

Una fila representa un registro o un grupo de valores de campos que contienen la información de la entidad en la tabla.

Una columna contiene información referente a un único campo o atributo.

tabla convencional

Pero a la hora de modelar hay que seguir una serie de pasos:

● Todos los registros de una tabla son del mismo tipo.
● Cada campo se almacena en una columna de la tabla.
● Cada columna se identifica mediante un nombre de columna.
● No se permite la duplicidad de columnas en la misma tabla (campos iguales).
● En ninguna tabla existirán campos duplicados.
● El orden de los registros es indiferente.
● En cada momento se pueden recuperar los registros mediante consultas (query).

A cada una de las filas de una tabla se la denomina tupla. Y a cada columna se la denomina atributo. La cardinalidad de una tabla es el número de filas que contiene y el grado de una tabla es el número de columnas. Además cada fila de la tabla debe de ser identificada de forma única por un atributo o conjunto de los mismos que se llamarán clave de la tabla o primaria.

grado y cardinalidad en una tabla

Al conjunto posible de valores que puede coger una columna se le denomina dominio siendo de dos tipos:

Dominio continuo: Los atributos toman todos los valores comprendidos entre un mínimo y máximo.
Dominio discreto: Solo tomarán valores comprendidos en un rango especificado.

Conversión.

La normalización es el proceso de imponer a las relaciones ciertas restricciones mediante una serie de transformaciones consecutivas. Con esto nos aseguramos de que la tabla tenga los atributos necesarios para describir coherentemente las entidades que representan.

De tal proceso, obtenemos las tablas quedan organizadas de forma óptima para su implementación, gestión y operatibilidad de sus datos.

Restricciones.
Podemos hablar de restricciones en las condiciones que han de cumplir los datos para su almacenamiento adecuado. Así exiten:

De clave: Conjunto de atributos que identifican de forma única a una entidad.
Restricciones de valor: UNIQUE. Es una restricción que impide que un atributo tenga un valor repetido.
Restricciones de integridad referencial: Se da cuando una tabla tiene una referencia a algún valor de otra tabla.
Restricciones de dominio: Establece que el valor que puede tomar un atributo esté dentro de dichas características del dominio.
Restricciones de comprobación: CHECK. Comprueba si el valor del atributo es válido conforme a una expresión.
Restricciones de valor: NULL.Un atributo puede ser obligatorio si no admite el valor NULL.
Triggers: O disparadores: Son acciones que se ejecutan para hacer ciertas tareas (scripts).
Restricciones genéricas o aserciones: Permiten validar atributos de una o varias tablas.

Transformación de diagrama Entidad-Relación al relacional.
Para la transformación del modelo antiguo al modelo relacional se siguen una serie de pasos.

diagrama entidad relación

Para cada entidad fuerte con sus atributos correspondientes, se crea una tabla con el nombre en plural de la entidad correspondiente, y con n columnas correspondientes a cada atributo de la propia entidad. Así que cada fila de la tabla por entidad corresponde a una ocurrencia de dicha entidad. La clave primaria la forman los atributos clave de la entidad A.

Si extrapolamos:

CATEGORIAS (Código, Descrición)
PRODUCTOS (Id, Nombre, Precio, Descripción)

Transformación de entidades débiles.
Para cada entidad débil con sus atributos anexados, y otra entidad fuerte de la que depende la entidad débil, se crea una tabla con los atributos de la entidad fuerte y la entidad débil. Y hayq ue tener en cuenta que:

● si solo tiene dependencia de existencia, la clave primaria de la entidad fuerte será la propia.
● Si la entidad débil tuviese además una dependencia de identificación, la clave primaria de la entidad fuerte será la unión de los atributos de la entidad débil y la entidad fuerte.

entidad fuerte y débil

CUENTAS_BANCARIAS (NºCuenta, saldo)
TRANSACCIONES (Código, Tipo, Cantidad)

Transformaciones de relación.
Por cada relación entre entidades se establece también una representación según una serie de normas que hay que tener en cuenta.

Se crea una tabla con todos los campos claves de las entidades y con los propios atributos de la relación.

Relaciones y entidades

AULAS (Número, Planta, Situación)
ESTUDIANTES (NºMatricula, Nombre, Dirección)
ASIGNATURAS (Nombre, Ciclo, Descripción)
ESTUDIOS(Número, Planta, NºMatricula,Nombre, ciclo, hora)

Excepciones de transformación de la relación.
La regla general no se aplica siempre a la creación de contenido y se dan las siguientes excepciones:

● Relaciones con cardinalidad 1:N
No se crea tabla para la relación, sino que se añade a la entidad con máxima participación (N), la clave de la entidad que actúa con participación máxima 1 (como calve foránea). Además si la relación tuviese atributos se importarían a la tabla de mayor participación N.

Relación 1-N

Y la transformación queda como se expresa en la siguiente tabla. Observa que en este caso no se han creado la tabla para la relación, sino que se ha añadido la tabla ACTORES la clave foránea NºLicencia_representante que hacia referencia al campo de NºLicencia de la tabla REPRESENTANTES. También se le ha añadido el atributo Contrato a dicha tabla.

ACTORES (Código, NombreArtístico, NombreReal, Nº_Licencia_Representante, Contrato)
REPRESENTANTES (NºLicencia, Nombre)

● Relaciones reflexivas de cardinalidad 1-N
En este caso tampoco se crea una tabla para la relación. Hay que crear una tabla con el nombre de la entidad, añadiendole otra vez la clave cambiada de nombre:

reflexivas con cardinalidad 1:N

La tabla única que se obtiene es la siguiente porque el empleado solo puede tener un jefe, por lo tanto se incorpora el DNI del jefe del empleado DNISupervisor), como clave foránea.

EMPLEADOS (DNI, Nombre, DNISupervisor)

● Relaciones 1-1
Este tipo de relaciones tampoco generan tabla. El paso de la tabla se realiza de igual forma que la general (relaciones 1-N). En este caso tampoco se genera tabla para la relación y se tiene la libertad de incorporar la clave de una de ellas en la otra.

relacion 1-1 no genera tabla

ACTORES (Código, Nombre, CódigoPersonaje)
PERSONAJES (Código, Nombre, Película)

He incorporado la clave de Personajes como clave foránea en la tabla actores.

Dependencias formales.

Habitualmente el diseño de una BBDD temina con el paso del modelo entidad-relación al modelo relacional. Sin embargo, siempre que se diseña un sistema informático se ha de medir la calidad del sistema, y si no cumple determinados criterios de calidad, hay que realizar de forma iterativa, sucesivos refinamientos en el diseño para conseguir la calidad deseada.

En una base de datos, los parametros que miden la calidad es la forma normal. Esta forma normal cumple ciertas restricciones al conjunto de atributos de un sistema. El proceso de obligar a ciertos atributos de un diseño a cumplir cierta forma normal se llama normalización.

Las formas normales pretenden alcanzar dos objetivos:

● 1. Almacenar en la BBDD cada hecho solo una vez, es decir evitar la redundancia de datos. De esta forma se reduce el espacio de la BBDD.

● 2. Que los hechos se almacenen en distintos sitios. Así se evitan anomalías al operar con los datos.

En la medida que se alcanzan mas formas normales, se avanza en la perfección de los objetivos. Cada forma normal, agrepa a la anterior.

Conceptos previos.

Dependencia funcional → Sean X e Y subconjuntos de atributos de una relación. Diremos que Y tiene una dependencia funcional de X, o que X determina a Y, si cada valor de X tiene asociado siempre un único valor de Y.
Dependencia funcional completa → En una dependencia funcional X -> Y, cuando X es un conjunto de atributos, decimos que la dependencia funcional es completa , si sólo depende de X, y no de ningún subconjunto de X.
Dependencia funcional transitiva → Supongamos que tenemos una relación con tres conjuntos de atributos: X, Y y Z,y las siguientes dependencias X -> Y, Y -> Z, Y -> |X. Es decir X determina Y e Y determina Z, pero Y no determina X. En ese caso, decimos que Z tiene dependencia transitiva con respecto a X, a través de Y.

Forma Normal 1 (FN1).
Para cumplir con esta forma normal debemos evitar que existan atributos multivaluados en nuestra tabla. En el siguiente ejemplo podemos la diferencia entre una misma tabla cumpliendo FN1 y sin hacerlo.

forma normal 1

Forma Normal 2.
Diremos que un modelo de datos está en FN2 si y sólo sí se encuentra en FN1 y cada atributo que no forma parte de la clave tiene dependencia completa de la misma.

LineaVenta(CodVenta, CodProd, cantidad, nombreProducto)

Como podemos ver, nombreProducto no depende directamente de la clave de LineaVenta sino que es un atributo de producto, por tanto debería quedar:

LineaVenta(CodVenta, CodProd, cantidad)
Productos(CodProd, nombreProducto)

Tercera Forma Normal (3FN).
Diremos que un modelo se encuentra en FN3 si y sólo sí se encuentra en FN2 y además, no existe ningún atributo no clave que dependa transitivamente de la clave.

Peliculas(Nombre, Género, Director, Fecha_Nacimiento)

Tanto género como director dependen completamente de la clave, sin embargo, la fecha de nacimiento presenta una dependencia transitiva con la película, pues realmente depende de Director. Por tanto:

Peliculas(Nombre, Género, Director)
Director(NIF, Nombre, Apellidos, Fecha_Nacimiento)

Forma normal de Boyce-Codd (FNBC).
Diremos que un módelo se encuentra en FNBC si y sólo sí se encuentra en 3FN y además no existe ningún determinante (Atributo con el que otro presenta una dependencia funcional completa) que no sea clave candidata.

ProductosProveedor(Cod_prod, cod_prov, CIF_Prov)

El propósito de esta tabla es mostrar información sobre qué proveedor nos proporciona cada producto, por tanto las claves candidatas serían {Cod_prod, Cod_Prov} o bien {Cod_prod, CIF_Prov} en cualquiera de los dos casos existe un determinante que no forma parte de la clave candidata. Para que esta relación quedase en FNBC:

ProductosProveedor(Cod_Prod, Cod_Prov)
Proveedores(Cod_Prov, CIF_Prov)