Normalizacion de Bases de Datos

La normalización es la transformación de las vistas de usuario complejas y del almacén de datos a un juego de estructuras de datos más pequeñas y estables. Además de ser más simples y estables, las estructuras de datos son más fáciles de mantener que otras estructuras de datos. (Kendall, 2005).

La normalización de bases de datos es un proceso que consiste en designar y aplicar una serie de reglas a las relaciones obtenidas tras el paso del modelo entidad-relación al modelo relacional. Con objeto de minimizar la redundancia de datos, facilitando su gestión posterior.

Una vez obtenido el esquema relacional resultantes del modelo entidad relación que representaba la base de datos, normalmente tendremos una buena base de datos. Pero otras veces, debido a fallos en el diseño o a problemas indetectables en esta fase del diseño, tendremos un esquema que puede producir una base de datos que incorpore estos problemas:

Redundancia. Se llama así a los datos que se repiten continua e innecesariamente por las tablas de las bases de datos.

Ambigüedades. Datos que no clarifican suficientemente el registro al que representan.

Tiene tres Formas:

Primera Forma Normal

Es la forma normal propia al esquema relacional, de uso obligatorio.

Todos los atributos llave están definidos.
No hay grupos repetidos en la tabla. Cada fila/columna contiene un solo valor, no un conjunto de ellos.
Todos los atributos son dependientes de la llave primaria.
Todos los atributos son atómicos. Un atributo es atómico si los elementos del dominio son simples e indivisibles.
No debe existir variación en el número de columnas.
Los campos no clave deben identificarse por la clave (dependencia funcional).
Debe existir una independencia del orden tanto de las filas como de las columnas; es decir, si los datos cambian de orden no deben cambiar sus significados.

Algunos ejemplos de tablas (o de vistas) que no satisfacen esta definición de primera forma normal son:

Una tabla que carece de una clave primaria. Esta tabla podría acomodar filas duplicadas, en violación de la condición de filas duplicadas.
Una vista cuya definición exige que los resultados sean retornados en un orden particular, de modo que el orden de la fila sea un aspecto intrínseco y significativo de la vista. Las tuplas en relaciones verdaderas no están ordenadas una con respecto de la otra.
Una tabla con por lo menos un atributo que pueda ser nulo. Un atributo que pueda ser nulo estaría en violación de la condición 4, que requiere a cada campo contener exactamente un valor de su dominio de columna. Sin embargo, debe observarse que este aspecto de la condición 4 es controvertido. Muchos autores consideran que una tabla está en 1FN si ninguna clave candidata puede contener valores nulos, pero se aceptan éstos para atributos (campos) que no sean clave, según el modelo original de Codd sobre el modelo relacional, el cual hizo disposición explícita para los nulos.Es imperativo mantener la unicidad de los valores de los atributos/columnas. En que si bien la solución inicial puede ser duplicar el registro/tupla para contener la información adicional, no es una medida aceptada. Otra opción aparente sería agregar curso 1 y curso 2. Al igual que lo indicado en la figura siguiente permtiría atributos en blanco o nulos.
Entonces, la solución pasa por la creación de otra entidad/tabla para el almacenamiento de teléfonos.

Segunda forma normal

Cree tablas independientes para conjuntos de valores que se apliquen a varios registros.

Relacione estas tablas con una clave externa.

Los registros no deben depender de nada que no sea una clave principal de una tabla, una clave compuesta si es necesario. Por ejemplo, considere la dirección de un cliente en un sistema de contabilidad. La dirección se necesita en la tabla Clientes, pero también en las tablas Pedidos, Envíos, Facturas, Cuentas por cobrar y Colecciones. En lugar de almacenar la dirección de un cliente como una entrada independiente en cada una de estas tablas, almacénela en un lugar, ya sea en la tabla Clientes o en una tabla Direcciones independiente.

Tercera forma normal

Elimine los campos que no dependan de la clave.

Los valores de un registro que no sean parte de la clave de ese registro no pertenecen a la tabla. En general, siempre que el contenido de un grupo de campos pueda aplicarse a más de un único registro de la tabla, considere colocar estos campos en una tabla independiente.

Por ejemplo, en una tabla Contratación de empleados, puede incluirse el nombre de la universidad y la dirección de un candidato. Pero necesita una lista completa de universidades para enviar mensajes de correo electrónico en grupo. Si la información de las universidades se almacena en la tabla Candidatos, no hay forma de enumerar las universidades que no tengan candidatos en ese momento. Cree una tabla Universidades independiente y vincúlela a la tabla Candidatos con el código de universidad como clave.

EXCEPCIÓN: cumplir la tercera forma normal, aunque en teoría es deseable, no siempre es práctico. Si tiene una tabla Clientes y desea eliminar todas las dependencias posibles entre los campos, debe crear tablas independientes para las ciudades, códigos postales, representantes de venta, clases de clientes y cualquier otro factor que pueda estar duplicado en varios registros. En teoría, la normalización merece el trabajo que supone. Sin embargo, muchas tablas pequeñas pueden degradar el rendimiento o superar la capacidad de memoria o de archivos abiertos.

Puede ser más factible aplicar la tercera forma normal sólo a los datos que cambian con frecuencia. Si quedan algunos campos dependientes, diseñe la aplicación para que pida al usuario que compruebe todos los campos relacionados cuando cambie alguno.