Definición
Normalizar es organizar las tablas de forma que cada dato esté guardado en un solo sitio.
El problema que resuelve es concreto. Imagina una única tabla de pedidos donde cada línea repite el nombre del cliente, su dirección y su teléfono. Tres cosas van mal a la vez:
- Al actualizar: si el cliente cambia de dirección, hay que corregir cientos de filas. Si una se escapa, hay dos verdades.
- Al insertar: no puedes dar de alta un cliente hasta que haga su primer pedido.
- Al borrar: si eliminas su último pedido, desaparecen también sus datos.
La solución es separar: una tabla de clientes, una de pedidos que apunta a ella con una clave foránea.
Formalmente esto se describe con «formas normales» numeradas. En la práctica, llegar a la tercera cubre prácticamente todo lo que un sistema de gestión necesita, y se resume en una frase: cada campo depende de la clave de su tabla y de nada más.
El coste
Normalizar tiene un precio y conviene decirlo: más tablas significan más uniones en cada consulta. Sacar un listado de pedidos con nombre de cliente, población y comercial asignado puede implicar cruzar cuatro tablas.
Con índices correctos, eso rara vez es un problema real. Se convierte en problema cuando el volumen crece mucho o cuando la consulta se ejecuta constantemente.
Cuándo desnormalizar a propósito
Desnormalizar es duplicar un dato deliberadamente. Hecho a ciegas es un error; hecho con criterio, es una decisión legítima. Los tres casos que la justifican:
Datos históricos que deben congelarse. El precio de una línea de pedido se copia en el momento de la venta. No se busca en la tabla de tarifas, porque el precio de hoy no es el que se facturó hace un año. Aquí duplicar no es redundancia: es guardar un hecho.
Totales precalculados. Guardar el importe total de un pedido en su cabecera evita recalcularlo en cada listado. A cambio, hay que mantenerlo al día sin fallos.
Tablas de informe. Estructuras aparte, generadas periódicamente, pensadas para leer rápido.
Ejemplo práctico
En un sistema de precios con tarifas generales y precios negociados por cliente, la estructura normalizada es clara: una tabla de productos, una de tarifas y una de precios especiales que relaciona cliente y producto.
Lo que aprendí: el modelo normalizado es el correcto para operar, y hay una excepción que no se negocia. En el momento de emitir un pedido o una factura, el precio y la descripción se copian en la línea. Si no lo haces, un documento antiguo cambia solo cuando alguien actualiza una tarifa, y eso no es un detalle técnico: es un problema contable y legal.
La regla que lo resume: los datos operativos se referencian; los datos de un documento emitido se copian.
El segundo aprendizaje, y es una trampa fina: al cruzar tablas que vienen de sitios distintos —una importada, otra creada a mano— pueden no coincidir en su configuración de cotejo de texto. El resultado no es un error visible: es una unión que devuelve menos filas de las que debería y nadie lo nota hasta que un cliente pregunta por un precio que no aparece. Un fallo silencioso, y de los caros.
Y una advertencia sobre el exceso contrario: normalizar hasta el absurdo produce modelos donde cada consulta cruza ocho tablas y nadie entiende el esquema. Si separar algo no evita ninguna contradicción real, no lo separes.
Errores comunes
- Una tabla gigante que repite datos de cliente en cada fila.
- No copiar precio y descripción en las líneas de un documento emitido.
- Desnormalizar sin necesidad, «por si acaso va lento».
- Totales precalculados que se desincronizan.
- Campos con varios valores separados por comas. Eso es una tabla que falta.
- Cruzar tablas con cotejos distintos, y perder filas en silencio.
- Normalizar tanto que el modelo sea inoperable.
Cuándo decidirlo
Al diseñar el modelo, y de nuevo cuando una consulta concreta se vuelve lenta de verdad — con medición, no con intuición.
El orden correcto es siempre el mismo: normaliza primero, desnormaliza después y solo con motivo. Al revés, acabas con datos duplicados que nadie sabe cuál es el bueno.
