Accueil Recherche | Plan Technique | Liens | Actualités | Formation | Emploi | Forums | Base
TUTORIEL cerig.efpg.inpg.fr 
Vous êtes ici : Accueil > Formation > Tutoriels > Bases de données relationnelles > Le mécanisme relationnel
        Révision : 26 décembre 2002
 
                  Les bases de données
relationnelles
                 
Chap.
précéd.
Plan du
tutoriel
Liste des
tutoriels
Chap.
suivant
 
Chapitre 5 : le mécanisme relationnel
 
1 - Introduction
                  Les entreprises sont nées et se sont développées bien avant que l'informatique n'apparaisse. De ce fait, la plupart des logiciels ont été créés pour informatiser des opérations que l'on effectuait auparavant manuellement. Au fur et à mesure que les ordinateurs acquéraient de la puissance, et que leur coût baissait, le nombre des applications informatisables ne cessait d'augmenter. Les SGBD n'ont pas fait exception à la règle, même si on l'a passablement oublié aujourd'hui.          
Tout ce que les anciens gestionnaires d'entreprise avaient inventé -- l'usage des codes, des index et des opérateurs logiques, le fractionnement des informations et leur répartition dans des "fichiers" multiples mais reliés, etc. -- a été repris (le plus astucieusement possible) pour créer les SGBD relationnels. Il faut bien reconnaître que, lors de l'informatisation des données de l'entreprise, on a beaucoup adapté, beaucoup formalisé, mais peu inventé. Cela devrait inciter messieurs les informaticiens à un peu plus de modestie.
Il est de bon ton, dans l'enseignement des BDD, d'oublier tout le passé. Pire, on présente souvent les choses sous un aspect aussi abstrait que possible -- la théorie des ensembles, vous connaissez ? -- et en usant d'un vocabulaire ésotérique à souhait. Nous nous donnons donc pour but, dans ce chapitre, de montrer que le fonctionnement des bases de données relationnelles est fondé sur des techniques éprouvées, qu'il est possible d'exposer simplement, et qu'il relativement facile de comprendre et d'assimiler.
2 - Les données redondantes
                  Réduire le plus possible la saisie d'informations redondantes est l'un des gros problèmes auquel se sont heurtés les gestionnaires des données de l'entreprise, avant que l'informatique ne vienne à la rescousse. Expliquons-nous à l'aide d'un exemple.          
Vous travaillez dans une entreprise qui vend des matériaux de construction, et l'informatique n'existe pas encore. Vos principaux clients sont des entrepreneurs du bâtiment et des entreprises de génie civil. Les clients les plus assidus viennent chercher des matériaux au moins une fois par jour. Quand vous écrivez dans vos livres que le camion de la "Société des Grands Travaux du Dauphiné et de la Matheysine" est venu charger 30 sacs de ciment, vous n'allez pas pour la centième fois depuis le début de l'année écrire laborieusement le nom et les coordonnées de ce fidèle client. Vous serez même lassé d'écrire seulement son nom, qui est beaucoup trop long ! Vous remplacerez ce nom par un code, qui en constitue une représentation très abrégée. Vous pouvez utiliser un code à consonance mnémotechnique (SGTDM par exemple), ou au contraire parfaitement arbitraire (530-Z, pourquoi pas).
Lorsque votre comptable exploitera le bon de livraison pour alimenter le compte du client ou pour générer une facture, il n'aura aucun mal à déterminer ce que désigne le code SGTDM. S'il ne s'en souvient plus, un fichier "Clients" est là pour l'aider. Tous les clients y ont leur fiche, et ces fiches sont classées par ordre alphabétique des codes. Chaque fiche contient tout ce qu'il faut pour identifier le client : son nom, son adresse, son numéro de téléphone, les remises consenties, etc. Toutes ces informations ont été saisies une fois et une seule, mais elles vont servir à de multiples reprises : à chaque facturation, à chaque rappel (le client paye en retard), à chaque coup de fil, à chaque envoi de publicité ciblée, etc. Bien entendu, le fait que les fiches soient classées par ordre alphabétique permet de retrouver très vite la fiche d'un code donné. Si les fiches se trouvaient dans le désordre, il faudrait en lire la moitié (en moyenne) pour retrouver la bonne.
Votre entreprise applique la même technique pour gérer son stock de produits, la liste de ses fournisseurs, son personnel, etc.
Vous n'êtes pas surpris, aujourd'hui, de voir des codes partout autour de vous (avec des codes barres, pour en rendre la lecture automatique) : dans les grandes surfaces pour les produits de consommation courante, dans les pharmacies pour les médicaments, dans les catalogues de vente par correspondance, chez le garagiste pour les pièces détachées, etc. De même que M. Jourdain faisait de la prose sans le savoir, vous baignez dans le relationnel sans vous en rendre compte.
3 - L'informatique arrive
                  Le temps passe, le coût de la main d'oeuvre ne cesse d'augmenter, et les décideurs de l'entreprise font leurs comptes : informatiser la gestion des données courantes de l'entreprise va permettre de faire des économies. D'ailleurs, les concurrents suivent le même chemin, pas question de rester à la traîne.          
Les données que manie couramment l'entreprise sont structurées. Pour chaque produit du stock, par exemple, on enregistre les mêmes séquences de données : code, nom, prix unitaire, code du fournisseur, état du stock, état minimal admissible, quantité minimale par commande, etc. Ces données peuvent donc être rangées dans des tables, dotées du nombre de colonnes requis. La première conséquence de l'informatisation a été la dématérialisation des données : chaque fichier est devenu une table, chaque fiche un enregistrement. Au lieur de remplir les fiches à la main, ou à la machine à écrire, on saisit désormais les informations au clavier. Les informations ne résident plus sur les fiches en bristol d'une boite appelée "fichier", mais sur le disque dur d'un ordinateur.
Mais ce n'est pas tout. Le gestionnaire du stock sait que le code du fournisseur relie la fiche produit au fichier "fournisseurs", mais il est doté d'intelligence, alors que l'ordinateur en est totalement dépourvu. Il faut donc imaginer un moyen pour faire en sorte que l'ordinateur sache que la table des produits et celle des fournisseurs sont liées par une relation basée sur des codes, et qu'il la gère. Il faut donc construire une base de données relationnelle, c'est à dire capable de gérer les relations comme le faisait jusque-là instinctivement le personnel de l'entreprise.
4 - Traduire les relations
                  Pour comprendre comment fonctionne une relation, il suffit de jeter un coup d'oeil à l'exemple représenté ci-dessous. Désormais, les "fichiers" sont dématérialisés et transformés en tables. La table de gauche contient la liste des produits commercialisés par l'entreprise. La table de droite contient la liste des fournisseurs. Considérons le premier produit, le ciment C-21 ; son code fournisseur vaut 3. Dans la table de droite, l'ordinateur lira que le fournisseur est la société "Ciments X", ainsi que toutes les informations qui la concernent (l'adresse, le téléphone, le fax, les conditions consenties, etc.). Sa recherche sera d'autant plus rapide que la table "Fournisseurs" sera trié dans l'ordre croissant des codes. Bref, le SGBD maniera les relations comme le ferait un être humain.          
Relation entre deux tables
Pour rendre le système plus sûr, nous allons demander à l'ordinateur de vérifier que, dans la table "Fournisseurs", nous n'avons pas attribué deux fois le même code (cela s'appellera "l'unicité de la clé"). Puis nous allons imposer que l'on ne puisse pas introduire un produit dans la table de gauche tant que le code fournisseur correspondant n'est pas défini dans la table de droite (cela fait partie de l'intégrité référentielle). Bref, l'ordinateur fera ce que faisaient les employés qui manipulaient les données, mais il ira beaucoup plus vite, il fera plus de contrôles, et il se trompera beaucoup moins. Cela ne veut pas dire qu'il n'y a plus personne dans l'entreprise, car il faut bien que quelqu'un pilote l'ordinateur -- et reçoive le client !
Mais... tous les étudiants des écoles de commerce vous le diront : il faut, chaque fois que c'est possible, avoir deux fournisseurs par produit. Cela évite les difficultés d'approvisionnement et le dérapage excessif des prix. Comment, dans le schéma ci-dessus, traduire le fait que le ciment peut provenir soit des Ciments X, soit de la société Truc ?
Créer une nouvelle colonne "Code four" dans la table de gauche ne servirait à rien, car rien n'indiquerait dans quel cas il faut utiliser le premier code, et quand il faut utiliser le second. La bonne solution consiste à créer un nouveau code, "C-22" si vous voulez. Nul ne sera surpris que le ciment ait deux codes car, même s'il s'agit du même produit (un Portland courant, par exemple), l'emballage des sacs est différent. Les clients les plus pointilleux vous diront même que le ciment C-22 et meilleur que le C-21. Après tout, ce n'est pas impossible, même si le ciment Portland a fait l'objet d'une norme.
Résumons-nous : la relation entre les deux tables nous permet de ne saisir qu'une seule fois les informations relatives à un fournisseur, même si ce dernier nous fournit plusieurs produits. Le mécanisme de la relation est basé sur l'usage de codes. Ce mécanisme fonctionne parce que, si un fournisseur nous livre plusieurs produits, chaque produit ne peut provenir que d'un seul fournisseur (pour qu'il en soit bien ainsi, nous avons dû créer quelques codes supplémentaires). En informatique, on parle de "relation 1-n" ou de "relation un à plusieurs". Les SGBD gèrent les relations 1-n sans problème, comme le faisaient les humains auparavant.
5 - Un cas difficile
                  Continuons l'informatisation de l'entreprise, et attaquons-nous aux bons de livraison. Pour chaque commande exécutée, il faut noter le numéro de la commande, la date, le nom -- ou plutôt le code -- de l'entreprise, puis la liste des produits -- ou plutôt de leurs codes -- avec les quantités livrées. Sur papier, pas de difficulté : on peut toujours faire tenir quelques lignes ou quelques dizaines de ligne sur une feuille de papier A4. Mais, pour reporter le tout dans une table, nous rencontrons un sérieux problème, comme le montre la figure ci-dessous. Combien devons-nous prévoir de colonnes pour le code du produit et la quantité correspondante ?          
Bons de livraison
Date Code ent. Code_prod Quantité Code_prod Quantité Etc.....?
1225 15/02/2001 SGTDM --------- ------ --------- ------
1226 15/02/2001 XYZT ---------- --- ---------- ---
1227 15/02/2001 CQFD -------- ------ -------- ------
etc.
Si nous en prévoyons beaucoup, nous gaspillerons de la mémoire à tour de bras. Si nous en prévoyons peu, nous serons obligés de faire plusieurs bons pour une même livraison, et nous dirons en hochant la tête : "C'est la faute de l'ordinateur". Un mien collègue, en pareil cas, donnait à ses étudiants le conseil suivant : "Vous ne savez pas comment faire ? Créez une nouvelle table !". Comparé à de l'algèbre relationnelle, cela fait un peu simpliste, mais... cela marche dans bien des cas, y compris celui qui nous occupe actuellement.
La nouvelle table (dite table de jonction) comportera trois colonnes :
            la première colonne contiendra un code assurant le lien avec la table "Bons de livraison". Ce code, qui doit désigner de manière unique chaque bon de livraison, sera tout simplement son numéro ;
  la seconde colonne contiendra les codes des produits ;
  la troisième colonne contiendra les quantités livrées.
Nous écrirons autant de lignes dans cette nouvelle table qu'il y avait de produits mentionnés sur chaque bon de livraison, comme le montre la figure ci-dessous. Nous voyons dans cette table que le bon de livraison n° 1225 comporte 30 sacs de ciment (C-22), 2 palettes de pavés (P-5) et 5 regards de 40 cm (R-10), toutes informations tirées de la table "Produits", la relation étant assurée via le code produit. La table "Bons de livraison" nous montre (grâce à la relation assurée par le numéro de bon) que l'entreprise livrée est notre bon client SGTDM. Les informations le concernant se trouvent dans la table "Clients", la relation étant assurée par le code client.
Table de jonction
N° bon Code_prod Quantité
1225 C-22 30
1225 P-5 2
1225 R-10 5
1226 etc.
Que s'est-il passé dans le cas des bons de livraison ? Nous nous sommes trouvés devant une relation plus complexe que précédemment. Un même bon de livraison peut mentionner plusieurs produit, et un même produit apparaît dans de nombreux bons de livraison (sinon, c'est un produit qui ne se vend pas, et il faut l'abandonner). Nous avons affaire à une relation n-n (ou plusieurs à plusieurs), difficile à gérer par des moyens informatiques, alors qu'il n'y a pas de problème avec les moyens manuels.
Heureusement pour nous, la création d'une table de jonction, puisant ses codes dans deux autres tables ("Bons de livraison" d'un côté, "Produits" de l'autre), nous a tirés d'affaire. Les informaticiens vous confirmerons qu'une relation n-n peut toujours être scindée en deux relations 1-n par création d'une table supplémentaire, laquelle est parfois appelée "table de jonction". Les mathématiciens pourront même vous en faire la démonstration rigoureuse, si vous appréciez l'abstraction.
6 - Conclusion
                  Nous avons tenté de montrer, à l'aide d'exemples concrets, que les bases de données relationnelles tirent leur origine dans la manière dont les entreprises géraient leurs données avant la grande vague d'informatisation de ces 20 dernières années. Les tables et leurs enregistrements sont issus des fichiers et de leurs fiches. Les clés et les relations proviennent directement de l'usage des codes. Le problème de la relation n-n, par contre, est spécifique de l'introduction de l'informatique, mais la création d'une table de jonction résout le problème sans grande difficulté.          
Les premiers SGBD mis sur le marché ne géraient pas les relations, et les entreprises les trouvaient fort malcommodes. Le succès des SGBD relationnels provient du fait qu'ils répondent bien aux besoins des entreprises -- parce qu'ils ont été conçus pour cela. Il n'y a ni mystère, ni mathématiques ensemblistes, cachés là-dessous.
Nous espérons que les informations contenues dans ce chapitre vous faciliteront l'étude du chapitre suivant, consacré à l'établissement du schéma relationnel. Si vous pensez que nous avons manqué notre but, et si vous avez des suggestions à nous faire pour améliorer ce texte, n'hésitez pas à envoyer un courrier électronique au CERIG. Merci !
Chapitre  précédent Plan du tutoriel Liste des tutoriels Chapitre suivant
Accueil | Technique | Liens | Actualités | Formation | Emploi | Forums | Base
Copyright © CERIG/EFPG 1996-2003
Réalisation et mise en page : J.C. Sohm