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

Je ne vais pas ici expliquer des bases des relations, car ce n’est nullement l’optique, mais les differentes relations possible entre nos tables. des informations basiques paraissent informations dans mon cours web, a sa lecon 16 (payant).

Le prerequis Afin de suivre votre didacticiel est de savoir bien legerement jouer au milieu des relations avec le menu Outils/Relations

Mes exemples cites dans votre didacticiel

se reposent sur une telle base de precisions.

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, votre n’est pas une bonne idee de mettre NomClient en Cle primaire puisque dans le quotidien courante, plusieurs clients vont pouvoir 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 peut y avoir plusieurs fois le aussi (2 fois Belgique dans notre cas).

L’autre table s’appelle Rel1_T_Pays, ainsi, ne contient qu’un seul champ Pays, en cle primaire (oui, cette fois, il ne peut pas y avoir 2 fois le aussi pays). Constatez que Les champs Pays et PaysOrigine que nous allons lier ensemble ne portent nullement le meme nom, ce qui ne gene en pas grand chose le mecanisme relationnel..

On peut bien evidemment creer 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 nullement dans ces listes pour rester vraiment au sein d’ une telle histoire de relations pure et dure.

On peut donc avoir un client n’ayant aucun pays (Daniel), et des clients ayant le aussi pays (Alice et Charles). NEANMOINS,, il est impossible de dire que Daniel vient du Chili notamment, 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 sur Pays de Rel1_T_Pays. (Dans un sens ou dans l’autre, aucune importance)

Et nous obtenons :

Les champs en gras NomClient et Pays sont simplement les cles primaires. Et le petit 1 et le 8 couche (signe qui veut dire “Infini”) seront la preuve que l’integrite referentielle a bien ete appliquee. Si nous avions eu de la clienti?le qui provenaient du Chili notamment, c’est a penser lorsqu’il y avait “Chili” indique pour un de la clienti?le, aussi, Access n’aurait jamais accepte d’effectuer l’integrite referentielle.

Cela peut y avoir d’autres soucis, comme le fait de ne point fermer une table avant d’aller au sein des relations, qui provoque des erreurs, mais a nouveau, referez-vous a notre lei§ons pour des informations plus basiques.

Modi?le 2 : une meme table se rattache a diverses champs, de 1 a diverses

Ce 2eme exemple ressemble beaucoup au premier, mais il y a votre fois 2 champs qui demandent a etre rattaches a une seule table externe :

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

Vous connaissez quoi ? ca ne pose nullement vraiment de probleme ! Dans outils/Relations, il vous suffira d’ajouter 2 fois Rel2_T_Pays, comme ceci :

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

Modi?le 3 : la relation de 1 a 1

Notre relation 1 a 1 reste vraiment plus rare que la relation 1 a diverses. Cela reste meme possible que vous n’en ayiez jamais besoin. Mais il va i?tre bien de connaitre a quoi i§a va servir !

Saviez-vous qu’Access ne gere jamais un nombre illimite de champs ? Eh non ! A partir de la centaine de champs, il convient s’attendre a votre 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 Prenons un exemple l’etat de patient tout d’un hopital. Il y aura bien entendu le nom, son age, son poids, puis le taux de cholesterol, de glycemie, ainsi, ensuite son nombre de globules rouges, blancs, machins bidules, trucs. bref, je ne suis gui?re medecin, mais je peux imaginer qu’on a besoin de 200 renseignements diverses pour 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 concept ? Bon, Afin de ne point nous attarcder dans le milieu medical, nous allons prendre un exemple tout bete : Nous allons datingmentor.org/fr/sugarbook-review coder une table au milieu des informations generales de la clienti?le, ainsi, une 2eme table avec les donnees Telecom (Telephone, fax, e-mail, . )

Il semble fort important que des deux champs lies (Ici NomClient et NomClient) soient en cle primaire, sinon, si l’un des deux ne l’est pas, ca ne fera gui?re une relation 1 a 1 mais 1 a plusieurs.

ATTENTION : Normalement, le sens dans lequel vous tirez un champ Afin de aller par l’autre n’a aucune importance. Du reste Afin de bien et cela concerne nos champs de 1 a plusieurs. Mais dans le contexte des champs relies de 1 a 1, ca A VRAIMENT de l’importance. On doit beaucoup tirer en table principale (ici Rel3_T_Client) VERS la ou nos autres tables liees de 1 a 1 (ici Rel3_T_ClientTelecom).

J’ai raison en est que tel les 2 tables paraissent liees avec integrite referentielle, il va falloir donc qu’un client qui existe dans une table devra exister dans l’autre. Mais dans la situation tout d’un NOUVEAU client, comment pourrait-il etre lie puisque moyen de le coder au sein d’ une table, il n’existe gui?re dans l’autre, vous comprenez ?

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

Et on fait De quelle fai§on alors .

Eh bien, en faisant bien gaffe de tirer les champs d’une table principale vers l’autre et gui?re l’inverse, vous POUVEZ alors 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.

NEANMOINS, vous ne pouvez PAS creer de nouveau client dans Rel3_T_Telecom avant de l’avoir cree dans Rel3_T_Client.

A part ca, ne creez pas de tables multiples “pour faire joli” ou pour la jouer style genre “Je sais se servir de nos relations 1 a 1”. Tant que vous pourrez tout stocker dans une meme 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 reconnai®tre d’une maniere generale que “normalement”, l’integralite des tables de la base de precisions seront reliees “1 a plusieurs”, les unes au milieu des autres. Les relations 1 a 1 sont rares.

Les relations sans integrite referentielle vont pouvoir se Realiser n’importe De quelle fai§on : vous pouvez tirez n’importe quel champ de n’importe quelle table, aussi si leur type de donnees est differents, de l’instant que vous ne cochez gui?re “integrite referentielle”. Lorsque vous creez une liste deroulante basee sur une nouvelle table, a J’ai fin de l’assistant, il vous devoile “Voulez-vous que des relations soient creees ?”. Si vous repondez Oui, Vous allez avoir 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 a toutes les autres sans integrite, vous pourrez etre presque certain qu’elle fut creee via quelqu’un qui ne connait gui?re le fonctionnement des relations.

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

Imaginons une table Rel4_T_Client, avec le nom de la clienti?le, et 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 souvent, il y en a un qui vient de la ville francaise, voire italienne ou enfin de n’importe quelle ville de l’univers.