Normalización

📐 Fundamento

Una dependencia funcional (DF) describe cómo un valor determina otro.

Notación: $X \rightarrow Y$ significa "X determina Y" — si conocés X, conocés Y de manera única.

Ejemplos:

• $\text{matricula} \rightarrow \text{nombre}$ : una matrícula identifica únicamente al alumno.
• $\text{ISBN} \rightarrow \text{titulo}, \text{autor}$ : el ISBN determina título y autor.
• $\text{producto_id} \rightarrow \text{precio}$ : cada producto tiene un precio.

Importante: las DF reflejan reglas del dominio del problema, no de los datos actuales. Aunque ahora dos productos casualmente tengan el mismo precio, no significa que precio dependa solo de producto_id (la regla puede cambiar).

Tipos:

• DF trivial. $A \rightarrow A$. Cualquier atributo se determina a sí mismo. No aporta información.
• DF parcial. $A \rightarrow B$ donde A es parte de la PK. Problema en 2FN.
• DF transitiva. $A \rightarrow B \rightarrow C$, donde B no es clave. Problema en 3FN.

Cómo encontrarlas: preguntale al dominio del negocio. "Si te doy el ISBN, ¿podés decirme título y autor sin ambigüedad?" Si sí, hay DF.

Cierre. El conjunto de todas las DFs implicadas por un conjunto dado se llama cierre (closure). Hay axiomas (Armstrong) para derivarlo. Lo dejamos como avanzado.

📐 Fundamento

Regla: cada celda contiene un solo valor atómico. Sin listas, sin estructuras anidadas.

Mal:

Bien:

(Y mejor todavía: tabla aparte cliente_telefono.)

Indicios de violación:

• Listas o sets en una sola celda ("rojo,azul,verde").
• Campos numerados (telefono1, telefono2, telefono3 — semi-mal).
• JSON o XML embebido cuando los datos son consultables.

Cuando JSON sí es OK: datos opacos para la base, no consultables. Por ejemplo, configuración del usuario que solo el cliente parsea. Si vas a hacer WHERE config->'theme' = 'dark', ya no es opaco — debería ser tabla aparte o columna.

📐 Fundamento

Pre-requisito: la tabla está en 1FN.

Regla: ningún atributo no-clave depende de parte de la PK. (Solo aplica si la PK es compuesta.)

Ejemplo de violación:

Tabla pedido_linea:
PK = (pedido_id, producto_id)

Atributos:
  pedido_id, producto_id, cantidad, importe, nombre_producto, precio_actual_producto
                                              ^                ^
                                              dependen solo del producto_id

nombre_producto y precio_actual_producto dependen de producto_id solo, no de la combinación. Esa es DF parcial — viola 2FN.

Solución: mover esos atributos a la tabla producto:

-- Antes (mal):
CREATE TABLE pedido_linea (
    pedido_id INT,
    producto_id INT,
    cantidad INT,
    importe DECIMAL,
    nombre_producto VARCHAR(100),     -- ¡no!
    precio_producto DECIMAL,           -- ¡no!
    PRIMARY KEY (pedido_id, producto_id)
);

-- Después (bien):
CREATE TABLE pedido_linea (
    pedido_id INT,
    producto_id INT REFERENCES producto(id),
    cantidad INT,
    importe DECIMAL,
    PRIMARY KEY (pedido_id, producto_id)
);

CREATE TABLE producto (
    id SERIAL PRIMARY KEY,
    nombre VARCHAR(100),
    precio DECIMAL
);

Por qué importa:

• Sin redundancia. El nombre del producto no se repite en cada línea.
• Sin anomalías de actualización. Si cambia el nombre, una sola fila.
• Más espacio. Líneas son chiquitas; el catálogo aparte.

Tablas con PK simple ya están automáticamente en 2FN (no hay "parte" de PK).

📐 Fundamento

Pre-requisito: la tabla está en 2FN.

Regla: ningún atributo no-clave depende transitivamente de la PK a través de otro no-clave.

Ejemplo de violación:

Tabla empleado:
PK = id

Atributos: id, nombre, departamento_id, departamento_nombre, departamento_telefono
                                        ^                   ^
                                        dependen de departamento_id, no de id directamente

DF transitiva: $\text{id} \rightarrow \text{departamento_id} \rightarrow \text{departamento_nombre}$.

Solución: mover datos del departamento a su propia tabla:

-- Antes (mal):
CREATE TABLE empleado (
    id SERIAL PRIMARY KEY,
    nombre VARCHAR(100),
    departamento_id INT,
    departamento_nombre VARCHAR(100),       -- ¡no!
    departamento_telefono VARCHAR(20)        -- ¡no!
);

-- Después (bien):
CREATE TABLE departamento (
    id SERIAL PRIMARY KEY,
    nombre VARCHAR(100),
    telefono VARCHAR(20)
);

CREATE TABLE empleado (
    id SERIAL PRIMARY KEY,
    nombre VARCHAR(100),
    departamento_id INT REFERENCES departamento(id)
);

Resumen 3FN: cada atributo no-clave depende del PK, todo el PK, y nada más que el PK (frase clásica).

📐 Fundamento

Pre-requisito: la tabla está en 3FN.

Regla: para toda DF $X \rightarrow Y$ no trivial, $X$ debe ser superclave (un superset de alguna llave candidata).

3FN deja un caso patológico que BCNF cierra: cuando una tabla tiene varias llaves candidatas que se solapan, puede haber DFs entre atributos clave que crean redundancia incluso en 3FN.

Ejemplo (concedido, raro):

Tabla curso_profesor_aula:
- (curso, profesor) → aula
- (aula, hora)     → curso

Posibles llaves candidatas: (curso, profesor) y (aula, hora).
Pero existe la DF: profesor → aula
                     ^         ^
                     no es llave   pero deriva

Ahí hay redundancia que 3FN no detecta, pero BCNF sí. La descomposición es más compleja.

En la práctica: la mayoría de las bases en buena 3FN están en BCNF. Casos donde difieren son raros. Si tu modelo entra en BCNF de natural, mejor; si no, 3FN es suficiente para 99% de los proyectos.

Más allá: existen 4FN (dependencias multivaluadas), 5FN, 6FN. Académicamente importantes, pero rara vez se aplican deliberadamente en la industria. 3FN o BCNF te llevan la mayor parte del camino.

📐 Fundamento

Las formas normales eliminan tres tipos de anomalías:

Anomalía de inserción

No podés insertar un dato sin tener otro al cual no debería estar atado.

Ejemplo: en la tabla universal anterior, no podés insertar un cliente nuevo si no tiene factura. Tendrías que crear factura "vacía" — feo.

Solución: tabla cliente separada permite insertar clientes sin facturas.

Anomalía de actualización

Cambiar un dato requiere actualizar muchas filas. Si te olvidás alguna, queda inconsistente.

Ejemplo: cambiar cliente_nombre requeriría actualizar todas las filas de facturas de ese cliente.

Solución: una sola fila en cliente se actualiza una sola vez.

Anomalía de eliminación

Borrar un dato accidentalmente borra otra información valiosa.

Ejemplo: si borrás la única factura de un cliente, perdés sus datos personales.

Solución: tabla cliente separada conserva la info aunque se borren todas sus facturas.