QUELLE EST LA TROISIÈME FORME NORMALE? (BASE DE DONNÉES) - LA TECHNOLOGIE - 2025

La troisième forme normale (bases de données) est une technique de conception de base de données relationnelle, où les différentes tables qui la composent sont non seulement conformes à la deuxième forme normale, mais tous ses attributs ou champs dépendent directement de la clé primaire.

Lors de la conception d'une base de données, l'objectif principal est de créer une représentation précise des données, des relations entre elles et des restrictions sur les données pertinentes.

Source: pixabay.com

Pour atteindre cet objectif, certaines techniques de conception de bases de données peuvent être utilisées, parmi lesquelles la normalisation.

Il s'agit d'un processus d'organisation des données dans une base de données pour éviter les redondances et les éventuelles anomalies dans l'insertion, la mise à jour ou l'élimination des données, générant ainsi une conception simple et stable du modèle conceptuel.

Il commence par examiner la relation fonctionnelle ou la dépendance entre les attributs. Ceux-ci décrivent certaines propriétés des données ou la relation entre elles.

Formes normales

La normalisation utilise une série de tests, appelés formes normales, pour aider à identifier le regroupement optimal de ces attributs et finalement établir l'ensemble approprié de relations qui prennent en charge les besoins en données d'une entreprise.

Autrement dit, la technique de normalisation est construite autour du concept de forme normale, qui définit un système de contraintes. Si une relation répond aux contraintes d'une forme normale particulière, la relation est dite sous cette forme normale.

Première forme normale (1FN)

Une table est dite en 1FN si tous les attributs ou champs qu'elle contient ne contiennent que des valeurs uniques. Autrement dit, chaque valeur de chaque attribut doit être indivisible.

Par définition, une base de données relationnelle sera toujours normalisée à la première forme normale, car les valeurs d'attribut sont toujours atomiques. Toutes les relations dans une base de données sont dans 1FN.

Cependant, le simple fait de quitter la base de données comme cela entraîne un certain nombre de problèmes, tels que la redondance et d'éventuelles échecs de mise à niveau. Des formes normales supérieures ont été développées pour corriger ces problèmes.

Deuxième forme normale (2FN)

Il traite de la suppression des dépendances circulaires d'une table. Une relation est dite en 2FN si elle est en 1FN et en outre chaque champ ou attribut non clé dépend entièrement de la clé primaire, ou plus précisément, il garantit que la table a un seul but.

Un attribut non clé est tout attribut qui ne fait pas partie de la clé primaire d'une relation.

Troisième forme normale (3FN)

Il traite de l'élimination des dépendances transitives d'une table. Autrement dit, supprimez les attributs non clés qui ne dépendent pas de la clé primaire, mais d'un autre attribut.

Une dépendance transitive est un type de dépendance fonctionnelle dans lequel la valeur d'un champ ou d'un attribut non clé est déterminée par la valeur d'un autre champ qui n'est pas non plus clé.

Vous devez rechercher des valeurs répétitives dans les attributs non clés pour vous assurer que ces attributs non clés ne dépendent de rien d'autre que la clé primaire.

Les attributs sont dits indépendants les uns des autres si aucun d'eux ne dépend fonctionnellement d'une combinaison d'autres. Cette indépendance mutuelle garantit que les attributs peuvent être mis à jour individuellement, sans risque d'affecter un autre attribut.

Par conséquent, pour qu'une relation dans une base de données soit sous la troisième forme normale, elle doit être conforme:

- Toutes les exigences de 2FN.

- S'il existe des attributs qui ne sont pas liés à la clé primaire, ils doivent être supprimés et placés dans une table séparée, reliant les deux tables au moyen d'une clé étrangère. Autrement dit, il ne devrait y avoir aucune dépendance transitive.

Exemples de troisième forme normale

Exemple 1

Soit la table STUDENT, dont la clé primaire est l'identification de l'étudiant (STUDENT_ID) et est composée des attributs suivants: STUDENT_NAME, STREET, CITY et POST_CODE, remplissant les conditions pour être 2FN.

Dans ce cas, STREET et CITY n'ont pas de relation directe avec la clé primaire STUDENT_ID, puisqu'elles ne sont pas directement liées à l'étudiant, mais dépendent totalement du code postal.

Comme l'élève est localisé par le site déterminé par CODE_POSTAL, STREET et CITY sont liés à cet attribut. En raison de ce second degré de dépendance, il n'est pas nécessaire de stocker ces attributs dans la table STUDENT.

Créer une nouvelle table

Supposons qu'il y ait plusieurs étudiants situés dans le même code postal, avec la table STUDENT ayant une immense quantité d'enregistrements, et qu'il soit nécessaire de changer le nom de la rue ou de la ville, alors cette rue ou ville doit être recherchée et mise à jour dans le tableau entier ÉTUDIANT.

Par exemple, si vous devez changer la rue «El Limón» en «El Limón II», vous devrez rechercher «El Limón» dans tout le tableau ÉTUDIANT puis le mettre à jour en «El Limón II».

La recherche dans une table énorme et la mise à jour d'un ou de plusieurs enregistrements prendront beaucoup de temps et affecteront donc les performances de la base de données.

Au lieu de cela, ces détails peuvent être conservés dans une table distincte (POSTCARD) qui est liée à la table STUDENT à l'aide de l'attribut POST_CODE.

La table POST aura comparativement moins d'enregistrements et cette table POST n'aura besoin d'être mise à jour qu'une seule fois. Cela sera automatiquement reflété dans la table STUDENT, simplifiant la base de données et les requêtes. Les tables seront donc en 3FN:

Exemple 2

Laissez le tableau suivant être utilisé avec le champ Project_Num comme clé primaire et avec des valeurs répétées dans les attributs qui ne sont pas des clés.

La valeur Téléphone est répétée chaque fois que le nom d'un responsable est répété. En effet, le numéro de téléphone n'a qu'une dépendance de second degré sur le numéro de projet. Cela dépend vraiment du gestionnaire d'abord, et cela dépend à son tour du numéro de projet, ce qui crée une dépendance transitive.

L'attribut Project_Manager ne peut pas être une clé possible dans la table Projets car le même responsable gère plusieurs projets. La solution pour cela est de supprimer l'attribut avec les données répétées (téléphone), en créant une table séparée.

Les attributs correspondants doivent être regroupés, créant une nouvelle table pour les enregistrer. Les données sont saisies et il est vérifié que les valeurs répétées ne font pas partie de la clé primaire. La clé primaire est définie pour chaque table et, si nécessaire, des clés étrangères sont ajoutées.

Pour se conformer à la troisième forme normale, une nouvelle table (Managers) est créée pour résoudre le problème. Les deux tables sont liées via le champ Project_Manager:

Références

1. Teradata (2019). Première, deuxième et troisième formes normales. Tiré de: docs.teradata.com.
2. Tutorial Cup (2019). Troisième forme normale (3NF). Tiré de: tutorialcup.com.
3. Base de données Dev (2015). Troisième forme normale (3NF) - Normalisation de votre base de données. Tiré de: databasedev.co.uk.
4. Conception de bases de données relationnelles (2019). Introduction à la troisième forme normale. Tiré de: relationneldbdesign.com.
5. Les nuls (2019). Formulaires SQL premier, deuxième et troisième normal. Tiré de: dummies.com.