Formas normales y por qué importan

Una tabla que repite el nombre del proveedor en cada uno de sus productos tiene un problema esperando: alguien va a corregir el nombre en una fila y no en las otras. Las formas normales son la respuesta sistemática a esa familia de problemas, y cada una tapa un agujero distinto.

Las tres anomalías que delatan el problema

El síntoma se llama anomalía y viene en tres formas. De actualización: un dato repetido se cambia en un lugar y queda inconsistente. De inserción: no se puede registrar un proveedor nuevo porque todavía no tiene productos y la tabla exige un producto. De borrado: se elimina el último producto y se pierde la información del proveedor.

Las tres tienen la misma causa: la tabla mezcla dos cosas distintas. Normalizar es separarlas.

La dependencia funcional, la herramienta formal

La herramienta formal es la dependencia funcional: $X \to Y$ significa que conocido $X$, el valor de $Y$ queda determinado. El CUIT determina la razón social; el número de factura determina su fecha.

La regla que resume todo es que cada atributo debe depender de la clave, de toda la clave y de nada más que la clave. Las tres primeras formas normales son las tres formas de violar esa frase.

Las tres primeras formas normales

Primera: nada de valores múltiples en una celda. Una columna con “rojo, azul, verde” adentro rompe cualquier consulta por color; eso va en una tabla aparte.

Segunda: ningún atributo depende de una parte de la clave compuesta. Si la clave es (factura, producto) y el nombre del producto depende sólo del producto, ese nombre está en la tabla equivocada.

Tercera: ningún atributo depende de otro atributo no clave. Si la tabla tiene código postal y ciudad, y el código postal determina la ciudad, la ciudad sobra: va con el código postal a su propia tabla.

Lo que hay más arriba

Hay más arriba. Boyce-Codd es una tercera forma normal más estricta, que corrige casos con varias claves candidatas superpuestas. La cuarta ataca las dependencias multivaluadas: dos atributos independientes entre sí en la misma tabla generan un producto cartesiano de filas espurias.

En la práctica, llegar a tercera forma normal o a Boyce-Codd cubre la inmensa mayoría de los problemas reales. Las formas superiores aparecen poco, y cuando aparecen suele ser señal de que el modelo conceptual estaba mal desde el principio.

Desnormalizar a propósito

Desnormalizar es guardar datos redundantes a propósito, para evitar joins caros o congelar un valor histórico. Es legítimo y a veces necesario, con dos condiciones: que sea una decisión consciente y que se sepa quién mantiene la consistencia.

Hay un caso donde ni siquiera es desnormalización, aunque lo parezca: copiar el precio en la línea de factura. Ese precio no es el precio del producto, es el precio pactado en esa venta. Son atributos distintos que casualmente coinciden el día de la emisión, y el modelo correcto los separa.

Normalizar primero y medir después

El orden de trabajo sensato es normalizar primero y medir después. La intuición sobre qué join va a ser lento es mala, y los motores resuelven joins sobre columnas indexadas mucho mejor de lo que uno espera.

La lectura de fondo es que la normalización protege la verdad de los datos y la desnormalización protege el tiempo de respuesta. Recuperar tiempo de respuesta es un trabajo acotado; recuperar datos que se contradicen entre sí, muchas veces no tiene arreglo.

Hasta dónde normalizar

La frase que resume las tres primeras es conocida y sigue siendo la mejor herramienta: cada atributo depende de la clave, de toda la clave y de nada más que la clave. Cada forma normal es una de las tres formas de violarla.

Cierre

Cada atributo depende de la clave, de toda la clave y de nada más que la clave: esa frase es 1FN, 2FN y 3FN. Eliminan las anomalías de actualización, inserción y borrado. Desnormalizar después es válido si es deliberado y alguien se hace cargo de la consistencia.