A moins que vous ne soyez 1 developpeur aguerri ou 1 fin connaisseur des bases de informations, elles vous ont certainement deja donne du fil a retordre.

Je ne vais pas ici expliquer les bases des relations, car ce n’est jamais le but, mais les differentes relations possible entre nos tables. des informations basiques seront precisions dans mon cours web, a la lecon 16 (payant).

Le prerequis Afin de suivre votre didacticiel est de savoir au moins un peu jouer avec les relations avec le menu Outils/Relations

Les exemples cites dans ce didacticiel

se reposent sur une telle base de donnees.

Exemple 1 : Le plus frequent, la relation 1 a diverses

Ca, c’est vraiment LA relation Notre plus courante.

Imaginez la table Rel1_T_Client avec 2 champs : NomClient et PaysOrigine. NomClient est en cle primaire. Bon, ce n’est nullement une agreable idee de mettre NomClient en Cle primaire puisque dans la vie courante, plusieurs clients ont la possibilite de avoir le aussi nom, mais c’est pour simplifier.

Nous avons un 2eme champ PaysOrigine qui n’est pas en cle primaire, forcement, puisqu’il peut y avoir plusieurs fois le meme (2 fois Belgique dans notre cas).

L’autre table s’appelle Rel1_T_Pays, ainsi, ne inclut qu’un seul champ Pays, en cle primaire (oui, cette fois, il ne est en mesure de jamais y avoir 2 fois le meme pays). Constatez que Mes champs Pays et PaysOrigine que nous allons lier ensemble ne portent gui?re le meme nom, ce qui ne gene en rien le mecanisme relationnel..

On va pouvoir beaucoup evidemment coder une liste deroulante dans la table Rel1_T_Client, sur le champ PaysOrigine, qui se basera concernant le champ Pays de Rel1_T_Pays. Je ne m’appesantis gui?re via ces listes pour rester vraiment dans cette histoire de relations pure et dure.

On peut donc avoir 1 client n’ayant aucune pays (Daniel), ainsi, des clients qui ont le meme pays (Alice et Charles). MAIS, il est impossible de dire que Daniel vient du Chili Prenons un exemple, car le Chili n’existe pas dans Rel1_T_Pays.

C’est dans Outils/Relations que nous allons faire glisser PaysOrigine de Rel1_T_Client sur Pays de Rel1_T_Pays. (Dans un sens ou dans l’autre, aucune importance)

Et nous obtenons :

Mes champs en gras NomClient et Pays paraissent seulement des cles primaires. Et le petit 1 et le 8 couche (signe qui veut dire „Infini“) sont la preuve que l’integrite referentielle a bien ete appliquee. Si nous avions eu des clients qui provenaient du Chili comme, c’est a dire quand il y avait „Chili“ indique pour un de la clienti?le, aussi, Access n’aurait jamais accepte de faire l’integrite referentielle.

Cela pourra y avoir d’autres soucis, comme le fait de ne point fermer une table avant d’aller dans les relations, qui provoque des erreurs, mais a nouveau, referez-vous a mon lei§ons Afin de des informations plus basiques.

Exemple 2 : une aussi table se rattache a plusieurs champs, de 1 a plusieurs

Ce 2eme exemple ressemble enormement au premier, mais Il existe cette fois deux champs qui demandent a etre rattaches a une seule table externe :

Nous avons cette fois votre champ PaysOrigine et un champ PaysHabitation.

Vous savez quoi ? ca ne pose gui?re du tout de probleme ! Dans outils/Relations, il va suffire d’ajouter deux fois Rel2_T_Pays, comme ceci :

J’INSISTE : Rel2_T_Pays _1 n’est Manque une copie en table Rel2_T_Pays ! C’est simplement la maniere d’Access de preciser que la meme table reste utilisee deux fois.

Modi?le 3 : la relation de 1 a 1

J’ai relation 1 a 1 est vraiment plus rare que la relation 1 a plusieurs. Il est aussi possible que vous n’en ayiez jamais besoin. Mais il est beaucoup de connaitre a https://datingmentor.org/fr/nobody-review/ quoi celle-ci peut servir !

Saviez-vous qu’Access ne gere pas un nombre illimite de champs ? Eh non ! A partir d’une centaine de champs, il va falloir s’attendre a ce qu’il vous dire 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 entre autres l’etat de patient tout d’un hopital. Cela y aura evidemment le nom, son 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 jamais medecin, mais je peux imaginer qu’on a besoin de 200 informations differentes Afin de un meme patient. Alors donc, comme vous n’arriverez gui?re a mettre 200 champs dans une aussi table, vous creerez deux tables, qui seront liees de 1 a 1.

Vous comprenez le principe ? Bon, pour ne pas nous attarcder sur le milieu medical, nous allons prendre un modi?le tout bete : Nous allons coder une table avec les donnees generales des clients, et une 2eme table au milieu des donnees Telecom (portable, fax, e-mail, . )

C’est tres important que les deux champs lies (Ici NomClient et NomClient) soient en cle primaire, sinon, si l’un des deux ne l’est nullement, ca ne fera gui?re une relation 1 a 1 mais 1 a quelques.

ATTENTION : Normalement, le sens dans lequel vous tirez un champ Afin de aller par l’autre n’a aucune importance. En tout cas Afin de tout ce qui concerne les champs de 1 a diverses. Mais dans le contexte des champs relies de 1 a 1, ca A VRAIMENT de l’importance. Il FAUT beaucoup tirer de la table principale (ici Rel3_T_Client) VERS la ou nos autres tables liees de 1 a 1 (ici Rel3_T_ClientTelecom).

Notre raison en est que tel les 2 tables paraissent liees avec integrite referentielle, il FAUT donc qu’un client qui existe dans une table doit exister dans l’autre. Mais dans la situation d’un NOUVEAU client, comment pourrait-il etre lie puisque moyen de le coder dans une table, il n’existe jamais dans l’autre, vous comprenez ?

Si je cree Francois tel nouveau client au sein d’ Rel3_T_Client, le temps que je ferme la table, et que j’aie le rajouter au sein d’ Rel3_T_:Telecom, Access va hurler : „He ! Vous ne pouvez gui?re rajouter Francois dans la premiere table, puisqu’il n’existe gui?re dans la 2eme !“ Et reciproquement !

Et on fera comment alors .

Eh bien, en faisant bien gaffe de tirer les champs une table principale vers l’autre et jamais l’inverse, vous POUVEZ aussi creer un nouveau client dans Rel3_T_Client sans Afin de autant qu’il y ait de relation avec l’autre table Rel3_T_Telecom. C’est d’ailleurs de que j’ai fait.

MAIS vous ne pouvez Manque creer de nouveau client dans Rel3_T_Telecom avant de l’avoir cree dans Rel3_T_Client.

A part ca, ne creez aucun tables multiples „pour faire joli“ ou pour la jouer style genre „Je sais choisir les relations 1 a 1“. Tant que vous pouvez bien stocker dans une aussi table, ca facilite les choses. d’autant que vous pouvez coder des requetes qui affichent tels ou tels champs.

Exemple 4 : la relation sans integrite referentielle

On va pouvoir dire d’une maniere generale que „normalement“, chacune des tables de la base de precisions seront reliees „1 a diverses“, les unes au milieu des autres. Mes relations 1 a 1 sont rares.

Les relations sans integrite referentielle ont la possibilite de se Realiser n’importe comment : vous pouvez tirez n’importe quel champ de toute table, meme si leur type de donnees est divers, du moment que vous ne cochez jamais „integrite referentielle“. Lorsque vous creez une liste deroulante basee sur une autre table, a la fin de l’assistant, il vous dit „Voulez-vous que des 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 les unes aux autres sans integrite, vous pourrez etre presque certain qu’elle a ete creee avec quelqu’un qui ne connait jamais le fonctionnement des relations.

Il est toutefois des cas ou 2 tables ont interet a etre reliees sans integrite referentielle.

Imaginons une table Rel4_T_Client, avec le nom de l’acheteur, ainsi, sa metropole de naissance qui est une liste deroulante qui va puiser les precisions dans Rel4_T_Ville :

Bon nombre de gens proviennent d’une vilel Suisse, mais de temps en temps, il y en a un qui vient d’une metropole francaise, voire italienne ou enfin de toute ville du monde.

A moins que vous ne soyez 1 developpeur aguerri ou 1 fin connaisseur des bases de informations, elles vous ont certainement deja donne du fil a retordre.