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)