Organisation des données dans les tables

Avant de se lancer dans la programmation proprement dite, vous aurez besoin de créer les tables pour le stockage des données.
Une part importante du code découlant de la structure de ces tables, mieux vaut partir sur des bases saines, plutôt que d'être obligé en cours de route de changer la répartition des données, et être obligé de ré-écrire les requêtes et le code qui les exploite!
Ce guide vous explique comment répartir les données dans vos tables en suivant les rêgles de normalisation.
Vous trouverez peut-être sa lecture superflue , dommage car il s'agir de notions essentielles.

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 nouvelles

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 :

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 et le prénom, le champ ville, la ville et 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.

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 :

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, … Une solution simple (mais non rigoureusement conforme) consiste à  rajouter un champ unité.

3) Seconde forme normale

Le respect de la seconde forme normale 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

Cette table respecte la 1 êre forme normale, mais ne respecte pas la seconde.

Si nous fixons p.ex. la clef primaire NumSalarié + NumAtelier , le champ (non-clef) heures est bien en totale dépendance de la clef primaire, puisqu'à  partir de cette clef, nous pouvons isoler un compte d'heures unique pour le couple NumSalarié + NumAtelier.

Par contre nous ne pouvons pas le faire pour le champ (non-clef) Nom, qui ne dépend que d'un morceau de la clef primaire.

Vous n'avez pas tout compris ? Regardez comment 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 troisiême forme normale.

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-clef ».

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 et n° du chef).

De la même façon, si on crée le nouveau service dans l'entreprise, nous ne pourront 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.