Création des relations entre les tables avec respect de l’intégrité

référentielle

II est important de définir un lien entre les différentes tables. L'intérêt est double :
Lors de l'ajout d'un enregistrement à une table reliée, il doit exister un enregistrement
correspondant dans la table contenant la clé primaire. Exemple : un livre ne peut se voir
attribuer un nom d'éditeur que si le nom de l'éditeur a été défini dans la table ÉDITEUR.
II est impossible de supprimer un enregistrement dans une table si des enregistrements
correspondants existent dans une table reliée. Exemple : on ne pourra supprimer le nom d'un
éditeur dans la table ÉDITEUR qu'après avoir supprimé tous les noms de l'éditeur dans la
table LIVRE.
 

Une boîte de dialogue apparaît :

Sélectionner les différentes
tables ajouter

 Si la liste des
champs n’apparaît
pas cliquer sur le
bouton

suite

Relations Page 1
  Sélectionner la clé
primaire et la faire glisser
sur la clé étrangère

 Cliquer sur Créer

 Sélectionner  Contrôler que les deux

« appliquer l’intégrité
champs sont bien les bons
référentielle »et
éventuellement les
autres options
Signification de la cardinalité 1 Signification de la cardinalité n
Un code livre dans la On peut trouver plusieurs fois
table LIVRES est unique la valeur n° matricule dans la
(clé primaire) table Emprunt (clé étrangère)
(clé primaire)

Les bases de données modernes sont relationnelles, c’est-à-dire qu’elles sont composées de tables mises en relations.
Chaque information élémentaire (le nom d’un client, le prix d’un produit, l’adresse postale d’un fournisseur
décomposée en 4 ou 5 parties…) n’est mémorisée qu’une seule fois, dans une des tables.
Les relations entre les tables permettent d’accéder aux informations élémentaires.
Par exemple, je ne vais pas mémoriser dans la table Commandes l’adresse du client qui passe commande : je
vaisnoter cette adresse une fois pour toutes dans la table Clients. Dans la table Commandes je ne vais mémoriser que
le code du client qui passe la commande, ce qui me donne accès à toutes les informations signalétiques sur le client,
sans avoir besoin de répéter l’information dans la table Commandes.
AVANTAGES :
Fiabilité : info stockée à un seul endroit = info toujours à jour.
Rapidité et facilité des MAJ, à un seul endroit : pas d’oubli, pas de perte de temps.
Saisie rapide : on ne tape qu’un identifiant : tout le reste est lu dans les tables de base.
Gain de place, sur les disques, puisque pas de répétition (avantage marginal vu la taille actuelle des disques…).
La rubrique principale de chaque table, celle qui donne accès à coup sûr à un et un seul enregistrement s’appelle
l’identifiant : sous Access, l’identifiant est en gras et s’appelle aussi clef primaire.
Une relation est créée en prévoyant dans une table une rubrique prévue pour contenir l’identifiant d’une autre
table. On appelle ces rubriques « sources de relations » des clefs externes (ou clefs étrangères).
Par exemple, dans la table Commandes, je mémorise le code du client dans une rubrique que je nomme [#Code client].
Le dièse # dans le nom des clefs étrangères permet de faciliter le repérage visuel de ces rubriques spéciales qui
donnent accès à plus d’information que les autres. Ce # n’est pas obligatoire, mais je vous le conseille fortement, par
souci de lisibilité.

Concrètement, pour créer une relation sous Access (voir figure de la page 1), on affiche la fenêtre des relations
(1), puis on glisse de l’identifiant à la clef étrangère (2) et on règle les contrôles d’intégrité référentielle

Relations Page 2
(3), c’est-à-dire les contrôles automatiques de cohérence de la base qu’on veut confier à Access.
Chaque relation a un côté « un » et un côté « plusieurs »(voir page 2) :
« pour un enregistrement du côté 1 (identifiant),
j’ai plusieurs enregistrements côté ∞ (clef étrangère) »
« pour un client, j’ai plusieurs commandes (au maximum) ».
« pour un enregistrement du côté ∞ (clef externe),
j’ai un et un seul enregistrement côté 1 (identifiant) »
« pour une commande, j’ai un seul client (au maximum) ».

Relations Page 3
Notez qu’on commence toujours la phrase par « pour UN… »
Une fois créée, la BDD va être modifiée par les opérateurs. Il y a 3 grands types d’interventions sur les tables : on
peut soit saisir de nouveaux enregistrements, soit supprimer des enregistrements, soit modifier des enregistrements
existants. À l’occasion de ces interventions, la BDD peut être rendue incohérente :
par exemple, si je laisse l’opérateur supprimer un client alors qu’il existe des commandes passées par ce client, je peux
me retrouver avec des commandes qui pointent vers un client inexistant : incohérence !
Access est capable de vérifier à ma place que ces incohérences n’apparaissent pas dans la base. C’est ce qu’il
appelle « appliquer l’intégrité référentielle ». Garder son intégrité, c’est rester entier, ne pas être endommagé…
Mais il ne faut pas tout interdire en bloc car ma base deviendrait très rigide et pénible à utiliser. Il faut réfléchir sur
chaque relation : on va interdire ce qui est impossible ou dangereux, mais on va autoriser ce qui est plausible et utile,
tout en procédant aux répercussions logiques nécessaires.

En cochant simplement « Appliquer l’IR », Access va

INTERDIRE :
Toute saisie incohérente du côté ∞ :
Par exemple, Access interdira la saisie d’une commande si
le code client tapé dans la commande n’existe pas dans la
table Clients.
Toute modification de l’identifiant côté 1 s’il
existe des enregistrements correspondants côté ∞.
Par exemple, si on veut changer le code du client Duracuire
(pour lui donner le code DURA123 à la place de 123, par
exemple), Access va interdire la transformation de ce code
s’il existe déjà une commande (ou plus !) au nom de ce
client.
Toute suppression d’enregistrement du côté 1
s’il existe des enregistrements correspondants du
Que l’un des champs est bien identifiant côté ∞.
Que le domaine de valeur des deux champs Par exemple, Access va interdire la suppression du client
est le même Duracuire s’il existe déjà des commandes au nom de ce
Texte  texte, client.
numérique entier  numérique entier Ce contrôle est simple mais contraignant : des opérations
…) utiles sont interdites, ce qui peut être parfois gênant. D’où
les possibilités suivantes :
Que la clé étrangère existe bien en clé
primaire
Un client ne peut pas passer commande s’il
n’existe pas dans la table client
En cochant, en plus, « Mettre à jour en cascade… »,
on aura les mêmes interdictions que ci-dessus, sauf sur le 2ème
point :
Toute modification de l’identifiant côté 1 est autorisée,
et s’il existe déjà des enregistrements correspondants
côté ∞, cette modification est automatiquement
répercutée sur les clefs externes (étrangères)
concernées !
Cela donne de la souplesse au contrôle de cohérence : Access
autorise au lieu d’interdire, mais il corrige automatiquement ce qui
doit être corrigé.
Par exemple, si on veut changer le code du client Duracuire (pour
lui donner le [Code client] DURA123 à la place de 123, par
exemple), Access va permettre la transformation de ce code, et s’il
existe déjà des commandes au nom de ce client (clef externe =
[#Code client] = 123), Access va automatiquement modifier la
valeur de ces clefs étrangères en y plaçant la nouvelle valeur
(DURA123).

Relations Page 4
 Dans les deux cas ci-contre, en cochant « Effacer en cascade… »,
Access va PERMETTRE :
Toute suppression d’enregistrement du côté 1, et s’il
existe des enregistrements correspondants du côté ∞,
Access va automatiquement supprimer tous ces
enregistrements liés !!!
Par exemple, Access va permettre la suppression du client
Duracuire, et s’il existe des commandes au nom de ce client, il
supprimera d’un coup toutes ces commandes (pas de retour en
arrière possible).
On sent que ce réglage est à la fois extraordinairement commode
et terriblement dangereux ! Là encore, on gagne en souplesse : on
n’interdit pas en bloc, on transforme ce qui doit l’être… Mais ici,
les transformations utiles à la cohérence peuvent être
dévastatrices…
ATTENTION ! DANGER ! COMMANDE TRÈS (TROP)
PUISSANTE !
BIEN RÉFLÉCHIR AU POUVOIR DE DESTRUCTION
QUE VOUS DONNEZ À L’OPÉRATEUR !
Pour simplifier, disons que, quand on crée une relation avec
Access :
on coche toujours les deux premiers choix (Appliquer l’IR
et MAJ en cascade),
mais on ne coche presque jamais la troisième (Effacer en
cascade), et toujours après une étude attentive des
risques encourus.
Remarque : dans ces quatre cas, Access va toujours interdire toute
saisie incohérente du côté ∞. Cette interdiction peut être très
gênante quand on veut qu’une clef étrangère puisse rester vide
quelque temps : normalement, le contrôle d’IR exige une parfaite
cohérence, c’est-à-dire l’existence côté 1 d’un enregistrement
correspondant à ce qui est saisi dans la clef externe côté ∞. Une
astuce consiste à créer un enregistrement « fantôme » côté 1 : par
exemple, en créant un fournisseur « Fournisseur inconnu », je me
donne le droit de ne pas taper le nom d’un fournisseur réel dans
tous les produits. La clef externe #Fournisseur dans la table
Produits peut alors être « logiquement vide » tout en étant
physiquement pleine…

Relations Page 5
Il peut être utile de savoir créer une relation réflexive, c'est-à-dire d’une table vers elle-même :

 

On crée d’abord une 2ème image de la table…

puis on relie l’identifiant 1de l’une à la clé étrangère de l’autre… Facile…

Dans une relation réflexive, il faut bien faire

attention à comprendre QUI représente
QUOI :

Ici, la table Employés représente les

subordonnés, puisque ce sont ses
enregistrements qui rendent des
comptes à quelqu’un,
•alors que Employés1 (le nom n’est
pas clair, tant pis) représente les
cadres puisque ses enregistrements
sont ceux qui sont cités dans la clé
étrangère des chefs…
• Du côté 1, les cadres, et du
côté , les subordonnés…
Logique…

Cette relation permet de demander simplement à Access un contrôle d’IR qui sera précieux : lors de la saisie du chef de chaque
salarié (clef étrangère #Rend compte à), Access va vérifier que le code saisi existe bien dans la table Employés ! Bien des
erreurs sont ainsi facilement évitées ! Par ailleurs, en cas de changement de matricule du cadre, tous les enregistrements
Relations
correspondant à ses subordonnés seront automatiquement mis à jour !… Très confortable ! Page 6