Normalización de base de datos: 1FN, 2FN y 3FN con ejemplo

La normalización de base de datos organiza relaciones a partir de sus atributos, claves y dependencias para reducir redundancias problemáticas y evitar anomalías de inserción, actualización y eliminación. En un diseño relacional, no consiste simplemente en dividir una tabla grande: cada separación debe conservar la información y responder a las reglas reales del dominio.

Para entenderla, conviene trabajar con un ejemplo que obligue a decidir qué identifica cada registro. En este artículo se usa un caso didáctico de inscripciones universitarias. A partir de él se distinguen la primera, segunda y tercera forma normal, se explica la diferencia con Boyce-Codd y se revisan las condiciones que una descomposición debe cumplir.

Antes de normalizar: atributos, claves y dependencias

Una dependencia funcional X → Y indica que, en todos los estados válidos de la relación, un mismo valor de X determina un único valor de Y. No se descubre únicamente porque una muestra pequeña no contenga contradicciones. Es una regla del dominio que debe confirmarse con quienes conocen el proceso. Los datos existentes pueden refutar una propuesta, pero su coincidencia accidental no la demuestra.

Supongamos una relación ficticia Inscripción con matrícula, nombre del estudiante, código de curso, nombre del curso, identificador de docente, nombre del docente y calificación. Para este ejercicio, cada estudiante aparece una sola vez por curso y cada curso tiene un docente asignado. La clave candidata es el par matrícula y código de curso. Si existen periodos, grupos o recursamientos, el modelo necesitaría otros atributos.

Qué anomalías queremos evitar

Si el nombre de un curso se repite en cada inscripción, corregirlo exige modificar varias filas. Cuando algunas quedan sin actualizar, aparecen versiones incompatibles del mismo dato. También podría ser imposible registrar un curso que todavía no tiene inscripciones, o perder su información al eliminar al último estudiante inscrito. Estos son problemas de representación, no errores que una consulta SELECT pueda resolver por sí sola.

Un identificador artificial no elimina estas anomalías. Agregar id_inscripción puede facilitar referencias técnicas, pero los nombres del curso y del docente seguirán repitiéndose si no se revisan las dependencias. La normalización exige analizar qué representa cada atributo. Las restricciones de unicidad y las claves foráneas complementan ese análisis al hacer explícitas ciertas reglas dentro del gestor.

Primera forma normal: una relación bien definida

En la presentación introductoria de la primera forma normal, cada atributo contiene un valor de su dominio y se evitan grupos repetidos como curso1, curso2 y curso3. Guardar varios códigos separados por comas en una celda dificulta reconocer cada inscripción y establecer restricciones. En el modelo propuesto, cada fila representa la participación de un estudiante en un curso.

La atomicidad debe interpretarse respecto del dominio y del uso previsto. No significa que cualquier texto deba dividirse en caracteres ni que todo dato compuesto sea incorrecto. Separar un domicilio puede ser útil para ciertas consultas, pero esa decisión necesita requisitos. El objetivo es una representación consistente de los hechos que la aplicación pretende consultar y mantener.

Segunda forma normal: evitar dependencias parciales

Una relación está en segunda forma normal si está en primera y ningún atributo no primo depende funcionalmente de una parte propia de alguna clave candidata. En el ejemplo, el nombre del estudiante depende de matrícula, y el nombre del curso depende de código de curso. Ambos dependen de una parte de la clave compuesta, mientras la calificación corresponde a la inscripción completa.

Este ejemplo no autoriza a eliminar cualquier repetición. Que la matrícula figure en muchas inscripciones es necesario para relacionarlas con un estudiante. La redundancia problemática está en repetir hechos que deberían mantenerse de manera independiente. Tampoco basta afirmar que una clave primaria de una columna garantiza automáticamente todo el diseño: deben considerarse las demás claves candidatas y las dependencias del dominio.

Tercera forma normal y dependencia transitiva

En Curso todavía aparece una dependencia que merece atención: código de curso determina identificador de docente, y este determina nombre del docente. El nombre puede repetirse si una misma persona imparte varios cursos. Una nueva separación crea Docente con su identificador y su nombre, mientras Curso conserva la referencia al docente correspondiente.

La definición formal de tercera forma normal exige que, para cada dependencia funcional no trivial X → A, X sea una superclave o A sea un atributo primo. La explicación habitual sobre eliminar dependencias transitivas de atributos no clave es útil para empezar, pero no sustituye esta condición cuando existen varias claves candidatas que se superponen. Una superclave identifica filas, aunque pueda contener atributos sobrantes.

Las claves foráneas de Inscripción apuntan a Estudiante y Curso; la de Curso apunta a Docente. Así, las consultas recuperan nombres mediante uniones. La documentación de PostgreSQL distingue las restricciones de clave primaria, unicidad y referencia. Su existencia no demuestra por sí misma que la base esté normalizada, pero ayuda a mantener la integridad del esquema elegido.

Boyce-Codd y descomposiciones correctas

La forma normal de Boyce-Codd, BCNF, exige que todo determinante de una dependencia funcional no trivial sea una superclave. Es más estricta que tercera forma normal porque no admite su excepción para atributos primos. No es otro nombre de cuarta forma normal. Su estudio permite reconocer casos con claves candidatas superpuestas que una explicación demasiado informal de 3FN podría pasar por alto.

Una descomposición sin pérdida permite reconstruir las relaciones válidas originales mediante la unión correspondiente, sin inventar combinaciones. La preservación de dependencias permite verificar las reglas originales a partir de las relaciones resultantes, sin necesitar ciertas uniones. Son propiedades diferentes. Dividir hasta alcanzar una forma normal no autoriza a ignorar qué información y restricciones pueden recuperarse después.

Cómo revisar un ejercicio y justificar sus decisiones

Puede representarse esta secuencia en un diagrama de flujo para distinguir decisiones y comprobaciones. Después conviene ejecutar casos válidos e inválidos, no solo consultas de lectura. Si el diseño falla al registrar un curso sin estudiantes, el ejemplo revela una dependencia que no se había separado. Un pequeño conjunto de pruebas es más explicativo que un esquema con muchas tablas sin justificación.

El diseño lógico y el rendimiento físico son niveles relacionados. Un sistema operativo y el gestor participan en la ejecución, pero índices, memoria y planes de consulta necesitan medición propia. Desnormalizar puede ser una decisión deliberada para una carga concreta, acompañada de reglas para sincronizar las copias. No equivale a abandonar el modelo ni a prometer que menos uniones siempre será más rápido.

Preguntas frecuentes

¿Normalizar significa eliminar todos los datos repetidos?

No. Las referencias entre relaciones repiten identificadores de manera intencional. La meta es organizar hechos y dependencias para evitar redundancias que generan anomalías. Dos filas con valores iguales en una columna no bastan para concluir que exista un problema de normalización.

¿Agregar una clave artificial resuelve la normalización?

No. Un identificador artificial puede ser útil, pero no elimina las dependencias entre los otros atributos ni las claves candidatas del dominio. Es necesario analizar esas relaciones y decidir dónde debe almacenarse cada hecho para mantenerlo de forma consistente.

¿Una base en tercera forma normal siempre es más rápida?

La forma normal describe propiedades del diseño, no una garantía universal de velocidad. El rendimiento depende de consultas, índices, cantidad de datos, concurrencia y otros factores. Primero se busca un modelo correcto; después se miden las operaciones representativas antes de introducir optimizaciones y duplicaciones controladas.

Video para profundizar