Discussion :

[fayred]

Bonjour,
voila, je dois modeliser un planning ( heures, jours, mois, années...) pour l'intranet de l'entreprise ou je fais mon stage.
Or, au niveau du MCD , je ne sais pas trop comment faire ...
Est -ce que je dois faire des entités distinctes pour jour, heure, mois annee? Et si oui comment les relier?
Sachant que le but c'est de pouvoir affecter un horaire (heure debut, heure fin, jour) à un employé.
J'ai déja consulté la FAQ Merise mais je n'arrive pas à comprendre le MCD qui est présenté, il me parait trop complexe.
Merci de votre aide!!!

[fsmrel]

Bonsoir Fayred,


Jour, Heure, Mois, Année sont des types et ne sauraient pas plus faire l’objet d’entités-types que Caractère, Décimal, Entier, j’en passe et des meilleures, à moins que ce ne soient les objets de gestion de votre univers. Je reconnais que tout n’est pas simple à ce sujet. Par exemple, Couleur peut être considérée comme un simple attribut pour une voiture et un objet de gestion dans un autre contexte : Couleur devant alors avoir des propriétés qui la caractérisent.

Concernant les horaires (supposés journaliers) des employés, ça pourrait commencer par quelque chose comme ceci (clés primaires soulignées) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
Employe (EmployeId, EmployeNom, ServiceId, ...)
             1        Fayred       s1
             2        Fsmrel       s2
            ...         ...        ...

Horaire (EmployeId, Date,        HeureDebut, HeureFin, ...)
             1      2007-05-11     07h00       13h59
             1      2007-05-11     17h00       23h59
             1      2007-05-12     00h00       03h59
             1      2007-05-12     07h00       17h59
            ...        ...          ...         ...

Façon Toad Data Modeler (freeware) :

[fayred]

En fait pour pouvoir réutiliser les horaires j'ai fait une association " travailler" entre horaire et salarié ou je mets la date. (et en plus c'est cette table la que j'historise )
Mais bon, ça me parait trop simple pour etre vrai!

[fsmrel]

Bonjour Fayred,

Je suis d’accord concernant votre MCD si la relation Travailler donne lieu au niveau MLD à une table dont chaque attribut est NOT NULL. Je vise en particulier l’attribut Date_fin : si la date de fin est systématiquement connue, alors cet attribut est à sa place. Si ça n’est pas le cas, alors il faut "casser" Travailler en deux, pour séparer les données actives des données historisées, comme on l’a vu dans la discussion "Historiser deux entités et leurs relations"
http://www.developpez.net/forums/sho...d.php?t=336896





En théorie, l’expulsion dans une entité-type ad-hoc vaut aussi pour l’attribut Date_sortie de l’entité-type Salarie si on veut rester dans la logique du "zéro valeur nulle".

[fayred]

En fait il y a deux dates differentes (jai du un peu melangé...) :

• date_entree date sortie qui correspondent à l'arrivée et au départ de l'employé de l'entreprise (pour ça je pense que le mcd ci dessus convient tout à fait merci!)

• date_debut date_fin qui correspondent aux dates de début et de fin d'un horaire

Exemple : un salarié arrive dans l'entreprise le 02/02/07 (date entree) et du 02/02/07 (date_debut) au 04/04/07 (date_fin) il fera 8h-17h(horaire), puis du 05/04/07 au 15/10/07 il fera 6h-15h.

Mais je pense qu'avec les deux discussions je peux faire un mcd correct donc merci!

[fayred]

En fait y a quand meme un truc qui me chagrine dans le schéma ci-ci dessus :
on peut mettre des attributs dans l'association car on a du 0-n 0-n.
Or un salarié a 1,1 entreprise.... ce qui fait une relation salarié 1,1 travailler 0,n entreprise. Dans ce cas là est -ce qu'on peut mettre des attributs dans l'association (date_debut et commentaires)?

[fsmrel]

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).

[fayred]

Je ne peux que m'incliner... Là, franchement je suis impressionnée et très reconnaissante!

Effectivement je pense que date_debut et commentaires n'ont rien a faire dans salarié mais je pensais que si jamais je dérogeais au sacro-saintMerise je serai hachée menue et découpée en rondelles... Merci de m'avoir rassuré, je vais donc faire comme ça, ça me convient parfaitement!