Formes normales et normalisation

Sommaire du document

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é) 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 nom, prénom, date-naissance, et modifier la table personne(nom, prenom, date_naissance, adresse) en personne(nom, prenom, date_naissance, rue, numero, code_postal, commune) pour satisfaire à la première forme normale.

En pratique le choix de l'identifiant (id) 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 nom, prénom, 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, prénom, date-naissance, et les liens ne sont plus possibles.

Donc, nous modifions la table personne(nom, prenom, date_naissance , adresse) en personne(id_personne, nom, prenom, date_naissance, rue, numero, code_postal, commune).

Un autre exemple que nous pouvons rencontrer :
personne(nom, prenoms, date_naissance) => l'attribut prénoms ne respecte pas la première forme normale car il est composé de plusieurs prénoms. Nous devons donc modifier la table en personne(nom, prenom1, prenom2, prenom3, 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 personne à une table prénoms pour permettre une cardinalité variable :
personne(id_personne, date_naissance)
prénom_personne(id_personne, 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 cours(id_enseignant, nom_enseignant, telephone_enseignant, nom_matiere, numero_syllabus). La clé est composée des attributs id_enseignant et nom_matiere.

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 nom_enseignant et telephone_enseignant ne dépendent que de id_enseignant, et numero_syllabus ne dépend que de nom_matiere.

Pour satisfaire à la 2è forme normale, nous devons décomposer la table de la manière suivante :

  • cours(id_enseignant, nom_matiere)
  • enseignant(id_enseignant, nom_enseignant, telephone_enseignant)
  • matière(nom_matiere, numero_syllabus)

Remarque en dehors de la 2è forme normale : en pratique, nous lierions la table enseignant à la table personne :

  • cours(id_enseignant, nom_matiere)
  • enseignant(id_enseignant, id_personne, matricule_enseignant) nous retrouvons ici seulement les informations relatives à l'enseignant qui ne figurent pas dans la table personne.
  • personne(id_personne, nom, prenom, telephone)
  • matière(nom_matiere, numero_syllabus)

 

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 personne(id, nom, prenom, rue, numero, code_postal, commune) de la manière suivante :

  • personne(id_personne, nom, prenom, id_rue, numero, id_commune)
  • rue(id_rue, nom)
  • commune(id_commune, code_postal, 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. »

 

Réseaux sociaux

Vous pouvez modifier vos préférences dans votre profil pour ne plus afficher les interactions avec les réseaux sociaux sur ces pages.

 

Nuage de mots clés

7 mots clés dont 0 définis manuellement (plus d'information...).

Avertissement

Cette page ne possède pas encore de mots clés manuels, ceci est donc un exemple automatique (les niveaux de pertinence sont fictifs, mais les liens sont valables). Pour tester le nuage avec une page qui contient des mots définis manuellement, vous pouvez cliquer ici.

Vous pouvez modifier vos préférences dans votre profil pour ne plus afficher le nuage de mots clés.

 

Astuce pour imprimer les couleurs des cellules de tableaux : http://www.gaudry.be/ast-rf-450.html
Aucun commentaire pour cette page

© Ce document issu de l′infobrol est enregistré sous le certificat Cyber PrInterDeposit Digital Numbertection. Enregistrement IDDN n° 5329-11341
Document créé le 18/03/07 03:00, dernière modification le Vendredi 17 Juin 2011, 12:12
Source du document imprimé : http:///www.gaudry.be/sgbdr-formes-normales.html
St.Gaudry©07.01.02
Outils (masquer)
||
Recherche (afficher)
Recherche :

Utilisateur (masquer)
Apparence (afficher)
Stats (afficher)
15838 documents
455 astuces.
550 niouzes.
3107 definitions.
447 membres.
8121 messages.

Document genere en :
0,08 seconde

Mises à jour :
Mises à jour du site
Citation (masquer)
Il y a bien des manières de ne pas réussir, mais la plus sûre est de ne jamais prendre de risques.

Benjamin Franklin
 
l'infobrol
Nous sommes le Mercredi 24 Mai 2017, 00:22, toutes les heures sont au format GMT+1.00 Heure, heure d'été (+1)