Formes normales et normalisation
La conception d'une base de données n'a rien de bien compliqué en sois, mais nécessite un minimum de rigueur et de bon sens. Il est plus intéressant de "perdre" un peu de temps à bien penser à la structure de la DB avant de la créer, que de perdre énormément de temps (et parfois perdre des données) à maintenir une DB mal modélisée au départ.
La normalisation des modèles de bases de données relationnelles, popularisée par la méthode Merise, est un processus qui intervient généralement au cours de la phase de conception du modèle entités-associations, mais qui peut intervenir plus tard afin de vérifier la robustesse du modèle relationnel et le corriger si nécessaire. Il s'agit d'un processus réversible, et sans perte d'information.
Les formes normales (FN) désignent certains types de relations entre les entités qui permettent d'éviter la redondance au sein des bases de données relationnelles afin d'éviter ou tout au moins de limiter les effets suivants :
- pertes de données
- incohérences au sein des données
- effondrement des performances des traitements
1FN : Première forme normale
« Une relation est en première forme normale si tout attribut contient une valeur atomique.
Chaque entité doit posséder un identifiant (une clé1) qui la caractérise de manière unique. »Toute base de données devrait adhérer au moins à la première forme normale, mais nous pouvons souvent constater que ce n'est pas toujours le cas. Par exemple, dans le cas d'un champ "adresse" dans une table (NF2, ou Non First Normal Form), comment retrouver toutes les personnes qui logent dans une certaine rue ?
Nous devons absolument séparer l'adresse en différentes valeurs (rue, numéro, etc.) pour respecter la première forme normale. Ceci nous permettra de simplifier énormément le travail de recherche, et nous pouvons par la suite créer une table pour les rues (voir la 2è forme normale : éviter la redondance et faciliter la maintenance).
Nous pouvons utiliser une clé composée de la combinaison des attributs {pers_nom, pers_pers_pers_date_naissance, pers_pers_date_naissance}, et modifier la table t_personne(pers_nom, pers_prenom, pers_date_naissance, pers_adresse) en t_personne(pers_nom, pers_prenom, pers_date_naissance, rue, numero, code_postal, commune) pour satisfaire à la première forme normale.
En pratique le choix de l'identifiant1 devrait porter sur un champ qui ne possède aucune signification logique hors de la base de données.
Dans le cas de notre exemple, si la clé est composée de la combinaison {pers_nom, pers_prenom, pers_pers_date_naissance}, et que la personne change de nom, la cohérence des données n'est plus assurée car certaines données d'autres tables peuvent être liées à cette personne par {ancien-nom, pers_prenom, pers_pers_date_naissance}, et les liens ne sont plus possibles.
Donc, nous modifions la table t_personne(pers_nom, pers_prenom, pers_date_naissance , pers_adresse) en t_personne(pers_pk, pers_nom, pers_prenom, pers_date_naissance, rue, numero, code_postal, commune).
Un autre exemple que nous pouvons rencontrer :
t_personne(pers_nom, pers_prenoms, pers_date_naissance) => l'attribut pers_prenoms ne respecte pas la première forme normale car il est composé de plusieurs prénoms. Nous devons donc modifier la table en t_personne(pers_nom, pers_prenom1, pers_prenom2, pers_prenom3, pers_pers_date_naissance).
Remarque en dehors de la forme normale : en pratique dans un cas pareil, nous devrions passer par une table intermédiaire qui lierait la table t_personne à une table t_prénom pour permettre une cardinalité variable :
t_personne(pers_pk, pers_date_naissance)
t_prenom(pers_fk, prenom)
2FN : Deuxième forme normale
« Une relation est en deuxième forme normale si et seulement si :
- elle satisfait à la première forme normale
- tout attribut de l'entité n'appartenant pas à la clé ne dépend pas que d'une partie de la clé. »Prennons comme exemple une table t_cours(enseignant_id, enseignant_nom, enseignant_telephone, matiere_nom, matiere_syllabus_numero). La clé est composée des attributs {enseignant_id, matiere_nom}.
Cette table satisfait à la première forme normale (nous avons une clé unique, et chaque attribut est atomique), mais pas à la deuxième forme normale car les attributs enseignant_nom et enseignant_telephone ne dépendent que de enseignant_id, et matiere_syllabus_numero ne dépend que de matiere_nom.
Pour satisfaire à la 2è forme normale, nous devons décomposer la table de la manière suivante :
- t_cours(enseignant_fk, matiere_nom)
- t_enseignant(enseignant_pk, enseignant_nom, enseignant_telephone)
- t_matiere(matiere_nom, matiere_syllabus_numero)
Remarque en dehors de la 2è forme normale :en pratique, nous lierions la table t_enseignant à la table t_personne par l'identifiant de la personne1 :
- t_cours(enseignant_fk, matiere_fk)
- t_enseignant(enseignant_pk, pers_fk, enseignant_matricule) //nous retrouvons ici seulement les informations relatives à l'enseignant qui ne figurent pas dans la table t_personne.
- t_personne(pers_pk, pers_nom, pers_prenom, pers_telephone)
- t_matiere(matiere_pk, matiere_nom, matiere_syllabus_numero)
3FN : Troisième forme normale
« Une relation est en troisième forme normale si et seulement si :
- elle satisfait à la deuxième forme normale
- tout attribut de l'entité n'appartenant pas à une clé ne dépend pas d'un attribut non clé. »Dans notre premier exemple avec les personnes, le code postal dépend de la commune et non de la personne. Nous devons décomposer la table t_personne(pers_id, pers_nom, pers_prenom, rue, numero, code_postal, commune) de la manière suivante :
- t_personne(pers_pk, pers_nom, pers_prenom, rue_fk, numero, commune_fk)
- t_rue(rue_pk, rue_nom)
- t_commune(commune_pk, commune_code_postal, commune_nom)
Si nous devons modifier le nom de la rue, les modifications sont immédiatement répercutées pour toutes les personnes qui habitent dans cette rue, nous avons donc facilité la maintenance des données. De plus, nous évitons la redondance des données avec la 2è forme normale, car le nom de la rue était présent dans chaque entité personne.
Forme normale de Boyce-Codd
« Une relation est en forme normale de BOYCE-CODD (BCNF) si, et seulement si :
- elle est en troisième forme normale
- les seules dépendances fonctionnelles élémentaires sont celles dans lesquelles une clé détermine un attribut. »4FN : Quatrième forme normale
« Une relation est en quatrième forme normale si et seulement si :
- les seules dépendances multi-valuées élémentaires sont celles dans lesquelles une clé détermine un attribut. »5FN : Cinquième forme normale
« Une relation est en cinquième forme normale si et seulement si :
- toute dépendance de jointure est impliquée par les clés candidates de la relation. »
Version en cache
20/11/2024 15:54:39 Cette version de la page est en cache (à la date du 20/11/2024 15:54:39) afin d'accélérer le traitement. Vous pouvez activer le mode utilisateur dans le menu en haut pour afficher la dernère version de la page.Document créé le 18/03/2007, dernière modification le 26/10/2018
Source du document imprimé : https://www.gaudry.be/sgbdr-formes-normales.html
L'infobrol est un site personnel dont le contenu n'engage que moi. Le texte est mis à disposition sous licence CreativeCommons(BY-NC-SA). Plus d'info sur les conditions d'utilisation et sur l'auteur.
- ↑a,b,c pk, fk, et id : Les suffixes pk, fk, et id correspondent à la même donnée, mais permettent de mieux identifier leur origine, leur rôle, et éviter des conflits dans le cas de jointures:
- pk, pour "Primary Key" est l'identifiant unique utilisé dans la table d'origine.
- fk, pour "Foreign Key" est l'identifiant unique utilisé dans une autre table, pour référencer la clé de la table d'origine(pk).
