Transformar una hoja de cálculo desordenada en un modelo relacional sólido es una de las habilidades más valiosas para cualquier persona que trabaje con datos. Comprender las formas normales permite detectar errores de diseño, eliminar redundancias y garantizar que la información se mantenga íntegra con el paso del tiempo y las actualizaciones constantes.
¿Qué es la normalización y por qué protege tus datos?
Cuando diseñas una base de datos relacional, el objetivo es organizar la información para que no se repita innecesariamente y no genere errores [0:10]. A ese proceso se le conoce como normalización, y se apoya en tres reglas fundamentales que se aplican de forma progresiva.
Sin normalizar, actualizar datos se vuelve riesgoso: cambias un valor en un lugar, olvidas otro y aparecen inconsistencias que desperdician espacio y comprometen el análisis [1:12]. La normalización garantiza que la base de datos siga siendo íntegra incluso después de múltiples transacciones a lo largo del tiempo.
¿Qué exige la primera forma normal?
La primera forma normal (1FN) es la regla más simple: cada celda debe contener un solo valor [0:22]. No se permiten listas ni grupos repetitivos dentro de una columna. En el ejemplo práctico, la tabla original tenía bloques de cuatro columnas que representaban distintas ventas de productos, con celdas vacías cuando un pedido no alcanzaba todos los espacios [3:14]. Si un pedido tuviera diez productos, la cantidad de columnas vacías sería enorme.
Para corregirlo se separaron los datos en dos tablas: una tabla de pedidos (cabecera) y una tabla de detalle de pedidos [5:22]. Así, el pedido 101 aparece una sola vez en la cabecera y sus productos se despliegan como filas individuales en el detalle, cada celda con un único dato.
¿Cómo funciona la segunda forma normal?
La segunda forma normal (2FN) exige que cada atributo dependa completamente de la clave primaria, no solo de una parte [0:32]. Esto resulta crítico cuando la clave es compuesta, por ejemplo, la combinación de pedido_id y producto_id.
En la tabla original, el mismo producto aparecía con precios distintos en diferentes filas: una Laptop HP Probook 450 registraba un precio de 1 350 en un lugar y otro diferente más adelante [3:50]. Un Mouse Inalámbrico Logitech mostraba 28 en una fila y 25 en otra con el mismo ID [4:10]. El precio no puede depender exclusivamente del ID del producto, porque las condiciones del mercado —ofertas, promociones, liquidaciones— alteran el valor en cada transacción [4:36].
La solución fue crear una tabla de productos independiente con su precio de lista y manejar en el detalle del pedido un campo llamado precio momento, que refleja el valor real al instante de la venta [6:30]. Con esta separación se eliminan las dependencias parciales.
¿Qué problema resuelve la tercera forma normal?
La tercera forma normal (3FN) busca eliminar las dependencias transitivas [0:46]. Un ejemplo claro: el código postal aparecía junto al ID del cliente. Si ese cliente se mudaba de ciudad, habría que actualizar manualmente todos los registros asociados [5:00].
Para resolverlo se creó una tabla de códigos postales donde el código depende de la ciudad, no del cliente [7:28]. La tabla de clientes pasó a almacenar únicamente el código postal como referencia, vinculándose con la nueva tabla a través de esa relación.
¿Cómo queda el modelo final después de normalizar?
El modelo resultante incluye varias tablas conectadas entre sí [7:50]:
- Códigos postales: ciudad y su código correspondiente.
- Clientes: ID, nombre, apellido, correo y código postal de la ciudad.
- Empleados: datos del empleado con un ID de sucursal que se gestiona en otra tabla.
- Pedidos: ID, fecha, cliente, empleado que atendió y estado (pendiente, confirmado, enviado, entregado).
- Detalle de pedidos: tabla intermedia de relación muchos a muchos entre pedidos y productos, con cantidad, precio momento y descuento.
- Productos: ID, nombre, precio de lista y categoría.
También se corrigió una anomalía detectada en los datos originales: la ciudad Buenos Aires aparecía escrita de forma completa en unos registros y abreviada en otros [5:06]. Este tipo de inconsistencia impide agrupar correctamente los datos durante el análisis.
¿Qué logramos al aplicar las tres formas normales?
El proceso completo se resume en tres acciones concretas [8:42]:
- Crear entidades que se materializan en tablas con llaves primarias.
- Establecer relaciones mediante llaves foráneas o tablas intermedias.
- Normalizar eliminando duplicados y dependencias incorrectas.
Cada forma normal construye sobre la anterior: primero un dato por celda, luego dependencia completa de la clave primaria y finalmente la eliminación de toda dependencia indirecta. El resultado es una base de datos que no se rompe al registrar nuevas transacciones.
¿Cuántos problemas de datos en tu trabajo actual serían evitables con un buen diseño relacional? Piensa en ese Excel que se usa mal, esa tabla con datos duplicados que genera errores constantemente, y comparte tu experiencia en los comentarios.
