Unidad 4

4.1 CONCEPTOS BÁSICOS

La normalización es el proceso de organizar los datos. Se incluye la creación de tablas y el establecimiento de relaciones entre ellas según reglas diseñadas tanto para proteger los datos como para hacer que la base de datos sea más flexible.

Los datos redundantes desperdician el espacio de disco y crean problemas de mantenimiento. Si hay que cambiar datos que existen en más de un lugar, se deben cambiar de la misma forma exactamente en todas sus ubicaciones. Un cambio en la dirección de un cliente es mucho más fácil de implementar si los datos sólo se almacenan en la tabla Clientes y no en algún otro lugar de la base de datos.

Uno de los parámetros que mide la calidad de una base de datos es la forma normal en la que se encuentra su diseño. Puede alcanzarse cumpliendo ciertas restricciones que impone cada forma normal al conjunto de atributos de un diseño. Obligar a los atributos de un diseño a cumplir ciertas formas normales se llama normalización.

Las formas normales pretenden alcanzar dos objetivos:

1.- Almacenar en la base de datos cada hecho solo una vez, es decir, evitar la redundancia de datos. De esta manera se reduce el espacio de almacenamiento.

2.- Que los hechos distintos se almacenen en sitios distintos.

4.2 PRIMERA FORMA NORMAL

Esta primera forma normal, nos lleva a no repetir datos en nuestras tablas. Si nuestra tabla de ventas repite una y otra vez, el nombre, el domicilio y otros datos del Cliente, es que no hemos aplicado esta normalizaciòn. Si tenemos una tabla clientes, en la tabla ventas, solo debería figurar el código del cliente, para que el resto de los datos se puedan referenciar automaticamente en el proceso.

Lo mismo ocurriría en una tabla de detalle de ventas, si por cada producto vendido colocamos el detalle del producto, con su descripción , medidas, etc. Tendriamos un desaprovechamiento de espacio y recursos muy grande. Para ello, tendremos nuestra tabla maestra de Productos y con solo grabar el código de dicho producto.

4.3 DEPENDENCIAS FUNCIONALES Y TRANSITIVAS

Intentaremos aclarar este concepto tan teórico con un ejemplo. Si tenemos esta relación:

Ciudades(ciudad, población, superficie, renta, país, continente)

Los atributos como población, superficie o renta tienen dependencia funcional de ciudad, así que de momento no nos preocupan.

En esta relación podemos encontrar también las siguientes dependencias: ciudad -> país, país -> continente. Además, país -> ciudad. Es decir, cada ciudad pertenece a un país y cada país a un continente, pero en cada país puede haber muchas ciudades. En este caso continente tiene una dependencia funcional transitiva con respecto a ciudad, a través de país. Es decir, cada ciudad está en un país, pero también en un continente.

4.4 SEGUNDA FORMA NORMAL

La Segunda Forma Normal nos habla de que cada columna de la tabla debe depender de la clave. Esto significa que todo un registro debe depender únicamente de la clave principal, si tuvieramos alguna columna que se repite a lo largo de todos los registros, dichos datos deberian atomizarse en una nueva tabla.:

Si toda una venta tendrá el mismo numero de Cliente y la misma Fecha. ¿Por que no crear una Tabla de VENTAS y que contenga esos 2 datos? Es evidente que la columna ClienteVenta y FechaVenta se repetirán por cada venta realizada.

Y ahora nuestra nueva tabla:

4.5 TERCERA FORMA NORMAL

La Tercera Forma Normal nos habla de que: ninguna columna puede depender de una columna que no tenga una clave y no puede haber datos derivados.

En el ejemplo anterior se notan campos que dependian de la clave principal y que podrian incluirse en una tabla maestra. Pero supongamos un ejemplo donde ciertas columnas no dependen de la clave principal y si dependen de una columna.

Los campos DESCRIPCION, MEDIDA y PROVEEDOR no dependen de VENTAID, no deberian estar dentro de la tabla de detalle de ventas, ya que dependen de PRODUCTOID. No se trata ya de eliminar grupos repetidos de datos, sino que ante la inclusion de una clave perteneciente a otra tabla, cualquier campo que sea subordinado de dicha clave debe estar en otra tabla y no en nuestra tabla detalle.

4.6 FORMA NORMAL BOYCE-CODD

Una relación está en Forma Normal Boyce-Codd si cualquier atributo sólo facilita información sobre claves candidatas, y no sobre atributos que no formen parte de ninguna clave candidata. Esto significa que no deben existir interrelaciones entre atributos fuera de las claves candidatas.

Para ilustrar esta forma normal tomemos como ejemplo lo siguiente.

Las ocupaciones de habitaciones de un hotel.
Ocupación(No_cliente, Nombre_cliente, No_habitación, fecha_entrada)
Habitación(No_habitación(PK), precio_noche, tipo_habitación)

En la primera relación los atributos No_cliente y Nombre_cliente sólo proporcionan información entre ellos mutuamente, pero ninguno de ellos es una clave candidata.

Esta estructura puede producir redundancia, en clientes habituales, donde se repetirá la misma información cada vez que el mismo cliente se aloje en el hotel.

La solución es simple, y consiste en separar esta relación en dos diferemtes:
Ocupación(No_cliente, No_habitación, fecha_entrada)
Cliente(No_cliente(PK), Nombre_cliente)
Habitación(No_habitación(PK), precio_noche, tipo_habitación)

4.7 OTRAS FORMAS NORMALES

Tomemos por ejemplo la tabla Agenda, dejando sólo los atributos multivaluados: Agenda(nombre, teléfono, correo)

Lo primero que debemos hacer es buscar las claves y las dependencias. Recordemos que las claves candidatas deben identificar de forma unívoca cada tupla. De modo que estamos obligados a usar los tres atributos para formar la clave candidata.

Pero las dependencias que tenemos son:
nombre ->-> teléfono
nombre ->-> correo

Y nombre no es clave candidata de esta relación.

Debemos separar esta relación en varias, tantas como atributos multivaluados tenga.
Teléfonos(nombre, teléfono)
Correos(nombre, correo)

Ahora en las dos relaciones se cumple la cuarta forma normal.

QUINTA FORMA NORMAL 5FN

Existe una quinta forma normal, sirve para eliminar dependencias de proyección, que raramente se encuentran en las bases de datos vistas con regularidad.

Fuentes de información

Modelo Relacional: Normalización

Normalización de Bases de Datos