Une incidente...
Il s’agit d’une variation sur l’évolution de la modélisation des associations, ce qui suit est donc en dehors du sujet traité, mais ça peut intéresser certains.
Utilisons un diagramme de classes : SIGNER prend alors la forme d’une classe-association :
Et le MLD dérivé est le suivant :
Où la clé primaire de la table SIGNER est bien le triplet {nomBat, nomSponsor, dateDebut}. AGL utilisé : PowerAMC.
MacFly, passons à votre remarque :
Envoyé par
MacFly58
L'identifiant de l'entité-type associative "SIGNER" semble être "datedébut", or ce n'est pas le cas.
C’est affaire de convention. Mutatis mutandis, votre remarque vaut aussi pour la classe-association que j’ai représentée. Cela dit, dans le diagramme hypothétique ci-dessous, SIGNER reste une association, elle est à considérer comme la transposition de la classe-association (qui en fait m’inspira...) :
Ainsi, BATEAU et SPONSOR participent évidemment à l’identification de l’association.
Simplement, il faudrait compléter la définition de l’identifiant d’une association merisienne.
Prenons l’énoncé fourni en 1979 par les pères de Merise (cf. page 9 de « Méthode de définition d’un système d’information », Centre technique informatique (CTI) du Ministère de l’Industrie, Mission à l’informatique, document signé par le ministre) :
Complétons la définition (c’est un peu lourd, mais on fera avec) :
L’identifiant d’une relation est obtenu par la concaténation des identifiants des entités-types qui participent à la relation et, parmi les propriétés portées par la relation, celles qui ont été désignées pour participer à l’identification de la relation.
Evidemment, bien qu’inspirée d’un diagramme de classes, la représentation graphique que j’ai utilisée peut être contestée et votre remarque est recevable. Il serait sans doute préférable de s’inspirer de DB-MAIN, lequel permet de modéliser ainsi, où l’on appelle un chat un chat :
On peut encore utiliser ne représentation à l’anglo-saxonne (PowerAMC dans sa version correspondante ne propose pas les ovales merisiens, les utilisateurs doivent donc procéder ainsi) :
Pour l’avoir utilisée chez des clients qui ne voulaient pas d’autre type de représentation, je n’ai pas senti que la dimension communication était mise à mal.
Envoyé par
MacFly58
Cela peut poser un problème de lecture du MCD pour un néophyte, et donc de contrarier l'un des principaux buts du MCD, qui est un outil de communication.
Le néophyte doit se mettre au courant des règles en vigueur. Pour reprendre l’exemple du diagramme de classes, il doit savoir que l’attribut dateDebut ne suffit pas pour « identifier » la classe-association.
Un MCD est bien sûr un outil de communication, mais par dérivation en MLD il donne aussi la structure de la base de données et là ça peut devenir très chaud si l’on n’y a pas pris garde, et des projets importants ont capoté parce les concepteurs n’en avaient pas pris la mesure (mes bien nombreuses missions d’audit et d’expertise m’ont permis d’en juger...)
)
Répondre avec citation
, MacFly, vous avez repéré un cas d’ubiquité, de bilocation, à savoir qu’il n’y a aucune raison qu’un équipier ait pu se trouver sur plus d’un bateau au cours d’une épreuve donnée, à moins d’être tombé à la patouille et d’avoir été repêché par des concurrents... 
.png)
Partager