Normalización de bases de datos (Parte 4): Tercera forma de normalización (3NF) y Forma de normalización Boyce-Codd (BCNF)

En los anteriores de la serie hemos analizado las otras dos formas de normalización o formas normales para una base de datos. El día de hoy veremos qué es la tercera forma normal o 3NF.

La 3NF fue diseñada para eliminar anomalías indeseables en los datos, reducir la necesidad de reestructurar con el paso del tiempo, hacer el modelo de datos más informativo y hacer que el modelo de datos sea neutral a distintos tipos de estadísticas de consultas. Cabe hacer notar que el Dr. Codd se dio cuenta posteriormente que la 3NF no lograba el primer punto, que es el de eliminar anomalías indeseables en los datos, por lo que desarrolló la forma normal Boyce-Codd para corregir las limitaciones de la 3NF.

Para que una base de datos cumpla con la 3NF debe satisfacer los siguientes requerimientos:

1. Debe cumplir con la segunda forma de normalización (2NF)
2. No debe tener dependencias transitivas

Dependencia transitiva

Una dependencia transitiva es aquella donde un atributo no-primario depende de otro atributo no primaro en lugar de depender del atributo primario o de la Clave principal. Veamos el ejemplo de la siguiente tabla 2NF que no cumple con 3NF:

En esta tabla se almacenan los campeones que ha habido en la Liga de fútbol mexicano. La Clave principal es el Torneo como tal. Sin embargo, hay una anomalía: el campo EquipoLocalidad depende de Equipo y no del Torneo como tal. La clave principal del torneo es, precisamente la de Torneo, no la de Equipo. Ésta es una dependencia transitiva, donde un campo que no es primario o principal depende de otro campo que tampoco es primario o principal. 

La forma de resolver esto es poner los campos Equipo y Localidad en otra tabla. Así, las tablas quedarían de la siguiente forma:

Nótese que con esto hemos eliminado las redundancias. Así, al hacer referencia a uno de los equipos de fútbol, si queremos ver sus detalles, simplemente los leeremos de la tabla correspondiente, misma que está vinculada en la tabla Campeonatos mediante la Clave externa (FK) Equipo. 

Forma de normalización Boyce-Codd

A esta forma se le conoce también como Forma de normalización 3.5 dado que es una extensión de la 3NF. Fue desarrollada en 1974 por los Dres. Raymond F. Boyce y Edgar F. Codd para satisfacer la condición de integridad de la base de datos. Para que una base de datos cumpla con la Forma de normalización Boyce-Codd (BCNF) debe satisfacer dos condiciones:

1. Debe cumplir con la Tercera forma de normalización
2. Para cualquier dependencia de A->B, A debe ser una superclave.

Para tenerlo más claro, BCNF o 3.5NF es 3NF pero más estricta. La finalidad de esta forma de normalización es la de incrementar la integridad de datos mediante la organización de las columas y tablas de una base de datos relacional para lograr la normalización. Tal normalización ocurre cuando hay relaciones establecidas entre las tablas y cuando las tablas tienen reglas establecidas para hacer que la base de datos sea más flexible y para conservar los datos.

En el ejemplo anterior, ya escindimos los datos de Equipo y Localidad en otra tabla. Sin embargo, volvemos a notar que aquí hay un problema: Un equipo, por sí mismo, puede ser una Clave candidata, pero Localidad, también. De hecho, un equipo pertenece a una localidad, pero una localidad puede tener varios equipos. Esta tabla no cumple con la 3.5NF, pues la columna localidad no depende de la Clave principal (equipo), por lo que habrá que volver a escindirla para que cumpla. Las localidades provendrían de una tabla Localidad de manera que se mantenga la integridad. Esto eliminaría la redundancia de localidades en la tabla de equipos y mantendría la integridad de la base de datos. 

3NF y BCNF en la tabla de Códigos Postales

Hasta ahora, nuestra base de datos de códigos postales que cumple con 2NF está así:

Por lo que vemos en la tabla, hay tres campos en particular que tienen dependencias transitivas: d_ciudad, c_oficina y d_zona. La buena noticia es que d_ciudad tiene una clave de ciudad en c_cve_ciudad, por lo que ésa fungirá como clave externa en la tabla de códigos postales. Por añadidura, c_cve_ciudad también depende de c_estado, pues las ciudades están organizadas por Estados. Así, para hacer la Clave principal en la tabla de Ciudades, deben incluirse las claves c_estado y c_cve_ciudad.

Así, nuestra tabla de códigos postales quedaría de la siguiente forma:

Ahora ya tenemos una base de datos que cumple con 1NF, 2NF y 3NF.

Cabe hacer notar que tenemos la Clave principal que está formada por c_estado, c_mnpio e id_asenta_cpcons. Sin embargo, esta tabla no cumple con BCNF porque d_codigo por sí misma es una superclave por sí misma, puesto que un código postal puede tener más de un asentamiento. Ante ello, es altamente recomendable, para que cumpla con BCNF, hacer una tabla únicamente de códigos postales para tener unicidad en los datos. Debido a que un código postal puede hacer una súperclave con c_estado y c_mnpio entonces con ello se puede hacer un vínculo unívoco (no se podría incluir id_asenta_cpcons, pues puede haber más de un asentamiento en un código postal). Así la tabla de códigos postales quedaría de la siguiente forma:

Ahora sí, ya tenemos una base de datos que cumple con 1NF, 2NF, 3NF y BCNF.

Veremos qué nos depara la 4NF en el siguiente de la serie. ¡Nos seguimos leyendo!