Je ne vais gui?re ici expliquer les bases des relations, car ce n’est gui?re le but, mais les differentes relations possible entre nos tables. des informations basiques seront donnees dans mon cours sur internet, a sa lecon 16 (payant).

Notre prerequis pour suivre votre didacticiel est de savoir au moins un tantinet jouer au milieu des relations avec le menu Outils/Relations

Les exemples cites dans votre didacticiel

se reposent sur cette base de precisions.

Exemple 1 : Notre plus frequent, la relation 1 a plusieurs

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

Imaginez la table Rel1_T_Client avec 2 champs : NomClient et PaysOrigine. NomClient reste en cle primaire. Bon, ce n’est gui?re une agreable idee de mettre NomClient en Cle primaire puisque dans le quotidien courante, plusieurs clients vont pouvoir avoir le meme nom, mais c’est pour simplifier.

Nous avons un 2eme champ PaysOrigine qui n’est pas en cle primaire, forcement, puisqu’il est en mesure de y avoir quelques fois le aussi (2 fois Belgique dans une cas).

L’autre table s’appelle Rel1_T_Pays, et ne contient qu’un seul champ Pays, en cle primaire (oui, une telle fois, il ne pourra jamais y avoir 2 fois le aussi pays). Constatez que Mes champs Pays et PaysOrigine que nous allons lier ensemble ne portent gui?re le aussi nom, cela ne gene en rien le mecanisme relationnel..

On peut bien evidemment coder une liste deroulante dans la table Rel1_T_Client, sur le champ PaysOrigine, qui se basera dans le champ Pays de Rel1_T_Pays. Je ne m’appesantis nullement dans ces listes pour rester vraiment au sein d’ cette histoire de relations pure et dure.

On peut donc avoir un client n’ayant aucun pays (Daniel), ainsi, des clients qui ont le meme pays (Alice et Charles). NEANMOINS,, il est impossible de dire que Daniel vient du Chili par 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 :

Les champs en gras NomClient et Pays seront juste les 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 de la clienti?le qui provenaient du Chili entre autres, c’est a dire s’il y avait “Chili” indique pour un des clients, alors, Access n’aurait pas accepte d’effectuer l’integrite referentielle.

Il pourra y avoir d’autres soucis, comme claque de ne pas fermer une table avant d’aller au sein des relations, qui provoque des erreurs, mais a nouveau, referez-vous a le file pour des renseignements plus basiques.

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

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

Nous avons une telle fois 1 champ PaysOrigine et un champ PaysHabitation.

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

J’INSISTE : Rel2_T_Pays _1 n’est PAS une copie d’la 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 est vraiment plus rare que la relation 1 a quelques. Cela reste meme possible que vous n’en ayiez jamais besoin. Mais c’est beaucoup de savoir a quoi cette dernii?re https://datingmentor.org/fr/rencontres-hindoues va servir !

Saviez-vous qu’Access ne gere pas un nombre illimite de champs ? Eh non ! A partir de la centaine de champs, vous devez s’attendre a votre que celui-ci 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 comme l’etat de patient d’un hopital. Il y aura bien entendu son nom, le age, son poids, puis son taux de cholesterol, de glycemie, et ensuite son nombre de globules rouges, blancs, machins bidules, trucs. bref, je ne suis nullement medecin, mais je peux imaginer qu’on a besoin de 200 renseignements differentes pour un meme patient. Alors donc, comme vous n’arriverez nullement 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 concernant le milieu medical, nous allons prendre un exemple tout bete : Nous allons coder une table au milieu des precisions generales de la clienti?le, ainsi, une 2eme table avec les informations Telecom (portable, fax, e-mail, . )

Cela reste reellement important que nos 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 1 champ pour aller vers l’autre n’a aucune importance. En tout cas pour tout ce qui concerne les champs de 1 a quelques. Mais dans le cas des champs relies de 1 a 1, ca A VRAIMENT de l’importance. Vous devez 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).

La raison en reste que comme les deux tables paraissent liees avec integrite referentielle, il faudra donc qu’un client qui existe dans une table doit exister au sein d’ l’autre. Mais dans le contexte d’un NOUVEAU client, De quelle fai§on pourrait-il etre lie puisque le temps de le coder au sein d’ une table, il n’existe nullement dans l’autre, vous comprenez ?

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

Et on fait comment aussi .

Eh bien, en faisant bien gaffe de tirer les champs en table principale vers l’autre et pas l’inverse, vous pourrez alors creer 1 nouveau client dans Rel3_T_Client sans pour autant qu’il y ait de relation avec l’autre table Rel3_T_Telecom. C’est d’ailleurs de que j’ai fera.

MAIS 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 aucun 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 aussi table, ca facilite les trucs. d’autant que vous pourrez creer des requetes qui affichent tels ou tels champs.

Exemple 4 : la relation sans integrite referentielle

On peut reconnai®tre d’une maniere generale que “normalement”, l’ensemble des tables de la base de donnees paraissent reliees “1 a quelques”, les unes avec les autres. Les relations 1 a 1 seront rares.

Les relations sans integrite referentielle ont la possibilite de se faire n’importe De quelle fai§on : vous pourrez tirez n’importe quel champ de chaque table, aussi si leur type de donnees est divers, de l’instant que vous ne cochez jamais “integrite referentielle”. Quand vous creez une liste deroulante basee via une nouvelle table, a Notre fin de l’assistant, il vous devoile “Voulez-vous que nos 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 nos unes a toutes les autres sans integrite, vous pourrez etre presque certain qu’elle a ete creee via un quidam 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 l’acheteur, ainsi, sa ville de naissance qui est une liste deroulante qui va puiser les donnees dans Rel4_T_Ville :

Bon nombre de gens proviennent de la vilel Suisse, mais souvent, il y en a votre qui vient de la metropole francaise, voire italienne ou enfin de n’importe quelle metropole du monde.