[MCD] Gestion des dates

Bonjour, dans l'analyse que je suis en train de realiser, je patauge :cry: avec la gestion des dates, et j'aimerais avoir votre avis :

Il s'agit de realiser une appli de notation des officiers de police judiciaire(opj).
Chaque année un opj reçoit une notation comprenant 5 notes et une appreciation generale : dans le mcd, est ce que l'on doit créer une entité Année reliée aux entités opj et notation ou est ce qu'il faut que année soit un attribut de la relation entre opj et notation ?

Cet opj possede une situation à un certain moment de sa carriere (date), soit il part à la retraite, soit il est muté, etc...et la je ne sais pas si ma date doit etre un attribut de la relation entre opj et situation ou un attribut de l'entité situation.

merci d'avance

Olivier

Je pense que le MCD le plus pertinent est le suivant
http://d.nanci.free.fr/Brio_1.jpeg
Commentaires
1/ La notation étant un événement annuel répétitif, le temps doit explicitement être modélisé comme une "dimension"; l'entité ANNEE est pleinement justifiée. La relation notation modélise chaque notation annuelle. L'autre modélisation envisagée est erronée; quel serait l'identifiant de l'entité notation ?

2/ Les 5 notes ont été modélisées en "propriété multivaluée". Cela signifie que chacune des 5 notes n'a pas de spécificité sémantique (comme si l'on avait 5 évaluateurs, un peu comme un jury); par contre si chaque note à une signification (note administrative, manière de servir, ponctualité, etc...), alors il faut expliciter chaque note par une propriété spécifique.

3/ Il faut distinguer:
- la situation de la personne à un moment donné
- les situations types issues du statut
Chaque situation personnelle est une occurrence de SITUATION PERSO.
On a une nouvelle occurrence chaque fois de la parsonne intègre cette situation; l'identifiant est donc la date d'entrée dans la situation, identification relative par rapport à la personne. Ainsi, tout changement de situation est nécessairement une nouvelle occurence, même si l'on revient à une situation déjà occupée dans le passé.
Les autre modélisations envisagées soit ne permettaient pas de revenir à une situation déjà occupée dans le passé, soit de limiter à une seule situation..

Bien sur, ce modèle est élémentaire par rapport à un cas réel (que je connais très bien pour l'avoir mis en oeuvre dans un autre corps...)

Le MLD correspondant est le suivant
http://d.nanci.free.fr/Brio_2.jpeg
Bien évidemment, l'optimisation (phase indispensable) devrait conduire à la suppresion de la table ANNEE, An restant toujours dans la clé primaire de Notation

merci pour vos explications et vos schemas mais je manque de pratique
alors pourriez vous m'expliquer quelques details :
pourquoi ne crée-t-on pas une entité notation avec un identifiant et en general dans un mcd qu'est ce qui fait qu'on gere la date comme une entité ou un attribut d'une entité ou d'une relation ?

Olivier

Citation:

---

pourquoi ne crée-t-on pas une entité notation avec un identifiant

---

Avec quel identifiant ? Que signifie une notation ? Si la réponse est "c'est la notation d'une personne pour une année" alors deux modélisations sont envisageables:
- celle représentée avec Notation en relation,
- modéliser Notation annuelle comme une entité, identifiée relativement par An, relatif à OPJ. Cette entité contenant les propriétés de notation (notes, appréciation).

http://d.nanci.free.fr/Brio_3.jpeg

La différence entre les deux modélisations est expliquée ci-après. Ma préférence va à la modélisation explicite de l'année à cause de la régularité annuelle de la notation.
De toute façon, les deux solutions conduisent au même résultat final au niveau MLD !

Citation:

---

qu'est ce qui fait qu'on gere la date comme une entité ou un attribut d'une entité ou d'une relation

---

Cette modélisation du temps fait l'objet de paragraphes complets dans certains bouquins; je résume.
Il faut distinguer :
1/les propriétés à valeur calendaire
Ce sont des propriétés qui prennent leur valeur dans le domaine du temps. Et pour celles là, il n'y a aucune raison de faire une entité spécifique.
Par exemple
date de règlement d'une facture,
date de naissance d'une personne
année d'obtention d'un diplôme
Ces propriétés se modélisent comme les autres. Ce serait une erreur de modélisation que de les sortir de leur entité (ou relation) et de les relier à une entité Date ou Année.

2/ la modélisation de la chronique des valeurs de propriétés
Certaines propriétés (ou ensemble de propriétés) prennent des valeurs à des échéances régulières dans le temps
Par exemple
le cours quotidien d'une action
la production hebdomaire d'une ligne de production
le PIB annuel d'un pays
Dans ce cas, l'entité temporelle correspondante (Jour, Semaine, Année) est modélisée explicitement et la propriété est généralement portée par une relation entre l'entité cocnernée et l'entité temporelle.
Cette modélisation est assez courante dans tous les problèmes de suivi ou de planification d'activités.

L'exemple suivant combine 1/ et 2/ : la date de prélèvement varie selon les mois de l'échéancier du prêt

http://d.nanci.free.fr/Brio_4.jpeg

3/ l'historisation
Cela concerne les propriétés dont les valeurs évoluent dans le temps, pour une même occurrence de l'entité (ou de la relation).
Il s'agit alors de distinguer
la valeur courante de la propriété
les valeurs antérieures de cette propriété
Par exemple
adresse d'une personne
date prévue de fin d'un projet

Il existe alors une notation symbolique (H), qui indique que cette propriété est historisable. Des règles existent pour prendre en compte cet aspect lors de la transformation en MLD.

4/ des propriétés, relatives à un objet, qui prennent des valeurs successives suite à un événement daté
Il s'agit généralement d'un ensemble de propriétés que l'on "mesure" à une date donnée, suite à un évenement déclencheur. Cet ensemble de valeurs est enregistré "à date"; la datation pouvant être une année, un mois, un jour.
On modélise alors une entité accueillant ces propriétés, avec comme identifiant une propriété temporelle de datation (date, semaine, mois, année), relatif à l'objet "mesuré.

Ainsi, l'exemple de l'OPJ combine deux cas
- la notation relève plutôt du cas 2/, cette notation étant régulière chaque année.
- les situations relèvent du cas 4/ car l'événement n'est pas régulier à l'échéance datée.

Un jour , il faudra que je prenne le temps d'expliquer tous cela sur Developpez.com, mais je risque d'avoir des problèmes avec mon éditeur....