1) Causes originelles :

1. Contrainte technique :

   Les données sont stockées sur des disques (magnétiques ou optiques). Pour retrouver une information, un nom par exemple, il faut que la tête de lecture la cherche sur le disque. Si les données ne sont pas structurées, chaque mot va être examiné et comparé au nom recherché. C'est le système de recherche séquentielle. Il est utilisé pour rechercher un mot dans un document de petite taille (quelque dizaines de pages). Ce système ne peut pas être utilisé pour faire une recherche dans un fichier comportant des millions de noms. Le temps d'attente de la réponse serait trop important.
   
   En revanche, il existe une possibilité intéressante de lecture du disque : l'accès direct. La tête de lecture peut accéder directement à une information se trouvant à un endroit quelconque d'un fichier. Pour cela, elle utilise un nombre de caractères (octets) à passer pour accéder directement à l'endroit recherché dans le fichier. Si par exemple une information à retrouver se trouve à partir du 50.000ème caractère, alors elle va passer les 49.999 caractères précédents en une seule fois sans les examiner (contrairement à l'accès séquentiel).
   
   L'astuce consiste à déterminer la longeur fixe d'un enregistrement. Si un fichier est structuré en enregistrement de 100 caractères chacun, alors pour accéder directement à la fiche N°17.232, il suffit à la tête de lecture de "sauter" (17.232 - 1) X 100 caractères soit : 1.723.100 caractères. Cette opération est réalisée instantanément en utilisant la table d'allocation de place au fichier (FAT) du système d'exploitation.
   
   Dans l'exemple ci-dessous, pour accéder à la fiche de THEODULE qui est la N°3, il faut passer les deux enregistrements précédents. Si chaque enregistrement fait 35 caractères, il faut donc passer 70 caractères pour accéder aux nom et téléphone de la fiche recherchée.
   
   


En conclusion, pour pouvoir rechercher efficacement une information dans un fichier, il faut que celui-ci soit structuré en enregistrement à longueur fixe.

Remarque : la rigueur m'oblige à dire que ce shéma est, depuis les années 1990, amélioré par des techniques permettant une bien meilleure gestion de la "consommation" en octets. Cependant, son développement ici n'apporterait aucun élément supplémentaire d'explication quant à la structuration des SGBD.



2. Contrainte logique d'unicité et de maintenance de l'information :
   
   Dans toute organisation, une information quelconque (adresse d'un client par exemple) ne devrait être écrit qu'une seule fois. Ceci serait le cas idéal. Chaque fois qu'un service aurait besoin de l'information, il consulterait le fichier central.
   
   Par exemple, le service commercial enregistre au fichier l'adresse d'un nouveau client. Le service livraison consulte son adresse pour expédier la marchandise et le service comptable fait de même pour envoyer la facture. Inversement si chaque service tient son propre fichier client, l'adresse doit être recopiée plusieurs fois (premier risque d'erreur) et surtout, lorsque l'adresse du client change, il est très probable que son adresse ne soit pas mise à jour dans les services (oubli de transmission de l'information).
   
   Le principe d'unicité de l'information permet de dire : "il n'y a qu'un seul endroit qui détient l'information et c'est à cet endroit qu'elle doit être cherchée"
   
   Ce principe est applicable pour n'importe quel traitement de l'information. Prenons comme exemple un journal simplifié d'entrée en stock de marchandises. Celui-ci, tenu dans une base de données simpliste se présente en une seule table :
   
   
   
   Pour chaque entrée en stock, le magasinier est obligé de d'écrire, entre autres informations, le nom du fournisseur et du produit. Même si le nom du fournisseur ou de l'article est utilisé plusieurs fois, il doit être ré-écrit. Le risque d'erreur est trop important.
   

2) Structuration en tableaux de même nature :

Pour répondre à la contrainte d'unicité d'information, on rassemble les informations dans des listes. Chaque liste représente une catégorie d'information. Par exemple on aura la liste des étudiants inscrits en MSG, la liste des cours proposés en MSG, la liste des professeurs, la liste des inscriptions etc. Le résultat doit être que chaque information n'est écrite qu'une fois. Ceci est bien le cas : dans la liste des professeurs ou des étudiants, chaque nom n'est écrit qu'une fois.

Dans l'exemple du journal de livraison, il faut créer trois listes : fournisseurs, articles et livraisons. Nous avons donc :



C'est de loin la phase la plus délicate. Elle dépend entièrement de la bonne analyse du système d'information. Dans cet exemple, une erreur aurait pu être de considérer que les livraisons du 15/02/02 sont identiques alors qu'elles concernent des marchandises différentes.

Les listes sont donc les tables de notre base de données.

3) Nécessité de la clé primaire

Le critère d'unicité est bien rempli. Cependant, un nouveau problème se pose alors : il n'est pas possible de faire la relation entre ces tables. Dans notre exemple, pour la livraison du 17/02/02 il n'est pas possible de dire quel fournisseur a fait la livraison ni quel article a été livré. D'un point de vue pratique, il nous manque le numéro du fournisseur et le code de l'article. Ces données nous permettraient d'aller chercher le nom du fournisseur d'une part et le libellé de l'article d'autre part.

On doit pouvoir retrouver la référence de chaque élément d'une liste ; c'est à dire la référence de chaque enregistrement. Pour cela, on va, avant toute chose, implanter l'identification unique des enregistrements dans toutes les tables : la clé primaire.

Nos tables vont donc se présenter de la façon suivante :



La champ clé primaire est ici représenté en rouge.

4) Utilisation de la clé primaire pour la connexion

La mise en relation d'une table T1 vers une table T2 se fait par copie de la clé primaire de la table T1 dans un champ de même nature de la table T2 appelé clé externe.

Dans notre exemple, chaque enregistrement de livraison doit comporter le numéro du fournisseur (champ CptFourn) et le numéro de l'article (champ CptArt). Nos tables se présentent maintenant de la façon suivante :



Les clés externes sont ici représentées en vert.

L'enregistrement de la livraison du 17/02/02 peut maintenant se "lire" de la façon suivante :
"La livraison N° 5 (CptLivr) a été faite le 17/02/02 (DateDeLivr) par le fournisseur Vladimir (CptFourn = 2) de 25 (Qté) articles Glablutz (CptArt = 3)."

5) Vérification par application du contrôle d'intégrité référentielle

Si une table T2 comporte un champ clé externe prévu pour contenir la valeur d'une clé primaire d'une table T1 alors :
- ce champ clé externe dans T2 ne peut pas être vide
- la valeur contenue dans ce champ correspond à la valeur d'une clé primaire de T1 existante
- il n'est pas possible de supprimer un enregistrement de la table T1 si sa clé primaire est utilisée dans la table T2

Dans notre exemple, on peut dire qu'il ne peut pas exister de livraison sans fournisseur ! donc :
- le champ CptFourn ne peut pas être vide.
- le champ CptFourn ne peut contenir que les valeurs "1" ou "2" ; à savoir les clés d'Arthur ou de Vladimir. Il n'est pas possible d'indiquer "789" qui ne correspond à aucun fournisseur.
- il n'est pas possible de supprimer le fournisseur Vladimir car sa clé primaire est utilisée dans la table des livraisons.