|
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. |
|
|
 |
|
|
|
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. |
|
|
 |
|
|
|
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. |
|
|
 |
|
