Il est un fait que dans le cas général, les relations peuvent être porteuses de données (attributs DateDebut et Commentaires de la relation Travailler). Se pose le cas des cardinalités maximales 0-1 et 1-1.
Supposons que 0-N soit transformée en 0-1 (un salarié fait partie d’au plus une entreprise) : je recommande de laisser les attributs DateDebut et Commentaires dans la relation Travailler. En effet, le MCD a pour vocation de faire l’objet d’un MLD et l’entité-type Travailler doit donner lieu à une table telle que DateDebut et Commentaires en soient des attributs. Si ces attributs sont migrés dans la table Salarie, on a tout faux au regard de la théorie relationnelle, puisque ces attributs doivent déclarés ainsi :
DateDebut ... NULL,
Commentaires ... NULL,
Il est démontré avec la théorie relationnelle — et des débats terribles ont eu lieu à ce sujet— que les valeurs nulles sont sources d’erreurs avec l’algèbre relationnelle. Notre défi est donc de faire en sorte de ne pas nous mettre en situation de danger quand nous utilisons les opérateurs relationnels.
Vous pouvez consulter la discussion http://www.developpez.net/forums/sho...d.php?t=267568
Reste donc le seul cas des cardinalités 1-1
Il est d’usage en Merise que dans ce cas particulier, les attributs DateDebut et Commentaires soient expulsés dans l’entité-type Salarie.
Je préfère personnellement être merisement incorrect quand j’estime être dans mon bon droit, et faire en sorte que la relation Travailler puisse donner lieu à une table au niveau logique. Ma motivation n’est pas liée à la modélisation conceptuelle.
Je ne veux pas être catégorique, aussi j’avance quelques arguments, en relation essentiellement avec la vie d’une production informatique (parfois il faut redescendre sur terre, on ne modélise pas forcément pour le seul plaisir de modéliser...)
J’analyse donc les conséquences en aval de l’application stricte du dogme :
Supposons donc que les attributs de la relation Travailler aient été absorbés par Salarie : les règles du jeu fluctuant avec le temps, comment répercuter dans des tables en production une règle nouvelle du genre : "Désormais, les personnes peuvent travailler pour plusieurs entreprises" ? Les DBA et les développeurs vont avoir du pain sur la planche puisqu’il y aura à mettre en œuvre une table Travailler jusque-là inexistante et modifier en conséquence les requêtes SQL hébergées par les programmes impliqués dans cette affaire, alors que si la table existe déjà, il suffit à peu de choses près de procéder à un Alter Table afin d’en compléter la clé primaire.
Et puis on aura l’air malins quand 2 ans plus tard, le nouveau PDG décidera que l’on revienne à l’ancienne situation : on va donc supprimer la table Travailler et migrer ses attributs dans la table Salarie ???
Si les données de tables telles que Salarie sont stables, il n’en va peut-être pas de même pour des attributs portés par les relations qu’elles entretiennent avec d’autres tables. Ainsi, il est des situations dans lesquelles on risque des inter-blocages des transactions (verrouillage des pages de données) qui autrement n’auraient pas lieu. Dans votre cas, le rattachement d’une personne à une entreprise est plutôt stable, mais il est d’autres situations dans lesquelles ça n’est absolument pas le cas. Supposons donc que la table Salarie soit bombardée de mises à jour concernant les attributs DateDebut et Commentaires : les DBA devront dégager ces attributs dans une table telle que Travailler (voire d’autres tables encore) pour que les gens qui ne font que consulter la partie stable de la table Salarie ne soient pas dérangés par ceux qui la mettent à jour.
Si les données représentées par les attributs de la relation Travailler occupent 2 fois plus de place que celles représentées par les attributs de l’entité-type Salarie, pourquoi rendre obèse cette dernière, au risque de ralentir les traitements ? Par exemple, là où les sauvegardes pourraient être parallélisées, ça ne devient plus possible : perte de temps qui à l’échelle de tables volumineuses va donner du souci à la production qui n’a pas besoin de cela.
Les quelques arguments que j’ai fournis sont plus justifiés par ce qui se passe dans la soute du bateau que par ce qui se passe dans le salon, mais le bateau doit avancer. Je n’aime pas mélanger les problèmes de conception et ceux de production, mais je le fais quand une règle de conception prétendue indiscutable a des répercussions allant très loin.
Cette règle merisienne me fait penser aux règles que l’on trouve dans les traités d’harmonie : si on ne les violait pas il n’y aurait que des œuvres musicales ennuyeuses. Rien de tel que frottement d’un Do# et d’un Ré bien amené par un Mozart, un Bach ou un Saint-Saëns, pour sentir des souris qui vous courent dans le dos.
Autrement dit, en réfléchissant à ce que j’ai avancé, à vous de décider si l’entité-type Salarie absorbe ou non les attributs de la relation Travailler.
Si vous choisissez de faire en sorte que la relation Travailler fasse l’objet d’une table, faites en une entité-type identifiée relativement à Salarie (cf. les pièces jointes).
Partager