Bonsoir,
Merci Paprick de nous avoir offert la possibilité de définir des classes d’entités fictives.
Comment procédait-on avant que Looping n'arrivât ? Cela me conduit à faire une mise au point au sujet de l’entité-type (classe d'entité) DATE (CALENDRIER).
En 2015, j’ai pondu un billet à propos de cette entité-type DATE :Que penser de la présence d'une entité-type DATE dans un MCD ?
Dans ce billet, J’ai tiré à vue, car cette entité-type devait se retrouver dans le MLD – puis dans le code SQL –sous forme de table, avec les contraintes d’intégrité référentielle et tout le toutim, alors que c’était parfaitement inutile.
En ces temps « pré-Looping », DB-MAIN nous permettait de contourner la contrainte d’identification implicite et inconditionnelle formulée dans les pages 97 et 98 du monument Ingénierie des systèmes d'information : Merise deuxième génération (4e édition, 2001), paragraphe II-D-3-d. Identification d'une relation type.
Avec l’identification explicite d’une association selon DB-MAIN, pas besoin d’entité-type DATE, dans l’exemple ci-dessous la date fait l’objet d’un attribut de l’association et entre dans la composition de l’identifiant :
Bien entendu, tout ça sent le souffre et Looping nous permet non seulement de respecter le dogme merisien, mais permet surtout d’éviter, avec intelligence et élégance, l’obligation de la création d’une table DATE parasite, grâce à la classe d’entité fictive CALENDRIER.
Encore une fois, merci Paprick !
-----
P.S.
Dans mon billet, en citant la page 138 de l’ouvrage de Nanci et Espinasse, je faisais en fait référence à la 3e édition de cet ouvrage.
Partager