Normalizacion de base de datos

Normalización de bases de datos

La normalización de bases de datos es un proceso importante en el diseño de bases de datos relacionales 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.

Objetivo

Las bases de datos relacionales se normalizan para:

·         Minimizar la redundancia de los datos.

·         Disminuir problemas de actualización de los datos en las tablas.

·         Proteger la integridad de datos.

·         En el modelo relacional es frecuente llamar «tabla» a una relación; para que una tabla sea considerada como una relación tiene que cumplir con algunas restricciones:

o   Cada tabla debe tener su nombre único.

o   No puede haber dos filas iguales. No se permiten los duplicados.

o   Todos los datos en una columna deben ser del mismo tipo.

 

Primera forma normal

Elimine los grupos repetidos de las tablas individuales.

Cree una tabla independiente para cada conjunto de datos relacionados.

Identifique cada conjunto de datos relacionados con una clave principal.

No use varios campos en una sola tabla para almacenar datos similares. Por ejemplo, para realizar el seguimiento de un elemento del inventario que proviene de dos orígenes posibles, un registro del inventario puede contener campos para el Código de proveedor 1 y para el Código de proveedor 2.

 

¿Qué ocurre cuando se agrega un tercer proveedor? Agregar un campo no es la respuesta, requiere modificaciones en las tablas y el programa, y no admite fácilmente un número variable de proveedores. En su lugar, coloque toda la información de los proveedores en una tabla independiente denominada Proveedores y después vincule el inventario a los proveedores con el número de elemento como clave, o los proveedores al inventario con el código de proveedor como clave.

 

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.

 

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.

 

Normalización de una tabla de ejemplo

Estos pasos demuestran el proceso de normalización de una tabla de alumnos ficticia.

 

Tabla sin normalizar:

 

Nº alumno          Tutor     Despacho-Tut   Clase1   Clase2   Clase3

1022      García   412         101-07  143-01  159-02

4123      Díaz       216         101-07  143-01  179-04

Primera forma normal: sin 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.

 

Las hojas de cálculo suelen usar la tercera dimensión, pero las tablas no deberían hacerlo. Otra forma de considerar ese problema es con una relación de uno a varios y poner el lado de uno y el lado de varios en tablas distintas. En su lugar, cree otra tabla en la primera forma normal eliminando el grupo repetido (Nº clase), según se muestra a continuación:

 

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         101-07

4123      Díaz       216         143-01

4123      Díaz       216         179-04

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 (la clave principal), de modo que la relación no cumple la segunda forma normal.

 

Las tablas siguientes demuestran la segunda forma normal:

 

Alumnos:

 

Nº alumno          Tutor     Despacho-Tut

1022      García   412

4123      Díaz       216

Registro:

 

Nº alumno          Nº clase

1022      101-07

1022      143-01

1022      159-02

4123      101-07

4123      143-01

4123      179-04

Tercera forma normal: eliminar los datos que no dependen de la clave

 

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

 

Alumnos:

Nº alumno          Tutor

1022      García

4123      Díaz

Personal:

 

Nombre              Sala        Dept.

García   412         42

Díaz       216         42