Bonsoir François,
L’usage chez les concepteurs est de modéliser la finalité. Comme vous dites, en toute rigueur la règle est la suivante :
Une personne peut avoir plusieurs adresses ;
Une personne doit avoir une adresse principale.
Ce qu’en passant je formulerais (je pinaille) :
Une personne doit avoir une adresse principale ;
Une personne peut en plus avoir plusieurs adresses secondaires.
Peu importe, comme vous le faites observer, cette règle est utopique puisqu’en conflit avec la réalité, à savoir qu’une personne n’est pas obligée de fournir d’adresse tant qu’il n’y a pas de livraison pour elle.
La finalité devient :
Si on doit effectuer une livraison pour une personne, alors celle-ci doit avoir une adresse principale ;
En plus de son adresse principale, une personne peut avoir des adresses secondaires.
Si l’utilisateur y voit un inconvénient c’est qu’il n’a pas tout dit quant aux règles de gestion...
La table ACTOR_ADDRESS existe car ADDRESS est utile à MAGASINS aussi, donc je ne peut pas faire migrer id_actor dans ADDRESS.
Dommage, on aurait pu voir les choses ainsi :
Lors de la saisie de l’adresse de livraison pour un client donné, au stade SQL on va chercher cette adresse dans la table ADRESSE_PPALE : si elle ne s’y trouve pas, le programme ne pourra que s’en rendre compte.
Et l’on aurait pu continuer : pour renforcer les contrôles, établir une association entre l’adresse et la livraison :
Avec vraisemblablement à la clé une contrainte de chemin à résoudre, la livraison pouvant faire référence à la personne concernée par une autre voie : ça se résout par trigger ou par identification relative propageant l’attribut PersonneId jusqu’à LIVRAISON via cette voie.
Mais bon, puisqu’on ne peut pas modifier la structure de la table ADRESSE, la mise en œuvre de la table ACTOR_ADDRESS s’impose, comme vous l’avez fait, avec au passage la remarque suivante : selon votre MCD une adresse fait référence à une seule personne alors que d’après la clé de la table ACTOR_ADDRESS de votre diagramme MWB (en conflit du reste avec les cardinalités), ça peut être à plusieurs personnes : ci-dessous je par du principe que c’est le MCD qui prime.
Votre diagramme montre qu’il y a une contrainte de chemin à résoudre. En effet, supposons que dans la table ACTOR_ADDRESS on ait la paire <adr1, act1> où la valeur <adr1> fait référence à la valeur <adr1> de la table ADDRESS et la valeur <act1> fait référence à la valeur <act1> de la table ACTOR, so far so good, mais l’affaire se corse (chef-lieu Ajaccio) ensuite, car rien n’empêche que dans la table ACTOR on ait la paire <act1, adr2>, aïe !
Pour éviter cela, on peut spécialiser ACTOR_ADDRESS en mettant en œuvre une table ADRESSE_PPALE pour les adresses principales :
Et dans l’esprit de ma remarque faite à propos des livraisons, des fois que ça serve à un moment donné, on peut garder sous le coude la mise œuvre d’une association avec LIVRAISON :
J'espère avoir compris votre problème, en tout cas je n'ai guère d'autres solutions à sortir de mon chapeau...
Partager