Meldwin's Blog

1 ) Normalisation des tables

Normaliser ses tables consiste à construire celles-ci selon des règles permettant notamment :

• D'éviter toute duplication d'information,
• D'accéder aux données de manière unique et rationnelle.

Cette normalisation est importante car elle apporte :

• Des requêtes plus simples à écrire,
• Des données plus facilement accessibles,
• Une meilleure intégrité des données,
• La diminution des erreurs lors de l'insertion ou de la suppression de nouvelle données.

Il s'agit de règles de bon sens, que l'on applique peut-être sans le savoir, mais leur formalisation permet de vérifier que vos tables respectent ces règles.

Il existe 5 formes normales, mais nous ne traiterons que les 3 premières qui sont les plus importantes.

2 ) Première Forme Normale

Cette règle stipule 3 points :

Premièrement : Les champs de chaque table doivent être "atomiques", c'est-à-dire qu'on ne peut pas les décomposer.

Exemple d'une table non conforme d'un carnet d'adresse :

L'exemple ci-dessus n'est pas conforme puisque le champ `nom' contient à la fois le nom & le prénom, le champ `ville', la ville & le code postal.

Pour normaliser cette table, il suffira de scinder certains champs :

Maintenant que tous les champs sont atomiques, les tris et les recherches seront plus simples et plus directs.

Deuxièmement : Il ne peut exister de champs répétitifs.

Exemple d'une table non conforme d'une gestion de DVD :

Cette table n'est pas conforme puisqu'elle contient des champs répétitifs. Il faudra donc la scinder en 2 tables :

Troisièmement : Chaque champ doit avoir une signification précise et constante dans le temps.

Exemple d'une table non conforme de gestion de la production d'une ferme :

Cette table n'est pas conforme puisque le champ `quantité' peut représenter des litres de lait ou des nombres d'oeufs. Pour être conforme à la norme, il faudrait avoir une table pour les poules, une table pour les vaches, mais cette normalisation a ses limites, car si cette ferme produit également des quintaux de blé, des tonnes de fourrage, etc.

Une solution simple mais non rigoureusement conforme consiste à rajouter un champ `unité'.

3 ) Seconde Forme Normale

Le respect de la 2FN est également important, même si sa définition peut paraître un peu obscure :

Toutes les propriétés non-clé doivent être totalement dépendantes de la totalité de la clé primaire.

Exemple d'une table non conforme gérant les heures des ouvriers d'un atelier :

Ici, nous pouvons constater que chaque champ ne peut pas être divisé, autrement dit ils sont tous `atomiques'. Ensuite, il n'y a ici aucun champ répétitif. Et pour finir, chaque champ a bel et bien une définition constante dans le temps.

On peut ainsi en conclure que notre table respecte bien la première forme normale. Mais ! Car il y a un `Mais', la définition de la deuxième forme normale n'est pas respectée dans l'exemple. Explications : Si nous fixons par exemple la clef primaire ( numero_salarie + numero_atelier ), le champ ( non clé ) `heures' est bien en totale dépendance de la clé primaire, puisqu'à partir de cette clé, nous pouvons isoler un compte d'heures unique pour le couple ( numero_salarie + numero_atelier ). Autrement dit : Un numéro de salarié et un numero d'atelier nous donne un & un seul compte d'heure. ( numero_salarie + numero_atelier ) => heure

Par contre, nous ne pouvons pas le faire pour le champ ( non clé ) `nom', qui ne dépend que d'un morceau de la clé primaire, à savoir le numéro de l'employé. Si nous nous penchons sur le champ `nom', on voit qu'il ne dépend que du champ `numero_salarie' qui n'est pas le seul attribut de la clé primaire, ainsi la deuxième forme normale n'est pas respectée.

Vous n'avez pas tout compris ?

Regardez ci-dessous comment cette table a été scindée pour être normalisée.

Deux avantages :

 * On évite ainsi la duplication de renseignements ( le nom du salarié n'apparaît plus qu'une seule fois )
 * On peut détruire des enregistrements d'heures sans conséquence sur les informations relatives au salarié.

4 ) Troisième Forme Normale

Aucun champ non-clé ne doit être en dépendance transitive avec la clé primaire.

Autrement dit, si la valeur d'un champ " non-clé " peut être déduite de la valeur d'un autre champ " non-clé " alors sa relation à la clé primaire est transitive ( puisqu'elle transite par un autre champ ) et la table n'est pas dans la 3FN.

Exemple d'une table non conforme gérant les employés d'une entreprise :

Dans cet exemple, il est possible de déterminer le nom du service et le code salarié de son chef uniquement à partir du code service qui est un champ " non-clé ".

Quels sont les risques ?

Si nous supprimons tous les employés d'un service donné, lors de la suppression du dernier enregistrement nous perdrons également les informations concernant le service lui-même ( nom du service & numéro du chef ). De la même façon, si on crée le nouveau service dans l'entreprise, nous ne pourrons pas l'ajouter tant qu'il n'y aura pas un salarié affecté à ce service.

La solution passe par un découpage de la table en deux autres tables répondant chacune aux 3 premières formes normales.

Note : Il est important de garder en tête que pour qu'une forme normale soit vérifiée, la forme normale précédente doit d'abord être vraie. C'est à dire que pour que la 3FN soit vraie, la 2FN doit être vraie mais aussi la 1FN. Si la 1FN n'est pas vérifiée, n'allez pas chercher plus loin