Normalización: De la 1FN a la 3FN Explicada de Forma Sencilla
La normalización de bases de datos reduce la redundancia y mejora la integridad de los datos. Desglosamos la Primera, Segunda y Tercera Forma Normal con ejemplos prácticos que puedes aplicar en tus propios esquemas.
La normalización es el proceso de organizar tu esquema de base de datos para reducir la redundancia y prevenir anomalías en los datos. Es uno de los conceptos más importantes en el diseño de bases de datos relacionales — y uno de los más incomprendidos.
¿Por Qué Normalizar?
Imagina una tabla donde cada fila de pedido contiene directamente el nombre, email y dirección del cliente. Si un cliente realiza 50 pedidos, su nombre y email se almacenan 50 veces. Cuando cambia su email, necesitas actualizar 50 filas. Si omites una, tus datos son inconsistentes.
La normalización resuelve esto dividiendo los datos en tablas separadas conectadas por claves foráneas. Los datos del cliente viven en un solo lugar, y los pedidos simplemente referencian al cliente por su ID.
Primera Forma Normal (1FN)
Una tabla está en 1FN cuando cada columna contiene únicamente valores atómicos (indivisibles) y no hay grupos repetidos. Esto significa que no puede haber arreglos, listas separadas por comas ni patrones del tipo "columna1, columna2, columna3".
Antes de la 1FN: Una tabla contacts con una columna phone_numbers que contiene "555-1234, 555-5678". Después de la 1FN: Una tabla separada phone_numbers con una fila por número de teléfono, vinculada a contacts mediante una clave foránea.
La regla es sencilla: cada columna debe contener un único valor. Si necesitas múltiples valores, crea una tabla separada.
Segunda Forma Normal (2FN)
Una tabla está en 2FN cuando ya está en 1FN y cada columna que no es clave depende de la clave primaria completa, no solo de una parte de ella. Esto aplica principalmente a tablas con claves primarias compuestas.
Ejemplo: Una tabla order_items con una clave compuesta de (order_id, product_id) y una columna product_name. El nombre del producto depende solo de product_id, no de la clave compuesta completa. Para corregirlo, mueve product_name a la tabla products.
En la práctica, si usas claves primarias sustitutas de una sola columna (como IDs auto-incrementales), es menos probable que violes la 2FN. Pero sigue siendo importante entender el principio.
Tercera Forma Normal (3FN)
Una tabla está en 3FN cuando está en 2FN y cada columna que no es clave depende directamente de la clave primaria, no de otra columna que tampoco sea clave. Esto elimina las dependencias transitivas.
Ejemplo: Una tabla employees con department_id, department_name y department_location. El nombre y la ubicación del departamento dependen de department_id, no del empleado. Solución: crea una tabla departments y conserva solo department_id en employees.
Cuándo Dejar de Normalizar
Existen formas normales más altas (FNBC, 4FN, 5FN), pero la 3FN es suficiente para la gran mayoría de las aplicaciones. De hecho, a veces desnormalizarás intencionalmente por rendimiento — almacenando un total_amount en un pedido en lugar de calcularlo a partir de los ítems cada vez.
La clave es comenzar normalizado y desnormalizar deliberadamente cuando tengas una necesidad de rendimiento medible. Nunca empieces desnormalizado esperando corregirlo después.
Visualizando la Normalización
Los diagramas ER son la mejor manera de detectar problemas de normalización. Cuando ves una tabla con demasiadas columnas, o columnas que parecen pertenecer a una entidad diferente, es una señal de que la tabla necesita dividirse. ER Flow hace que este proceso sea visual e iterativo — arrastra columnas a nuevas tablas, define relaciones y ve el resultado al instante.