Introduction à la normalisation de la base de données Les trois premières formes normales

L'objectif d'une normalisation de la base de données relationnelle est d'atteindre et d'améliorer intégrité des données et éviter redondance des données Donc, pour éviter les anomalies d'insertion, de mise à jour ou de suppression possibles. Une base de données relationnelle est normalisée en appliquant une série de règles appelées formulaires normaux. Dans cet article, nous discuterons des trois premières formes normales.

Dans ce tutoriel, vous apprendrez:

• Quelle est la première forme normale
• Quelle est la deuxième forme normale
• Quelle est la troisième forme normale

Exigences et conventions logicielles utilisées

La première forme normale

Supposons que nous ayons le tableau suivant que nous utilisons pour stocker des informations sur certains films:

+----+--------------------+--------------------+------+ | ID | Nom | genre | Année | + ---- + -------------------- + -------------------- + - ---- + | 1 | L'exorciste | Horreur | 1973 | | 2 | Les suspects habituels | Thriller, néo-noir | 1995 | | 3 | Star Wars | Space-Opera | 1977 | +----+--------------------+--------------------+------+ 

Le tableau ci-dessus, ne satisfait pas le Première forme normale, pourquoi? Pour que la première forme normale soit satisfaite, chaque colonne d'une table doit contenir atomique (indivisible) Données. Dans la deuxième rangée de notre table, qui contient des informations sur le film «The Usual Suspects», nous pouvons voir que le genre la colonne contient des données qui ne sont pas atomiques. Deux genres sont réellement répertoriés: thriller et néo-noir. Disons que dans notre représentation, nous voulons permettre à un film d'être associé à plus d'un genre; Comment résolvons-nous le problème?

La première chose qui vous vient à l'esprit peut être d'ajouter une nouvelle ligne dans le même tableau, de répéter les informations sur le film et de spécifier simplement un genre par brut. Cette idée est assez horrible, car nous aurions beaucoup de données redondantes (nous devrions répéter les mêmes informations de film chaque fois que nous voulons l'associer à un nouveau genre!).

Une autre solution légèrement meilleure serait d'ajouter une nouvelle colonne, donc pour avoir, par exemple, un genre1 et genre2 Colonnes. Cependant, cela représenterait, entre autres choses, une limite: et si un film devait être répertorié dans plus de deux genres?

Une façon plus intelligente de résoudre ce problème est de créer un nouveau tableau utilisé pour stocker les informations de genre. Voici le tableau «genre»:

+----+-------------+ | ID | Nom | + ---- + ------------- + | 1 | Horreur | | 2 | Néo-noir | | 3 | Space-Opera | | 4 | Thriller | +----+-------------+ 

Maintenant, puisque celui entre le genre et le film est un plusieurs à plusieurs La relation (un film peut être liée à plusieurs genres, et un genre peut être lié à de nombreux films différents), pour l'exprimer sans redondance de données, nous pouvons utiliser un SO
appelé table de jonction:

+----------+----------+ | film_id | Genre_id | + ---------- + ---------- + | 1 | 1 | | 2 | 2 | | 2 | 4 | | 3 | 3 | +----------+----------+ 

Notre table de jonction a la seule tâche pour exprimer la relation plusieurs à plusieurs entre les deux tables ou entités film et genre. Il n'est composé que par deux colonnes: film_id et genre_id. Le film_id la colonne a un clé étrangère contrainte au identifiant colonne du film table, et le genre_id a une contrainte de clé étrangère à la identifiant colonne du genre tableau. Les deux colonnes ensemble sont utilisées comme un composite Clé primaire, donc la relation entre un film et un genre ne peut être exprimée qu'une seule fois. À ce stade, nous pouvons supprimer la colonne «Genre» du tableau «film»:

+----+--------------------+------+ | ID | Nom | Année | + ---- + -------------------- + ------ + | 1 | L'exorciste | 1973 | | 2 | Les suspects habituels | 1995 | | 3 | Star Wars | 1977 | +----+--------------------+------+ 

Le tableau est maintenant en première forme normale.

La deuxième forme normale

La première forme normale est une condition préalable pour la seconde: pour que la deuxième forme normale soit satisfaite, les données doivent déjà être Première forme normale Et il ne devrait pas y avoir dépendance partielle d'attributs secondaires d'un sous-ensemble de tout clé candidate.

Qu'est-ce qu'une dépendance partielle? Commençons par dire que dans une table, il pourrait y en avoir plus clé candidate. Une clé candidate est une colonne, ou un ensemble de colonnes qui ensemble peuvent être identifiées comme uniques dans un tableau: un seul des
clés candidates, sera choisie comme table clé primaire, qui identifie uniquement chaque ligne.

Les attributs qui font partie des clés candidats sont définis comme prime, tandis que tous les autres sont appelés secondaire. Pour qu'une relation soit en deuxième forme normale, il ne devrait pas y avoir d'attribut secondaire qui dépend d'un sous-ensemble
d'une clé candidate.

Voyons un exemple. Supposons que nous ayons un tableau que nous utilisons pour stocker des données sur les joueurs de football et leurs scores pour chaque Gameday pour une application de football fantastique, quelque chose comme ceci:

+-----------+------------+-----------+------------+---------+-------+ | Player_id | First_name | Last_name | Rôle | Gameday | Score | + ----------- + ------------ + ----------- + ------------ + --------- + ------- + | 111 | Cordaz | Alex | Gardien de but | 18 | 6.50 | | 117 | Donnarumma | Gianluigi | Gardien de but | 18 | 7.50 | | 124 | Handanovic | Samir | Gardien de but | 18 | 7.50 | +-----------+------------+-----------+------------+---------+-------+ 

Jetons un coup d'œil à cette table. Tout d'abord, nous pouvons voir qu'il satisfait la première forme normale, car les données de chaque colonne sont atomiques. Les données contenues dans le joueur_id la colonne pourrait être utilisée pour identifier uniquement un joueur, mais
peut-il être utilisé comme clé principale pour le tableau? La réponse est non, car une ligne pour chaque joueur existera pour chaque Gameday! Ici, nous pourrions utiliser un composite Clé primaire à la place, fabriqué par la combinaison du joueur_id et gameday colonnes, puisque une seule et une seule entrée peut exister pour ce joueur pour chaque Gameday.

Ce tableau satisfait-il la deuxième forme normale? La réponse est non, voyons pourquoi. Nous avons précédemment dit que chaque attribut qui ne faisait partie d'aucune clé candidate est appelé secondaire et pour que la table satisfait la deuxième normale
la forme ne doit pas dépendre d'un sous-ensemble de toute clé candidate, mais cela doit dépendre de la clé candidate dans son ensemble.

Prenons le rôle attribut, par exemple. Il s'agit d'un attribut secondaire, car il ne fait partie d'aucune clé candidate. On peut dire qu'il dépend fonctionnellement de joueur_id, Puisque si le joueur change, le rôle d'associé peut également changer; Cependant, il ne dépend pas de gameday, qui est l'autre composant de la clé primaire composite, car même si le Gameday change le rôle du joueur. On peut dire ça rôle dépend fonctionnellement d'un sous-ensemble de la clé primaire composite, donc la deuxième forme normale n'est pas satisfaite.

Pour résoudre le problème, nous pouvons créer une table séparée utilisée pour décrire exclusivement chaque joueur:

+-----------+------------+-----------+------------+ | Player_id | First_name | Last_name | Rôle | + ----------- + ------------ + ----------- + ------------ + | 111 | Cordaz | Alex | Gardien de but | | 117 | Donnarumma | Gianluigi | Gardien de but | | 124 | Handanovic | Samir | Gardien de but | +-----------+------------+-----------+------------+ 

Nous pouvons maintenant supprimer ces informations de la table de score et la faire regarder de cette façon:

+-----------+---------+-------+ | Player_id | Gameday | Score | + ----------- + --------- + ------- + | 111 | 18 | 6.50 | | 117 | 18 | 7.50 | | 124 | 18 | 7.50 | +-----------+---------+-------+ 

La deuxième forme normale est maintenant satisfaite.

La troisième forme normale

La deuxième forme normale est une pré-requise pour la troisième forme normale. Pour être en troisième forme normale, un tableau doit déjà être sous forme normale et ne doit pas contenir d'attributs qui sont à dépendre transitoire sur la table principale de la table. Qu'est-ce que ça veut dire? On peut dire que nous avons un dépendance transitive Lorsqu'un attribut secondaire ne dépend pas directement de la clé primaire du tableau, mais qu'il dépend d'un autre attribut secondaire. Supposons que nous ajoutions deux nouvelles colonnes au joueur Tableau ci-dessus, donc cela ressemble à ceci:

+-----------+------------+-----------+------------+---------+-----------+ | Player_id | First_name | Last_name | Rôle | Club | Club_City | + ----------- + ------------ + ----------- + ------------ + --------- + ----------- + | 111 | Cordaz | Alex | Gardien de but | Crotone | Crotone | | 117 | Donnarumma | Gianluigi | Gardien de but | Milan | Milano | | 124 | Handanovic | Samir | Gardien de but | Inter | Milano | +-----------+------------+-----------+------------+---------+-----------+ 

Nous avons ajouté le club et club_city colonnes à la table pour spécifier, respectivement, le club associé à un joueur et à la ville auquel le club appartient. Malheureusement, la table ne satisfait pas maintenant le troisième forme normale, pourquoi? C'est assez simple: le club_city L'attribut ne dépend pas directement de joueur_id, qui est la clé primaire du tableau, mais elle a une dépendance transitive à ce sujet, via un autre attribut secondaire: club.

Comment résoudre le problème afin que la troisième forme normale soit satisfaite? Tout ce que nous avons à faire est de créer une autre table, où enregistrer des informations sur chaque club. Voici la table «Club»:

+-----------+-----------+ | club_name | Club_City | + ----------- + ----------- + | Crotone | Crotone | | Milan | Milano | | Inter | Milano | +-----------+-----------+ 

Nous avons isolé les informations du club dans un tableau dédié. En tant que clé principale pour le tableau, dans ce cas, nous avons utilisé le club_name colonne. Dans le joueur table que nous pouvons maintenant supprimer club_city colonne, et ajoutez une contrainte de clé étrangère à la club colonne pour qu'il fait référence à la club_name colonne dans le club tableau:

+-----------+------------+-----------+------------+---------+ | Player_id | First_name | Last_name | Rôle | Club | + ----------- + ------------ + ----------- + ------------ + --------- + | 111 | Cordaz | Alex | Gardien de but | Crotone | | 117 | Donnarumma | Gianluigi | Gardien de but | Milan | | 124 | Handanovic | Samir | Gardien de but | Inter | +-----------+------------+-----------+------------+---------+ 

La troisième forme normale est maintenant satisfaite.

Conclusions

Dans ce tutoriel, nous avons parlé des trois premières formes normales d'une base de données relationnelle et de la façon dont ils sont utilisés pour réduire la redondance des données et éviter les anomalies d'insertion, de suppression et de mise à jour. Nous avons vu quelles sont les conditions préalables de chaque forme normale, quelques exemples de leurs violations et comment les réparer. Cependant, d'autres formes normales existent au-de.

Tutoriels Linux connexes:

• Choses à installer sur Ubuntu 20.04
• Une introduction à l'automatisation Linux, des outils et des techniques
• Masterring Bash Script Loops
• Choses à faire après l'installation d'Ubuntu 20.04 Focal Fossa Linux
• Mint 20: Mieux que Ubuntu et Microsoft Windows?
• Fichiers de configuration Linux: 30 premiers
• Configuration de ZFS sur Ubuntu 20.04
• Ubuntu 20.04 astuces et choses que vous ne savez peut-être pas
• Manipulation de Big Data pour le plaisir et le profit Partie 1
• Boucles imbriquées dans les scripts bash