Fork me on GitHub

Documentations > Développeurs > Fiches techniques > Organisation des données dans les tables

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 :

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

Licence, certains droits réservés
Partager Twitter Partagez cette article sur GG+
  Voir cet article en format PDF Imprimer cet article Envoyer cet article

Naviguer à travers les articles
Article précédent Base de données et requêtes
Propulsé avec XOOPS | Graphisme adapté par Tatane, Grosdunord, Montuy337513

97 Personne(s) en ligne (1 Personne(s) connectée(s) sur Documentations) | Utilisateur(s): 0 | Invité(s): 97 | Plus ...