Relation avec intégrité référentielle

En gros (fonction principale mais on reviendra plus en détail là-dessus) par un double clic sur une relation dans la vue des relations vous aurez la boîte de dialogue suivante:

1. Activer l'intégrité référentielle (Enforce Referentiel Integrity):

Si vous effacez un enregistrement, ceux qui y font référence seront bloqués mais le choix est quand même possible (sous-options). Vous n'avez aussi plus la possibilité d'avoir dans la table contenant la clé étrangère de la relation, d'éléments qui ne correspondent pas au contenu de la table contenant la primaire de la relation (d'où le terme "intégrité").

2. Mise à jour en cascade:

Cette option est disponible seulement si vous avez activé l'intégrité référentielle. Elle est utile aux personnes qui auraient fait l'erreur de mettre leur clé primaire ailleurs que sur un champ ID (numéro auto). Nous n'en ferons donc pas usage dans ce support.

Cette option est par contre redondante (ce qui ne signifie pas qu'il ne faut quand même pas l'activer) si vos clés étrangères sont basées sur des listes à choix.

3. Suppression en cascade:

A pour fonction de supprimer tous les enregistrements reliés à l'objet supprimé (vous perdez ainsi en quelque sorte l'historique)

Remarques:

R1. Il n'est pas nécessaire que des champs reliés aient un même nom. C'est le contenu qui fait foi.

R2. Les tables sources de la relation doivent avoir une clé primaire avec un index unique.

R3. La relation doit se baser sur le champ de la clé primaire (respectivement de l'index unique).

Lisez également le contenu de votre support et l'aide électronique intégrée à MS Access au sujet des relations pour avoir un complément d'informations.

Evidemment, habituellement il n'y a pas (du moins il ne devrait pas avoir) de données dans les tables lorsque l'on crée les relations !!!

Entrons maintenant un peu plus dans les détails au niveau des relations (partie théorique un peu barbante mais nécessaire).

Dans un premier temps, voici un rappel des conditions à satisfaire pour créer des relations:

1. La clé primaire est le champ de la table qui sert d'identifiant à un enregistrement. Il s'agit d'un champ indexé sans doublon.

2. La clé étrangère est le champ de la table qui servira à matérialiser la relation avec la clé primaire. Il doit être de même taille et de même type de données que la clé

primaire à laquelle il est lié. Il est utile de lui donner le même nom que celui porté par la clé primaire correspondante.

3. Pour créer une relation de un à un, il faut impérativement lier des champs ayant leur propriété "indexé" à "oui-sans doublon".

4. Pour créer une relation de un à plusieurs, il suffit de lier les champs entre eux.

D'habitude, la relation se fait d'une clé primaire vers une clé étrangère.

5. Pour créer une relation de plusieurs-à-plusieurs il faut créer une troisième table (dont le besoin et le contenu se définissent tout à fait naturellement), appelée une "table de jonction" (au fait c'est une table normale mais bon…), et lui ajouter des champs, clés étrangères, possédant les mêmes définitions que les champs clé primaire de chacune des deux autres tables.

6. Nous créons des clés primaires combinées dans des tables de transitions ce qui assure par exemple qu'un couple de champs soit unique.

Créez maintenant les relations suivantes entre les tables que vous avez pour l'instant par rapport au schéma ci-dessous (votre formateur vous expliquera les tenants et aboutissants dans les détails).

Attention, des erreurs ont exprès été glissées dans ce schéma (erreurs de nommage des champs, d'intégrité, de position de clé primaire, d'index, etc.) et… n'oubliez pas que vous n'avez pas encore toutes relativement à la finalité du cours donc ne paniquez pas si vous n'avez quelque chose d'identique à ce qui est montré dans la figure !!!

Figure 6 Schéma (simple) de la BDD

Remarques:

R1. D'une formation à l'autre, ce schéma peut changer un peu (votre formateur aime bien parfois varier ses cours…). Par exemple avec de bons participants en deux jours nous arrivons à un schéma relationnel comme celui de la page suivante:

R2. Certaines erreurs ont aussi été exprès introduites dans le schéma ci-dessus afin que les participants mettent en application leurs connaissances du cours initiation.

Pour vous exercer, vous pouvez tenter de répondre à ces questions (elles sont traitées dans les détails lors du cours):

1. Pourquoi la clé primaire de la table tblArticles n'a pas été mise sur le champ idArticle?

2. Où faudrait-il activer l'intégrité référentielle dans ce schéma ?

3. La mise-à-jour en cascade a-t-elle alors un sens pour les tables reliées cette clé primaire strCodeArticle?

4. Et la mise-à-jour en cascade pour les autres relations ?

5. Quand faut-il activer la suppression en cascades des champs ?

6. Comment pouvons-nous rendre un champ unique sans utiliser de clé primaire (VBA?, index?, etc.)???

7. Comment rendre le prénom et le nom d'un individu dans la table tblClients unique?

8. Faut-il mettre un index combiné dans la table tblLanguesEmp ou pas ? Pourquoi ? Ce schéma est extrêmement simple et il est aussi extrêmement rare d'avoir quelque chose d'aussi petit et simple dans MS Access, une bonne moyenne (nivelée vers le bas) serait plutôt du type suivant (voir page suivante):

Clé primaire simple ou combinée ?

Figure 7 Exemple de BDD (taille standard) Revenons à notre exemple de départ et détaillons-le:

Précisions sur l'intégrité référentielle:

L'intégrité référentielle est un mécanisme de vérification qui s'assure que chaque clé étrangère est en correspondance avec sa clé primaire. Non seulement il vérifie l'intégrité des données écrites dans la clé étrangère, mais encore, il maintient cette intégrité en cas de modification ou de suppression de la clé primaire.

En conséquence, lorsque l'intégrité référentielle est appliquée sur une relation, on ne peut pas trouver, dans la clé étrangère, de données autres que celles contenues dans la clé primaire correspondante.

Dès lors, bien que toutes les données figurant dans la table contenant la clé étrangère soient en relations avec les données de la table contenant la clé primaire, l'inverse n'est pas exact.

Si la "Mise à jour en cascade" et la "Suppression en cascade" ne sont pas actives, il n'est pas donné à l'utilisateur la possibilité de supprimer ou de mettre à jour AUTOMATIQUEMENT le champ de la table d'origine étant déjà en relation avec des champs de la table étrangère. Il sera toujours possible de le faire par automatisme ou programmation.

Testez, comme exercice:

1. L'intégrité référentielle

2. L'intégrité référentielle avec la mise à jour en cascade

3. L'intégrité référentielle avec la suppression en cascade

Au hasard, un des participants ira au poste du formateur pour démontrer le bon fonctionnement de ces outils.