Normalización de bases de datos: guía y formas normales (1NF, 2NF, 3NF)

Guía práctica sobre normalización de bases de datos: entiende 1NF, 2NF y 3NF, aprende a evitar redundancias, mejorar integridad y optimizar consultas en bases relacionales.

La normalización de las bases de datos es un enfoque para el diseño de bases de datos que fue introducido por Edgar F. Codd en la década de 1970. Algunas bases de datos, conocidas como bases de datos relacionales, permiten almacenar los datos en grupos separados. Cada grupo se denomina comúnmente tabla. Para proporcionar información útil, estos grupos están conectados entre sí. Por ejemplo, los estudiantes pueden almacenarse en un grupo y las clases en otro. Para mostrar que un estudiante está inscrito en una clase, se establece una "relación" de un grupo a otro. Un estudiante podría tener una relación con muchas clases, en cada una de las cuales estaría inscrito, mientras que una clase tendría una relación con muchos estudiantes.

Una alternativa tradicional es la "base de datos de archivos planos", en la que todos los datos se agrupan como en una hoja de cálculo. El problema de las bases de datos de archivos planos es que pueden tener muchos espacios en blanco y hay mucha información que debe repetirse para cada entrada. Esto significa que la base de datos es más grande de lo que tiene que ser, y hace más probable que la base de datos contenga errores. Las bases de datos relacionales, al dividir los datos en grupos, reducen la posibilidad de que se produzcan errores y no ocupan más espacio del necesario. Pero para que funcione tiene que estar bien diseñada.

La normalización de las bases de datos es un método para diseñar buenas bases de datos relacionales. Hay varias "formas normales", cada una de las cuales tiene reglas que la base de datos debe cumplir. Codd especificó originalmente tres conjuntos de criterios que deben cumplir las diferentes bases de datos: primera, segunda y tercera forma normal.

Si una relación (o "tabla de la base de datos") cumple una determinada forma normal, no es vulnerable a ciertas modificaciones que afectarán a la integridad de los datos. El inconveniente de cumplir una serie de criterios de este tipo suele ser que la consulta de determinados datos de la base de datos será más difícil (más joins entre tablas) y puede requerir mayor coste computacional.

Por qué normalizar: anomalías y dependencias

La normalización busca eliminar redundancias y dependencias indeseadas. Las anomalías más frecuentes que se evitan con una buena normalización son:

• Anomalía de inserción: no poder añadir datos nuevos sin proporcionar información no disponible.
• Anomalía de actualización: tener que actualizar el mismo dato en muchos registros distintos, con riesgo de inconsistencia.
• Anomalía de borrado: perder información útil al eliminar un registro.

Conceptos clave:

• Clave primaria (PK): identificador único de cada fila.
• Clave candidata: cualquier conjunto de atributos que pueda servir como clave primaria.
• Dependencia funcional: un atributo B depende funcionalmente de A si conociendo A se determina B (A → B).

Primera forma normal (1NF)

Requisitos principales:

• Cada tabla debe tener filas únicas (habitualmente mediante una clave primaria).
• Los atributos deben contener valores atómicos: no se permiten conjuntos ni listas en una sola celda.
• No debe haber grupos repetitivos de columnas.

Ejemplo sencillo: en vez de tener una columna "cursos" con valores como "Matemáticas, Física" en la tabla de estudiantes, se separa esa información creando una tabla de matrícula/inscripción donde cada fila representa la relación estudiante–curso. Así se evita almacenar varias clases en una misma celda.

Segunda forma normal (2NF)

Requisitos principales:

• La tabla debe estar en 1NF.
• No debe existir dependencia parcial: ningún atributo no clave puede depender solo de una parte de una clave primaria compuesta.

Ejemplo: una tabla Inscripciones con clave primaria compuesta (student_id, course_id) no debería contener atributos como student_name (que depende solo de student_id). student_name debe moverse a la tabla Estudiantes. Mantener student_name en Inscripciones infringiría 2NF y provocaría redundancia y anomalías de actualización.

Tercera forma normal (3NF)

Requisitos principales:

• La tabla debe estar en 2NF.
• No debe existir dependencia transitiva: los atributos no clave no deben depender de otros atributos no clave.

Ejemplo: si una tabla Empleados contiene (employee_id PK, dept_id, dept_name), y dept_name depende de dept_id (que no es clave primaria), entonces dept_name depende transitivamente de employee_id → dept_id → dept_name. La solución es crear una tabla Departamentos (dept_id, dept_name) y almacenar solo dept_id en Empleados.

Formas normales superiores y excepciones prácticas

Más allá de la 3NF existen la Boyce–Codd Normal Form (BCNF), la 4NF y la 5NF, que tratan dependencias más complejas (por ejemplo, dependencias multivaluadas o de unión). En muchos sistemas reales, alcanzar BCNF o 4NF es deseable, pero no siempre imprescindible.

En la práctica también existe la estrategia contraria: la desnormalización. Para aplicaciones de lectura intensiva o por razones de rendimiento se puede duplicar intencionadamente cierta información para evitar múltiples joins. La desnormalización debe hacerse con cuidado y normalmente se compensa con mecanismos de mantenimiento (triggers, procesos batch, etc.).

Guía rápida para normalizar una tabla

1. Identificar la clave primaria y las claves candidatas.
2. Comprobar que los atributos son atómicos (1NF).
3. Si la clave es compuesta, mover atributos que dependan solo de una parte de la clave a tablas separadas (2NF).
4. Eliminar dependencias transitivas moviendo atributos a tablas adecuadas (3NF).
5. Revisar si existen dependencias más complejas que requieran BCNF u otras formas.

Ejemplo de esquema normalizado (caso estudiantes y cursos)

• Estudiantes(student_id PK, nombre, fecha_nacimiento, correo)
• Cursos(course_id PK, titulo, créditos)
• Inscripciones(student_id FK, course_id FK, fecha_inscripción, nota) — clave primaria compuesta (student_id, course_id)

Este diseño evita redundancia de nombres de estudiantes o títulos de cursos, permite mantener consistencia y facilita consultas sobre relaciones entre entidades.

Consideraciones finales

La normalización mejora la integridad y reduce el almacenamiento innecesario, pero puede aumentar la complejidad de las consultas. Algunas recomendaciones:

• Normaliza hasta el nivel necesario (habitualmente 3NF o BCNF) antes de optimizar por rendimiento.
• Usa índices para acelerar búsquedas y joins en tablas normalizadas.
• Documenta las claves y dependencias funcionales; facilita el mantenimiento y evita errores.
• Cuando desnormalices por rendimiento, aplica pruebas y establece procesos para mantener la consistencia.

Preguntas y respuestas

P: ¿Qué es la normalización de bases de datos?

P: ¿Qué es una base de datos de archivos planos?

P: ¿Cómo reducen las bases de datos relacionales la posibilidad de que se produzcan errores?

P: ¿Qué son las formas normales?

P: ¿Cuáles son los inconvenientes de cumplir determinados conjuntos de criterios para las formas normales?

Búsqueda por letra