POURQUOI LES DONNÉES SONT-ELLES STRUCTURÉES DE FACON RELATIONNELLE ?
1) Causes originelles :
Les bases de données sont difficiles à structurer. Ceci n'est pas le fruit de l'imagination sadique de quelques chercheurs en informatique mais imposé par de fortes contraintes techniques et logiques :
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.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.
NOTIONS FONDAMENTALES
La structuration des bases de données en tables reliées entre elles s'explique de la façon suivante :