4 Modelo Relacional: Normalización

Llegamos al último proceso netamente teórico del modelado de bases de datos: la normalización. La normalización no es en realidad una parte del diseño, sino más bien una herramienta de verificación. Si hemos diseñado bien los módelos conceptual y lógico de nuestra bases de datos, veremos que la normalización generalmente no requerirá cambios en nuestro diseño.

Normalización  

Antes de poder aplicar el proceso de normalización, debemos asegurarnos de que estamos trabajando con una base de datos relacional, es decir, que cumple con la definición de base de datos relacional.

El proceso de normalización consiste verificar el cumplimiento de ciertas reglas que aseguran la eliminación de redundancias e inconsistencas. Esto se hace mediante la aplicación de ciertos procedimientos y en ocasiones se traduce en la separación de los datos en diferentes relaciones. Las relaciones resultantes deben cumplir ciertas características:

• Se debe conservar la información:
• Conservación de los atributos.
• Conservación de las tuplas, evitando la aparición de tuplas que no estaban en las relaciones originales.
• Se deben conservar las dependencias.

Este proceso se lleva a cabo aplicando una serie de reglas llamadas "formas normales".

Estas reglas permiten crear bases de datos libres de redundancias e inconsistencias, que se ajusten a la definición del doctor Codd de base de datos relacional.

MySQL usa bases de datos relacionales, de modo que deberemos aprender a usar con soltura, al menos, las tres primeras formas normales.

La teoría completa de bases de datos relacionales es muy compleja, y puede resultar muy oscura si se expresa en su forma más simbólica. Ver esta teoría en profundidad está fuera de los objetivos de este curso, al menos por el momento.

Sin embargo, necesitaremos comprender bien parte de esa teoría para aplicar las tres primeras formas normales. La comprensión de las formas cuarta y quinta requieren una comprensión más profunda de conceptos complejos, como el de las dependencias multivaluadas o las dependencias de proyección.

Generalmente, en nuestras aplicaciones con bases de datos (que podríamos calificar como domésticas o pequeñas), no será necesario aplicar las formas normales cuarta y quinta, de modo que, aunque las explicaremos lo mejor que podamos, no te preocupes si no consigues aplicarlas por completo.

Por otra parte, si estos conceptos no queden suficientemente claros la culpa es completamente nuestra, por no ser capaces de explicarlos claramente.

Pero ánimo, seguro que en poco tiempo aprendemos a crear bases de datos fuertes y robustas. Pero antes, y sintiéndolo mucho, debemos seguir con algunas definiciones más.

Primera forma normal (1FN)  

Definición: Para que una base de datos sea 1FN, es decir, que cumpla la primera forma normal, cada columna debe ser atómica.

Atómica no tiene que ver con la energía nuclear :-), no se trata de crear columnas explosivas ni que produzcan grandes cantidades de energía y residuos radiactivos...

Atómica significa "indivisible", es decir, cada atributo debe contener un único valor del dominio. Los atributos, en cada tabla de una base de datos 1FN, no pueden tener listas o arrays de valores, ya sean del mismo dominio o de dominios diferentes.

Además, cada atributo debe tener un nombre único. Esto es algo que en general, al menos trabajando con MySQL, no nos preocupa; ya que la creación de las tablas implica definir cada columna de un tipo concreto y con un nombre único.

Tampoco pueden existir tuplas idénticas. Esto puede parecer obvio, pero no siempre es así. Supongamos una base de datos para la gestión de la biblioteca, y que el mismo día, y al mismo socio, se le presta dos veces el mismo libro (evidentemente, el libro es devuelto entre cada préstamo, claro). Esto producirá, si no tenemos cuidado, dos registros iguales. Debemos evitar este tipo de situaciones, por ejemplo, añadiendo una atributo con un identificador único de préstamo.

Como vemos, las restrinciones de la primera forma normal coinciden con las condiciones de las relaciones de una base de datos relacional, por lo tanto, siempre es obligatorio aplicar esta forma normal.

Aplicar la primera forma normal es muy simple, bastará con dividir cada columna no atómica en tantas columnas atómicas como sea necesario. Por ejemplo, si tenemos una relación que contiene la información de una agenda de amigos con este esquema:

Agenda(Nombre, email)

El nombre, normalmente, estará compuesto por el tratamiento (señor, señora, don, doña, excelencia, alteza, señoría, etc), un nombre de pila y los apellidos. Podríamos considerar el nombre como un dato atómico, pero puede interesarnos separar algunas de las partes que lo componen.

¿Y qué pasa con la dirección de correo electrónico? También podemos considerar que es un valor no atómico, la parte a la izquierda del símbolo @ es el usuario, y a la derecha el dominio. De nuevo, dependiendo de las necesidades del cliente o del uso de los datos, podemos estar interesados en dividir este campo en dos, o incluso en tres partes (puede interesar separar la parte a la derecha del punto en el dominio).

Tanto en esta forma normal, como en las próximas que veremos, es importante no llevar el proceso de normalización demasiado lejos. Se trata de facilitar el trabajo y evitar problemas de redundancia e integridad, y no de lo contrario. Debemos considerar las ventajas o necesidades de aplicar cada norma en cada caso, y no excedernos por intentar aplicar las normas demasiado al pié de la letra.

El esquema de la relación puede quedar como sigue:

Agenda(Nombre_Tratamiento, Nombre_Pila, Nombre_Apellidos, email)

Otro caso frecuente de relaciones que no cumplen 1FN es cuando existen atributos multivaluados, si todos los valores se agrupan en un único atributo:

Libros(Titulo, autores, fecha, editorial)

Hemos previsto, muy astutamente, que un libro puede tener varios autores. No es que sea muy frecuente pero sucede, y más con libros técnicos y libros de texto.

Sin embargo, esta relación no es 1FN, ya que en la columna de autores sólo debe existir un valor del dominio, por lo tanto debemos convertir ese atributo en uno multivaluado:

Libros
Titulo                autor     fecha       editorial
Que bueno es MySQL    fulano    12/10/2003  La buena
Que bueno es MySQL    mengano   12/10/2003  La buena
Catástrofes naturales tulano    18/03/1998  Penútriga