Tercera forma normal y superiores

Una relación está en tercera forma normal cuando está en segunda y no existen dependencias transitivas. Dicho de otra forma: el único determinante admitido dentro de la relación es la propia clave, así que ningún atributo ajeno a ella puede determinar a otro.

Una dependencia es transitiva cuando la clave determina un atributo y ese atributo determina a un tercero. Si la clave determina a C y C determina a D, entonces la clave determina a D dando un rodeo, y D acaba repetido en todas las filas que compartan el mismo valor de C.

La corrección es la misma que en la segunda forma normal: se saca el atributo determinado junto con su determinante a una relación nueva, y el determinante se queda en la original como clave ajena.

-- id_tema es la clave; determina a id_bloque, e id_bloque
-- determina a nombre_bloque. Dependencia transitiva.
tema(id_tema, titulo, id_bloque, nombre_bloque)

-- En 3FN: el bloque pasa a tener relación propia.
tema(id_tema, titulo, id_bloque)
bloque(id_bloque, nombre_bloque)

La tercera forma normal es el punto en el que se detiene la mayoría de los diseños reales. A partir de aquí las formas normales resuelven casos cada vez menos frecuentes y el coste en uniones deja de compensar en muchos escenarios.

Segunda forma normal: dependencias parciales de una parte de la clave. Tercera: dependencias transitivas a través de un atributo que no es clave. Esa es la diferencia que se pregunta.

La forma normal de Boyce-Codd es un afinamiento de la tercera: cubre una anomalía que la tercera deja pasar. Su enunciado es más corto y más exigente: una relación está en Boyce-Codd si y solo si todos sus determinantes son claves candidatas.

La tercera forma normal solo vigila los atributos no principales, así que da por bueno que un atributo que no es clave candidata determine a un atributo que sí forma parte de la clave. Boyce-Codd cierra ese hueco: en ella no se admite ningún determinante que no sea clave candidata, forme parte de la clave el atributo determinado o no.

El caso solo aparece cuando se dan tres condiciones a la vez: la relación tiene varias claves candidatas, al menos una es compuesta, y se solapan compartiendo algún atributo. Si no se cumplen las tres, tercera forma normal y Boyce-Codd coinciden.

-- R(id_alumno, materia, tutor)
-- Un tutor imparte una sola materia, y un alumno tiene un tutor
-- por materia. Claves candidatas: (id_alumno, materia) y
-- (id_alumno, tutor).
--
-- Está en 3FN: no hay atributos no principales.
-- No está en FNBC: tutor determina a materia y tutor no es
-- clave candidata.

-- Descomposición:
tutoria(id_alumno, tutor)
tutor_materia(tutor, materia)

Toda relación en Boyce-Codd está en tercera forma normal, pero no al revés. La prueba rápida: buscar un determinante que no sea clave candidata.

Una relación está en cuarta forma normal cuando está en Boyce-Codd y toda dependencia multivaluada no trivial que contenga está implicada por una clave candidata. En la práctica: no puede haber dos dependencias multivaluadas independientes conviviendo en la misma relación.

El síntoma es inconfundible. Si una relación junta dos hechos que no tienen nada que ver entre sí, la tabla se ve obligada a guardar todas las combinaciones posibles de ambos, y el número de filas crece como el producto de las dos listas en lugar de como su suma.

Si una asignatura la imparten dos profesores y se ofrece en dos cursos, una tabla que guarde asignatura, profesor y curso tiene que tener cuatro filas para expresar algo que en realidad son dos hechos de dos elementos cada uno. Y al añadir un tercer profesor habría que añadir dos filas, una por curso, aunque el profesor no tenga relación con el curso.

La solución es separar los dos hechos en dos relaciones: una que enlace asignatura con profesor y otra que enlace asignatura con curso. La información se conserva y la explosión combinatoria desaparece.

La cuarta forma normal se ocupa de las dependencias multivaluadas. El indicio para reconocerla es una tabla que guarda el producto cartesiano de dos listas independientes.

La quinta forma normal, también llamada forma normal de proyección-unión, exige que toda dependencia de combinación esté implicada por las claves candidatas. Se ocupa del caso en que una relación se puede descomponer en tres o más piezas sin pérdida de información, aunque no se pueda descomponer en dos.

Tiene una particularidad que la distingue de todas las anteriores: no se deduce de la estructura del esquema. Depende de la semántica y de qué combinaciones son posibles en el mundo real, así que hay que conocer el dominio para detectarla. Es una situación rara y en un diseño corriente casi nunca aparece.

La sexta forma normal es el extremo de la serie: una relación está en sexta cuando no admite ninguna descomposición sin pérdida que no sea trivial. La consecuencia práctica es que sus relaciones quedan reducidas a la clave primaria y, como mucho, un atributo más. Se usa sobre todo en bases de datos temporales, donde cada atributo tiene su propio periodo de validez y conviene tratarlo por separado.

Las formas normales son acumulativas: para estar en tercera hay que estar antes en segunda, y para estar en segunda hay que estar en primera. Por eso decir que una relación está en tercera forma normal ya afirma que cumple las dos anteriores, y por eso no tiene sentido preguntarse por la cuarta si falla la primera.

Esa acumulación tiene una consecuencia útil al resolver un supuesto: se avanza en orden y en cuanto una forma falla, se para. La respuesta a «¿en qué forma normal está esta relación?» es siempre la última que cumple antes del primer fallo.

En el otro sentido, normalizar no es un fin en sí mismo. Cada descomposición añade una unión a las consultas, y en sistemas con mucha lectura eso se nota. La desnormalización consiste en dar marcha atrás de forma deliberada, reintroduciendo una redundancia concreta para ahorrar uniones frecuentes.

Es una decisión legítima, pero con dos condiciones. La primera es que se tome con medidas de rendimiento delante, no por intuición. La segunda es que se asuma el trabajo que trae: si un dato pasa a estar en dos sitios, alguien tiene que garantizar que los dos se actualizan a la vez, y ese alguien suele ser un disparador o una rutina de la aplicación.

Se normaliza para proteger la consistencia y se desnormaliza para ganar rendimiento en lectura. Desnormalizar sin medir no es una optimización, es un diseño mal hecho con otro nombre.