Master en diseño Web.

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.

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.

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.

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.

● 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 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:

Transformación de entidades débiles.

● 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.

Transformaciones de relación.

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

Excepciones de transformación de la relación.

● 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.

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.

● 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:

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.

● 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.

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).

Forma Normal 2.

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

Tercera Forma Normal (3FN).

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:

Forma normal de Boyce-Codd (FNBC).

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: