Discussion :

[MacFly58]

Alors que je m'exprimais sur une relation 1,1 --- 1,1 d'un MCD de Idriss, CinePhil a éveillé ma curiosité.


Citation de CinePhil :

Sur le plan de la modélisation, si on a ceci :
A -1,1----Associer----1,1- B

Ça veut dire qu'une des entités est un "multi-attribut" de l'autre. Un seul A déterminant un seul B et vice versa, les deux entités devraient être fusionnées.

Mais sur le plan sémantique ça peut aussi être quelque peu incohérent de fusionner les deux entités, même si les règles de gestion imposent ces couples de cardinalités.

"Un directeur dirige une seule agence et une agence n'a qu'un directeur."

Directeur -1,1----Diriger----1,1- Agence

Il n'est sémantiquement pas logique de fusionner l'agence et son directeur. Il sera plus logique, dans le MLD puis dans les tables, de mettre l'identifiant du directeur en clé étrangère dans l'agence.

Pour ma part, cela ne me gène pas du tout de fusionner une agence et son directeur. Le nom d'un directeur me semble être un attribut d'une agence dans le cas exposé.

Auriez-vous en tête un autre cas qui mettrait en évidence votre raisonnement svp ?
Par ailleurs le mot "sémantiquement" me semble obscure. Voulez-vous par là évoquer le fond du problème plutôt que sa forme ?

[ok.Idriss]

Re

Personnellement, par rapport au MCD en question, je ne trouve pas logique de fusionner une entité facture et intervention (pareil pour un directeur et une agence) : il s'agit de deux choses bien distinctes même si d'un point de vue fonctionnel cela marcherai tout aussi bien. Après je n'ai pas dit que la fusion était interdite mais qu'elle n'était pas obligatoire (en gros chacun fait comme il préfère ou comme on lui impose) ...

J'ai appris de mon côté que le fait d'avoir des cardinalités 1,1 (ou 0,1) de part et d'autre d'une association était possible, qu'il suffisait ensuite de mettre la clef étrangère dans une seule des deux tables par la suite et que généralement, on choisi de mettre cette clef étrangère du côté la table dont l'entité, qui lui correspond, a le plus d'association avec les autres (même si cela aussi n'est pas obligatoire, on peut tout aussi bien la mettre de l'autre côté, il s'agit encore là d'une question de logique) ...

Pour ma part, cela ne me gène pas du tout de fusionner une agence et son directeur. Le nom d'un directeur me semble être un attribut d'une agence dans le cas exposé.

Si tu n'as que le nom ok mais si tu doit avoir toutes les propriétés d'une agence (id, nom, adresse, tel, etc) et toutes celles du directeur (matricule, nom, prenom, adresse, tel, email, date de naissance, etc) c'est autre chose ...

Auriez-vous en tête un autre cas qui mettrait en évidence votre raisonnement svp ?
Par ailleurs le mot "sémantiquement" me semble obscure. Voulez-vous par là évoquer le fond du problème plutôt que sa forme ?

Le fond du problème c'est que même si ça peut paraître plus optimisé de faire une chose dans un projet quelconque il faut que cela reste cohérent pour une plus grande compréhension de tous. Par exemple, il n'est pas cohérent d'avoir une seule et même table pour un directeur et une agence. Si une base de donnée comporte une nombre important de tables (plusieurs centaines par exemple) comme il arrive souvent en entreprise, il devient difficile pour un des mainteneurs (on n'est pas toujours tout seul à bosser) de retrouver certaines données si elles sont mal organisée => On perd plus de temps qu'on en gagne.

Pour rester cohérent et s'y retrouver même le simple nom des tables reste important et suit parfois un formalisme préconisé par l'entreprise en question, si on commence à fusionner des tables qui correspondent à des choses bien distinctes ...

Cordialement,
Idriss

[CinePhil]

Pour ma part, cela ne me gène pas du tout de fusionner une agence et son directeur. Le nom d'un directeur me semble être un attribut d'une agence dans le cas exposé.

Comme l'a très bien exprimé ok.Idriss, s'il n'y a que le nom, on le met en attribut de l'agence. S'il y a les informations complètes du directeur, on se retrouve clairement dans un cas de "multi-attribut", comme je l'avais appelé dans mon message.

Ça veut dire qu'une des entités est un "multi-attribut" de l'autre.

de plus, cette notion de Directeur peut être une entité fille qui hérite d'une entité Personne :
Directeur -(1,1)----Etre----0,1- Personne
|---------------1,1----Diriger----1,1- Agence

Auriez-vous en tête un autre cas qui mettrait en évidence votre raisonnement svp ?

On pourrait vouloir enregistrer des prototypes de véhicules à moteur avec le détail des caractéristiques du moteur.
Vehicule -1,1----Avoir----1,1- Moteur

Dans un club équestre, chaque cavalier pourrait se voir attribué un seul cheval :
Cheval -1,1----Attribuer----1,1- Cavalier

En cherchant un peu, on pourrait trouver sans doute moult autres exemples.

Par ailleurs le mot "sémantiquement" me semble obscur. Voulez-vous par là évoquer le fond du problème plutôt que sa forme ?

Sémantiquement : relatif à la sémantique, c'est à dire au sens. Il est clair qu'un directeur et une agence sont sémantiquement deux entités différentes, tout comme un véhicule et son moteur ou un cheval et son cavalier.

C'est donc pour ça que dans mon message je commençais par aborder le côté théorique de la conception :
A -1,1----Asssocier----1,1- B ==> Fusion de A et de B.
Mais si A est sémantiquement très différent de B, il peu être préférable de bien séparer A et B malgré les cardinalités.

Être confronté à ces cardinalités peut aussi conduire à se poser des questions sur la justesse des règles de gestion.
Ne serait-il pas plus pertinent de voir le scénario suivant :
1) Le groupe X souhaite lance le projet de créer une agence à Bordeaux.
2) On crée l'agence dans la BDD.
3) On nomme son directeur pour l'ouverture de l'agence.
4) On enregistre M. Dupont en tant que directeur de l'agence.

Dès lors, le MCD est plutôt le suivant :
Agence -0,1----Avoir----1,1- Directeur

Et cette fois la clé étrangère se trouve dans la table des directeurs et pas dans celle des agences.

[MacFly58]

C'est limpide, y compris pour les relations 0,1-1,1

Merci

[hmimoud]

Bonjour,

Désolé de revenir à ce sujet qui a déjà été marque résolu, mais en cherchant sur le forum une solution à mon problème d'une relation 1,1 --- 1,1 d'un MCD, j'ai trouvé cette discussion qui m'a levée une autre ambiguïté.

Dans l'exemple du directeur et de l'agence, si on adopte la solution de mettre par exemple dans le MLD l'identifiant du directeur en clé étrangère dans l'agence, il y aura un problème puisque cela sera traduit comme si le directeur dirige plusieurs agences, et du coup au niveau pratique, lorsque qu'un utilisateur tentera d’insérer plusieurs agences pour un même directeur cela sera accepté faute d'absence de contrainte pour gérer cela, ce qui n’obéit pas aux règles de gestion désirées.

Je souhaite savoir si la suggestion suivante que j'ai jugé sine qua non pour résoudre ce problème, l'est vraiment :

En plus de mettre l'identifiant du directeur en clé étrangère dans l'agence, la clé étrangère doit être défini comme unique !

Merci

[Richard_35]

Bonjour Hmimoud,

En plus de mettre l'identifiant du directeur en clé étrangère dans l'agence, la clé étrangère doit être défini comme unique !

==> pour moi, c'est OK (en fait, créer un index unique sur cette clé étrangère). De mon point de vue, cela équivaut à une contrainte "merisienne".

Reste à savoir si ça passera au "rasoir" de Fsmrel...

[Kropernic]

Si un directeur dirige une seule agence et qu'une agence est dirigée par un directeur, alors dans le MLD, la colonne directeur est une clef alternative de la table agence et se doit donc d'avoir sa contrainte d'unicité (au moyen d'un index unique en sql server par exemple).