Pour suivre cette leçon, vous devez avoir suivi les leçons précédentes. Ou plus précisément, vous devez être en possession de la base de données procd.mdb telle qu'elle était à la fin de la leçon précédente. Si vous n'êtes pas certain de l'avoir, vous pouvez la télécharger ici
Résumé
de la leçon précédente| La fois passée, nous avons vu qu'il est possible de créer des listes déroulantes basées sur d'autres tables. Contrairement aux listes déroulantes locales, ces listes déroulantes permettent de choisir parmi un important choix de valeurs. L'autre facilité se situe au niveau de la table : Il suffit d'ajouter de retirer, ou de changer l'orthographe d'un pays dans la table T_Pays par exemple, pour que la liste déroulante Pays de la table T_Client soit automatiquement mise à jour ! |
Aperçu de
cette leçon| Dans cette leçon, nous allons regarder en détail les relations entre les tables : Vous apprendrez que les relations sont une sorte de "police", un "Service de contrôle" qui vérifie que votre base de données reste bien cohérente au niveau des données qu'ele contient. |
Nous avons vu, il y a 2 leçons, comment faire pour empêcher de saisir une
valeur qui n'est pas proposée dans une liste déroulante : 
. Mais.. Attention :
Cette option n'entre en jeu qu'à partir du moment ou vous définissez Limiter à
liste : Oui. Jusque-là, on pouvait écrire n'importe quoi... Je m'explique
:
. Vous pouvez, mais
dès que vous allez changer de champ ou d'enregistrement, vous aurez le message
. C'est
bian mais... Ca n'empêche pas qu'il existe encore Bill Clunton qui vient de YoupiLand (qui est un pays fantaisiste), et Michael Jordane, qui vient d'U.S.A... Au lieu de USA (Sans les points entre les lettres... C'est important !)
Ce qui fait qu'en définitive, cette sécurité n'est pas suffisante
Oui. Quittez la table T_Client, et allez dans Outils/Relations. Cette boîte
de dialogue apparait : 
. Cliquez deux fois sur T_Client, et également 2 fois sur T_Pays
: 
.
Cliquez ensuite sur 
. Vos deux tables T_Client et T_Pays sont maintenant apparente
dans les relations : 
.
Vous pouvez redimensionner ou déplacer les tables pour voir la totalité de la
table T_Client par exemple : 
.
Une fois que vous avez bien sous les yeux les 2 tables avec tous leurs champs
(srutout la table T_Client qui contient pas mal de champs), nous allons essayer
de les lier ensemble : Prenez Pays de T_Pays, et faites le glisser sur IDClient
de T_Client : 
. Vous constatez que quand vous faites glisser la souris, elle
se trasforme en petit rectangle (
). C'est normal.
Cette boîte de dialogue apparait : 
. Cliquez sur 
. Maintenant,
les 2 tables sont liées comme ceci : 
par une petite ligne
noire.
Oui. Cliquez sur T_Pays 
, et appuyez sur la touche DELETE 
Cliquez sur l'icône 
, et cliquez 2 fois sur T_Pays : 
, puis cliquez sur 
. La table est
réapparue !
Oui, je vous ai fait faire quelque chose de faux exprès. En fait, quand on clique sur une table et qu'on la supprime avec DEL (quand on est dans les relations évidemment), en fait, on ne supprime rien du tout : Ni la table, ni la relation qu'elle a avec d'autres tables. En fait, tout ce qu'on fait, c'est que simplement on MASQUE la table dans les relations. La table est toujours là, la relation aussi, mais simplement, on ne les voit plus.
En fait, il faut cliquer précisément sur la petite ligne noire qui relie les
2 tables : 
, et seulement quand la ligne est sélectionnée (elle devient un
tout petit peu plus épaisse quand on clique dessus), on appuye sur DEL (). Un
message de confirmation apparait : 
. Cliquez sur 
, et la relation a
maintenant disparu. Vous vous retrouvez avec vos 2 tables comme au début : .
Si, bien sûr. Mais j'ai lié exprès deux champs qui n'ont rien à voir l'un avec l'autre simplement pour montrer que dans les relations, on peut lier n'importe quel champ de n'importe quelle table avec n'importe quel champ de n'importe quelle autre table.
Il n'y a pas d'intérêt autre que de dire : "Tiens, cette table possède un champ qui est très copain avec un autre champ d'une autre table". C'est tout... Comme par exemple, le champ PaysOrigine de T_Client est très copain avec le champ Pays de la table T_Pays en ce sens que c'est un PaysOrigine de ta table T_Client qui est une liste déroulante basée sur Pays de la table T_Pays.
Oui, c'est tout... POUR L'INSTANT ! En fait, nous allons maintenant réaliser une relation qui tient la route : C'est à dire que nous allons en quelque sorte "marier" les deux tables T_Client et T_Pays. Vous vous rappelez : Un peu plus haut dans la leçon, nous avions défini des pays pour le moins fantaisistes : Michael Jordane provient des U.S.A (Alors que le vrai pays est USA, sans les points), et Bill Clunton vient carrément de YoupiLand (Un pays de ma plus pure imagination).
Toujours est-il que ça ne va pas : C'est le désordre le plus total. Il faudrait, pour que notre base de données soit fiable, que tous les clients, SANS EXCEPTION, fassent partie d'un pays QUI EXISTE dans la table de référence T_Pays. Si un client vient de U.S.A, alors U.S.A DOIT exister dans T_pays. Pareil pour YoupiLand (Ce qui est idiot, puisque YoupiLand est un pays fantaisiste : En fait, PERSONNE n'est issu de YoupiLand !).
On ne dit pas "Marier les tables". Dans le jargon très poétique des
informaticiens, nous disons "Appliquer l'intégrité référentielle". Pour ce
faire, créez une relation entre Pays de T_Pays jusque PaysOrigine de T_client.
La boite de dialogue suivante apparait : 
. Mettez une coche dans
"Appliquer l'intégrité référentielle" : 
. Cliquez sur .
Oui. C'est un des messages d'erreur les plus communs d'Access. De plus, il n'est pas très compréhensible... Je vous le traduit :
Impossible de créer cette relation et surtout, d'appliquer l'intégrité rérérentielle (Marier les 2 tables)
Les données (ce que vous avez écrit) dans la
table "T_Client" ne respectent pas les règles d'intégrité référentielle.
Par
exemple, certains enregistrements (certains clients) font peut-être (même
sûrement) référence à un Pays dans la table associée (T_Pays) sans qu'il y ait
d'enregistrement pour ce pays dans la table primaire (Des pays fantaisistes
existent dans la table T_Client sans qu'ils existent dans T-Pays).
Modifiez les données (Partez à la chasse aux
pays fantaisistes dans la table T_Client pour les remplacer par des pays normaux
- c'est à dire des pays qui existent dans T_Pays) pour tous les enregistrements
(Clients) associés.
Si vous souhaitez créer la relation sans suivre les
règles d'intégrité référentielle (si finalement vous vous en fichez que les
clients fassent partie de pays non référencés dans la table T-Pays), désactivez
la case à cocher "Apliquer l'intégrité référentielle (enlever la
coche)"
Cliquez sur OK (Pas le choix)
Ben voilà, en clair, tant que vous avez des clients qui font partie d'un pays qui n'existe pas dans la table T_Pays, pas question d'appliquer l'intégrité référentielle... Eh oui... Si vous aviez par exemple 500'000 clients, et que UN SEUL d'entre eux faisait partie d'un pays non référencé, vous auriez eu le MEME message d'erreur...
Cette relation, c'est un peu la police de votre base de données.
Alors, nous allons corriger tout ça. Marche à suivre :
Si vous avez suivi parfaitement les instructions, vous ne devriez PLUS avoir
de message d'erreur, mais Access devrait vous avoir créé la relation entre les 2
tables comme ceci : 
. Vous constatez que la relation possède un petit 
et un petit 
. C'est le signe que la
relation s'est bien déroulée, et que, surtout, l'intégrité référentielle s'est
appliquée correctement. A partir de maintenant, on peut dire que les deux tables
sont liées "A la vie à la mort". A partir de maintenant, il va être STRICTEMENT
IMPOSSIBLE de donner pour un client quelconque un pays qui n'existe pas dans ta
table T_Pays (ce qui est évidemment très rassurant)
Oui. Pas de pays, c'est correct. Vraiment, ce qui n'est pas correct, c'est uniquement le fait d'avoir un pays non référencé. Mais un pays vide, ça ne fait rien. Heureusement... Parce que si vous avez à entrer un nouveau client dont vous ne connaissez pas le pays, il faut bien pouvoir le laisser vide quand même...
Dans ce sens là, pas de problème. Dans T_Pays, vous pouvez avoir autant de pays que vous voulez qui ne sont pas référencés chez les clients, ce n'est pas un problème. C'est seulement dans le sens d'un client qui fait partie d'un pays qui n'existe pas dans T_Pays qui pose un problème.
Heureusement qu'on peut ajouter des pays dans T_Pays sans qu'il y ait d'enregistrement correspondant dans les clients ! Imaginez qu'on ne puisse pas dans les pays non plus avoir de pays qui ne correspondent à aucun client... Tout à coup, vous avez un nouveau client, John Lemon qui vient de Grande-Bretagne : Vous ne pourriez pas indiquer qu'il vient de Grande-Bretagne parce que bien sûr, Grande-Bretagne n'existe pas dans T_Pays, mais vous ne pourriez alors pas non plus ajouter Grande-Bretagne dans T_Pays sous prétexte qu'il n'y a encore aucun client de Grande-Bretagne... C'est le serpent qui se mord la queue... Vous suivez toujours ?
Exactement. D'ailleurs, nous allons essayer. Quittez les relations, et ouvrez
T_Client. Essayez de définir Autriche pour Juliette Griko, appuyez sur ENTER.
Vous avez cette erreur : 
Bien vu ! Effectivement. MAIS... Maintenant, en mode création, définissez justement pour le champ Pays "Limiter à liste" : NON. Lancez la table en mode saisie de données, et essayez d'entrer à nouveau Autriche pour Juliette Griko. Appuyez sur ENTER
Oui, mais vous n'avez pas encore enregistré votre changement... Quand vous avez appuyé sur ENTER, c'est maintenant le champ suivant qui est sélectionné (Ville), mais TOUJOURS de Juliette Griko... C'est suelement quand vous allez enregistrer que ça va mal se passer : Essayez de descendre d'un enregistrement :
"Vous avez essayé d'entrer Autriche, qui n'est pas un pays existant dans T_Pays"
Eh non...
Eh non... Tandis que maintenant, c'est sût et certain, ça ne peux pas arriver. Votre table est vraiment fiable.
Dans l'absolu, non ! ça n'a rien à voir avec les relations. D'ailleurs, nous avions créé des listes déroulantes sans la moindre relation... Mais par contre, c'est quand même plus sympathique d'en avoir une... Vous imaginez si vous avez une relation avec intégrité référentielle entre T_Client et T_Pays, mais pas de liste déroulante ? Quelle galère ! Il faudrait connaître par coeur tous les pays !
Bon... Hem... On peut résumer ?| Il est possible de faire des relations entre les
tables de 2 manières : Avec ou sans intégrité référentielle. S'il n'y a
pas d'intégrité référentielle, les relations ne servent pas à grand
chose. Par contre, quand elle est appliquée, alors, tout est sécurisé : Les 2 champs mis en relation DOIVENT absolument correspondre sans exception. Pour appliquer l'intégrité référentielle, il faut que le champ qui sert de "source" (Pays de T_Pays dans notre exemple) soit en clé primaire, sinon, ça ne marche pas. |
Avez-vous bien compris ?
|
Exercice|
Créez une base de données ClubVacances, dans laquelle vous créez 4 tables, exactement comme ceci : (Il est PRIMODIAL que vous recopiez exactement les choses pour le bien de l'exercice - Nul besoin, par contre, de faire des listes déroulantes, à moins que vous n'en ayez envie parce que c'est quand même plus commode...) T_Client
T_Sport
T_LangueMaternelle
T_Pays
L'exercice consiste à lier toutes ces tables AVEC
intégrité référentielle, comme ceci : |
Si vous n'êtes pas tout à fait certain d'avoir suivi correctement toutes les étapes de cette leçon, vous avez la possibilité de télécharger ici la version de procd.mdb exactement dans l'état ou elle devrait être à la fin de cette leçon.
Aperçu
de la leçon suivante| Lors de la prochaine leçon, nous entrerons plus en profondeur dans les relations, et nous constaterons qu'il n'est pas si aisé d'avoir une base de données tout à fait cohérente, et qu'un travail de réflexion est indissociable de la conception d'une base de données, si on ne veut pas qu'elle chancelle après quelque temps avant de s'écrouler complètement, provoquant de très nombreuses heures passées à la récupération des données ! |
