Normalización de bases de datos

La normalización de bases de datos es un conjunto de reglas y de técnicas de diseño cuyo objetivo es organizar los datos de manera que no se repitan innecesariamente ni puedan volverse contradictorios entre sí. El problema fundamental que aborda es la redundancia, es decir, tener el mismo dato copiado en múltiples lugares, ya que la redundancia es la causa de las llamadas anomalías, que son inconsistencias que aparecen cuando se modifican los datos. Por ejemplo, si el nombre y la dirección de un cliente se guardan repetidos en cada uno de sus pedidos, al cambiar ese cliente de dirección habría que actualizar todas las copias, y si alguna se olvida, la base de datos acabaría afirmando dos direcciones distintas para el mismo cliente. La normalización resuelve esto estableciendo que cada hecho debe guardarse una sola vez, en su lugar correspondiente, de modo que al actualizarlo solo haya que tocarlo en un sitio. En la práctica, normalizar consiste en repartir los datos en varias tablas bien delimitadas, cada una dedicada a un tipo de entidad, y conectarlas mediante claves, de forma que la información de los clientes viva en una tabla de clientes, la de los pedidos en una de pedidos, y así sucesivamente, en lugar de amontonarlo todo en una única tabla gigante y repetitiva. Las reglas de la normalización se organizan en niveles progresivos llamados formas normales, de las cuales las tres primeras cubren la inmensa mayoría de los casos prácticos. El resultado de un buen diseño normalizado es una base de datos coherente que envejece bien y en la que las anomalías simplemente no pueden producirse.

Las anomalías son las inconsistencias y problemas que surgen al manipular una base de datos que tiene datos redundantes, es decir, repetidos, y son precisamente lo que la normalización busca evitar. Se distinguen tradicionalmente tres tipos. La anomalía de actualización se produce cuando un mismo dato está copiado en varios sitios y se modifica solo en algunos de ellos, dejando la base de datos en un estado contradictorio; por ejemplo, si la dirección de un cliente está repetida en todos sus pedidos y se actualiza solo en algunos, coexistirán direcciones distintas para el mismo cliente, y ya no se sabrá cuál es la correcta. La anomalía de inserción se produce cuando la estructura obliga a tener un dato para poder registrar otro que en realidad es independiente; por ejemplo, si los datos de los clientes solo existen dentro de la tabla de pedidos, no habría forma de dar de alta a un cliente nuevo hasta que hiciera su primer pedido, lo cual es una limitación artificial y absurda. La anomalía de borrado es la contraria: se produce cuando al eliminar un registro se pierde sin querer información que debería conservarse; por ejemplo, si se borra el único pedido de un cliente y sus datos solo vivían en esa fila, se perderían también los datos del cliente. Las tres anomalías tienen la misma raíz, que es la redundancia y la mezcla inadecuada de distintos tipos de información en una misma tabla. La normalización las elimina de raíz al garantizar que cada hecho se almacene una sola vez y en la tabla que le corresponde, de manera que actualizar, insertar o borrar un dato no tenga efectos secundarios indeseados sobre otros datos no relacionados.

Las tres primeras formas normales son niveles progresivos de normalización, y cada una exige una condición que corrige un tipo concreto de mala organización de los datos. La primera forma normal, o 1NF, exige que cada celda de una tabla contenga un solo valor atómico, es decir, que no haya listas ni conjuntos de valores metidos en una misma casilla; por ejemplo, en lugar de una celda que contenga lápiz, goma y regla juntos, debe haber una fila separada para cada valor, de modo que cada dato ocupe su propia celda de forma individual. La segunda forma normal, o 2NF, se aplica cuando la clave primaria es compuesta, es decir, formada por varias columnas, y exige que cada columna que no forma parte de la clave dependa de la clave completa y no solo de una parte de ella; esto obliga a sacar a otra tabla aquellos datos que en realidad dependen únicamente de un componente de la clave, como los datos propios de un producto que no dependen del pedido concreto en el que aparece. La tercera forma normal, o 3NF, exige que las columnas que no son clave dependan únicamente de la clave primaria y no de otras columnas que tampoco son clave; esto obliga a separar en su propia tabla los datos que dependen de otro dato en lugar de la clave, como la información del cliente, que depende del identificador del cliente y no directamente del pedido, y que por tanto debe vivir en una tabla de clientes referenciada mediante una clave foránea. Existe una regla mnemotécnica muy conocida que resume el espíritu de la 3NF diciendo que cada columna debe depender de la clave, de toda la clave y de nada más que la clave. En la práctica, aplicar estas tres formas equivale a repartir sensatamente los datos en tablas dedicadas, cada una a su tema, conectadas por claves.

En la gran mayoría de los casos prácticos, normalizar hasta la tercera forma normal es suficiente y constituye el objetivo razonable para un buen diseño de base de datos. Las tres primeras formas normales cubren y eliminan los problemas de redundancia y las anomalías más comunes e importantes, y un esquema en tercera forma normal es limpio, coherente y fácil de mantener para la práctica totalidad de las aplicaciones habituales. Existen formas normales superiores, con nombres y condiciones más estrictas, que abordan casos particulares y situaciones de dependencia más sutiles, pero en la práctica rara vez es necesario llegar hasta ellas, ya que los escenarios que corrigen son poco frecuentes y muchas veces un diseño en tercera forma normal ya los satisface de forma natural. Por eso, la recomendación práctica es apuntar a la tercera forma normal como estándar de un diseño correcto, sin obsesionarse con alcanzar niveles superiores salvo que un caso concreto lo justifique claramente. Es más, dedicar un esfuerzo desproporcionado a perseguir formas normales muy altas puede complicar innecesariamente el diseño con un beneficio marginal. La actitud más sana es entender el espíritu de la normalización, que es evitar la redundancia y guardar cada hecho una sola vez en su tabla adecuada, y aplicar ese criterio con buen juicio hasta la tercera forma normal, que ofrece el mejor equilibrio entre coherencia, simplicidad y practicidad. Y en los casos en que el rendimiento de lectura lo exija, la desviación deliberada se hace en la dirección contraria, desnormalizando de forma controlada, y no buscando formas normales aún más estrictas.

La desnormalización es el proceso deliberado de introducir cierta redundancia en una base de datos previamente normalizada, con el objetivo de mejorar el rendimiento de las lecturas. Su motivación surge de un compromiso: la normalización optimiza la coherencia y evita las anomalías al repartir los datos en tablas separadas, pero eso implica que, para reunir información que estaba dispersa, hay que combinar varias tablas mediante operaciones de unión, lo que en escenarios de lecturas muy frecuentes o de grandes volúmenes puede tener un coste apreciable en velocidad. La desnormalización consiste en duplicar estratégicamente algunos datos para evitar esas uniones y acelerar las consultas más críticas. Ahora bien, esto tiene sentido solo bajo ciertas condiciones y con importantes salvedades. La primera es el orden correcto: se debe partir siempre de un diseño normalizado, que es lo correcto por defecto, y desnormalizar únicamente después, cuando existe una necesidad de rendimiento real y medida, no anticipada por suposición. La segunda es la conciencia del coste: al reintroducir redundancia se vuelve a abrir la puerta a las anomalías, de modo que el dato duplicado debe gestionarse con cuidado, manteniéndolo sincronizado mediante los mecanismos adecuados para que las copias no se contradigan. Desnormalizar, por tanto, no es un atajo ni una excusa para un diseño descuidado, sino una decisión de ingeniería consciente que intercambia coherencia por velocidad en puntos concretos y justificados. Hacerlo desde el principio y sin motivo equivale simplemente a un mal diseño, mientras que hacerlo de forma medida y controlada sobre una base normalizada es una optimización legítima.

La normalización suele conducir a tener más tablas que un diseño ingenuo que lo amontona todo en una sola, pero es un error entenderla simplemente como fragmentar en cuantas más tablas mejor, porque el objetivo no es multiplicar tablas sino eliminar la redundancia y organizar cada tipo de información en su lugar adecuado. Es cierto que, al aplicar las formas normales, los datos que estaban mezclados y repetidos en una única tabla se reparten en varias tablas dedicadas, una para cada tipo de entidad, como clientes, pedidos y productos, conectadas mediante claves, y que por tanto el número de tablas aumenta respecto a la tabla única inicial. Sin embargo, ese aumento es una consecuencia del criterio correcto, que es dar a cada hecho un único lugar de residencia, y no un fin en sí mismo. Fragmentar tablas sin este criterio, separando datos que en realidad pertenecen juntos y no generan redundancia, no aporta ningún beneficio y solo complica el diseño y las consultas innecesariamente. La normalización bien entendida busca el punto justo: tantas tablas como distintos tipos de entidad y relación existan realmente, cada una cohesionada en torno a un tema, ni más ni menos. Por eso conviene guiarse por la intuición de que cada cosa debe estar en su tabla y guardarse una sola vez, en lugar de por una regla mecánica de crear tablas. Un buen diseño normalizado tiene exactamente las tablas que necesita para representar fielmente la realidad sin repeticiones, y esa cantidad emerge de forma natural al aplicar las formas normales con sentido, no de un afán por dividir.