Discussion :

[giovan]

Bonjour à tous,
quelqu'un pourrait-il me démystifier la relation au niveaux de ses propriétés.
Comment savoir a quel moment est-il pertinent de mettre une ou des propriétés dans une relation ?

Merci de vos réponses.

[fsmrel]

Bonjour Giovan,


Supposons qu’on ait des produits stockés dans des entrepôts (exemple repris de [1]) :



Si l’on doit connaître la quantité en stock de chaque produit par entrepôt, le MCD devient :


Si quelqu'un conteste, qu'il présente ses arguments.

__________________________

Ministère de l'Industrie - Centre technique informatique : Méthode de définition d'un système d'information - Fascicule 4, guide pratique pour l’élaboration des modèles de données et de traitements - juin 1979

Ce document entérine la naissance officielle de Merise.

[CinePhil]

François, toi d'habitude si verbeux, je te trouve léger sur ce coup !

En cours de maths, on m'a appris que la démonstration par l'exemple n'est pas une bonne méthode car il peut exister un autre exemple qui ne satisfera pas la démonstration.

Je reprends donc la question posée :

Comment savoir a quel moment est-il pertinent de mettre une ou des propriétés dans une relation ?

Je commencerai par corriger le terme "relation" en "association" que je préfère pour ne pas confondre avec le modèle relationnel !

Puis je reprends l'exemple de fsmrel :

Si l’on doit connaître la quantité en stock de chaque produit par entrepôt...

Où placer cette quantité ?

Première solution : Je place la quantité des produits dans l'entité type "ENTREPOT".
Quelle information est donnée ?
Une quantité de produits dans un entrepôt mais je ne sais pas s'il s'agit de la somme des quantités de tous les produits contenus dans l'entrepôt ou s'il s'agit de la quantité de biglotrons, de blasters, de lampes merveilleuses ou de confettis !
L'information est incomplète, ce n'est pas le bon emplacement pour cette quantité.

Deuxième solution : Je place la quantité des produits dans l'entité type "PRODUIT".
Quelle information est donnée ?
Une quantité d'un produit mais je ne sais pas si cette quantité est celle de ce produit dans l'entrepôt de Toulouse, dans celui de San Francisco ou dans celui de Tatooïne ou dans la totalité des entrepôts !
L'information est incomplète, ce n'est pas le bon emplacement pour cette quantité.

Il ne reste qu'une troisième solution : mettre cette quantité dans l'association "STOCKER".
Quelle information est donnée ?
Une instance de l'association correspond à 1 produit stocké dans 1 entrepôt. La quantité figurant dans cette association sera donc bien celle de ce produit dans cet entrepôt.
C'est l'information voulue donc c'est le seul endroit où je peux placer cette quantité.

Généralisation :
Je place une information dans une association lorsque celle-ci est bien propre à l'ensemble des entités types participant à l'association.

[giovan]

Bonjour,

merci beaucoup pour vos réponses et du temps que vous y avez passé, cela m'a bien aidé.
Un détail encore, pour reprendre votre exemple pourquoi ne pas créer une entité appelé "quantité". Quel sont les avantages et inconvénients de l'une et l'autre ?

Merci

[CinePhil]

Ajouter une entité type "quantite" n'apporterait rien, sauf si, à la rigueur, la quantité serait à choisir parmi un nombre restreint de valeurs. Il y aurait alors une entité type de référence des quantités autorisées.

[fsmrel]

Bonsoir,

Comment savoir a quel moment est-il pertinent de mettre une ou des propriétés dans une relation ?

Supposons qu’on vous envoie faire l’audit du MCD de l’entreprise Dubicobit chez qui les concepteurs du grand cabinet d’expertise Tartempion Consultants ont modélisé pour la 1re fois de leur vie après avoir suivi un cours de deux jours sur la conception, et qui ont maintenant regagné leurs pénates (depuis un bon moment...)

Supposons encore qu'au cours de votre audit vous examiniez plus particulièrement les associations-types binaires de ce MCD. Ainsi, vous tombez sur cette partie selon laquelle un établissement de l’entreprise Dubicobit a exactement un directeur et un directeur dirige exactement un établissement ; par ailleurs le directeur P1 de l'établissement E1 fait partie des effectifs de l’établissement E2 (E1 n’étant pas nécessairement égal à E2). La propriété « Depuis » portée par l’entité-type DIRECTEUR est pour le moins ambiguë et vous aurez des états d’âme : faut-il comprendre qu’il s’agit de la date depuis laquelle l’intéressé fait partie des effectifs de E2 ? De la date depuis laquelle il dirige E1 ? De la date de sa dernière prime de bilan ? Et ce n’est pas le flou qui règne dans le dossier de conception détaillé qui va vous aider à y voir clair.




Vous me direz : « Ce MCD n'est pas fameux ! », ce à quoi je répondrai : « Pour le moins, et c’est bien pour ça qu’on vous a demandé de faire un audit ! »

Quoi qu’il en soit, vous irez vous renseigner auprès des utilisateurs pour tirer les choses au clerc clair. Suite aux différents entretiens, supposons que l’aménagement suivant convienne :



Le directeur P1 a une prime de bilan attribuée par la direction générale de Dubicobit (qui se situe au dessus des établissements), il dirige l'établissement E1 depuis la date D11, il est employé depuis la date D12 par l’établissement E2 (qui peut éventuellement être E1).

Comme dit CinePhil :

« Je place une information dans une association lorsque celle-ci est bien propre à l'ensemble des entités types participant à l'association. »

Mais il y aura toujours un pinailleur qui s'y connaît pour prétendre que ça ne va pas, parce qu’une association binaire avec une patte à cardinalité maximale à 1 ne peut pas être porteuse de données, en vertu de quoi il faudrait représenter les choses comme ceci :



Ou comme cela :



Sans doute. En fait, c’est un point tout à fait secondaire, mais non négociable pour certains (et ce dès la fin des années soixante-dix) notamment pour nombre de ceux qui ont enseigné Merise, l’enseignent et l’enseigneront. Mais tout le monde ne partage pas forcément cette vision des choses : une association-type peut être porteuse de propriétés, point barre ai-je envie de dire, on ne va pas commencer à rentrer dans les cas particuliers du style : « Dans le cas des cardinalités maximales 1 on rapatrie les propriétés dans les entités-types, sauf quand les cardinalités minimales sont à 0 », etc. Conceptuellement parlant les deux positions sont à mon sens acceptables, et on retiendra la représentation qui a la préférence de l'utilisateur...

La FAQ Merise prend position, mais sans argumenter, sans dire pourquoi ça serait peccamineux de faire porter des propriétés dans des associations-types binaires. Je cite par ailleurs l’ouvrage de référence [1] :

Toute relation binaire avec cardinalité 1,1 ne peut être porteuse de propriété. En effet, une telle propriété migre alors obligatoirement dans l’entité portant cette cardinalité 1,1.

Il s’agit là d’un raisonnement circulaire, un argument d’autorité qui ne prouve rien, propre à instaurer un dialogue de sourds à la Fernand Raynaud... Si je pose la question : « Pourquoi donc une telle association ne pourrait-elle être porteuse de propriétés ? » Réponse : « Parce que ces propriétés doivent migrer ! »¹

Quoi qu’il en soit, pour reprendre la variante :




Pour prendre un exemple, PowerAMC en dérivera le MLD ci-dessous en annonçant : « 0 erreur » (quitte à signaler un cycle possible, mais n'intervenant pas ici) :



Où l'on notera que la table DIRIGER a deux clés candidates : {EtablissementId} et {PersonneId}.

Maintenant à chacun de voir ce qui lui convient le mieux : propriétés portées par une association-type binaire, ou délocalisées dans une entité-type (ou plus, comme ci-dessus). De toute façon c’est au niveau du MLD que les choses se dénouent et que sont closes les polémiques.

Ainsi, en reprenant le MCD :



PowerAMC produit le MLD (noter la clé alternative symbolisée par le mickey <ak>) :



Attention à la variante qui suit, pour peu qu'un directeur fasse partie des effectifs de l'établissement qu'il dirige...

Quelqu'un pourrait-il me démystifier la relation au niveau de ses propriétés.

Quels autres mythes en particulier vous interpellent ?

______________________________
¹ A la limite on m’avancera qu’une association binaire vaut dépendance fonctionnelle (DF), ce qui ferait doucement rigoler les théoriciens du relationnel à qui l’on doit la théorie des DF (Codd, Armstrong, Bernstein, Beeri, Fagin et j’en passe) : disons qu’une association binaire a un goût de DF, mais il y a des limites à ne pas franchir, il n’y a pas équivalence, ou alors il faut intégrer les axiomes d’Armstrong à Merise, notamment celui d’augmentation et là, bonjour les dégâts ! (Comme disait l’autre, « Armstrong ? Qui c’est c’gars-là ? »
______________________________

[1] Dominique Nanci, Bernard Espinasse. Ingénierie des systèmes d’information Merise Deuxième génération. Sybex 1996.

[fsmrel]

François, toi d'habitude si verbeux, je te trouve léger sur ce coup !

Hum... je trouve le qualificatif « verbeux » un tantinet péjoratif : serait plus acceptable « peu avare d’explications » ou équivalent. Même chose pour le qualificatif « léger » qui a une coloration peu amène, du genre « réfutable », « manquant de fondement » alors que ce que j’ai écrit ne peut être infirmé, même si avec l’énoncé « quantité en stock de chaque produit par entrepôt » j’ai été concis et expéditif, résumant ce que développe par exemple Michel Diviné dans Parlez-vous Merise à ce propos (et j'invite tout un chacun à étudier cet ouvrage).