Merise et MCD : à propos de l'entité-type DATE

Par fsmrel

__________________________________

Que penser de la présence d'une entité-type DATE dans un MCD ?

Certains concepteurs éprouvent à juste titre une grande réticence à modéliser une entité-type DATE dans un MCD et, pour prendre l’exemple classique des livraisons de produits par des fournisseurs, préfèrent considérer la date de livraison comme un simple attribut (de type Date, bien sûr). Sémantiquement parlant, ils ont parfaitement raison, car si FOURNISSEUR et PRODUIT représentent des entités-types de plein droit, en revanche, depuis près de quarante ans qu’on modélise des MCD, en Merise ou autre, on a toujours eu des scrupules à mettre en œuvre une prétendue entité-type DATE, sauf peut-être chez Chronos, et encore... (Il va sans dire que si l’application a besoin d’utiliser un calendrier, alors on mettra en oeuvre une entité-type du genre CALENDRIER, je renvoie à ce sujet à [Nani2001], page 138, figure 7.50).

Mais...

Puisqu’on évoque Chronos, remontons le temps, à l’époque à laquelle naquit la déesse Merise. En juin 1979, parut le document de référence suivant :



Ce document fut émis par le centre technique informatique (CTI) du Ministère de l’Industrie (Mission à l’informatique), sous la responsabilité d’un comité de pilotage aréopagique impressionnant (Ministère du Budget, Ministère de la Justice, etc.)

Page 9, on y lit ceci (caractères gras et italiques d’origine, ainsi que la belle faute d’orthographe) :


Autrement dit, une association n’a pas d’identifiant propre, explicite, et cette définition est communément admise ([Rochfeld1989] page 79, [Matheron2007] page 57, [Collongues1987] page 41, [Tabourier1986] page 81, ...). Disons qu’une association hérite implicitement des identifiants de la collection des entités-types participantes.
Sans doute par prudence, Dominique Nanci et Bernard Espinasse furent plus laconiques ([Nanci2001] page 100), se bornant à écrire : « une relation type n’a pas d’identifiant propre ».

Quoi qu’il en soit, prenons l’exemple des livraisons de produits par des fournisseurs, avec les règles de gestion des données suivantes :



Dans ces conditions, le MCD ci-dessous ne tient pas la route, car l’association LIVRER ayant pour identifiant implicite la paire {FourId, ProdId}, on ne peut donc mémoriser qu’une seule date de livraison, ce qui fait que la règle RG3 n’est pas respectée :



Ce que confirme le MLD :



Pour que la règle RG3 soit respectée, l’identifiant attendu pour l’association est nécessairement le triplet {FourId, ProdId, Date}, on doit donc se résigner à faire évoluer le MCD, et mettre en oeuvre une entité-type DATE que je qualifierais volontiers de « zombie de service » :



MLD :



La clé primaire de la table LIVRER est bien le triplet qu’on attend {FourId, ProdId, Date}, aussi l’attribut Date de la table LIVRER suffit à notre bonheur : la table DATE est inessentielle, inutile et doit disparaître. Si on ne le fait pas, et si des dizaines autres tables y font référence, elle devra contenir à peu de choses près un calendrier sur des années (intégrité référentielle oblige), ce qui serait idiot. Tout ça parce que lors de la dérivation du MCD en MLD on a appliqué la règle gravée dans le granit, mais erronée (essentialité oblige) comme on est en train de le démontrer : « toute entité-type devient une table », énoncée par des merisiens rompus à la modélisation conceptuelle, mais manifestement pas assez compétents en ce qui concerne le modèle relationnel de données (et je ne parle pas des conséquences au niveau physique si l’on n’y prend garde, c'est-à-dire la prolifération d’une foultitude d’index ne contenant que l’attribut Date, donc inutiles la plupart du temps et surtout coûteux lors des opération de mise à jour, c'est-à-dire bons pour la poubelle).

Bref, Le MLD doit être nettoyé, débarrassé de cette table DATE, et se résumer à ceci :



Heureusement, un AGL comme PowerAMC permet d’’éviter la génération de la table DATE ; dans le MCD, il suffit de décocher la case idoine dans la fenêtre « Propriétés de l’entité » :



Revenons maintenant sur la définition de l’identifiant d’une association :



Dominique Nanci et Bernard Espinasse (cités plus haut) ont eu raison de rester muets à ce sujet. Pour aller plus loin, je me rallie pour ma part, à ce qu’écrit Jean-Luc Hainaut (Université de Namur), père de DB-MAIN :



Avec l’identification implicite, on est ramené à la situation connue



D’où un MLD analogue à celui produit par PowerAMC :



Avec l’identification explicite, DB-MAIN permet qu’on définisse l’identifiant de LIVRER à partir de ses attributs (dont Date fait ici partie) et des entités-types associées :



Ainsi, n’a-t-on pas à définir d’entité-type DATE, ce qui donne raison aux concepteurs réticents, évoqués au début de ce billet.

MLD :



Ce MLD, résultant de l’identification explicite, ressemble étrangement à celui résultant de l’identification implicite, à ceci près que la table DATE inutile a disparu (entraînant dans sa disparition la contrainte d’intégrité référentielle rendue superflue qui liait la table LIVRER à la table DATE).

Ainsi méfions nous des règles gravées dans le granit, mais contestables et lourdes de conséquences, du genre :



Corrigeons cela et, plus généralement, essayons de débarrasser le merisier de ce qui le parasite.

___________________________________

Références

[Collongues1987] Alain Collongues, Jean Hugues, Bernard Laroche – merise, méthode de conception (Dunod informatique, 2e édition, 1987)

[Matheron2007] Jean-Patrick Matheron – Comprendre Merise, Outils conceptuels et organisationnels (Eyrolles, 12e tirage, 2007)

[Nanci2001] Dominique Nanci, Bernard Espinasse – Ingénierie des systèmes d'information : Merise deuxième génération (4e édition, 2001) (Vuibert, quatrième édition, 2001)

[Rochfeld1989] Arnold Rochfeld et José Moréjon – La méthode Merise, Tome 3, Gamme opératoire (Les Éditions d’Organisation, 1989)

[Tabourier1986] Yves Tabourier – De l’autre côté de Merise (Les Éditions d’Organisation, 1986)

_______________________________