Normalización de la base de datos
La normalización de la base de datos es el proceso de organizar los datos siguiendo una serie de buenas prácticas y bases teóricas que desembocan en estructuras de datos saneadas. Esta normalización afecta, fundamentalmente, a las tablas y relaciones que las unen, así como restricciones y campos que los forman, para proteger la integridad de la información que almacenan entre otras ventajas. Esta integridad afecta, obviamente, al dato único, eliminando redundancias y dependencias innecesarias o, por el contrario, aportando las necesarias.
La normalización, ayudando a conseguir el dato único, tiende a eliminar la información redundante en las bases de datos que cumplen estas normas. Si el negocio exige un cambio en un dato, éste se propagará o afectará a otras tablas solo donde sea necesario.
Además, con la normalización ayudamos a eliminar dependencias no necesarias o relaciones que no deberían de existir. Por ejemplo, si tenemos un registro que nos identifica la información fiscal de una empresa, no deberíamos encontrar, en el mismo registro, calificadores que dependan de terceras tablas o que son temporales o se deba registrar un histórico.
Estas reglas o normas se denominan “formas normales” que se aplican en cascada, de manera que si se cumple la primera regla, es decir, la base de datos cumple la primera norma, se dice que la base de datos está en la “primera forma normal”. Si se cumplen las tres primeras reglas, la base de datos se considera que está en la “tercera forma normal”. Existen niveles superiores pero, en el sector, se asume que el cumplimiento de estas 3 primeras reglas es suficiente para aportar una coherencia profesional a una base de datos. En nuestro caso, el cumplimiento de estas 3 normas ayudarían claramente a que el CIO pueda tener facilidades para disponer del dato único.
Muchas veces, el proceso de “normalización” de una base de datos, si no se ha realizado desde su creación, requiere reestructuración, creación de nuevas tablas, nuevas relaciones, etc… siendo un trabajo considerable pues afecta tanto a los niveles de las bases de datos, negocio y aplicación de los sistemas de gestión.
Principales formas normales que ayudan a tener un dato único:
- Primera forma normal. En esta forma normal se debe disponer de una tabla independiente para cada conjunto de datos relacionados, identificando cada conjunto de datos relacionados con una clave principal. Además, los datos de significado similar no deben estar en una misma tabla. Por ejemplo, los stocks de un artículo, si tenemos multialmacén, no deben ser varios campos en una misma tabla del tipo “Stock almacen1”, “Stock almacen2”, etc… sino que debería estructurarse en una o más tablas donde se registre, por cada almacén y artículo, el stock.
- Segunda forma normal. Si tenemos información que se aplica a múltiples registros, ésta debe estar organizada en entidades separadas y unida con una clave ajena. Por ejemplo, supongamos que tenemos la información de un cliente que se utilizará en múltiples operaciones (venta, llamada, devolución, etc…); la información del cliente se organiza de forma independiente y única pero se relaciona con el resto de operaciones con una clave ajena.
- Tercera forma normal. Para cumplir esta forma normal debemos diseñar los datos de manera que en un mismo registro de una tabla, todos sus campos dependen de la clave primaria. Por ejemplo, en un registro de una venta, no debería almacenarse el stock del artículo ya que no tiene una dependencia directa con la venta. También se verían afectados campos calculados, como el stock de un producto concreto. Puede ser interesante aplicar la tercera forma normal sólo a los datos que cambian con frecuencia ya que, de lo contrario, se podría ver afectado el rendimiento de la base de datos al tener que desglosar, en numerosas tablas de menor tamaño, toda la información.
Existen otras formas normales pero, como hemos comentado, las tres primeras son clave en el diseño de una base de datos orientada al dato único. Siempre, en última instancia, es el CIO o el responsable del diseño de las bases de datos el que debe de decidir hasta qué punto “formalizar” el diseño con las formas normales.
