[Article] Organisation des données dans les tables

[Plume]

Bonjour à tous ^^

Z'avez vu ? C'mon premier tutoriel !!

Ca vaut au moins ça :bois:

Introduction

Avant de se lancer dans la programmation proprement dite, vous aurez besoin de créer les tables pour le stockage de 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 & être obligé de ré-écrire les requêtes & le code qui les exploite !
Ce tutoriel vous explique comment répartir les données dans vos tables en suivant les règles de la normalisation.

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 :

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.

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, 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.

:bye:

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

P.S : Commentaires ?