En el ejemplo anterior, una tabla en la Primera Forma Normal (ESTUDIANTES-CLASES) fue descompuesta en dos tablas en la Segunda Forma Normal, con el fin de eliminar los problemas asociados con la redundancia de datos y el comportamiento anómalo. Sin embargo, algunas tablas en la Segunda Forma Normal pueden presentar aún problemas de redundancia y anomalías. Estos problemas pueden ser eliminados mediante transformaciones que den como resultado tablas que se dice están en la Tercera Forma Normal. El ejemplo siguiente ilustra este procedimiento.
 

Adición de datos de los profesores

Supongamos que queremos modificar el diseño de la base de datos implícito en las tablas ESTUDIANTE y ESTUDlANTE-CLASE, con el fin de incluir los nombres y oficinas de los profesores de cada una de las clases. Como la tabla ESTUDIANTE-CLASE contiene ya datos acerca de las clases, parece que sería el lugar más indicado para incluir información acerca de los profesores. Conseguimos nuestro objetivo mediante la siguiente modificación de ESTUDIANTE-CLASE:

ESTUDIANTE-CLASE-PROF[ID-ESTUDIANTE, ID-CLASE, CALIFICACION, PROFESOR, OFICINA]
 
 

hemos vuelto a renombrar la tabla para indicar su contenido. La siguiente tabla contiene unos datos de muestra.
 

Claves y dependencias funcionales

Analicemos la tabla en términos de claves y dependencias, al igual que lo hicimos para el ejemplo anterior. La clave de la tabla permanece igual que hasta ahora, concretamente ID-ESTUDIANTE + ID-CLASE, porque el hecho básico contenido en cada fila sigue siendo una combinación determinada de estudiante y clase. Las dependencias funcionales de la tabla son las siguientes:
 
 

¿Qué forma normal? Como las dependencias funcionales de ID-CLASE son parciales, la tabla ESTUDIANTIE-CLASE-PROF no está en la Segunda Forma Normal. Una vez más, el motivo de esto es que cada fila representa dos hechos básicos: el hecho estudiante/clase es el mismo de antes, pero también existe otro hecho ligeramente oculto: cada clase existe independientemente de los estudiantes matriculados en ella.
 
 

Transformación a la Segunda Forma Normal

La tabla ESTUDIANTE-CLASE-PROF, debido a estas dependencias parciales, exhibirá los mismos tipos de problemas de redundancia y anomalías que hemos señalado anteriormente. Esto puede verificarse estudiando los datos de muestra de la siguiente tabla:
 

Al igual que en el ejemplo anterior, estas dificultades pueden ser eliminadas descomponiendo las dependencias parciales, con lo que se obtienen las siguientes nuevas tablas:

ESTUDIANTE-CLASE[ID-ESTUDIANTE, ID-CLASE, CALIFICACION]

CLASE-PROF[ID-CLASE, PROFESOR, OFICINA]
 
 

Fíjese en que la descomposición ha dado como resultado la creación nuevamente de la tabla ESTUDIANTE-CLASE, que se indicaba anteriormente, y que se encontraba en la Segunda Forma Normal. Si enfocamos nuestra atención sobre CLASE-PROF, nos damos cuenta de que también está en la Segunda Forma Normal, debido a las dependencias funcionales mostradas. Es decir, cada uno de los atributos que no constituyen una clave son totalmente dependientes de lD-CLASE, que es la clave.
 
 

Redundancia de datos y comportamiento anómalo

Estudiando una muestra de datos para CLASE-PROF se puede percibir que, incluso aunque la tabla está en la Segunda Forma Normal, aún existe una redundancia de datos considerable: los nombres y números de oficina de algunos de los profesores aparecen más de una vez. Además, la tabla muestra los mismos tipos de anomalías de modificación que ya se analizaron anteriormente.

Anomalías de actualización. Si un profesor determinado se mueve de una oficina a otra, es preciso modificar varias entradas de la tabla. Esto constituye otro ejemplo en el cual el cambio de un único hecho, en este caso, la asociación entre un profesor y un oficina, exige la alteración de varias entradas de la tabla.

Anomalías de borrado. Supongamos que un profesor pierde todas sus clases, debido a la falta de asistencia de los alumnos. Cuando se eliminan todas las entradas de la tabla, sucede lo mismo con el número de oficina del profesor. Es decir, como el profesor no tiene ninguna clase, la base de datos pierde la información que lo relaciona con un oficina concreto. Esto es una anomalía de borrado, y no debe producirse.

Anomalías de inserción. Supongamos que un nuevo profesor se incorpora a la escuela, pero aún no tiene asignada ninguna clase. No será posible añadir el nombre ni el número de oficina de esta persona a la tabla, porque la clave de la tabla es ID-CLASE. No tiene sentido incluir una entrada en la tabla, que no tenga un valor de la clave, ya que dos de dichas entradas darían como resultado dos filas con el mismo valor de la clave, lo cual viola la estructura básica de las tablas relacionales. Por supuesto, sería posible asignarle un valor de clave falso, de forma que pudiera introducirse el profesor como una fila separada, pero los problemas potenciales asociados con este método son lo suficientemente molestos como para que se descarte este tipo de solución.
 
 

Dependencias funcionales transitivas

Parece que hemos encontrado que, aunque CLASE-PROF esta en la Segunda Forma Normal, presenta exactamente los mismos tipos de problemas que existían en nuestros ejemplos precedentes de tablas en la Primera Forma Normal. De hecho, la razón para este tipo de problemas es también similar a la que vimos antes: existe todavía algún tipo de dependencia funcional dentro de la tabla. Esta dependencia surge del hecho de que aunque OFICINA es funcionalmente dependiente de ID-CLASE, también es funcionalmente dependiente de PROFESOR:

PROFESOR ® OFICINA

Esta dependencia puede observarse estudiando los datos de la tabla CLASE-PROF, fijándose en que los valores de OFICINA van completamente ligados a los de PROFESOR.

La relación PROFESOR ® OFICINA es un ejemplo de una dependencia funcional transitiva, que se define de la forma siguiente:
 
 

La dependencia transitiva y sus problemas asociados de redundancia de datos pueden ser eliminados mediante una técnica similar a la que usamos para eliminar las dependencias parciales: descomponiendo la dependencia en una tabla aparte, de la forma siguiente:

CLASE-PROF [ID-CLASE, PROFESOR]

PROFESORES [NOMBRE, OFICINAJ
 
 

Cada una de estas tablas se dice que está en la Tercera Forma Normal, que se define de la siguiente forma:
 
 

Como resultado de la descomposición de la tabla, los datos de la tabla CLASE-PROF se convierten de la siguiente manera:
 

En los de las tablas anteriores; un examen revela que los problemas de redundancia de datos y de comportamiento anómalo han desaparecido.
 
 

La mejor Forma Normal

Las Formas Normales que se han presentado hasta ahora, así como las que se analizarán más adelante, son, en cierto sentido, ideales que el diseñador debe tener en mente. Sin embargo, no es absolutamente esencial que una tabla tenga que estar en una forma determinada para que resulte útil. Por ejemplo, una tabla que no está en Segunda Forma Normal podría ser utilizada tal como está para el almacenamiento, recuperación y modificación de datos. El diseñador, sin embargo, debería ser consciente de las dificultades potenciales relacionadas con las anomalías de modificación, y del espacio de almacenamiento adicional requerido por culpa de la redundancia de datos.
 
 

Descomponer o no descomponer

Con frecuencia se elige deliberadamente no transformar una tabla a la Tercera Forma Normal, dejándola en alguna de las otras dos formas. Considere el ejemplo siguiente:

CLIENTES [RUT, NOMBRE, TELEFONO, CALLE, CIUDAD, REGION]

Esta tabla no está en la Tercera Forma Normal, ya que existe una dependencia transitiva entre dos de los atributos:

CIUDAD ® REGION
 
 

Con el fin de eliminar estas dependencias parciales, sería necesario descomponer la tabla CLIENTES de esta forma.

Por otro lado, supongamos que nuestra base de datos consta de las dos tablas (segundo diseño). En este caso, sería necesario un proceso de dos etapas para cada cliente:

La Tercera Forma Normal es una meta útil, pero el diseñador tendrá que afrontar a menudo la elección de sacrificar el ideal a lo práctico.