En otra entrada hemos visto que las bases de datos relacionales almacenan la información en tablas normalizadas, pero ¿qué es la normalización de datos?
La normalización de datos es un conjunto de reglas que protegen a los datos de lo que en el modelo relacional se denomina anomalías de datos. En cristiano, éstas reglas evitan que pasen cosas raras con la información que contienen.
En función de la cantidad de reglas que hayas adoptado en una tabla ésta tendrá una forma normal determinada. A medida que adoptamos más reglas aumenta la forma normal de una tabla, protegiéndola contra una cantidad creciente de anomalías de datos.
En teoría, éstas reglas deben adoptarse en un orden determinado. Es decir, no deberías adoptar las reglas de la segunda forma normal si has decidido no adoptar las de la primera.
Para explicar lo que es una anomalía, imaginemos que tenemos una base de datos para una aseguradora, en la que almacenamos los datos de los clientes y las pólizas que tienen contratadas. Supongamos que tratamos de almacenar toda ésta información en la misma tabla:
Anomalía de duplicación: los datos de cada cliente estarán duplicados para cada póliza que tenga contratada.
Anomalía de borrado: cuando el cliente no tenga pólizas contratadas, perderemos también sus datos.
Anomalía de actualización: si queremos modificar una propiedad del cliente, tendremos que hacerlo en las filas de todas las pólizas que tenga contratadas. No sólo es ineficiente, también abrimos la puerta a que si el proceso de actualización se interrumpe algunos de los registros serán actualizados y otros no.
Anomalía de inserción: no podemos añadir los datos de un nuevo cliente si éste no tiene pólizas.
Hay otros tipos de anomalías, pero vemos que son inconsistencias o errores que aparecen en nuestros datos porque no hemos diseñado correctamente nuestra base de datos.
Cada registro debe poder ser recuperado de forma individual.
No se debe utilizar el orden en el que los registros son insertados a una base de datos para almacenar información.
No se deben mezclar tipos de datos en una misma columna (enteros y texto, etc…)
Si nuestra tabla cumple todas éstas reglas, estará en primera forma normal
Cada atributo que no forme parte de una clave (primaria, compuesta o foránea) debe depender únicamente de la clave primaria de la tabla.
Si la clave es compuesta, todos los campos que no formen parte de ésta deberán depender de la combinación de los campos de la clave. No debe ocurrir que una columna sólo dependa de una de las columnas de la clave.
Éstas reglas nos dicen que todas las variables de un registro deben pertenecer a la entidad referenciada por la clave primaria. En una tabla de usuarios, si la clave primaria es ID, y tenemos un usuario con ID 2353, todos los campos del registro deben pertenecer al usuario con ID 2353 y no a otros.
Los valores de una columna no pueden depender de los valores de otra, a no ser que ésta segunda sea un campo clave.
Normalmente ésta regla se viola cuando hay información que hace referencia a la misma propiedad de una entidad, pero codificada de otra manera. Por ejemplo, supongamos que tenemos una columna de calificaciones (de 1 a 10), y otra que nos indica si la persona ha aprobado o no. Si la nota es mayor que 5 aprobado vale “Sí”, y en caso contrario vale “No”. Si modificamos la nota de un sujeto de 3 a 8 la base de datos nos permitirá hacerlo sin problema, pero entonces la información no tiene sentido. Una persona con un 8 debería estar aprobada, pero la base de datos nos indicará que está suspensa ya que al insertar el registro aprobado tenía el valor “No”.
A la tercera forma normal se la denomina la forma normal de Boyce-Codd. Suele ser suficiente con llegar a éste nivel.
Si una tabla tiene una clave compuesta, las columnas que la componen deben ser independientes entre sí. Cualquier combinación entre los valores de las columnas debe ser posible.
Por ejemplo, imaginemos que tenemos una heladería con varios sabores de helado y varios formatos de presentación (cono o tarrina). Según ésta regla, todos los sabores deben estar disponibles en ambos formatos. Si existe algún helado que no pueda pedirse en cono o en tarrina, la tabla no cumple ésta regla.
Si en nuestra lógica de negocio se contempla la posibilidad de que haya combinaciones que no son posibles, deberemos modelarlo de otra forma. Si simplemente ponemos las combinaciones disponibles en una tabla, la base de datos no devolverá un error si intentamos añadir una combinación imposible.
Una tabla en quinta forma normal no puede ser descrita como el resultado de una serie de joins de un conjunto de tablas.
Es decir, la quinta forma normal garantiza que nuestra tabla no se puede descomponer en otras tablas, de forma tal que al hacer un join entre éstas tablas podamos obtener nuestra tabla original.
Implica que nuestros datos están organizados de la forma más atómica posible.
Las diferentes formas normales protegen a nuestras tablas de una serie de anomalías o inconsistencias en los datos que contienen.
Sobre el papel, éstas reglas deben implementarse en orden, pero en la práctica, puedes elegir implementar o no éstas reglas individualmente. En muchos casos puede ser conveniente ignorar algunas e implementar otras. Se debe ver como una serie de principios útiles para el diseño de bases de datos, no como un absoluto que debamos seguir siempre.