Más allá de la tercera forma normal

Al preparar la teoría de las bases de datos relacionales, F.F. Codd propuso primero las tres reglas de la normalización. Al examinar las situaciones del mundo real, él y otros diseñadores comprendieron que podrían ocurrir problemas adicionales en algunas situaciones, por lo que se crearon «formas normales» adicionales. Por suerte, estas situaciones no suelen surgir en la práctica.

Las tablas deben estar en la 3NF.

Forma normal de Boyce-Codd

Deben analizarse las columnas; si varias de ellas presentan una dependencia oculta entre sí (siendo que si de la tabla se eliminan filas y por ello se pueden perder datos importantes) debe agregarse una nueva tabla para hacer explícita la dependencia entre esas columnas. Como buena práctica y por cuestiones de flexibilidad se recomienda dejar la tabla original y agregar la nueva.

Cuarta forma normal

El problema se presenta cuando hay relaciones binarias pero el modelador intenta mostrarlas como una relación combinada. Si se detecta que hay una dependencia oculta entre columnas, se debe dividir la tabla en varias tablas (las necesarias) para mostrar cada una de las dependencias haciéndolas explícitas.

Forma normal dominio-llave

En 1981, Fagin describió un enfoque diferente para las tablas normalizadas cuando propuso la forma normal dominio-llave (DKNF), la cual describe la meta final al diseñar una base de datos. Si una tabla está en la DKNF, también debe estar en la 4NF, 3NF y todas las demás formas normales. La dificultad es que no hay un método definido para hacer que una tabla esté en la DKNF. De hecho, es posible que algunas tablas nunca puedan convertirse a la DKNF.

La meta de la DKNF es hacer que cada tabla represente un tema y que para todas las reglas de negocios se exprese en términos de restricciones de dominios y relaciones de llaves. Es decir, todas las reglas de negocios se describen de manera explícita por medio de las reglas de las tablas. Las restricciones de dominios son sencillas; representan las limitaciones que se aplican a los datos en una columna.

Todas las otras reglas de negocios deben expresarse en términos de relaciones con las llaves. En particular, no puede haber relaciones ocultas.

Para definir un grupo de tablas en la DKNF, primero hay que trabajar en las reglas de la 3NF. Después, confirmar que se tiene una lista completa de las reglas de negocios. A continuación, asegurarnos que las reglas de negocios están expresadas en términos de restricciones de dominios y relaciones de las llaves. Revisar las llaves primarias para confirmar que sean únicas; y que se han capturado todas las relaciones muchos a muchos. Comprobar que no haya reglas ocultas ni dependencias. Establecer relaciones con llaves foráneas para imponer las reglas de existencia y para hacer coincidir los datos en las otras tablas.

La meta al diseñar la base de datos es desarrollar un modelo de la organización, y la DKNF aclara esta meta al afirmar que el mejor diseño de una base de datos es el que declara de manera explícita todas las reglas de negocios como reglas de la base de datos.