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

Hola viajero web, me da gusto que estés en EWebik, hoy tocaremos un nuevo tema para complementar nuestro curso gratuito de base de datos (DB), hoy estudiaremos la normalización de bases de datos y las 5 formas normales, analizaremos cada forma aplicando todo lo que hemos aprendido hasta este punto.

Sin más comencemos y en verdad espero que al finalizar este post te vayas complacido de haber dado clic en EWebik.

Juan Carlos García
by Juan Carlos García2-Sept-20227

Para iniciar, es importante que comprendas el termino 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 estas convencido de que es cada cosa, te invito a revisar los siguientes post donde profundizamos en cada tema.

Suscribirme

Gracias por tu calificación:

7

Categorías


  • EWebik
  • React JS
  • SQL
  • Base de datos
  • PHP - MySQL
  • Página Web
  • Servidores
  • Flexbox
  • NodeJS
  • WordPress
  • POO

🥇 Creación de páginas web

⚡️ Quiero mi página web 💪🏼

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(a1, a2, a3, … , an)

  • Y una relación es una función de un esquema relacional: r(R)
  • No obstante, es valido 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(a1, a2, a3, … , an)
    • R1(a1, a2, a3)
    • R2(a10, a20, a30)
    • R3(a100, a200, a300)

Ahora, no podemos nada mas 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 vallamos 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 esta 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) este 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:

Empleados

NombreApellidoPuestoProyectos
JoséPérezSupervisorAplicación móvil iOS, Página web, CMS
ÁngelaGarcíaSupervisorBase de datos, CMS

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.

Empleados

No EmpleadoNombreApellidoPuestoProyecto 1Proyecto 2Proyecto 3
1JoséPérezSupervisorAplicación móvil iOSPágina webCMS
2ÁngelaGarcíaSupervisorBase de datosCMS 

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 limite, ya que en este caso, un empleado no podría tener más de tres proyecto.
  • Por otra parte, si observas, Á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:

No EmpleadoNombreApellidoPuestoProyecto
1JoséPérezSupervisorAplicación móvil iOS
1JoséPérezSupervisorPágina web
1JoséPérezSupervisorCMS
2ÁngelaGarcíaSupervisorBase de datos
2ÁngelaGarcíaSupervisorCMS

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”.

Proyectos asignados

No EmpleadoProyecto
1Aplicación móvil iOS
1Página web
1CMS
2Base de datos
2CMS

 

Empleados

No EmpleadoNombreApellidoPuesto
1JoséPérezSupervisor
2ÁngelaGarcíaSupervisor

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:

Proyectos asignados

No EmpleadoProyecto
1Aplicación móvil iOS
1Página web
1CMS
2Base de datos
2CMS
  • 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.

 

Proyectos

No ProyectoProyecto
100Aplicación móvil iOS
101Página web
102CMS
103Base de datos

 

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.

Proyectos asignados

No EmpleadoNo ProyectoProyecto
1100Aplicación móvil iOS
1101Página web
1102CMS
2103Base de datos
2102CMS

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

Proyectos asignados

No EmpleadoNo Proyecto
1100
1101
1102
2103
2102

 

📌 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:

Ejemplo de como llevar una relación a la primera forma normal 1NF

 

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 primaría 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.

 

Suscribirme

Gracias por tu calificación:

7

Categorías


  • EWebik
  • React JS
  • SQL
  • Base de datos
  • PHP - MySQL
  • Página Web
  • Servidores
  • Flexbox
  • NodeJS
  • WordPress
  • POO

🥇 Creación de páginas web

⚡️ Quiero mi página web 💪🏼

💡 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 esta 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 primara 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 primaría, 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 ha realizar un ejemplo.

 

Ejemplo: ¿Cómo hacer que una relación este 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.

Proyectos asignados

No EmpleadoNo ProyectoProyectoCosto
1100Aplicación móvil iOS$10000
1101Página web$25000
1102CMS$50000
2103Base de datos$100000
2102CMS$50000

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.

Proyectos

No ProyectoProyecto
100Aplicación móvil iOS
101Página web
102CMS
103Base de datos
102CMS
  • Ahora debemos asegurarnos que no existan tuplas duplicadas, que en este caso es eliminar el último registro.

Proyectos

No ProyectoProyecto
100Aplicación móvil iOS
101Página web
102CMS
103Base de datos
  • Dejemos el resto de atributos junto a la llave primaria

Proyectos asignados

No EmpleadoNo ProyectoCosto
1100$10000
1101$25000
1102$50000
2103$100000
2102$50000

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 esta en su segunda forma normal (2FN).

 

 

 

 

 

 

 

Suscribirme

Gracias por tu calificación:

7

Categorías


  • EWebik
  • React JS
  • SQL
  • Base de datos
  • PHP - MySQL
  • Página Web
  • Servidores
  • Flexbox
  • NodeJS
  • WordPress
  • POO

🥇 Creación de páginas web

⚡️ Quiero mi página web 💪🏼

💡 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, sí, 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á mas 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 esta permitido en la 3FN.

Para corregir esta anomalia, 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.

Equipos asignados

No ClienteNombreApellidoIMEINombre equipoCelular
1JuanGonzález123456789Equipo 15500000000
2SandraPérez113456789Equipo 25500000001
3SantiagoValdés113356789Equipo 35500000002
4PedroGarcía113355789Equipo 45500000003
5RolandoGarcía113355779Equipo 55500000004

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:

 

Equipos asignados

No ClienteNombreApellidoIMEI
1JuanGonzález123456789
2SandraPérez113456789
3SantiagoValdés113356789
4PedroGarcía113355789
5RolandoGarcía113355779

 

Equipos

IMEINombre equipoCelular
123456789Equipo 15500000000
113456789Equipo 25500000001
113356789Equipo 35500000002
113355789Equipo 45500000003
113355779Equipo 55500000004

 

📌 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.

 

 

Suscribirme

Gracias por tu calificación:

7

Categorías


  • EWebik
  • React JS
  • SQL
  • Base de datos
  • PHP - MySQL
  • Página Web
  • Servidores
  • Flexbox
  • NodeJS
  • WordPress
  • POO

🥇 Creación de páginas web

⚡️ Quiero mi página web 💪🏼

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 ocaciones, 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 calculo, 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:

EstudianteMateriaProfesor
JuanAlgoritmosProfesor 1
JuanBase de datosProfesor 2
JuanLenguajes de programaciónProfesor 3
PedroBase de datosProfesor 2
PedroLenguajes de programaciónProfesor 4
LuisAlgoritmosProfesor 1
LuisLenguajes de programaciónProfesor 3

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:

MateriaProfesor
AlgoritmosProfesor 1
Base de datosProfesor 2
Lenguajes de programaciónProfesor 3
Lenguajes de programaciónProfesor 4

 

EstudianteProfesor
JuanProfesor 1
JuanProfesor 2
JuanProfesor 3
PedroProfesor 2
PedroProfesor 4
LuisProfesor 1
LuisProfesor 3

 

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.

 

Suscribirme

Gracias por tu calificación:

7

Categorías


  • EWebik
  • React JS
  • SQL
  • Base de datos
  • PHP - MySQL
  • Página Web
  • Servidores
  • Flexbox
  • NodeJS
  • WordPress
  • POO

🥇 Creación de páginas web

⚡️ Quiero mi página web 💪🏼

💡 Cuarta forma normal (4FN)

Esta forma nace gracias a Margaret S. Wu, quien en un estudio, analizo 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 tato:

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.

Envío de celulares

SucursalTipo equipoZona
Sucursal 1Celular 1Zona 1
Sucursal 1Celular 1Zona 2
Sucursal 1Celular 2Zona 1
Sucursal 1Celular 2Zona 2
Sucursal 2Celular 1Zona 1
Sucursal 2Celular 2Zona 1
Sucursal 3Celular 1Zona 1
Sucursal 3Celular 1Zona 3

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.

 

SucursalTipo equipo
Sucursal 1Celular 1
Sucursal 1Celular 1
Sucursal 1Celular 2
Sucursal 1Celular 2
Sucursal 2Celular 1
Sucursal 2Celular 2
Sucursal 3Celular 1
Sucursal 3Celular 1

 

SucursalZona
Sucursal 1Zona 1
Sucursal 1Zona 2
Sucursal 1Zona 1
Sucursal 1Zona 2
Sucursal 2Zona 1
Sucursal 2Zona 1
Sucursal 3Zona 1
Sucursal 3Zona 3
  • Ahora, eliminemos las tuplas repetidas:
SucursalTipo equipo
Sucursal 1Celular 1
Sucursal 1Celular 2
Sucursal 2Celular 1
Sucursal 2Celular 2
Sucursal 3Celular 1
SucursalZona
Sucursal 1Zona 1
Sucursal 1Zona 2
Sucursal 2Zona 1
Sucursal 3Zona 1
Sucursal 3Zona 3

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.

Suscribirme

Gracias por tu calificación:

7

Categorías


  • EWebik
  • React JS
  • SQL
  • Base de datos
  • PHP - MySQL
  • Página Web
  • Servidores
  • Flexbox
  • NodeJS
  • WordPress
  • POO

🥇 Creación de páginas web

⚡️ Quiero mi página web 💪🏼

💡 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. R1 ⋈ R2 = R

Por lo tanto, sí: R1 ⋈ R2 = 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 R1, R2, R3, … , RN y estas son una descomposición de una relación R, entonces sí:

R1 ⋈ R2  ⋈ R3  …  ⋈ Rn  = 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

 

ProveedorEquipoProyecto
P1E1Proyecto 1
P2E2Proyecto 2
P3E3Proyecto 3
P4E4Proyecto 1

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

 

ProveedorEquipo
P1E1
P2E2
P3E3
P4E4
ProveedorProyecto
P1Proyecto 1
P2Proyecto 2
P3Proyecto 3
P4Proyecto 1
EquipoProyecto
E1Proyecto 1
E2Proyecto 2
E3Proyecto 3
E4Proyecto 1

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:

ProveedorEquipoProyecto
P1E1Proyecto 1
P2E2Proyecto 2
P3E3Proyecto 3
P4E4Proyecto 1

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

R1 ⋈ R2  ⋈ R3  …  ⋈ Rn  = 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 R1, R2 y R3 si están en quinta forma normal.

 

 

Ejercicio 2: agencias de marketing

 

AgenciaEmpresaServicio
Agencia 1Empresa 1Servicio 1
Agencia 1Empresa 1Servicio 2
Agencia 1Empresa 2Servicio 3
Agencia 2Empresa 1Servicio 3

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

 

AgenciaEmpresa
Agencia 1Empresa 1
Agencia 1Empresa 2
Agencia 2Empresa 1

 

AgenciaServicio
Agencia 1Servicio 1
Agencia 1Servicio 2
Agencia 1Servicio 3
Agencia 2Servicio 3

 

EmpresaServicio
Empresa 1Servicio 1
Empresa 1Servicio 2
Empresa 1Servicio 3
Empresa 2Servicio 3

 

Hagamos la unión natural:

AgenciaEmpresaServicio
Agencia 1Empresa 1Servicio 1
Agencia 1Empresa 1Servicio 2
Agencia 1Empresa 1Servicio 3
Agencia 1Empresa 2Servicio 1
Agencia 1Empresa 2Servicio 2
Agencia 1Empresa 2Servicio 3
Agencia 2Empresa 1Servicio 3

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

R1 ⋈ R2  ⋈ R3  …  ⋈ Rn ≠ R

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

Y por lo tanto, nuestra relación original esta 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.

 

Suscribirme

Gracias por tu calificación:

7

Categorías


  • EWebik
  • React JS
  • SQL
  • Base de datos
  • PHP - MySQL
  • Página Web
  • Servidores
  • Flexbox
  • NodeJS
  • WordPress
  • POO

🥇 Creación de páginas web

⚡️ Quiero mi página web 💪🏼

Excelente, hemos terminado, espero que hayas aprendido como normalizar una base de datos con cada una de las formas normales que hemos visto. Ahora ya sabes que en algunas ocaciones 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 este libre de redundancias.

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

🧐 Autoevaluación: Normalización de base de datos

1 ¿Qué es la normalización de una base de datos y para qué sirve?

2 ¿Qué se busca en la primera forma normal 1FN?

3 ¿Cuáles son los tipos de normalización que existen?

Juan Carlos García

Juan Carlos García

Durante años he desarrollado plataformas dedicadas al rastreo satelital y varios sitios web que se encuentran en la primera página de Google, y hoy quiero compartir contigo lo que se en tecnologías como: Node JS, PHP, C# y Bases de datos.

Si quieres apoyarme sígueme en mis redes sociales y suscríbete a mi canal de YouTube.

Desarrollador de software

© 2022 EWebik

Diseño de páginas web y aplicaciones moviles.