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 > Les relations (fin)
        Révision : 23 janvier 2003
 
                  Les bases de données
relationnelles
                 
Chap.
précéd.
Plan du
tutoriel
Liste des
tutoriels
Chap.
suivant
 
Chapitre 8 : les listes comparées aux relations
 
1 - Introduction
                  Arrivés à ce stade de notre étude des SGBD, nous sommes amenés à nous poser la question suivante : quelle est la différence entre une liste externe (basée sur une table) et une relation ? Pourquoi ne pas toujours utiliser l'une et ignorer l'autre ?          
Comme nous allons le montrer, une liste externe implique une relation, et nous pourrons la doter de tous les attributs d'une relation. Une relation, par contre, ne crée pas de liste déroulante, et ne peut donc pas jouer le rôle de liste. Nous sommes tentés d'en déduire que, dans Access tout au moins, il est préférable de créer une relation sous forme de liste, puis d'attribuer les propriétés voulues à la relation sous-jacente. En fait, la conclusion finale est plus nuancée.
Comme pour les autres chapitres, nous utiliserons le SGBD Access comme support pratique de ce tutoriel (ou tutorial, ou cours en ligne).
2 - La relation sous-jacente à une liste
                  Nous réutilisons l'exemple du chapitre 4, dans lequel une table appelée "Communes" sert de liste externe à une table appelée "Personnes". La table "Communes" possède un champ intitulé "Commune". La table "Personnes" possède trois champs intitulés "Nom", "Prénom" et "Commune".          
Dès que la liste est créée à l'aide l'assistant "Assistant liste de choix", les deux tables se trouvent liées par une relation. IL suffit, pour s'en rendre compte, d'ouvrir la fenêtre "Relations" en cliquant sur l'icône correspondante. Si nécessaire, on clique sur l'icône "Afficher la table" pour ouvrir la boite de dialogue du même nom, et introduire les deux tables précitées. La figure ci-dessous représente le résultat obtenu : lorsqu'il a créé la liste, l'assistant a simultanément créé une relation, qui est en quelque sorte sous-jacente à la liste.
Une liste implique une relation
L'existence de cette relation n'est pas vraiment une surprise. Comme nous l'avons déjà signalé dans le chapitre précédent, à une liste externe correspond effectivement une relation 1-n.
Si nous supprimons la relation sous-jacente (clic droit, option "Supprimer"), nous constatons que la liste fonctionne comme si de rien n'était, et que ses propriétés (onglet "Liste de choix") ne sont pas modifiées. Nous en concluons que la relation sous-jacente n'est pas indispensable au fonctionnement de la liste.
Au passage, nous en déduisons la méthode qui permet de supprimer une liste. Pour l'appliquer à l'exemple que nous avons choisi :
            dans la fenêtre "Relations", nous supprimons la relation correspondant à la liste ;
  la table "Personnes" étant ouverte en mode "Modifier", nous sélectionnons le champ "Commune", puis l'onglet "Liste de choix", et nous modifions la propriété "Afficher le contrôle" de "Zone de liste déroulante" en "Zone de texte".
3 - Une liste est aussi une relation
                  En règle générale, nous n'avons pas intérêt à supprimer la relation sous-jacente à une liste, car nous pouvons profiter de sa présence pour bénéficier de ses propriétés, en plus de celles de la liste.          
Ainsi, si nous plaçons une clé sur le champ "Commune" de la table "Communes", nous voyons apparaître la sous-table, comportement normal d'une relation. Mais nous disposons aussi, dans la table "Personnes", de la présence de la liste permettant de remplir le champ "Commune" (si la commune requise est déjà présente dans la table "Communes").
La relation sous-jacente peut également être dotée de l'intégrité référentielle, ce qui rend plus sûr le fonctionnement de la liste. Pourquoi s'en priver ?
Bref, une liste fonctionne à la fois comme une liste et comme une relation. Il est des cas où nous n'en avons pas vraiment besoin, mais il est aussi des cas où cela peut nous rendre service -- celui des tables de jonction, par exemple.
Attention ! il est impossible, dans Access 2002, de créer une liste quand la relation correspondante existe déjà. Il faut détruire la relation, créer la liste, puis doter la relation sous-jacente des propriétés désirées.
4 - Le cas des tables de jonction
                  Rappelons qu'une table de jonction est une table que l'on crée pour scinder une relation n-n en deux relations 1-n. Pour illustrer ce cas, nous utiliserons l'exemple d'une liste de fournisseurs et de leurs produits.          
Un même fournisseur peut fournir plusieurs produits, et un même produit peut provenir de plusieurs fournisseurs. Nous nous trouvons dans le cas classique d'une relation n-n, que nous scindons en deux relations 1-n en créant une table de jonction. Notre exemple implique donc trois tables ("Fournisseurs", "Produits", "Jonction") liées par deux relations. Nous faisons l'hypothèse qu'il n'y a pas de problème d'homonymie, ni pour les fournisseurs, ni pour les produits. Nous plaçons une clé sur le champ "Fournisseur" de la table "Fournisseurs", et une sur le champ "Produit" de la table "Produits".
Les tables se présentent comme le montre la figure ci-dessous. Pour remplir la table de jonction, il faut recopier soit le nom du produit (quand la sous-table produit est affichée), soit le nom du fournisseur (quand la sous-table fournisseurs est affichée), ce qui n'est pas admissible.
Une solution non satisfaisante
Supprimons les relations, reconstruisons-les sous forme de liste, puis dotons-les de l'intégrité référentielle. La nouvelle situation est représentée par la figure ci-dessous. Si la table "Produit" est renseignée, on peut remplir la table "Fournisseurs" et la table "Jonction" (sous-table) dans une seule fenêtre, comme le montre la figure.
La bonne solution
5 - L'usage des codes
                  Tout ce que nous avons dit au chapitre 4 sur l'usage des codes dans les listes s'applique tel quel aux relations. Supposons que, dans l'exemple que nous utilisons, nous ayons des problèmes d'homonymie pour les fournisseurs et pour les produits. Nous allons donc introduire des codes pour ces deux entités. Le schéma relationnel se trouve modifié comme suit :          
Schéma relationnel avec codes
Bien entendu, comme au chapitre 4, on masque les codes, et tout se passe comme s'ils n'existaient pas quand on remplit les tables.
6 - Conclusion
                  Une liste de choix externe (c'est à dire basée sur une table) est une relation 1-n dotée d'un mécanisme particulier. Il est souvent intéressant de créer une relation sous forme de liste d'abord, puis de doter ensuite la relation sous-jacente des propriétés requises (intégrité référentielle). Cette technique est particulièrement intéressante pour la saisie des informations dans les tables de jonction.          
Il ne faut pas hésiter à utiliser des codes pour régler des problèmes d'homonymie. Il faut absolument confier la gestion de ces codes au SGBD, et nous conseillons de faire en sorte que ces codes soient cachés à l'opérateur -- à moins qu'il ne tienne absolument à les voir, bien entendu.
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