comment modéliser le fait qu'on veut garder un historique?

**zamoto** · 10/05/2006, 14h18

Voilà donc je dois gérer la gestion des stagiaires dans une entreprise de formation.
j'ai une table stagiaire dans mon MCD avec comme attributs id_stag, nom_stag, prenom_stag, etc... et date_arrivée, date_départ. Ces 2 dates sont affectées au stagiaire dès son inscription.

Donc quand je voudrai faire une requète SQL pour afficher les stagiaires en formation, je ferai par exemple :
SELECT * FROM stagiaire WHERE date_today < date_depart;

SQL pour ceux qui ne sont plus actuellement en formation mais qui sont tout de même dans la base :
SELECT * FROM stagiaire WHERE date_today > date_depart;

Mais ça c'est du trifouillage nan? normalement je pense que je devrais créer une table DATE à part, mais je ne vois pas du tout comment la relier à ma table stagiaire et où placer mes attributs date_arrivée date_départ.

J'aurai besoin d'un expert en la matière.

Merci d'avance

**qi130** · 10/05/2006, 21h10

Académiquement parlant, il faut une table Date.

Pour autant, le bon sens (et l'expérience

) enseigne que ce genre de chose est passablement couteux car les interventions sur cette table sont systématiques (au moins 1 fois par an afin de la peupler des dates de l'année à venir); avec les corrolaires:
- qui le fait
- combien ça coûte
- risque de blocage du système en cas d'oubli
- pas d'épuration possible (la date est FK)
- cette table grossit, grossit, grossit

et en fin de compte, sur les 365 dates d'une année civile, combien servent dans la table des stagiaires ? 20% maxi ? (10% est peut-être plus proche de la vérité).

Bref, tu l'auras compris, l'approche est la suivante:
- mentionne cette table dans ton MCD,
- dénormalise ton modèle lors du passage en MPD en expliquant/justifiant pourquoi

et hop le tour est joué

**Luc Orient** · 10/05/2006, 21h34

Envoyé par qi130

Académiquement parlant, il faut une table Date.

Franchement et même à ce niveau, je ne pense pas que ce soit nécessaire.
La FAQ Merise, très claire et fort bien faite comme je dis à chaque fois, parle de "propriétés (ou attributs) temporelles" et considère bien que ce sont des propriétés et pas des entités.
Et puis encore une fois on retrouve cette confusion fréquente des niveaux de conception, à savoir que si l'on est au niveau MCD on ne parle pas de tables (c'est une notion de niveau MLD/MPD) mais d'entités.

**qi130** · 10/05/2006, 22h38

Merci pour ce rappel sémantique. Je fais mon mea culpa sur cet abus de langage.

Pour autant, la FAQ aussi bien réalisée soit elle n'est qu'un recueil de trucs & astuces, pas le manuel du parfait Merisien, même si elle fait la part belle aux best practices.

Je considère que faire l'économie d'une entité Date au niveau d'un MCD est un manque de professionnalisme (les FN ne doivent pas rester des concepts).

Le 1er audit venu mettra cela en avant: "manque de maîtrise de la conception", mais c'est un moindre mal.

Plus grave, car phénomène quotidien, est le problème de celui qui viendra maintenir ce système dans 2, 5 ou 10 ans , avec ses interrogations relatives à ces dates qui n'apparaissent nulle part mais sont utilisées partout; et l'obligation d'autopsier les programmes pour tenter de comprendre ce qu'une annotation lui aurait appris à la 1ère lecture d'un dossier de maintenance.

Mais il est plus facile de verser dans la facilité, surtout pour ceux qui ne maintiendront pas leur chef d'oeuvre conceptuel

**Soutou** · 10/05/2006, 23h08

Envoyé par zamoto

j'ai une table stagiaire dans mon MCD avec comme attributs id_stag, nom_stag, prenom_stag, etc... et date_arrivée, date_départ. Ces 2 dates sont affectées au stagiaire dès son inscription.

J'aurai besoin d'un expert en la matière.

Merci d'avance

Il me semble que les 2 dates se trouvent dans l'entité Stagiaire au niveau du MCD et se retrouveront en tant que colonnes dans la table Stagiaire dans la base.
Je ne vois pas là d'historique à gérer car à un id_stag tu as bien une date arrivée et une date départ.
En revanche si à un id_stag tu veux stocker une liste de dates d'arrivée et de départ alors là, il faudrait une table en +.

**Luc Orient** · 10/05/2006, 23h20

Envoyé par qi130

...
Je considère que faire l'économie d'une entité Date au niveau d'un MCD est un manque de professionnalisme (les FN ne doivent pas rester des concepts).
...

Je suis désolé mais je maintiens mon point de vue.
Définition d'une Entité (tirée de la FAQ Merise, encore et toujours ...) :
"Modélisation d'un objet d'interêt (en terme de gestion) pour l'utilisateur"
L'objet "date" tel qu'il est défini ici ne me semble pas rentrer dans cette définition.

Quand aux FN, si il s'agit bien des Formes Normales, elles s'appliquent au modèle relationnel (donc au MLD/MPD) pas au MCD.
Confusion des niveaux de conception encore une fois ...

**zamoto** · 11/05/2006, 09h30

Envoyé par Soutou

Il me semble que les 2 dates se trouvent dans l'entité Stagiaire au niveau du MCD et se retrouveront en tant que colonnes dans la table Stagiaire dans la base.
Je ne vois pas là d'historique à gérer car à un id_stag tu as bien une date arrivée et une date départ.
En revanche si à un id_stag tu veux stocker une liste de dates d'arrivée et de départ alors là, il faudrait une table en +.

En fait, il faudrait que quand mes pages PHP seront réalisé, j'ai une page qui affiche les stagiaires actuellement en formation, et une autre qui affiche tous les stagiaires depuis la création du site.
Mais, si j'ai bien compris, avec mon entité STAGIAIRE qui contient la date d'arrivée et la date de départ, un stagiaire ne pourra pas faire 2 formations avec 2 dates d'arrivée et de départ différentes c'est ça?

Donc si je veux gérer ça il faut que je rajoute une entité DATE contenant l'attribut "date_debut" relié à STAGIAIRE avec une association EST_INSCRIT qui contiendrait l'attribut "date_fin" et au niveau des cardinalités :
DATE (0;n) EST_INSCRIT
EST_INSCRIT (1;n) STAGIAIRE

ça vous semble correct??!!

Merci encore

**Médiat** · 11/05/2006, 09h39

Que tu aies besoin d'une troisième Table au niveau physique avec comme Clé (Stagiaire, DateArrivee) est assez clair, cela n'impose pas d'avoir une table Date.
Seule la définition données par Luc Orient doit permettre de définir ou non une table Date (par exemple, si c'est juste la liste des dates, il est clair que cela n'a pas d'intérêt).

**qi130** · 11/05/2006, 09h44

La faq, la faq, la faq.... l'Evangile ne fait pas la bible !

Quand aux FN, si il s'agit bien des Formes Normales, elles s'appliquent au modèle relationnel (donc au MLD/MPD) pas au MCD.

Envoyé par J-P Matheron

La FN d'une relation [comprendre au sens modèle relationnel] introduite par Codd est parfaitement transposable au MCD

"Comprendre Merise" - Eyrolles 1988

**Luc Orient** · 11/05/2006, 09h51

Envoyé par zamoto

...

Donc si je veux gérer ça il faut que je rajoute une entité DATE contenant l'attribut "date_debut" relié à STAGIAIRE avec une association EST_INSCRIT qui contiendrait l'attribut "date_fin" et au niveau des cardinalités :
DATE (0;n) EST_INSCRIT
EST_INSCRIT (1;n) STAGIAIRE

ça vous semble correct??!!

Merci encore

Il me semble qu'il faut définir une Entité "Formation" avec :
- Stagiaire
- Date début
- Date fin

EDIT : Non tout faux ! oups ! oups !

Il faut une entité "Formation" et une Relation "Est inscrit à" ...

Autres Relations, Propriétés et cardinalités à définir ...

La Relation "Est inscrit à" est sans doute à transformer en Table lors du passage au MLD / MPD. Je viens de tomber dans le piège que je signalais auparavant ...

**zamoto** · 11/05/2006, 10h33

Sinon je viens de penser à une autre solution :

Si je ne rajoute aucune entité et que dans mon entité STAGIAIRE je modifie la clé primaire en la composant de Id_stag et et de date_deb.
La je pourrai avoir un stagiaire qui commence une formation à 2 dates différentes avec des dates de fin de formation différentes, non??

**Luc Orient** · 11/05/2006, 10h39

Envoyé par qi130

...
J-P Matheron a écrit :
La FN d'une relation [comprendre au sens modèle relationnel] introduite par Codd est parfaitement transposable au MCD

"Comprendre Merise" - Eyrolles 1988

Dont acte.

**Médiat** · 11/05/2006, 10h56

Envoyé par zamoto

Si je ne rajoute aucune entité et que dans mon entité STAGIAIRE je modifie la clé primaire en la composant de Id_stag et et de date_deb.
La je pourrai avoir un stagiaire qui commence une formation à 2 dates différentes avec des dates de fin de formation différentes, non??

A priori : mauvaise solution, tu n'as plus de d'entité stagiaire, mais une entité Stagiaire sur un stage avec duplication d'un certain nombre d'informations sur le stagiaire, de plus Id_stag ne correspond plus à rien ; bref solution à éviter complètement. Si tu considères que la même personne qui vient sur deux stages n'est pas le même stagiaire, inutile de mettre la date dans la clé, et si tu considères que c'est bien le même stagiaire, alors il te faut deux tables.

**EvilAngel** · 11/08/2006, 13h06

Salut à tous,

je me permet de reprendre de la fil de la conversation car mon souci est voisin de celui exprimé par Zamoto, mais plus simple j'imagine.

Dans mon cas, un compagnie gère des "serveurs" qui sont loués à ses clients. Ces serveurs présentent une configuration logicielle globale appelée Package (office 2003, reader 7, ....) Ces packages sont numérotés par version (1.0, 1.1,...)

J'ai donc dans mon MCD une entité Package (avec id_pck, version_pck...) et une entité Serveur.
Comment modifier la relation qui les lie pour que je puisse connaitre non seulement le package actuel du Serveur mais égalment ses évolutions de package dans le passé ?

J'imagine au niveau physique une table avec la clef étrangère du serveur, la clef étrangère du package et une date (celle du la mise a jour du package par exemple)

Merci

PS: je me remet à Merise en dépoussiérant mes souvenirs universitaires. Tout n'est pas encore revenu. N'hésitez pas sur les explication.

**Le Pharaon** · 11/08/2006, 13h47

Désolé de ne pas pouvoir les posts précédents
Est ce qu'on peut retrouver un package sur des serveurs différents ?

**EvilAngel** · 11/08/2006, 15h44

Tout a fait.

Au niveau des cardinalités: un package peut etre présent sur 0 à N serveur à un instant précis.
Un serveur ne peut avoir qu'un et un seul package installé à un instant t.

J'avais dans mon MCD:
Serveur |--1,1--|Relation|--0,N--|Package|

**Le Pharaon** · 14/08/2006, 13h19

**EvilAngel** · 14/08/2006, 19h41

Merci pour cette réponse.
Par contre les cardinalités me semblent louche.

Un serveur ne peut contenir à un instant t qu'un et un seul package.
Alors pour moi la cardinalité entre serveur et relation est:
Serveur|--1,1--|Relation|