Normalización de Base de Datos

UNIDAD 6

En esta unidad aprenderá:

1. Qué es Normalización
2. Reglas de normalización para cada Forma Normal.
3. Otras formas de Normalización
4. Ejemplo de Normalización de una base de datos.
5. Recomendaciones generales para el buen diseño de una base de datos.


Qué es Normalización
La normalización es un proceso de organizar los datos de una base de datos según reglas diseñadas con el objetivo de hacer evitar la redundancia en sus datos, las dependencias incoherentes y proteger la integridad de los datos.

La normalización de base de datos está definida por reglas. Cada regla se denomina "forma normal". Una base de datos bien diseñada debe cumplir por lo menos las primeras tres formas normales. Aunque es posible otros niveles de normalización, la “tercera forma normal” se considera el máximo nivel necesario para la mayoría de los modelo de base de datos relacionales.

Reglas de Normalización para cada forma normal:

Primera forma normal

1. Eliminar los grupos repetidos de las tablas individuales.
2. Crear una tabla independiente para cada conjunto de datos relacionados.
3. Identificar cada conjunto de datos relacionados con una clave principal.
4. No usar varios campos en una sola tabla para almacenar datos similares.

Segunda forma normal

1. Crear tablas independientes para conjuntos de valores que se apliquen a varios registros y relacionar estas tablas con una clave externa.
2. Los registros no deben depender de nada que no sea de su clave principal. Una clave compuesta si es necesario.

Tercera forma normal

1. Eliminar los campos que no dependan de la 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.

Otras formas de normalización

La cuarta forma normal, también llamada Forma normal de Boyce Codd (BCNF, Boyce Codd Normal Form), y la quinta forma normal existen, pero rara vez se consideran en un diseño real. Si no se aplican estas reglas, el diseño de la base de datos puede ser menos perfecto, pero no debería afectar a la funcionalidad.

Ejemplo de normalización de una Base de Datos

Dada la siguiente tabla, aplique el proceso de normalización.

Nº alumno	Tutor	Despacho-Tut	Clase1	Clase2	Clase3
1022	García	412	101-07	143-01	159-02
4123	Díaz	216	201-01	211-02	214-01

Primera forma normal: no hay grupos repetidos

Las tablas sólo deben tener dos dimensiones. Puesto que un alumno tiene varias clases, estas clases deben aparecer en una tabla independiente. Los campos Clase1, Clase2 y Clase3 de los registros anteriores son indicativos de un problema de diseño.

Una forma de considerar este problema es con una relación de “uno a varios” y poner el lado de uno y el lado de varios en tablas distintas. Por lo tanto, se modifica la tabla eliminando el grupo repetido (Nº clase):

Nº alumno	Tutor	Despacho-Tut	Nº clase
1022	García	412	101-07
1022	García	412	143-01
1022	García	412	159-02
4123	Díaz	216	201-01
4123	Díaz	216	211-02
4123	Díaz	216	214-01

Segunda forma normal: eliminar los datos redundantes

Observe los diversos valores de (Nº clase) para cada valor de (Nº alumno) en la tabla anterior. (Nº clase) no depende funcionalmente de (Nº alumno) que es la clave principal, de modo que la relación no cumple la segunda forma normal.

Las dos tablas siguientes demuestran la segunda forma normal:

Alumnos:

Nº alumno	Tutor	Despacho-Tut
1022	García	412
4123	Díaz	216

Clases:

Nº alumno	Nº clase
1022	101-07
1022	143-01
1022	159-02
4123	201-01
4123	211-02
4123	214-01

Tercera forma normal: eliminar los datos no dependientes de la clave

En el último ejemplo, (Despacho-Tut) que es el número de despacho del tutor es atributo  que depende funcionalmente del Tutor no del alumno. La solución es pasar ese atributo de la tabla Alumnos a la tabla Tutores, según se muestra a continuación:

Alumnos:

Nº alumno	Tutor
1022	García
4123	Díaz

Tutor:

Nombre	Despacho	Dept
García	412	Informática
Díaz	216	Contabilidad

Recomendaciones generales para el buen diseño de una base de datos:

1. Cada tabla debe tener un nombre único.
2. No pueden existir registros duplicados en una tabla.
3. El valor de todos los campos en una tabla deben ser atómicos. Su dominio es simple e indivisible.
4. La tabla contiene una clave primaria única para identificar cada registro.
5. La clave primaria no puede contener valores nulos.
6. Si para almacenar un grupo de datos se requieren varios registros, se deben crear tablas separadas y relacionarlas mediante una clave foránea.
7. No deben existir campos en un registro que no dependan de la  clave. (Dependencia Funcional).

Unidad 5 - Unidad 7