Tema 15: Normalización 1FN, 2FN, 3FN, BCNF: por qué las tablas no deben repetirse

Identificador: PF-015 | XP: 200 | Insignia: 🥇 Oro | Tier: Aprendiz

Tiempo estimado: 90-120 min | Pre-requisitos: PF-014

🖼️ Imagen de inicio del tema

[Moka con pirámide de 4 niveles (1FN, 2FN, 3FN, BCNF). Sofía, Don Carlos, Citlalli ascendiendo por la pirámide de la normalización.]

🎯 Aprenderás

Las 5 formas normales (1FN, 2FN, 3FN, BCNF, 4FN) y su propósito. Identificar violaciones de cada forma normal. Aplicar la normalización paso a paso. Cuándo desnormalizar (volver atrás) por motivos de performance.

🏛️ Visión mexica — Por Citlalli

"Los tlacuilos aprendían desde jóvenes a NO repetir información en los codex. Si el nombre de un altépetl aparecía en 10 codex diferentes, cualquier corrección debía hacerse en 10 lugares. Era propenso a errores. La solución: tener UN codex maestro de altépetl, y los otros codex solo REFERENCIABAN al maestro.

Eso es la NORMALIZACIÓN: eliminar redundancia para que cada dato viva en UN SOLO lugar. La pirámide de formas normales (1FN, 2FN, 3FN, BCNF) es el nivel de 'pureza' de tu modelo. Como en el calmécac, mientras más normalizado, menos propenso a errores."

📚 Bloque 1: 1FN — Primera Forma Normal

Regla: cada celda debe tener un valor atómico (no divisible).

-- MAL: columna con múltiples valores
CREATE TABLE clientes_mal (
    id INT,
    nombre VARCHAR(100),
    telefonos VARCHAR(200)  -- '555-1234, 555-5678, 555-9012'
);
-- BIEN: 1FN
CREATE TABLE clientes (
    id INT,
    nombre VARCHAR(100)
);
CREATE TABLE telefonos (
    id INT,
    cliente_id INT,
    telefono VARCHAR(20),
    FOREIGN KEY (cliente_id) REFERENCES clientes(id)
);

Citlalli: "1FN es la base. Si no la cumples, nada más funciona. Es como construir sobre arena: las pirámides se derrumban."

📚 Bloque 2: 2FN — Segunda Forma Normal

Regla: estar en 1FN + cada columna no-llave depende de TODA la llave primaria (no solo parte).

Aplica solo a tablas con llave compuesta.

-- MAL: pedido_items con dependencia parcial
CREATE TABLE pedido_items_mal (
    pedido_id INT,
    producto_id INT,
    cantidad INT,
    nombre_producto VARCHAR(150),  -- depende solo de producto_id
    PRIMARY KEY (pedido_id, producto_id)
);
-- BIEN: 2FN
CREATE TABLE pedido_items (
    pedido_id INT,
    producto_id INT,
    cantidad INT,
    PRIMARY KEY (pedido_id, producto_id)
);
-- El nombre del producto está en la tabla productos.

📚 Bloque 3: 3FN — Tercera Forma Normal

Regla: estar en 2FN + no hay dependencias transitivas (columnas no-llave que dependen de otras columnas no-llave).

-- MAL: dependencia transitiva
CREATE TABLE pedidos_mal (
    id INT,
    cliente_id INT,
    cliente_nombre VARCHAR(100),  -- depende de cliente_id, no de id
    total DECIMAL(10,2)
);
-- BIEN: 3FN
CREATE TABLE pedidos (
    id INT,
    cliente_id INT,
    total DECIMAL(10,2),
    FOREIGN KEY (cliente_id) REFERENCES clientes(id)
);
-- El nombre del cliente está en la tabla clientes.

📚 Bloque 4: BCNF — Boyce-Codd

Regla: estar en 3FN + para cada dependencia funcional X → Y, X debe ser una superllave.

En la práctica, BCNF corrige casos raros donde 3FN no es suficiente. Para la mayoría de aplicaciones reales, 3FN es suficiente.

📚 Bloque 5: Cuándo DESnormalizar

A veces la normalización estricta causa queries muy lentas. La desnormalización (volver atrás parcialmente) se hace por performance.

Ejemplo: en un data warehouse, en vez de hacer JOIN cada vez, copias el `cliente_nombre` en la tabla de hechos. Eso es desnormalización. Está bien en contextos analíticos pero no en operacionales.

Don Carlos: "Regla práctica: normaliza hasta 3FN en sistemas transaccionales (OLTP). Desnormaliza selectivamente en analíticos (OLAP). El 80% de los casos reales usan 3FN sin problemas."

🤖 AI Mission

Pídele: "Dame una tabla mal diseñada que viole 1FN, 2FN y 3FN al mismo tiempo, y muéstrame paso a paso cómo normalizarla. Que sea un ejemplo de una tienda online con clientes, pedidos y productos."

⚠️ Errores típicos

Sobre-normalizar (ir más allá de 3FN sin razón). No normalizar (repetir datos como cliente_nombre en cada pedido). Confundir dependencias parciales con transitivas. Olvidar que BCNF es a veces necesaria.

🧪 LAB 15.1 — "Normaliza Tienda Tlalli paso a paso"

Punto de partida (diseño NO normalizado):

CREATE TABLE pedidos_mal (
    id INT,
    fecha DATETIME,
    cliente_id INT,
    cliente_nombre VARCHAR(100),
    cliente_email VARCHAR(150),
    cliente_ciudad VARCHAR(80),
    producto_id INT,
    producto_nombre VARCHAR(150),
    producto_precio DECIMAL(10,2),
    cantidad INT,
    subtotal DECIMAL(10,2),
    total DECIMAL(10,2)
);

Tu tarea:

Identifica qué formas normales viola. Normaliza paso a paso hasta 3FN. Escribe el SQL final con las tablas separadas.

📝 Quest 15

¿1FN requiere? A) Llave primaria. B) Valores atómicos. C) No NULL. D) Foreign keys. ¿2FN es para llaves? A) Primarias simples. B) Compuestas. C) Foráneas. D) Candidatas. ¿Dependencia transitiva? A) A→B→C. B) A→B. C) A→C. D) Ninguna. ¿BCNF es más estricta que 3FN? A) Sí. B) No. C) Iguales. D) Depende. ¿Cuándo desnormalizar? A) Nunca. B) Por performance. C) Siempre. D) Solo en OLTP. ¿4FN trata? A) Dependencias funcionales. B) Dependencias multivaluadas. C) Llaves primarias. D) NULL. ¿Una tabla con 1 columna viola 1FN? A) Sí. B) No. C) A veces. D) Depende. ¿3FN implica? A) Solo llaves. B) 1FN y 2FN. C) 2FN. D) 1FN. ¿Por qué normalizar? A) Performance. B) Eliminar redundancia. C) Complejidad. D) Velocidad. ¿Desnormalización es mala? A) Siempre. B) A veces, según contexto. C) Nunca. D) Solo en 2025.

Da un ejemplo de violación de 3FN. ¿Por qué sobre-normalizar es problemático? ¿Cuándo desnormalizarías en la vida real?

✅ Respuestas

1-B, 2-B, 3-A, 4-A, 5-B, 6-B, 7-B, 8-B, 9-B, 10-B.

🏛️ Tras las huellas — Por Citlalli

"Los tlacuilos aprendían desde jóvenes a NO repetir información en los codex. La solución: tener UN codex maestro de altépetl, y los otros codex solo REFERENCIABAN al maestro. La NORMALIZACIÓN es eliminar redundancia para que cada dato viva en UN SOLO lugar."

📓 Cierre

1. La forma normal que más me costó fue:

2. La dependencia transitiva que más me confundió:

3. El modelo que voy a normalizar:

4. Cómo voy a aplicar normalización:

🎉 Cierre del Capítulo 2

¡Felicidades! Con este tema cierras el corazón del libro: SQL aplicado, modelado y normalización. Si entiendes estos 9 temas, ya tienes el 70% de lo que necesitas para tu primera entrevista de DBA junior. Los próximos capítulos (3: administración, 4: nube y carrera) se construyen sobre esta base.

🚀 ¿Qué sigue?

Capítulo 3 — Administración del motor (DBA hands-on): 10 temas sobre GRANT, ACID, locks, backup físico, PITR, replicación, EXPLAIN, índices, autovacuum, y seguridad. La transición de "saber SQL" a "ser DBA profesional".

Por cierto, ¿cómo vas de energía? Estos 9 temas son densos. Si quieres pausar y seguir en otra sesión, todo el Word está listo para reimprimir. Solo dime y pausamos.