Association n-aire, date et cardinalité

**master_och** · 08/02/2009, 17h14

Bonjour

J'ai du mal à comprendre les association n-aires, en fait voilà les questions dont je trouve pas la réponse:

- Quelle est la signification exacte des cardinalités présents dans les pattes d'une association ternaire?

- Peut-on avoir dans l'une des n pattes une cardinalité maximale égale à 1?

- Quelles sont les conditions qui doivent être vérifiées pour pouvoir juger si une association n-aire est correctement utilisé ou non?

- J'ai lu dans plusieurs cours que les associations n-aire peuvent être remplacées par plusieurs associations binaire, laquelle des 2 solutions convient le mieu et pourquoi?

En fait les notions que j'ai reçue sur les associations n-aire, dans des cours que j'ai télécharger sur internet, sont très floux et certaines corrections d'exemples me paraissent contradctoires ... je compte sur vos réponses alors pour m'éclaircir la dessus.

voilà merci d'avance

bon pour entrer directement dans la difficulté voici l'exemple dans lequel je bloque dans l'image jointe.

en fait dans un exemple presque identique à celui ci dans un cours, une telle solution a été refusé pour la raison suivante:

une telle modélisation accepte le fait qu'à une date donnée, une vache peut être inséminée par plusieur taureaux alors qu'en réalité (cad dans la ferme pour laquelle je modelise une base de donnée) c'est pas possible.

Ma solution est-elle correcte? sinon pouvez vous m'aider à trouver une solution convenable?

**SQLpro** · 09/02/2009, 09h23

- Quelle est la signification exacte des cardinalités présents dans les pattes d'une association ternaire?

Elles peuvent être 0,n ou 1,n sans importance car la clef e la table étant l'ensemble des FK se cera toujours l'équivalent d'un 1:n

- Peut-on avoir dans l'une des n pattes une cardinalité maximale égale à 1?

Non, cela n'a pas de sens. Si vous avez une ternaire avec
A 0,1 vers B et C
B 0,n vers A et C
C 0,n vers A et B
La question pour A est : du fait de la cardinalité maximale 1, A est-elle liée à B ou (exlusif) à C ?

- Quelles sont les conditions qui doivent être vérifiées pour pouvoir juger si une association n-aire est correctement utilisé ou non?

C'est de la sémantique dont dépendant des DF

- J'ai lu dans plusieurs cours que les associations n-aire peuvent être remplacées par plusieurs associations binaire, laquelle des 2 solutions convient le mieu et pourquoi?

Vrai, mais cela introduit alors un cycle, est c'est généralement moins facile à gérer !

A +

**CinePhil** · 09/02/2009, 13h24

Envoyé par master_och

bon pour entrer directement dans la difficulté voici l'exemple dans lequel je bloque dans l'image jointe.

en fait dans un exemple presque identique à celui ci dans un cours, une telle solution a été refusé pour la raison suivante:

une telle modélisation accepte le fait qu'à une date donnée, une vache peut être inséminée par plusieur taureaux alors qu'en réalité (cad dans la ferme pour laquelle je modelise une base de donnée) c'est pas possible.

Ma solution est-elle correcte? sinon pouvez vous m'aider à trouver une solution convenable?

L'entité Date est-elle vraiment utile ici ?

Règles de gestion :
1) Un taureau peut inséminer plusieurs vaches à une date donnée
2) Une vache ne peut-être inséminée au plus que par un taureau à une date donnée
3) Un taureau peut inséminer la même vache à des dates différentes
4) Une vache peut être inséminée par le même taureau à des dates différentes

MCD :
Taureau -0,n----Inséminer à telle date----0,n- Vache

Tables :
Taureaux (T_Id, T_Num_Nat, T_DateNaissance...)
Vaches (V_id, V_Num_Nat, V_DateNaissance...)
Inseminations (I_Id_Taureau, I_Id_Vache, I_DateInsemination)

Pas besoin de ternaire ici.
Dans la pratique, on a rarement besoin d'une entité 'date'. Il est plus facile de considérer que c'est une donnée portée par des associations ou des entités.

**master_och** · 10/02/2009, 06h06

Bonjour

Tout Dabord merci bien pour votre aide, qui m'est très précieux

Sinon à propos de l'utilité de l'entité date, l'exemple que j'ai mis n'est qu'une très petite partie de mon MCD, qui a besoin d'utiliser la date dans 7 "endroits" (entité ou association) différents, c'est pour ca qu'on m'a dit que la répétition de l'attribut date plusieurs fois pourrait être considéré comme une sorte de redondance, et on m'a fortement recommandé de créer une entité date.

Je tiens à noter que toutes les associations binaire reliées à l'entité date ont pour cardinalité maximale dans l'une des pattes (autre que celle reliée à la date) égale à 1, cad que l'entité date a toujours une clé étrangère.

Pour les associations ternaires ils sont similaires à l'exemple que j'ai mis, ca peut se transformer en association binaire et je peux utiliser la date comme étant attribut dans l'association obtenue.

Je suis donc entre 2 solutions: supprimer l'entité date et la transformer en attribut à chaque fois que j'en ai besoin, cela rendra mon MCD plus simple et plus facile à lire, mais en contre partie y aura de la redondance.L'autre solution sera de garder l'entité date, cela rendra le schema beaucoup plus compliqué, mais sans redondance.
Laquelle des deux solutions me recommandez-vous?

**CinePhil** · 10/02/2009, 09h33

mon MCD, qui a besoin d'utiliser la date dans 7 "endroits" (entité ou association) différents, c'est pour ca qu'on m'a dit que la répétition de l'attribut date plusieurs fois pourrait être considéré comme une sorte de redondance, et on m'a fortement recommandé de créer une entité date.

Ce qui serait redondant, ce serait de répéter une date d'insémination dans plusieurs tables, soit disant pour faciliter l'écriture des requêtes.
Mais une date de naissance, d'insémination, d'achat, de vente, d'abattage sont des concepts différents, même s'ils ce sont tous des dates. Il n'y a donc pas redondance.

Je suis donc entre 2 solutions: supprimer l'entité date et la transformer en attribut à chaque fois que j'en ai besoin, cela rendra mon MCD plus simple et plus facile à lire, mais en contre partie y aura de la redondance.L'autre solution sera de garder l'entité date, cela rendra le schema beaucoup plus compliqué, mais sans redondance.
Laquelle des deux solutions me recommandez-vous?

Ben moi je ne mets jamais d'entité Date. Je n'en ai jamais trouvé l'utilité.

**master_och** · 10/02/2009, 09h54

Tout à fait logique, merci bien pour ton soutient, je vais suivre ton conseil

**SQLpro** · 10/02/2009, 11h12

Ben moi je ne mets jamais d'entité Date. Je n'en ai jamais trouvé l'utilité.

Eh ben ça c'est une erreur !

A +

**master_och** · 10/02/2009, 11h57

En fait, dans mon MCD, l'entité date me parait très utile, et dans d'autres endroits je trouve qu'il est suffisant et beaucoup plus simple de l'utiliser comme attribut.

ma question est donc, est-il convenale d'utiliser dans certains entités un attribut date, alors qu'on a déjà définit une entité date?

**CinePhil** · 10/02/2009, 14h52

Envoyé par SQLpro

Eh ben ça c'est une erreur !

A +

Ce serait bien que tu développes cette erreur ! Je ne demande qu'à apprendre !

**fsmrel** · 12/02/2009, 00h44

Envoyé par CinePhil

Ben moi je ne mets jamais d'entité Date. Je n'en ai jamais trouvé l'utilité.

Envoyé par SQLpro

Eh ben ça c'est une erreur !

Si je puis m’immiscer : tout dépend du mode de représentation graphique utilisé.

Si l’on utilise Merise et si la date participe à l’identification d’une association-type, on est conduit à mettre en œuvre une entité-type DATE, puisque l’identifiant de l’association-type est implicitement constitué des identifiants des entités-types connectées.

En conséquence, à partir du MCD qui suit, et à condition de pouvoir demander que la génération d’une table DATE ne soit pas effectuée (Ce qui est le cas, par exemple, avec Power AMC) :

On produit alors le MLD suivant :

Mais si l’AGL orienté Merise ne permet pas d’éviter la génération d’une table DATE, vous ferez comme on faisait à la fin des années quatre-vingts (c'est-à-dire quand l’intégrité référentielle a enfin était prise en compte (par DB2), à savoir en 1988) : au niveau du MLD, supprimer manuellement chaque clé étrangère faisant référence à la table DATE, pour enfin pouvoir supprimer celle-ci. A l’époque, je dus le faire, des nuits durant, à la nausée...

Maintenant, si au lieu du mode de représentation graphique de Merise, on utilise celui de IEF (Information Engineering Facility de James Martin) ou équivalent (mode Entité/Relation de Power AMC par exemple, comme ci-dessous) :

Alors on produit exactement le même MLD.

Bien sûr, dans tout ce qui précède, j’ai considéré que la date n’est jamais qu’un type et non pas un objet de gestion en tant que tel.

**CinePhil** · 12/02/2009, 10h23

Serait-il faut de faire un MCD Merise de la sorte (désolé, je n'ai pas de modeleur au point sous la main) ?

EntiteA
A_Id
...
|
0,n
|
|
Associer
DateAB
|
|
0,n
|
EntiteB
B_Id
...

Ce qui donnerait bien également :
EntiteA(A_Id, ...)
EntitéB(B_Id, ...)
Associer(A_Id, B_ID, DateAB)

**master_och** · 12/02/2009, 12h11

Si l’on utilise Merise et si la date participe à l’identification d’une association-type, on est conduit à mettre en œuvre une entité-type DATE, puisque l’identifiant de l’association-type est implicitement constitué des identifiants des entités-types connectées.

Serait-il faut de faire un MCD Merise de la sorte (désolé, je n'ai pas de modeleur au point sous la main) ?

EntiteA
A_Id
...
|
0,n
|
|
Associer
DateAB
|
|
0,n
|
EntiteB
B_Id
...

Ce qui donnerait bien également :
EntiteA(A_Id, ...)
EntitéB(B_Id, ...)
Associer(A_Id, B_ID, DateAB)

logiquement je croix que c'est faut, puisque en utilisant une association binaire, deux occurences des entité A et B n'auront le droit d'être associées qu'une seule fois, et par suite un couple d'occurences (A,B) n'aura pas la possibilité de se répéter dans plusieurs dates.

cad en prenant l'exemple que j'ai mis au début, si on fait une association binaire entre vache et taureau et on met la date comme attribut dans cet association, alors une vache n'aura la possibilité d'etre insiminé par un taureau qu'une seule fois, dans une et une seule date.

**master_och** · 12/02/2009, 12h17

J'ai encore une petite question: dans mon MCD il m'est necessaire d'utiliser l'entité date dans certains endroits, mais dans d'autres endroits il m'est suffisant d'utiliser la date comme attribut, est-il convenable de mettre la date comme attribut, alors qu'on a déjà créer une entité date ??

**fsmrel** · 12/02/2009, 12h38

Envoyé par CinePhil

Serait-il faut de faire un MCD Merise de la sorte [...]

Oui. Comme je l’ai écrit dans mon précédent message, l’identifiant d’une association-type merisienne est implicitement constitué des identifiants des entités-types connectées, jamais explicitement comme vous le faites. Autrement dit, si vous faites figurer DateAB en tant que propriété de l’association-type, vous ne pouvez pas faire participer cette propriété à l’identifiant de l’association-type : graphiquement, souligner DateAB est interdit.

On aurait dû faire évoluer Merise pour permettre que des attributs d’une association-type participent à l’identification de celle-ci, mais les dogmes sont tout puissants...

A défaut, on peut toujours en passer par des notations du type IEF, où l’association-type est remplacée par une entité-type associative, un rond par un carond (carré jouant le rôle de rond). J’ai illustré cela dans mon précédent message.
Voyez aussi la discussion avec flippaeti (association-type Distribuer).

**fsmrel** · 12/02/2009, 13h33

Envoyé par master_och

est-il convenable de mettre la date comme attribut, alors qu'on a déjà créer une entité date ??

C’est non seulement tout à fait convenable, mais tout à fait recommandé, au nom de l’indépendance des concepts. Imaginez que vous définissiez une entité-type TEXTE, est-ce pour autant qu’il faudrait tirer un lien entre cette entité-type et tous les attributs de type TEXTE ?

L’entité-type DATE ne doit son existence qu’à un dogme merisien selon lequel, je le répète, l’identifiant d’une association-type est implicitement constitué des identifiants des entités-types connectées. Si donc un attribut de type Date doit participer à l’identifiant d’une telle association-type, il faudra en passer par les fourches caudines merisiennes et mettre en œuvre une telle entité-type.

Je reprends ce que j’ai déjà dit par ailleurs : DATE est un type banal et vous pouvez définir des attributs de ce type autant qu’il vous plaira : date de saillie, date d’embauche, date de démission, date de paye, tout en faisant abstraction d’une prétendue entité-type DATE qui a fait souffrir des générations de concepteurs respectueux du dogme et que vous ajouterez à votre représentation graphique seulement contraint et forcé (mais qui devra disparaître au niveau du MLD, puisque la table DATE n’y sera qu’une contrainte devenue non seulement inutile mais pénalisante, faisant double emploi, donc devant passer au fil du rasoir d’Ockham).

**CinePhil** · 12/02/2009, 14h01

Cette intéressante discussion me fait penser que j'ai dans ma base de données le cas inverse :

Règle de gestion :
"Un utilisateur peut participer à un à plusieurs projets avec un certain statut."

MCD :
Utilisateur -0,n----Participer----0,n- Projet
Statut -0,n-----------|

Les tables qui devraient en découler :
Utilisateur(U_Id, ...)
Projet(P_Id, ...)
Statut(S_Id, ...)
Participer(U_Id, P_Id, S_Id)

Sauf qu'un utilisateur ne peut avoir qu'un statut dans un projet. L'unicité doit donc porter sur le couple (Utilisateur, Projet) et non pas sur le triplet (Utilisateur, Projet, Statut).

J'ai donc mis en clé primaire le couple et S_id n'est qu'une simple clé étrangère.

Est-ce faux ?

Aurais-je dû laisser le triplet en clé primaire et ajouter une contrainte d'unicité sur le couple ?

**master_och** · 12/02/2009, 15h10

J'ai encore une petite question: dans mon MCD il m'est necessaire d'utiliser l'entité date dans certains endroits, mais dans d'autres endroits il m'est suffisant d'utiliser la date comme attribut, est-il convenable de mettre la date comme attribut, alors qu'on a déjà créer une entité date ??

Ma question n'est-elle pas claire? j'ai besoin d'une réponse pour avancer ...

**CinePhil** · 12/02/2009, 15h22

Euh... la réponse est donnée par fsmrel juste un peu plus haut !

**fsmrel** · 12/02/2009, 15h44

Envoyé par CinePhil

[...]un utilisateur ne peut avoir qu'un statut dans un projet. L'unicité doit donc porter sur le couple (Utilisateur, Projet) et non pas sur le triplet (Utilisateur, Projet, Statut).
J'ai donc mis en clé primaire le couple et S_id n'est qu'une simple clé étrangère.
Est-ce faux ?
Aurais-je dû laisser le triplet en clé primaire et ajouter une contrainte d'unicité sur le couple ?

Au vu de la règle de gestion, quand vous passez au niveau du MLD, la clé primaire de la table Participer doit effectivement être réduite au couple {U_Id, P_Id}, tandis que l’attribut S_Id ne fait l’objet que d’une simple clé étrangère. Vous n’avez donc pas faux.

Le problème est que vous avez dû intervenir manuellement pour corriger le tir, ce qui n’est pas ce qu’il y a de mieux quand votre MCD devient copieux et que se pose le problème de la maintenance au fil des ans : lors d’une nouvelle dérivation du MCD en MLD, votre successeur n’aura peut-être pas eu l’idée de consulter vos notes consignant vos interventions manuelles.

Alors, comment produire un MLD sans intervention manuelle ? Disons que c'est AGL dépendant. Par exemple, avec Power AMC, je produirai le MCD suivant (pour des raisons de commodité, je ramène les noms des objets à une lettre) :

D’où le MLD (correct) produit par l’outil :

Si vous utilisez Win’Design, pour produire le même MLD, vous pourrez définir une CIF (voyez la FAQ Merise, plus précisément la règle de gestion « pour une Matière, un Candidat ne compose que dans une Salle. ») :

Le trait en pointillés représente le pivot de la CIF, c'est-à-dire l’association-type impliquée dans cette affaire, pour laquelle on doit vérifier la dépendance fonctionnelle (DF) merisienne U x P → S, qui se traduira au niveau MLD par la DF relationnelle non triviale et irréductible {UId, PId} → {Sid}, prouvant que le couple {UId, PId} est clé candidate de la table R.