 |
|
|
| |
| PRATIQUE ALGO/METHODES |
|
|
|
| Expliquez-moi... La normalisation d'une base de données |
| |
| Organiser sa base SQL sans risquer de créer des sources d'anomalies ou des problèmes logiques : le principe de la théorie de normalisation s'applique à tout projet dynamique souhaitant grandir.
(15/12/2006) |
  |
 |
Forum |
|
|
Réagissez
dans les forums
de JDN Développeurs
|
Pas forcément prise en compte lors de la mise en place d'un projet dynamique, la normalisation d'une base de données devient rapidement une nécessité une fois que le projet a pris de l'ampleur, et qu'il ne peut plus se suffire de deux ou trois tables seulement.
Il est courant dans de telles situations de scinder une table en plusieurs, de réorganiser les données et de tenter de reprendre en main la logique de stockage. Malheureusement, c'est lors de ces réorganisations que des problèmes peuvent se créer : requêtes SQL à rallonge, anomalies de mise à jour, redondances... En optimisant les tables, la normalisation tente de parer ces difficultés.
La normalisation correspond au processus d'organiser ses données afin de limiter les redondances, divisant une table en plusieurs, et en les reliant entre elles par des clefs primaires et étrangères. L'objectif est d'isoler les données afin que l'ajout, l'effacement ou la modification d'un champ puisse se faire sur une seule table, et se propager au reste de la base par le biais des relations. Pour ce faire, la normalisation introduit en tout 8 formes normales.
|
Les formes normales
|
|
Forme
|
Implication
|
|
1NF
First Normal Form
|
Chaque table doit avoir une clef primaire. Il faut éliminer les colonnes en doublon. Chaque ligne doit contenir une seule valeur.
|
|
2NF
Second Normal Form
|
Si une table dispose d'une clef, toutes les propriétés doivent en dépendre : les données que l'on retrouve dans plusieurs lignes doivent être sorties dans une table séparée.
|
|
3NF
Third Normal Form
|
Les données d'une table ne dépendent que de la clef, et pas d'une autre colonne de la table : toute colonne dépend non seulement de la clef, mais également d'une autre colonne qui doit être sortie dans sa propre table.
|
|
BCNF
Boyce-Cod Normal Form
|
Aucune propriété faisant partie de la clef d'une relation 3NF, ne doit dépendre d'une propriété ne faisant pas partie de la clef primaire. Il faut donc créer une nouvelle table dont la clef primaire sera la propriété dont provient la relation.
|
|
4NF
Fourth Normal Form
|
Il ne doit y avoir qu'une et une seule dépendance multivaluée élémentaire.
|
|
5NF
Fifth Normal Form
|
Toute dépendance de jointure est impliquée par des clefs candidates de la relation.
|
|
Domaine/key Normal Form
|
Il ne doit exister aucune contrainte sinon celles de domaine ou de clef.
|
|
6NF
Sixth Normail Form
|
La sixième forme, encore récente, demande à prendre en compte la dimension temporelle.
|
L'idée générale reste qu'il peut être raisonnable de décomposer une relation complexe en deux relations plus simples.
La normalisation d'une base doit se faire dans la mesure : si une forme élevée amène à des données bien organisées, elle peut aussi inutilement rendre complexe les requêtes nécessaires - et même être complexe à appliquer : plus la forme est élevée, plus elle est difficile à appliquer. À chacun d'y trouver son compte, donc.
|
|
|
|
|
|
|
