voici pourtant ce qu’on peut lire dans le livre : Access 2007 et VBA (paru en 03/2008)
par Bernard Minot, Jean-Michel Léry

dont l’extrait ci-dessous est disponible chez Google books à la page 42:

Les relations de 1 à 1
Nous supposons la présence de deux tables contenant des données relatives, par exemple, à vos contacts professionnels, d’une part, et à vos contacts personnels, d’autre part. La conjugaison de ces deux tables peut se décliner ainsi :
– Un contact professionnel correspond soit à zéro, soit à un et au plus un contact personnel (un partenaire commercial peut aussi être un ami !) ;
– Un contact personnel correspond soit à zéro, soit à un et au plus un contact personnel (même raison).
Nous sommes ici devant une relation de un à un. A priori, et pourvu que les uns et les autres n’aient pas de rôle particulier à jouer dans le système d’information à mettre en place, il n’y a aucune raison pour ne pas fusionner purement et simplement les deux fichiers. La seule opération à mettre en place avant ladite fusion consiste à créer une propriété particulière à la table qui fusionne les deux fichiers pour distinguer les « commerciaux » des « amis personnels ». Cet exemple peut être généralisé : les relations de un à un dans une base bien conçue n’existent pas(1).

(1). Seul cas de figure possible : si la table doit compter plus de 255 colonnes, il sera nécessaire de créer une table « fille ».

grrrmffff…

Prenons la classique table des commandes telle qu’on la trouve dans la base type « les comptoirs »:

Commande(idCommande, #idClient,# idEmploye, dateCommande, AlivrerAvant,DateEnvoi,…, PaysLivraison,…)

Chaque commande est passée par un client et est saisie par un employé.
Pour illustrer notre démonstration, supposons que les clients puissent annuler leurs commandes et qu’on souhaite conserver l’historique des commandes annulées.
Comme l’annulation ne doit pas entraîner la suppression physique de la ligne dans la table des commandes, c’est au plan conceptuel puis logique que nous devrons mettre en place notre solution d’annulation des commandes.

Nous pensons tout de suite à un champ de type « oui/non » (booléen) :

Commande(idCommande, #idClient,#idEmploye, dateCommande, AlivrerAvant,DateEnvoi,…, PaysLivraison,…, AnnulationCommande)

AnnulationCommande=Vrai si la commande est annulée.

Mais supposons que lorsqu’une commande est annulée, on veuille connaître certaines informations supplémentaires comme :
– La date d’annulation (type « date »)
– Le motif de l’annulation (type « texte» ou « mémo »)
– L’employé qui a validé l’annulation (identifiant de l’employé de type « numérique- entier long »)

La solution qui saute aux yeux:

Commande(idCommande, #idClient,# idEmploye, dateCommande, AlivrerAvant,DateEnvoi,…, PaysLivraison,…, AnnulationCommande, DateAnnulation, MotifAnnulation, #idEmployeAnnulation)

Si on suppose qu’une minorité de commandes sont annulées dans la pratique, nous nous retrouvons avec une palanquée de champs vides dans la table.
Or lorsque le volume de données devient significatif, une flopée de champs vides peut poser des problèmes de performances. Le fichier Access grossit car l’emplacement mémoire réservé pour le stockage des données numériques est effectif même si le contenu est vide.

Le développeur doit également prendre les précautions nécessaires afin d’éviter des saisies du type :

Dans le 1er cas, s’agit-il d’une commande annulée mais dont on ne connait pas les {DateAnnulation, MotifAnnulation, idEmployeAnnulation} ou bien d’une commande annulée par erreur ?
Dans le 2ème cas, que vient faire l’employé Davolio si la commande n’a pas été annulée ?

Notez également que si vos règles de gestion imposent que lors d’une annulation de commande, les attributs {DateAnnulation, MotifAnnulation, idEmployeAnnulation} doivent obligatoirement être renseignés, vous ne pouvez plus vous tourner vers une contrainte forte au niveau du moteur d’Access en mettant la propriété « Null interdit » à « Oui ».

Retour à la modélisation…

Retournons aux fondamentaux de la modélisation des données.
Mettons en œuvre dans notre modélisation le concept de commande annulée via l’entité-type « CommandeAnnulee » et écrivons les règles de gestion :
– Une commande peut être une commande annulée
– Une commande annulée est une commande

La traduction avec les cardinalités façon MERISE nous donne le bout de MCD :

Commande——0,1——-être——–1,1——-CommandeAnnulee

Puis au niveau logique :

CommandeAnnulee(#idCommande, DateAnnulation, MotifAnnulation, #idEmployeAnnulation)

Ce qui nous donne le schéma Access (dans la fenêtre des relations):

Commande-1———–1-CommandeAnnulee

Malgré l’apparente symétrie du schéma qui ne fait pas apparaître les cardinalités minimales du MCD, nous avons bien une table référencée (Commande) et une table référençante (CommandeAnnulee) avec la clé idCommande à la fois clé primaire et étrangère.

Commande:

CommandeAnnule:

Seule la commande n°10249 est annulée puisque le n° de commande est dupliqué dans la table CommandeAnnule.

Notez également que si vos règles de gestion imposent que lors d’une annulation de commande, les attributs {DateAnnulation, MotifAnnulation, idEmployeAnnulation} doivent obligatoirement être renseignées, vous pouvez assurément vous tourner vers une contrainte forte au niveau du moteur d’Access en mettant simplement la propriété « Null interdit » à « Oui » dans la table CommandeAnnule.

Voilà, les Null inutiles deviennent interdits de séjour dans les tables…