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 :

Nom	Adresse	Ville
Albert Martin	12 avenue Jean Jaures	F-69003 Lyon
Benoît Solo	71 rue des martyrs	B-1070 Bruxelles

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 :

Nom	Prénom	Adresse	Code_postal	Ville
Martin	Albert	12 avenue Jean Jaures	F-69003	Lyon
Solo	Benoît	71 rue des martyrs	B-10708	Bruxelles

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

id_ user	dvd_1	dvd_2	dvd_3
205	Psychose	Mobby Dick
206	Men in black	Le grand bleu	Fahrenheit 451
207	Les choristes

Cette table n'est pas conforme puisqu'elle contient des champs répétitifs.

Il faudra donc la scinder en 2 tables :

Table 1 id_ dvd Titre Id_emprunteur 43 Psychose 205 44 Men in black 206 45 Les choristes 207

Table 2 id_ user nom prénom 205 Leroy Marc 206 Lascience Olivier 207 Lechat Claude

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

animal	date	quantité
Poule01	31/07/2004	2
Vache01	31/07/2004	25
Poule02	31/07/2004	3

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

NumSalarié	Nom	NumAtelier	Heures
20036	Durand	1	18,5
20036	Durand	2	6,7
36900	Leroux	2	8,5
45002	Frank	3	23,5
45002	Frank	1	4,8

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.

Table 1 NumSalarié Nom 20036 Durand 36900 Leroux 450002 Frank		Table 2 NumSalarié NumAtelier Heures 20036 1 18,5 20036 2 6,7 36900 2 8,5 45002 3 23,5 45002 1 4,8
Clef primaire : Numsalarié		Clef primaire : NumSalarié + Numatelier

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 :

Nom	NumSalarié	Date_naissance	Service	NomService	NumChef
Durand	5001	15/01/1948	5	Vente	4580
Martin	5002	12/04/1957	6	Informatique	4120

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.

Table 1 NumSalarié Nom Date_Naiss Service 5001 Durand 15/01/1948 5 5002 Martin 12/04/1957 6

Table 2 Service Nom NumSalarié_Chef 5 Vente 4580 6 Informatique 4120

<a href="http://creativecommons.org/licenses/by-nc-sa/2.0/fr/" title="Licence, certains droits réservés"><img src="http://www.frxoops.org/images/cdr_bouton.gif" alt="Licence, certains droits réservés" /></a>