Je ne vais gui?re ici expliquer les bases des relations, car votre n’est nullement l’optique, mais les differentes relations possible entre nos tables. des informations basiques sont precisions dans mon cours sur internet, a sa lecon 16 (payant).
Notre prerequis pour suivre votre didacticiel est de savoir au moins un brin jouer avec les relations avec le menu Outils/Relations
Mes exemples cites dans votre didacticiel
se reposent sur cette base de donnees.
Exemple 1 : Notre plus courant, la relation 1 a quelques
Ca, c’est vraiment LA relation J’ai plus courante.
Imaginez la table Rel1_T_Client avec 2 champs : NomClient et PaysOrigine. NomClient reste en cle primaire. Bon, ce n’est pas une agreable idee de mettre NomClient en Cle primaire puisque dans le quotidien courante, plusieurs clients peuvent avoir le aussi nom, mais c’est pour simplifier.
Nous avons un 2eme champ PaysOrigine qui n’est jamais en cle primaire, vraiment, puisqu’il est en mesure de y avoir diverses fois le aussi (2 fois Belgique dans notre cas).
L’autre table s’appelle Rel1_T_Pays, et ne contient qu’un seul champ Pays, en cle primaire (oui, votre fois, il ne est en mesure de gui?re y avoir 2 fois le aussi pays). Constatez que Les champs Pays et PaysOrigine que nous allons lier ensemble ne portent nullement le aussi nom, ce qui ne gene en pas grand chose le mecanisme relationnel..
On peut beaucoup evidemment coder une liste deroulante dans la table Rel1_T_Client, sur le champ PaysOrigine, qui se basera via le champ Pays de Rel1_T_Pays. Je ne m’appesantis gui?re sur ces listes pour rester vraiment au sein d’ cette histoire de relations pure et dure.
On peut donc avoir 1 client qui n’a aucun pays (Daniel), ainsi, de la clienti?le ayant le meme pays (Alice et Charles). MAIS, il va i?tre impossible de dire que Daniel vient du Chili Prenons un exemple, car le Chili n’existe jamais dans Rel1_T_Pays.
C’est dans Outils/Relations que nous allons faire glisser PaysOrigine de Rel1_T_Client dans Pays de Rel1_T_Pays. (Dans un sens ou dans l’autre, aucune importance)
Et nous obtenons :
Mes champs en gras NomClient et Pays seront seulement des cles primaires. Et le petit 1 et le 8 couche (signe qui veut dire “Infini”) paraissent la preuve que l’integrite referentielle a bien ete appliquee. Si nous avions eu de la clienti?le qui provenaient du Chili entre autres, c’est a dire quand il y avait “Chili” indique pour un de la clienti?le, alors, Access n’aurait gui?re accepte de faire l’integrite referentielle.
Cela va y avoir d’autres soucis, tel le fait de ne pas fermer une table avant d’aller dans les relations, qui provoque des erreurs, mais a nouveau, referez-vous a notre lei§ons pour des details plus basiques.
Modi?le 2 : une aussi table se rattache a diverses champs, de 1 a diverses
Ce 2eme exemple ressemble enormement au premier, mais Il existe votre fois deux champs qui demandent a etre rattaches a une seule table externe :
Nous avons votre fois votre champ PaysOrigine et un champ PaysHabitation.
Vous savez quoi ? ca ne pose nullement vraiment de probleme ! Dans outils/Relations, il suffit d’ajouter 2 fois Rel2_T_Pays, comme ceci :
J’INSISTE : Rel2_T_Pays _1 n’est PAS une copie une table Rel2_T_Pays ! C’est simplement la maniere d’Access de preciser que la meme table reste utilisee 2 fois.
Modi?le 3 : la relation de 1 a 1
La relation 1 a 1 est vraiment plus rare que la relation 1 a plusieurs. Il va i?tre meme possible que vous n’en ayiez jamais besoin. Mais Il semble beaucoup de savoir a quoi cette dernii?re peut servir !
Saviez-vous qu’Access ne gere nullement un nombre illimite de champs ? Eh non ! A partir de la centaine de champs, il va falloir s’attendre a ce qu’il vous penser que la table comporte de trop nombreux champs ! Ca vous interesse, les limites d’Access ? Cliquez ici !
Imaginez que vous avez une table absolument gigantesque gerant par exemple l’etat de patient d’un hopital. Il y aura evidemment le nom, le age, le poids, puis son taux de cholesterol, de glycemie, et ensuite son nombre de globules rouges, blancs, machins bidules, trucs. bref, je ne suis pas medecin, mais je peux imaginer qu’on a besoin de 200 renseignements diverses Afin de un meme patient. Alors donc, comme vous n’arriverez pas a mettre 200 champs dans une aussi table, vous creerez 2 tables, qui seront liees de 1 a 1.
Vous comprenez le principe ? Bon, pour ne point nous attarcder via le milieu medical, nous allons prendre un modi?le tout bete : Nous allons coder une table au milieu des precisions generales des clients, ainsi, une 2eme table avec les precisions Telecom (Telephone, fax, e-mail, . )
Il semble tres important que nos deux champs lies (Ici NomClient et NomClient) soient en cle primaire, sinon, si l’un des deux ne l’est pas, ca ne fera pas une relation 1 a 1 mais 1 a plusieurs.
ATTENTION : Normalement, le sens dans lequel vous tirez 1 champ pour aller vers l’autre n’a aucune importance. En tout cas Afin de tout ce qui concerne les champs de 1 a diverses. Mais dans le cas des champs relies de 1 a 1, ca A VRAIMENT de l’importance. On doit bien tirer une table principale (ici Rel3_T_Client) VERS la ou les autres tables liees de 1 a 1 (ici Rel3_T_ClientTelecom).
J’ai raison en est que comme les deux tables seront liees avec integrite referentielle, il convient donc qu’un client qui existe dans une table doit exister dans l’autre. Mais dans le contexte d’un NOUVEAU client, comment pourrait-il etre lie puisque le temps de le coder au sein d’ une table, y n’existe pas dans l’autre, vous comprenez ?
Si je cree Francois tel nouveau client au sein d’ Rel3_T_Client, moyen que je ferme la table, ainsi, que j’aie le rajouter au sein d’ Rel3_T_:Telecom, Access va hurler : “He ! Vous ne pouvez pas rajouter Francois dans la premiere table, puisqu’il n’existe gui?re dans la 2eme !” Et reciproquement !
Et on fera comment aussi .
Eh bien, en faisant bien gaffe de tirer les champs de la table principale vers l’autre et pas l’inverse, vous POUVEZ aussi creer un nouveau client au sein d’ Rel3_T_Client sans pour autant que celui-ci y ait de relation avec l’autre table Rel3_T_Telecom. C’est d’ailleurs de que j’ai fera.
MAIS vous ne pouvez Manque creer de nouveau client dans Rel3_T_Telecom avant de l’avoir cree dans Rel3_T_Client fonctionnement tgpersonals.
A part ca, ne creez aucune tables multiples “pour faire joli” ou pour la jouer ton genre “Je sais utiliser des relations 1 a 1”. Tant que vous pouvez bien stocker dans une aussi table, ca facilite les trucs. d’autant que vous pourrez coder des requetes qui affichent tels ou tels champs.
Exemple 4 : la relation sans integrite referentielle
On va pouvoir dire de la maniere generale que “normalement”, chacune des tables de la base de precisions sont reliees “1 a quelques”, les unes au milieu des autres. Mes relations 1 a 1 paraissent rares.
Les relations sans integrite referentielle peuvent se Realiser n’importe comment : vous pourrez tirez n’importe quel champ de chaque table, meme si leur type de donnees est multiples, du moment que vous ne cochez jamais “integrite referentielle”. Si vous creez une liste deroulante basee sur une autre table, a la fin de l’assistant, il vous dit “Voulez-vous que les relations soient creees ?”. Si vous repondez Oui, vous aurez une relation sans integrite referentielle.
Si vous entrez dans une base de donnees dans laquelle vous constatez que la quasi totalite des tables sont liees des unes aux autres sans integrite, vous pouvez etre limite certain qu’elle fut creee via un quidam qui ne connait pas le fonctionnement des relations.
Il existe toutefois des cas ou deux tables ont interet a etre reliees sans integrite referentielle.
Imaginons une table Rel4_T_Client, avec le nom du client, et sa ville de naissance qui est une liste deroulante qui va puiser les informations dans Rel4_T_Ville :
La plupart des gens proviennent de la vilel Suisse, mais souvent, il y en a un qui vient de la ville francaise, voire italienne ou enfin de toute metropole de l’univers.
