La normalización de bases de datos se puede resumir en una sola frase: "Guarda el mismo hecho en un solo lugar." La forma sistemática de lograrlo es 1NF → 2NF → 3NF.
¿Por qué es importante? Porque si la misma información está repartida en varias filas, en el momento en que corriges una y dejas las demás igual, los datos entran en contradicción. A esto se le llama anomalía de actualización. Pruébalo tú mismo aquí abajo.
Si cambia el laboratorio de Prof.A, en una tabla no normalizada hay que corregir manualmente las 2 filas. Si se te pasa хотя sea una, aparece una contradicción: "Prof.A está en Room 301 y también en Room 502". En una tabla en 3NF, basta con cambiar exactamente 1 fila.
Eso es, en esencia, toda la normalización — lo demás son reglas para decidir "qué columna debe ir dónde para que cada hecho se guarde en un solo lugar".
Dependencia funcional — el criterio para decidir la normalización
La normalización analiza "de qué depende esta columna". A eso se le llama dependencia funcional.
Por ejemplo, student_id → student_name significa "si conoces el ID del estudiante, el nombre queda determinado".
En el diagrama de abajo, fíjate en el color de las flechas:
- Verde = depende de la clave completa (correcto)
- Amarillo = depende solo de una parte de la clave (dependencia parcial → viola 2NF)
- Rojo punteado = depende pasando por una columna no clave (dependencia transitiva → viola 3NF)
Eliminar las flechas amarillas y rojas = dividir la tabla = normalizar.
Ver 1NF → 2NF → 3NF de una vez
Haz clic abajo y observa paso a paso cómo se divide la tabla. Las celdas rojas indican: "esta columna no debería estar aquí".
1NF: un valor por celda
Si en una sola celda pones varios valores como MATH101, CS102, no podrás buscar bien ni hacer JOIN correctamente.
Regla: todas las celdas deben ser atómicas (un solo valor).
Columnas como phone1, phone2, phone3 tienen el mismo problema — solo están escondiendo los valores dentro del nombre de la columna.
2NF: eliminar dependencias parciales
En una tabla con clave compuesta (student_id, course_id), student_name depende solo de student_id. No depende de la clave completa, sino solo de una parte — eso es una dependencia funcional parcial.
Regla: toda columna no clave debe depender de la clave completa.
Si hay una dependencia parcial, esa columna se saca y se coloca en una tabla aparte.
¿Y si la clave tiene una sola columna? Entonces una dependencia parcial es imposible, así que si está en 1NF, automáticamente está en 2NF.
3NF: eliminar dependencias transitivas
En la tabla Courses, instructor_office no depende directamente de course_id (la clave). Sigue la ruta course_id → instructor_id → instructor_office — es decir, una columna no clave depende de otra columna no clave. Eso es una dependencia transitiva.
Regla: las columnas no clave deben depender solo de la clave. No deben depender pasando por otra columna no clave.
Solución: separar instructor_office en la tabla Instructors.
En vez de memorizar, hazte una sola pregunta
"Toda propiedad no clave debe depender de la clave, de toda la clave y de nada más que la clave."
Esa frase lo resume todo:
- de la clave = 1NF (el hecho debe poder identificarse por una clave)
- de toda la clave = 2NF (debe depender de la clave completa, no de una parte)
- de nada más que la clave = 3NF (debe depender directamente de la clave, no pasando por columnas no clave)
Si en un examen te sale un problema de normalización, hazte solo esta pregunta: "¿De quién depende esta columna? ¿De la clave completa, de una parte de la clave o de una columna no clave?"
Errores comunes
"Con llegar a 3NF ya está todo hecho" — 3NF es un muy buen punto de partida, pero no el final. A veces hace falta una forma más estricta como BCNF, y otras veces se desnormaliza a propósito por rendimiento.
"Cuantas más tablas se dividan, mejor" — el objetivo de la normalización no es aumentar el número de tablas, sino hacer que "cada tabla se encargue de un solo tipo de hecho". Si divides sin una razón real (una relación de dependencia), solo complicas los JOIN.
"Si uso NoSQL, no necesito normalización" — la normalización es un término propio de las bases de datos relacionales, pero el problema de "mantener consistencia en datos duplicados" existe en cualquier DB. Incluso al desnormalizar, hay que saber "qué estás sacrificando".
Compruébalo tú mismo
Elige una tabla de tu propio proyecto y haz esto:
- Escribe cuál es la clave.
- Revisa si cada columna no clave depende de la clave completa o solo de una parte. → Si depende de una parte, viola 2NF.
- Revisa si alguna columna no clave depende de otra columna no clave. → Si ocurre, viola 3NF.
Con solo estos 3 pasos puedes detectar la mayoría de los problemas de normalización.
¿Necesitas ayuda con un problema?
Sube tu pregunta y obtén una solución verificada, paso a paso, en segundos.
Abrir GPAI Solver →