Introducción a la normalización de la base de datos Las tres primeras formas normales

El objetivo de una normalización de la base de datos relacional es lograr y mejorar integridad de los datos y evitar redundancia de datos Entonces, para evitar posibles anomalías de inserción, actualización o eliminación. Una base de datos relacional se normaliza aplicando una serie de reglas llamadas formularios normales. En este artículo discutiremos las tres primeras formas normales.

En este tutorial aprenderás:

• ¿Cuál es la primera forma normal?
• ¿Cuál es la segunda forma normal?
• ¿Cuál es la tercera forma normal?

Requisitos y convenciones de software utilizados

La primera forma normal

Supongamos que tenemos la siguiente tabla que usamos para almacenar información sobre algunas películas:

+----+--------------------+--------------------+------+ | ID | nombre | género | año | +----+--------------------+--------------------+- ----+ | 1 | El exorcista | Horror | 1973 | | 2 | Los sospechosos habituales | Thriller, Neo-Noir | 1995 | | 3 | Star Wars | Space-Opera | 1977 | +----+--------------------+--------------------+------+ 

La tabla de arriba, no satisface el Primera forma normal, por qué? Para satisfacer la primera forma normal, cada columna de una tabla debe contener atómico datos (indivisibles). En la segunda fila de nuestra tabla, que contiene información sobre la película "los sospechosos habituales", podemos ver que el género La columna contiene datos que no son atómicos. En realidad se enumeran dos géneros: Thriller y Neo-Noir. Digamos que en nuestra representación queremos permitir que una película se asocie con más de un género; ¿Cómo resolvemos el problema??

Lo primero que viene a la mente puede ser agregar una nueva fila en la misma tabla, repetir la información sobre la película, y simplemente especificar un género por bruto. Esta idea es bastante horrible, ya que tendríamos muchos datos redundantes (deberíamos repetir la misma información de la película cada vez que queremos asociarla con un nuevo género!).

Otra solución ligeramente mejor, sería agregar una nueva columna, así que tener, por ejemplo, un género y género2 columnas. Sin embargo, esto, entre las otras cosas, representaría un límite: ¿Qué pasaría si una película se enumere en más de dos géneros??

Una forma más inteligente de resolver este problema es crear una nueva tabla utilizada para almacenar la información de los géneros. Aquí está la tabla "género":

+----+-------------+ | ID | nombre | +----+-------------+| 1 | Horror | | 2 | Neo-Noir | | 3 | Space-Opera | | 4 | Thriller | +----+-------------+ 

Ahora, ya que el que entre género y película es un muchos a muchos Relación (una película puede estar relacionada con varios géneros, y un género puede estar relacionado con muchas películas diferentes), para expresarla sin redundancia de datos, podemos usar un SO
llamado mesa de unión:

+----------+----------+ | película_id | género_id | +----------+----------+| 1 | 1 | | 2 | 2 | | 2 | 4 | | 3 | 3 | +----------+----------+ 

Nuestra mesa de unión tiene la única tarea de expresar la relación de muchos a muchos entre las dos tablas o entidades películas y género. Está compuesto solo por dos columnas: Movie_id y Genre_id. El película_id La columna tiene un clave externa restricción al identificación columna del película mesa y el género_id tiene una restricción de clave extranjera para el identificación columna del género mesa. Las dos columnas juntas se usan como un compuesto Clave principal, por lo que la relación entre una película y un género se puede expresar solo una vez. En este punto, podemos eliminar la columna "Género" de la tabla "Película":

+----+--------------------+------+ | ID | nombre | año | +----+--------------------+------+| 1 | El exorcista | 1973 | | 2 | Los sospechosos habituales | 1995 | | 3 | Star Wars | 1977 | +----+--------------------+------+ 

La tabla ahora está en primera forma normal.

La segunda forma normal

La primera forma normal es un requisito previo para el segundo: para que la segunda forma normal sea satisfecha, los datos ya deben estar en Primera forma normal y no debería haber ninguno dependencia parcial de atributos secundarios de un subconjunto de cualquier llave candidata.

¿Qué es una dependencia parcial?? Comencemos diciendo que en una mesa podría haber más de uno llave candidata. Una clave candidata es una columna, o un conjunto de columnas que juntas pueden identificarse como únicas en una tabla: solo una de las
claves candidatas, que se eligirán como la tabla Clave primaria, que identifica de manera única cada fila.

Los atributos que forman parte de las claves candidatas se definen como principal, mientras que todos los demás se llaman secundario. Para que una relación esté en la segunda forma normal, no debe haber ningún atributo secundario que dependa de un subconjunto
de una llave de candidato.

Veamos un ejemplo. Supongamos que tenemos una tabla que usamos para almacenar datos sobre jugadores de fútbol y sus puntajes para cada juego para una aplicación de fútbol de fantasía, algo como esto:

+-----------+------------+-----------+------------+---------+-------+ | Player_id | First_Name | Last_Name | papel | juego de juego | puntaje | +-----------+------------+-----------+------------ +---------+-------+| 111 | Cordaz | Alex | Portero | 18 | 6.50 | | 117 | Donnarumma | Gianluigi | Portero | 18 | 7.50 | | 124 | Handanovic | Samir | Portero | 18 | 7.50 | +-----------+------------+-----------+------------+---------+-------+ 

Echemos un vistazo a esta mesa. En primer lugar, podemos ver que satisface la primera forma normal, ya que los datos en cada columna son atómicos. Los datos contenidos en el jugador_id La columna podría usarse para identificar de manera única a un jugador, pero
¿Se puede usar como clave principal para la tabla?? La respuesta es no, porque existirá una fila para cada jugador para cada juego! Aquí podríamos usar un compuesto Clave principal en su lugar, hecha por la combinación de la jugador_id y día de juego columnas, ya que una sola entrada puede existir para ese jugador para cada jugador.

¿Esta tabla satisface la segunda forma normal?? La respuesta es no, veamos por qué. Anteriormente dijimos que se llama a cada atributo que no es parte de las claves candidato secundario y para la mesa para satisfacer la segunda normalidad
formar no debe depender de un subconjunto de cualquier clave candidata, pero debe depender de la clave del candidato en su conjunto.

Tomemos el role atributo, por ejemplo. Es un atributo secundario, ya que no es parte de ninguna clave de candidato. Podemos decir que depende funcionalmente de jugador_id, Dado que si el jugador cambia, también el papel asociado puede cambiar potencialmente; Sin embargo, no depende de día de juego, cuál es el otro componente de la clave primaria compuesta, ya que incluso si el día de un día cambia el papel del jugador sigue siendo el mismo. Podemos decir eso role depende funcionalmente de un subconjunto de la clave primaria compuesta, por lo tanto, la segunda forma normal no está satisfecha.

Para resolver el problema, podemos crear una tabla separada utilizada para describir exclusivamente a cada jugador:

+-----------+------------+-----------+------------+ | Player_id | First_Name | Last_Name | papel | +-----------+------------+-----------+------------ + | 111 | Cordaz | Alex | Portero | | 117 | Donnarumma | Gianluigi | Portero | | 124 | Handanovic | Samir | Portero | +-----------+------------+-----------+------------+ 

Ahora podemos eliminar esa información de la tabla de puntuación y hacer que se vea de esta manera:

+-----------+---------+-------+ | Player_id | juego de juego | puntaje | +-----------+---------+-------+| 111 | 18 | 6.50 | | 117 | 18 | 7.50 | | 124 | 18 | 7.50 | +-----------+---------+-------+ 

La segunda forma normal ahora está satisfecha.

La tercera forma normal

La segunda forma normal es un requisito previo para la tercera forma normal. Para estar en tercera forma normal, una tabla ya debe estar en segunda forma normal, y no debe contener atributos que son dependiente de transferencia en la tabla Clave principal. Qué significa? Podemos decir que tenemos un dependencia transitiva Cuando un atributo secundario no depende directamente de la clave primaria de la tabla, pero tiene una dependencia de otro atributo secundario. Supongamos que agregamos dos nuevas columnas al jugador tabla arriba, por lo que se ve así:

+-----------+------------+-----------+------------+---------+-----------+ | Player_id | First_Name | Last_Name | papel | club | club_city | +-----------+------------+-----------+------------ +---------+-----------+| 111 | Cordaz | Alex | Portero | Crotone | Crotone | | 117 | Donnarumma | Gianluigi | Portero | Milán | Milano | | 124 | Handanovic | Samir | Portero | Inter | Milano | +-----------+------------+-----------+------------+---------+-----------+ 

Agregamos el club y club_city columnas a la tabla para especificar, respectivamente, el club asociado con un jugador, y la ciudad a la que pertenece el club. Lamentablemente, la mesa ahora no satisface el Tercera forma normal, por qué? Es bastante simple: el club_city El atributo no depende directamente de jugador_id, Cuál es la clave principal de la tabla, pero tiene una dependencia transitiva de ella, a través de otro atributo secundario: club.

Cómo resolver el problema para que la tercera forma normal esté satisfecha? Todo lo que tenemos que hacer es crear otra tabla, dónde registrar información sobre cada club. Aquí está la mesa "Club":

+-----------+-----------+ | club_name | club_city | +-----------+-----------+| Crotone | Crotone | | Milán | Milano | | Inter | Milano | +-----------+-----------+ 

Aislamos información del club en una mesa dedicada. Como clave principal para la tabla, en este caso, utilizamos el nombre del club columna. En el jugador Tabla que ahora podemos eliminar club_city columna, y agregue una restricción de clave extranjera al club columna para que haga referencia al nombre del club columna en el club mesa:

+-----------+------------+-----------+------------+---------+ | Player_id | First_Name | Last_Name | papel | club | +-----------+------------+-----------+------------ + ---------+ | 111 | Cordaz | Alex | Portero | Crotone | | 117 | Donnarumma | Gianluigi | Portero | Milán | | 124 | Handanovic | Samir | Portero | Inter | +-----------+------------+-----------+------------+---------+ 

La tercera forma normal ahora está satisfecha.

Conclusiones

En este tutorial, hablamos sobre las tres primeras formas normales de una base de datos relacional y cómo se utilizan para reducir la redundancia de datos y evitar la inserción, eliminación y anomalías de actualización. Vimos cuáles son los requisitos previos de cada forma normal, algunos ejemplos de sus violaciones y cómo solucionarlos. Sin embargo, existen otras formas normales más allá de la tercera, en las aplicaciones más comunes, alcanzar la tercera forma normal es suficiente para lograr una configuración óptima.

Tutoriales de Linux relacionados:

• Cosas para instalar en Ubuntu 20.04
• Una introducción a la automatización, herramientas y técnicas de Linux
• Mastering Bash Script Loops
• Cosas que hacer después de instalar Ubuntu 20.04 fossa focal Linux
• Mint 20: Mejor que Ubuntu y Microsoft Windows?
• Archivos de configuración de Linux: los 30 principales más importantes
• Configuración de ZFS en Ubuntu 20.04
• Ubuntu 20.04 trucos y cosas que quizás no sepas
• Manipulación de Big Data para la diversión y las ganancias Parte 1
• Bucles anidados en guiones Bash