…ou réhabilitation de la relation de type « un à un » sous Access (modeste tentative):

Résumé: Autant le dire tout de suite. La relation de type « un à un » (-1——-1-) n’a pas la cote chez les développeurs Access et est souvent ignorée chez le débutant qui n’y verrait de toute façon qu’une source de complications supplémentaires dans ses développements.
Tantôt perçue comme une « erreur de conception », tout au plus un artifice permettant de franchir la barre des 255 champs pour une table Access (ce qui rend pourtant la conception suspecte), la relation « un à un » sera ignorée aux profits de traitements peut être allégés mais souvent aux dépends de l’intégrité, de la cohérence des données et des performances.

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…