Structure agrégation ou l'association d'association

Bonjour à tous,

Mon professeur et moi sommes en total désaccord sur un formalisme, j'ai beaucoup cherché sur Internet, mais je n'arrive pas à obtenir de réponse claire et précise. Je suis actuellement en Licence pro. Informatique, et je sais que l'on m'a appris que cela était possible en BTS Informatique de Gestion.

Ma question concerne la structure agrégation. Est-il oui ou non, autorisé de modéliser ceci selon MERISE 2.

http://www.fsmwarden.com/developpez_...gregation).jpg

Si quelqu'un d'expert dans le domaine pouvait me fournir une réponse tranchée, je lui en serais grandement reconnaissant. :roll:

Bonjour,

A dire vrai, Merise n’est pas mon domaine d’expertise, mais je peux quand même vous fournir quelques indications. Votre représentation est celle qui a été proposée il y a 34 ans par John Miles Smith et Diane C.P. Smith.

Mais que je sache, la représentation smithienne de l’agrégation n’a pas été retenue pour Merise 2. Le terme « agrégation » ne figure même pas dans l’ouvrage de référence : « Ingénierie des systèmes d’information : Merise deuxième génération » de Dominique Nanci et Bernard Espinasse. Ce terme ne figure pas non plus dans le compte-rendu de la journée AFCET du 15 novembre 1990 : « Le formalisme de données Merise, extension du pouvoir d'expression ».

On parle épisodiquement de l’agrégation dans les forums DVP. Voyez par exemple ce message à l’attention de bloups.

Voyez encore la discussion avec master_och, notamment les messages 27 et 34, ainsi que la discussion avec mathieu57, le message 7.

Mais en fait quel est ton problème ?
Au delà de la notation, que veux-tu exprimer ?

En UML on parle d'agrégation mais je ne sais pas si la sémantique est la même que celle dont tu parles.
Exemple : Une pièce dans une maison est une agrégation de murs = on considère que les murs sont des composants de la pièce = il y a un tout et ses parties

Citation:

---

Envoyé par ego

Mais en fait quel est ton problème ?
Au delà de la notation, que veux-tu exprimer ?

---

Le message à l’attention de bloups auquel j'ai renvoyé vever contient la réponse à votre question.

Rien à voir avec le concept d’agrégation d’UML qui n’est qu’un homonyme de celui qui a été défini par Smith & Smith (en 1977 je le rappelle).

Il s'agit d’un problème de représentation selon l’approche Entité/Association. Le but de la manœuvre, au moins chez Smith & Smith, ou chez Korth & Silberschatz (Database System Concepts, McGraw-Hill, 1986), est de traiter du problème de l’association d’associations. Je cite Korth :

« One limitation of the E-R model is that it is not possible to express relationships among relationships. »

Dans l'exemple de vever, la solution expéditive consiste évidemment à transformer l’association-type COUVRIR en entité-type identifiée relativement à REGION et PRODUIT :
http://www.fsmwarden.com/developpez_...egation)V2.jpg

Ou encore, en Merise, d'utiliser une CIF (l'identifiant de l'association-type COUVRIR est composé seulement de la paire {NoRegion, NoProduit}) :

http://www.fsmwarden.com/developpez_...gation)CIF.jpg

Ok je comprend
La solution "expéditive" me parait bien, non ?
En fait, si l'association représente un concept métier important, c'est que bien souvent (toujours ?) il y a une entité métier qui se cache derrière. Et il est donc préférable d'identifier clairement, en la nommant, cette entité.

Citation:

---

Envoyé par ego

Ok je comprend
La solution "expéditive" me parait bien, non ?

---

Oui, mais tout dépend de ce que vever veut montrer. S'il a pris la peine de mettre en œuvre une agrégation à la Smith & Smith, c’est qu’il a des motivations fortes, mais dont il ne nous a pas fait part. Par exemple, on pourrait conjecturer que COUVRIR représente un catalogue des produits par régions, indépendamment des représentants, lesquels seraient en conséquence à affecter à des catalogues prédéfinis. Mais une association avec une association façon Rochfeld, Moréjon, Negros a autant de pouvoir d’expression que cette agrégation. De la même façon, sans perte de pouvoir d’expression, au sens de Codd (fin des années soixante-dix), COUVRIR est une entité-type associative et peut être mise en relation avec tout type d’entité, forte, faible ou associative, orthogonalité des concepts oblige (en passant, Codd ne dessine pas, c’est un logicien, donc les histoires de carrés et de ronds le laissent parfaitement indifférent). En revanche, il faut reconnaître que la CIF est pour sa part moins porteuse de sens (elle n’est qu’une contrainte), même si au niveau tabulaire le résultat de la dérivation est strictement le même.

D'accord avec toi, tout dépend de ce que l'on veut vraiment mettre en avant.

Merci pour vos réponses.

Tout d'abord l'exemple que j'ai posté ne touche absolument pas mon problème, je l'ai trouvé sur internet de manière à schématiser la notion que je voulais exprimer. Je pense opter pour la première alternative proposée par fsmrel. Mais est-il autorisé, en MERISE toujours, d'avoir des entités sans attributs (COUVRIR) ?

Citation:

---

Envoyé par vever

Je pense opter pour la première alternative proposée par fsmrel. Mais est-il autorisé, en MERISE toujours, d'avoir des entités sans attributs (COUVRIR) ?

---

Ça n’est pas toujours autorisé (il faut au minimum un attribut identiant), mais concernant votre MCD, c'est tout bon car :

1) Nous sommes dans le cas de l’identification relative (cardinalités 1,1 mises entre parenthèses, notation Power AMC) et l’identifiant de l’entité-type faible COUVRIR existe donc, par convention il est hérité de l’identifiant des entités-types plus fortes REGION (attribut NoRegion) et PRODUIT (attribut NoProduit) : la paire {NoRegion , NoProduit} constitue de facto l’identifiant de COUVRIR.

2) Au niveau du diagramme tabulaire, COUVRIR hérite en plus de l’attribut NoRep qui est identifiant de l’entité-type REPRESENTANT.

=>

Au final, au niveau tabulaire, cela fait trois attributs pour COUVRIR, dont deux constituent sa clé, et Merise aurait mauvaise grâce à invalider une telle représentation !

Voici le MLD fourni par Power AMC pour qui tout baigne, du MCD au MLD :

http://www.fsmwarden.com/developpez_...gation)MLD.jpg

Très bien ! Dernière interrogation, une association entre deux entités faibles est-elle possible ? Je souhaiterais en effet, pour une autre hypothétique entité faible, réutiliser les identifiants de REGION et de PRODUIT. Cela serait alors très simple d'associer COUVRIR avec cette nouvelle entité, avec (1,1) pour cardinalité du côté de cette dernière entité. J'ai le droit ? :roll:

Supposons qu’une paire Région-Produit couvre un certain nombre de segments, numérotés de 1à n pour chaque paire. La représentation suivante est valide (orthogonalité des concepts oblige) :


MCD
http://www.fsmwarden.com/developpez_...egment_MCD.jpg


MLD
http://www.fsmwarden.com/developpez_...egment_MLD.jpg


Voyez aussi, entre autres, la discussion avec knoxville.

Ca me semblait logique aussi mais étant donné que le concept de structure agrégation aussi... Je préférais demander ! :)

En tout cas un grand merci à toi pour ta disponibilité, ta clarté et l'exhaustivité de tes explications. Si tous les utilisateurs du forum sont comme toi, les problèmes de chacun ne devrait pas durer plus d'une journée ! :ccool::ccool::ccool:


Bonne continuation et encore merci pour cette précieuse aide ! ;)