Normalización de base de datos: descripción y características de las 5 formas normales.

Para iniciar, es importante que comprendas el término normalizar y como es que este lo aplicamos en una base de datos.

¿Qué es la normalización de una base de datos (DB)?

Una definición sencilla es que la normalización es un proceso repetitivo que nos permite aplicar una serie de reglas a nuestras relaciones, con la finalidad de evitar redundancias y garantizar la integridad de los datos.

Entonces, con la normalización vamos a normalizar, ordenar y mejorar nuestras relaciones.

¿Para qué sirve la normalización de base de datos?

Bien, anteriormente te he mencionado que deseamos mejorar y ordenar nuestras relaciones, pues bien, a lo que me refiero es eliminar redundancias, en un capítulo anterior de este curso, vimos como a través del manejo de dependencias funcionales podemos eliminar redundancias y mejorar nuestros conjuntos de dependencias.

Pues bien, la normalización de una base de datos (DB), busca precisamente esto:

• Disminuir o eliminar las redundancias.
• Minimizar los problemas de actualización de datos en las relaciones.
• Asegurar la integridad de los datos

En muchas bases de datos se presentan anomalías por un mal diseño, por ejemplo, podemos encontrar anomalías en: la actualización, modificación o eliminación de datos, y si, normalizamos nuestra base de datos, podremos mitigar estas anomalías.

Base de datos normalizada: Fundamentos

Antes de continuar con el tema, en este punto ya debes estar familiarizado con algunos términos, por ejemplo:

• Relaciones
• Tuplas
• Atributos

Y debes comprender los fundamentos de la álgebra relacional

• Operaciones fundamentales
  • Selección
  • Proyección
  • Unión
  • Diferencia de conjuntos
  • Producto cartesiano
  • Renombramiento
• Dependencias funcionales
• Cierre canónico

Si al leer esto no estás convencido de que es cada cosa, te invito a revisar los siguientes post donde profundizamos en cada tema.

Reglas de normalización de una base de datos

Para comenzar, recordemos un poco la notación que establece la teoría relacional.

• Un esquema relacional lo podemos representar a través de:

R(a₁, a₂, a₃, … , a_n)

• Y una relación es una función de un esquema relacional: r(R)
• No obstante, es válido nombrarle relación a un esquema relacional, tal como lo hemos hecho hasta el momento: R(a1, a2, a3, … , an) o R

Por lo regular, tenemos la Relación original o mega relación ya que contiene todos los elementos y, lo que vamos hacer es dividirla en relaciones más pequeñas, con el objetivo de ir mitigando los errores de diseño:

• R(a₁, a₂, a₃, … , a_n)
  • R1(a₁, a₂, a₃)
  • R2(a₁₀, a₂₀, a₃₀)
  • R3(a₁₀₀, a₂₀₀, a₃₀₀)

Ahora, no podemos nada más dividir y ser felices, sino que debemos seguir una serie de reglas bien definidas, a estas reglas se les conoce como "Formas Normales" y las veremos a continuación.

Las 5 formas normales (FN)

Existen 5 reglas que podemos aplicar a las relaciones de nuestra base de datos, tres de ellas fueron postuladas por Edgar F. Codd, quien fue el creador del modelo relacional.

Ahora vayamos paso por paso comprendiendo y analizando cada una de las formas normales.

💡 Primera forma normal (1FN)

Esta primera forma normal indica que:

Una relación está en Primera Forma Normal (1FN) si, y solo si, no tiene grupos repetidos.

Por lo tanto y según lo establecido en el modelo relacional, en una relación se debe cumplir que:

• No deben existir grupos repetitivos.
• No importa el orden.
• Debe existir una llave primaria.
• Todos los atributos deben ser atómicos.
• No debe tener tuplas repetidas.

Ejemplo: ¿Cómo hacer que una tabla (relación) esté en la primera forma normal (1FN)?

Supongamos que tenemos la siguiente relación que representa los proyectos que lleva cada empleado y el puesto que tiene actualmente:

En dicha tabla de empleados, tenemos los siguientes problemas:

• No existe una llave primaria.
• El atributo proyecto no es una columna atómica o indivisible.

Entonces, hagamos los siguientes cambios:

• Primero agreguemos una llave primaria y le llamaremos No Empleado
• Y dividamos el atributo Proyecto que no es atómico, en atributos atómicos, con el mismo dominio.

Al dividir el atributo Proyecto, tenemos atributos atómicos, pero, también creamos algo que se llama grupo repetitivo, este tipo de grupos generan algunos problemas, por ejemplo:

• Imponen un límite, ya que en este caso, un empleado no podría tener más de tres proyecto.
• Por otra parte, si observamos, Ángela solo tiene dos proyectos, por lo que el atributo Proyecto 3 se encuentra vacío, lo que provoca un desperdicio de espacio.
• Otro de los problemas está relacionado a las búsquedas, ya que, por ejemplo: en este caso, si deseamos conocer los proyectos que tiene cada empleado, deberíamos realizar búsquedas sobre tres atributos diferentes.

Entonces, cómo aún tenemos grupos repetitivo, y según la definición de la primera forma normal, las relaciones no deben tener ningún grupo repetitivo, por lo tanto, debemos encontrar una forma de eliminar dicho grupo.

¿Cómo eliminar los grupos repetitivo?

Bien, en este punto en el que nos encontramos, lo más sencillo es generar una tupla por cada concurrencia que exista, esto nos llevaría a la siguiente tabla:

Haciendo esto hemos eliminado al grupo repetitivo, pero:

• Ahora tenemos llaves primarias repetidas
• Y redundancia a simple vista en los datos.

Por lo tanto, debemos seguir operando, y lo que vamos hacer ahora es dividir nuestra tabla en dos relaciones:

1. Una relación con el grupo repetitivo que llamaremos “Proyectos asignados”.
2. Y otra relación con el resto de atributos que contenga los datos de la relación original, la cual nombraremos nuevamente como Empleados
3. Ahora, simplemente debemos agregar la llave primaria de Empleados en la nueva relación “Proyectos asignados”.

Como vimos en capítulos anteriores, entre Empleados y Proyectos asignados se tiene un redundancia débil, además, Empleados cumple con lo establecido por el modelo relacional y la primera forma normal, por lo tanto nuestra relación Empleados ha quedado en primera forma normal (1FN).

Tabla intermedia o tabla de relación

Sin embargo, Proyectos asignados no esta normalizada, así que debemos repetir el proceso hasta que dicha relación este en la 1FN, para ello ocuparemos una tabla intermedia, pero antes, analicemos como esta actualmente:

• Observemos que la llave No Empleados tienen datos duplicados, no obstante, es una llave primaria de Empleados, y en esta relación es una llave foránea, y según lo que vimos en el modelo relacional, una llave foránea puede tener datos duplicados.
• También podemos ver que el atributo Proyectos tiene redundancia respecto al dato CMS.

Para eliminar la redundancia en el atributo Proyectos, debemos crear otra relación que:

• Almacena los datos de los proyectos
• Y que tenga su propia llave primaria.
• A esta nueva relación la nombraremos como Proyectos.

Ahora simplemente, agreguemos nuestra llave primaria No Proyecto en nuestra relación Proyectos Asignados, por buenas prácticas asegúrate de tener las llaves siempre al inicio de la relación.

Ahora nuestra relación Proyectos Asignados:

• Cuenta con dos llaves foráneas:
  • No Empleado
  • No Proyecto
• Estas dos llaves foráneas componen una llave primaria compuesta.
• No existen tuplas duplicadas
• No importa el orden
• Todos sus atributos son atómicos
• Y no hay grupos repetitivos

Sin embargo, el atributo Proyecto es un atributo derivable, ya que, podemos obtenerlo de la tabla Proyectos, por lo que podemos eliminarlo y quedarnos solamente con:

• No Empleado
• No Proyecto

📌 Por lo tanto, la tabla Proyectos asignados es una tabla de relación o tabla intermedia, que en este caso, relaciona la tabla Empleados y Proyectos y, además, se encuentra en la primera forma normal (1FN).

Finalmente llegaríamos al siguiente esquema de relaciones:

Entonces, en la primera forma normal:

• El objetivo es eliminar los grupos repetitivos de forma independiente:
  1. Moviendo el grupo a una nueva entidad.
  2. Se agrega la llave primaria original, convirtiéndose en llave foránea.
  3. Si nuestra nueva entidad no posee una llave primaria natural, podemos agregar una llave suplente o una llave de otra entidad.
• Si en proceso de normalización, nos encontramos con otras entidades, debemos repetir el proceso de normalización.

💡 Segunda forma normal (2FN)

A esta segunda forma también se le conoce como “Forma de la dependencia funcional completa”, pero ¿Qué no sindica la segunda forma normal (2FN)?

Una relación está en segunda forma normal si, y sólo si: esta en la primera forma normal y no cuenta con dependencias parciales, es decir, ninguno de los atributos depende únicamente de una parte de la llave primaria.

Y a que se refiere con depender únicamente de una parte de la llave primaría, pues bien, recordemos que en una relación existen llaves primarias, y esta llave primaria puede estar formada por uno o mas atributos, entonces:

• La llave primaria completa es la conformación de todos los atributos que forman la llave, ya sea uno o más de uno.
• En una entidad los atributos pueden depender de todos los atributos que conforman la llave primaria, a esto se le conoce como dependencia funcional completa.
• Pero, también existe el caso donde en una entidad, los atributos dependan únicamente de algunos atributos que conforman la llave primaria, a esto se le conoce como dependencia funcional parcial.

📌 Entonces, podríamos decir, que una relación que se encuentra en la 1FN, también se encuentra en la 2FN, si su llave primaria depende únicamente de un atributo simple.

Por lo tanto, para llevar a una relación a la segunda forma normal necesitamos:

1. Identificar las dependencias parciales.
2. Crear una nueva relación por cada dependencia parcial existente.

Con estos dos pasos, al final, cada relación resultante sólo debe tener dependencias funcionales completas y, para qué, se comprenda mejor, pasemos a realizar un ejemplo.

Ejemplo: ¿Cómo hacer que una relación esté en la segunda forma normal (2FN)?

Analicemos el siguiente caso , el cual es similar al que usamos en la 1FN: una relación con la asignación de proyectos y el costo.

Ahora, podemos identificar lo siguiente:

• Tenemos una llave primaria compuesta:
  • No Empleado
  • No Proyecto
• Y los atributos Proyecto y Costo son atributos dependientes.
• No obstante, el atributo costo depende de la llave compuesta, es decir, tanto de No Empleado como de No Proyecto, a esto se le conoce como una dependencia funcional completa.
• Por otra parte, el atributo Proyecto, únicamente depende del atributo No proyecto, es decir, solo depende de una parte de la llave primaria, a esto se le conoce como dependencia funcional parcial.

Bajo estas condiciones y recordando la definición de la segunda forma normal, tenemos dependencias parciales, lo que nos indica que Proyectos asignados no esta en la segunda forma normal, para poder eliminar las dependencias, tenemos que hacer lo siguiente:

1. Separar las dependencias en una nueva relación.
2. Eliminar las tuplas duplicadas.
3. Dejar en una relación el resto de atributos con su llave primaria.

• Entonces, primero separemos las dependencias parciales y crearemos una relación de nombre Proyecto.

• Ahora debemos asegurarnos que no existan tuplas duplicadas, que en este caso es eliminar el último registro.

• Dejemos el resto de atributos junto a la llave primaria

Con esta división hemos logrado que en las dos relaciones nuevas:

• Todos los atributos dependan únicamente de su llave primaria.
• Además, tienen un dominio común “No Proyecto”, con el cual podremos realizar la unión natural entre estas nuevas relaciones.

📌 Por lo tanto, las relaciones Proyecto y Proyectos asignados está en su segunda forma normal (2FN).

💡 Tercera forma normal (3FN)

En esta tercera forma normal tocamos el tema de la transitividad y es por ello que se conoce como la forma de la dependencia funcional transitiva y dice lo siguiente.

Una relación se encuentra en tercera forma normal, si, y sólo si, se encuentra en la segunda forma normal y no contiene atributos con dependencias transitivas.

¿Qué son los atributos primos y atributos no primos?

Quizá la definición de la tercera forma normal (3FN) parezca muy compleja, pero lo que al final quiere decir es que, todos los atributos que no forman parte de la llave primaria, deben depender únicamente de la llave primaria y no de otro atributo que no sea parte una llave.

Para que se comprenda mejor, definamos lo siguiente:

• Un atributo primo, es aquel atributo que forma parte de una llave.
• Y un atributo no primo, es aquel que no forma parte de ninguna llave.

📌 Entonces, en la tercera forma normal ningún atributo no primo puede depender funcionalmente de otro atributo no primo.

Dependencia funcional transitiva

Bien, supongamos lo siguiente:

α → β 

Y

β → γ

Por transitivadad podemos de cir que:

α → γ

Por lo tanto, en una dependencia funcional transitiva, existen atributos dependientes, que a su vez, dependen de otro conjunto de atributos que también es dependiente.

Ahora, ya que tenemos el concepto de transitividad, la tercera forma normal indica que ningún atributo no determinante debe depender transitivamente de la llave primaria.

Ejemplo 1: analizando la tercera forma normal a través del álgebra.

Primero hagamos un ejemplo ocupando el álgebra, verás que de esta forma se comprende mejor el tema de transitividad, y cuando veamos un ejemplo con tablas, te será más fácil comprenderlo.

Supongamos tenemos la siguiente relación R:

R(A, B, C, D)

Y un conjunto de dependencias F:

F(AB → C, C → D)

Gracias al conjunto de dependencias F, podemos deducir, que:

• La llave primaria es: A y B, y por lo tanto A y B son atributos primos.
• Y las dependencias son: C y D, por lo que C Y D son atributos no primos.
• Además, por transitividad: AB → D.

📌 Después de este deducción podemos indicar qué, C → D se contrapone con la tercera forma normal (3FN), ya que, el atributo no primo “D” depende de otro atributo no primo “C”, lo cual no está permitido en la 3FN.

Para corregir esta anomalía, debemos:

• Separar las dependencias funcionales que se contraponen con la 3FN creando una nueva relación R2.
• Por otra parte, en la relación original, eliminamos el atributo dependiente (R1).

Quedando de la siguiente manera:

R1(A, B, C) y R2(C, D)

Haciendo esto, deducimos que:

• En R1:
  • A y B son primos
  • C es no primo
• En R2
  • C es primo
  • D no es primo

Al realizar la división ningún atributo no primo, depende funcionalmente de otro atributo no primo, además, ambas relaciones se encuentran en segunda forma normal, por consiguiente: R1 y R2 se encuentran en la tercera forma normal (3FN).

Ejemplo 2: llevando una relación a la tercera forma normal.

En la siguiente relación “Equipos asignados”, podemos ver los equipos que se encuentran asignados a los clientes.

Nuestra relación Equipos asignados:

• Se encuentra en la primera forma normal, ya que
  • Cumple con lo establecido en el modelo relacional.
  • Cuenta con una llave primaria No Cliente.
  • No hay grupos repetitivos.
• Y también se encuentra en la segunda forma normal, ya que:
  • Ninguno de los atributos depende únicamente de una parte de la llave primaria.

Obteniendo dependencias funcionales

Para realizar el análisis, identifiquemos las dependencias funcionales:

No Cliente → Nombre, Apellido, IMEI

IMEI → Nombre equipo, Celular

Donde:

IMEI no es un atributo primo y, tanto Nombre equipo y Celular dependen de IMEI, sin embargo, Nombre equipo y Celular, tampoco son atributos primos. Esto se contrapone con la 3FN y debemos corregirlo separando las dependencias que se contraponen con 3FN y eliminando de la relación original los atributos dependientes, quedando de la siguiente manera:

📌 Ahora nuestras nuevas relaciones “Equipos asignados” y “Equipos”, no tienen atributos no primos dependientes de otros atributos no primos, por lo que, ambas tablas se encuentran en la tercera forma normal (3FN).

Por último, en muchos casos de la vida real, normalizar nuestra base de datos hasta este punto, es más que suficiente, ya que, hemos eliminado la mayoría de los casos de redundancia y anomalías que generan problemas, no obstante, existen otras formas normales que podemos aplicar  en ciertos casos ,y que, dependiendo de nuestra aplicación, quizá sea sea necesario el considerar aplicarlas.

Muy bien, cuando normalizamos por arriba de la tercera forma normal, se dice que es una Normalización superior, ya que, como te mencione anteriormente, con las tres formas normales en muchas ocasiones, es más que suficiente, sin embargo, existen algunos casos donde no podemos eliminar ciertas redundancias únicamente aplicando las tres primeras formas normales, y esos casos son los que veremos a continuación.

💡 Forma normal de Boyce y Codd (BCNF)

La forma normal de Boyce y Codd, nace en 1974 a manos de Raymond Boyce y Edgar Codd, quienes se dan cuenta que a pesar de aplicar las tres primeras formas normales, puede haber ciertas redundancias muy inusuales, sobre todo cuando existe más de una llave candidata y dichas llaves tienen atributos en común.

Una relación se encuentra en la forma normal de Boyce y Codd, siempre y cuando, se encuentre en la tercera forma normal y para cada una de las dependencias funcionales no triviales, el determinante es una super llave.

Super llave

Recordemos que una super llave es un atributo o conjunto de atributos que identifica en forma única a una relación, entonces:

• Para toda dependencia funcional α → β el cierre o cerradura de α es igual a la relación {α}+ = R

Ejemplo: calcular llaves candidatas mediante álgebra.

Supongamos que tenemos la siguiente relación R:

R(X, Y, Z)

Y su conjunto de dependencias F:

F(XY → Z, Z → Y)

Bien, analicemos:

• Dado el conjunto de dependencias, vemos que el atributo X no lo podemos obtener por ninguna forma, en otras palabras, “X” es un atributo primordial y debe formar parte de cualquier super llave.
• Ahora, calculemos la cerradura de las llaves candidatas, no me detendré en explicar a detalle el cálculo, para eso te invito a revisar la clase de álgebra relacional.

Dado que “X” es un atributo que debe estar en cualquier super llave, tenemos los siguientes casos:

{XY}+ = {XYZ}

{XZ}+ = {XZY}

El resultado de la cerradura para las posibles llaves “XY” y “XZ” contiene a todos los elementos de la relación R, por lo tanto, se demuestra que ambas son candidatas a ser una llave, y que tienen como atributo en común a “X”, ahora regresemos a analizar nuestras dependencias y veamos si los determinantes son una super llave:

• Para XY → Z, vemos que el determinante “XY” sí es una super llave, ya que su cierre contiene a todos los elementos de R y tiene al atributo X.
• Para Z → Y, vemos que “Z” no es una super llave, ya que no tiene como determinante a “X”, por lo tanto, Z → Y se contrapone a la forma normal de Boyce y Codd (BCNF).

Para llevar nuestra relación R a la forma normal de Boyce y Codd, haremos algo similar a lo que hemos hecho en los puntos anteriores:

1. Movemos a una nueva relación R1 la dependencia funcional que se contrapone a BCNF.
   • R1(Y, Z)
2. Y en la relación original eliminamos los atributos dependientes de la dependencia funcional que se contrapone a BCNF.
   • R2(X, Z)

Hecho lo anterior, podemos realizar una unión natural entre R1 y R2, para recuperar la relación original R, por lo tanto: R1 y R2 se encuentra en la forma normal de Boyce y Codd.

Ejemplo 2: llevar la siguiente relación a la forma normal de Boyce y Codd.

Apliquemos lo aprendido en el ejercicio 1, supongamos que tenemos la siguiente relación:

Analizando la relación, tenemos que:

• Varios estudiantes pueden tomar la misma materia.
• Y a la vez, más de un profesor puede dar la misma materia.

Con esto, podemos determinar el conjunto de dependencias funcionales:

• Para poder obtener a un profesor, necesitamos conocer al estudiante y la materia.
  • Estudiante, Materia → Profesor
• Y mediante un profesor, podemos conocer una materia.
  • Profesor → Materia

Como puedes observar, prácticamente es el mismo caso que el ejercicio anterior, por lo tanto, las llaves candidatas son:

• Estudiante, Materia
• Estudiante, Profesor

Pareciera que no hay ningún problema ¿Cierto? Pero, viendo la relación con datos:

• ¿Qué pasaría si un estudiante decide dejar una materia? Por ejemplo: Pedro deja la materia de lenguajes de programación, si esto llegará a pasar, eliminaríamos la tupla y no sabríamos que el Profesor 4 imparte la materia lenguajes de programación.
• Por otra parte, si llega un nuevo profesor y quiere dar una nueva materia, no podríamos agregar una nueva tupla a nuestra relación hasta que un estudiante se inscriba a esa materia con ese nuevo profesor.

Precisamente es este tipo de anomalías lo que trata de eliminar la forma normal de Boyce y Codd, y para ello:

• Nos centramos en la dependencia funcional Profesor → Materia y la movemos a una nueva relación:
  • R1 (Materia, Profesor)
• Y en la relación original, dejamos el determinante de esta dependencia funcional más el resto de atributos.
  • R2 (Estudiante, Profesor)

Quedando nuestras relaciones de la siguiente manera, recuerda eliminar las tuplas duplicadas:

Ahora nuestras nuevas relaciones R1 y R2, se encuentran en la forma normal de Boyce y Codd y eliminan las anomalías de inserción y eliminación de datos que vimos previamente y, a través de una unión natural, podemos obtener los datos de la relación original R.

💡 Cuarta forma normal (4FN)

Esta forma nace gracias a Margaret S. Wu, quien en un estudio, analizó las bases de datos de cerca de cuarenta empresas, donde nueve bases de datos, presentaban anomalías que dieron paso a esta 4FN.

La cuarta forma normal tiene como objetivo eliminar todas las dependencias multivaluadas de nuestras relaciones, por lo tanto:

Una relación está en cuarta forma normal, sí, y sólo si, se encuentra en la tercera forma normal o en la forma BCNF y cada dependencia multivaluada no trivial que exista, el determinante es una Super llave.

¿Qué es una dependencia multivaluada?

En esencia una dependencia multivaluada es una sentencia donde dos o mas atributos son independientes unos de otros.

Para que esto se entienda mejor debemos conocer como representarla y leerla, por ejemplo, podemos representarla a través de una línea con doble flecha:

A ↠ B

Y se lee como: A multidetermina a B

Generalmente, las dependencias funcionales son dependencias de generación de igualdad y las dependencias multivaluadas se denominan dependencias de generación de tuplas.

Entonces: A ↠ B quiere decir que si dos tuplas de una relación R coinciden en todos los atributos de A, por lo tanto, sus componentes en B se pueden intercambiar y las dos tuplas resultantes también están en R.

Ahora, también existen aquellas dependencias funcionales multivaluadas triviales, que nos dicen los siguiente:

Una dependencia multivaluada del tipo A ↠ B es trivial cuando B es parte de A.

Por lo tanto, si una relación contiene dependencias multivaluadas se contraponen a la cuarta forma normal y debemos eliminarla.

Ejemplo: llevar una relación a la cuarta forma normal.

Supongamos que tenemos una relación que indica la cobertura de envío de varias sucursales que venden celulares, donde, cada sucursal cubre ciertas zonas donde envía los tipos de celulares que tiene asignados.

La relación Envío de celulares:

• Cumple con lo establecido en el modelo relación.
• No tiene grupos repetitivos.
• No tiene dependencias parciales.
• No hay ninguna dependencia transitiva.
• Y el determinante es una super llave.

Nuestra relación Envío de celulares esta en la tercera forma normal y cumple con la forma normal BCNF.

No obstante, existe un redundancia muy sutil:

• Sucursal 3 aparece dos veces, ya que, debe cubrir tanto la Zona 1 y Zona 3.

Entonces, si a Sucursal 3 se le asigna un nuevo tipo de equipo a vender, tendríamos que agregar tantas tuplas que satisfagan las zonas que debe cubrir, que en este caso, tendríamos que agregar dos tuplas.

Este tipo de dependencias es lo que vimos anteriormente como una dependencia multivaluada y, se contrapone a la cuarta forma normal. 😫

Para eliminar esta anomalía, tenemos que hacer algo similar a los casos anteriores, dividir en relaciones más pequeñas separando las dependencias multivaluadas, que en este caso, Sucursal multidetermina a Tipo equipo, pero también multidetermina a Zona, quedando las relaciones de la siguiente forma.

• Ahora, eliminemos las tuplas repetidas:

Al hacer este movimiento en ambas relaciones, eliminamos la anomalía, y cumpliríamos con la cuarta forma normal y, podemos agregar mas zonas a una sucursal o podemos agregar más tipos de equipos a cualquier sucursal.

💡 Quinta forma normal (5FN)

Para finalizar con el tema de normalización, analicemos la quinta forma normal, también conocida como la Forma normal de la proyección - unión (PJ/NF).

Un relación esta en quinta forma normal, si, y sólo si, esta en cuarta forma normal y toda dependencia de unión natural no trivial, es implicada por una super llave.

Para comprender de manera sencilla la 5FN, primero tenemos que entender el concepto de: descomposición no aditiva.

Descomposición no aditiva

Si recordamos un poco lo que nos indica, el álgebra relacional determinamos que:

• En la unión natural: no siempre es posible reconstruir la relación original, ya que todo depende de las proyecciones que usamos al descomponer la relación original.
• Unión natural no aditiva (Lossless Join): es una unión natural que da como resultado la relación original. R₁ ⋈ R₂ = R

Por lo tanto, sí: R₁ ⋈ R₂ = R decimos que la descomposición de R en R1 y R2 ha sido una descomposición no aditiva. 

Y bajo este concepto podemos replantear la definición de la quinta forma normal en lo siguiente:

Una relación está en quinta forma normal (5FN) o en forma normal de la proyección unión (PJ/NF) sí, y sólo si, esta en la cuarta forma normal y, no puede ser descompuesta no aditivamente en relaciones más pequeñas.

Ya que hemos entendido la dependencia no aditiva veamos que es una dependencia de unión natura.

Dependencia de unión natural

Si tenemos R₁, R₂, R₃, … , R_N y estas son una descomposición de una relación R, entonces sí:

R₁ ⋈ R₂  ⋈ R₃  …  ⋈ R_n  = R

• Si la unión natural de todas las proyecciones da como resultado la relación original R, R satisface la dependencia de unión natural.
• Lo anterior indica que todas las dependencias individuales: α_n → β_n son no triviales, lo que indica que el cierre de α_n es diferente a la relación original {α_n}+ ≠ R
• Por lo tanto, sí: {α_n}+ ≠ R, R no esta en la quinta forma normal

Si una relación satisface la dependencia de unión natural, dicha relación no se encuentra en la quinta forma normal, ya que puede ser descompuesta no aditivamente en relaciones más pequeñas.

Espero no haberte confundido con tanta reformulación y definiciones, pero creo que de esta manera se comprende mejor la quinta forma normal, ahora pasemos hacer un ejercicio para que te quede más claro.

Ejemplo: ¿Cómo llevar una relación a su quinta forma normal?

Para saber si una relación se encuentra o no en la quinta forma normal, vamos validar si satisface o no la dependencia de unión natural.

Ejercicio 1: proveedores de equipos

Para validar si esta relación está en quinta forma normal, debemos crear n proyecciones, en este caso son solo 3:

Ahora hagamos la unión natural de las relaciones, recuerda que el orden con el que haces la unión natural no importa, debes llegar al mismo resultado:

Después de llevar a cabo la unión natural vemos que hemos vuelto a obtener la relación original, esto quiere decir que se ha cumplido:

R₁ ⋈ R₂  ⋈ R₃  …  ⋈ R_n  = R

Y por lo tanto, nuestra relación original no esta en la quinta forma normal ya que satisface la dependencia de unión natural, no obstante las proyecciones R₁, R₂ y R₃ si están en quinta forma normal.

Ejercicio 2: agencias de marketing

Hagamos lo mismo que en el ejercicio uno, obtengamos todas su proyecciones posibles y después hagamos su unión natural.

Hagamos la unión natural:

Después de llevar a cabo la unión natural vemos que no hemos podido recuperar la relación original, esto quiere decir que no se ha cumplido:

R₁ ⋈ R₂  ⋈ R₃  …  ⋈ R_n ≠ R

Incluso, si eliminaremos estas tuplas, seguiríamos teniendo un registro de más, que en la relación original.

Y por lo tanto, nuestra relación original está en la quinta forma normal, ya que no satisface la dependencia de unión natural y no es necesario realizar ningún tipo de división.

Excelente, hemos terminado, espero que hayas aprendido cómo normalizar una base de datos con cada una de las formas normales que hemos visto. Ahora ya sabes que en algunas ocasiones no es suficiente normalizar hasta la tercera forma normal, ya que hay anomalías que que siguen causando redundancias.

Si en algún momento te enfrentas a realizar una normalización superior, recuerda evaluar si realmente es necesario y si las reglas de negocio lo permiten, quizá debas considerar usar una base de datos desnormalizada para que tu base principal esté libre de redundancias.

En fin, espero haber podido ayudarte y que hayas aprendido algo nuevo, nos vemos en el siguiente post.