Discussion :

[champomy62]

Bonjour, je reviens avec une petite question sur comment modéliser bien un historique de temps.

En effet, je suis confronté à un problème que j’ai déjà eu mais la solution retenue n’était pas super efficace. (Fonctionnelle mais possible de faire mieux)

Voici le soucis:

Un employé n’est pas obligé de travaillé sur un projet mais peut travailler sur plusieurs projets en même temps.

Un projet à sa création n’est pas obligé d’avoir des employées car on ne sait pas forcément qui va travailler dessus de suite, mais pourra en avoir plusieurs.

La relation travailler sert à définir qui travaille sur quoi et ce depuis quand.
Admettons que le patron décide que l’employé A travaille à partir du 1 er janvier 2015 sur le projet X.
6 mois plus tard, le patron décide que l’employé A ne travaille plus sur le projet X, on affecte une date de fin. (juin 2015)

Quelques temps plus tard, le patron décide à nouveau que l’employé A travaille sur le projet X. (1 er aout)

Et puis pour X raison, la secrétaire se trompe et affecte de nouveau l'employé A sur le projet X!!! Erreur ici car l'employé est déjà employé sur ce projet et n'a pas de date de fin.

Ce que je veux faire, c’est éviter que l’utilisateur puisse à nouveau affecter l’employé A sur le projet X si il y a déjà un autre enregistrement sans date de fin. J'ai pensé à éclater la relation travailler en deux relations pour avoir comme nouvelle relation 'avoir travailler' qui aurait comme attribut le projet, l'employé, la date de début et la date fin.

Comment puis-je modéliser cette contrainte ? Si c’est possible.

Sinon j'avais pensé à faire une requête SQL encapsulé dans une procédure stocké qui me conterait le nombre d'occurence pour un
{projet donnée, employé donné, date fin à null}. Si le nombre est > 0 alors un employé travaille actuellement sur ce projet sinon il ne travaille pas encore.

Mais c'est moche non ?

Je vous remercie du temps donné.

[CinePhil]

Ce n'est pas un problème de modélisation des données. Il faut faire un trigger à l'insertion qui vérifie que l'employé ne travaille pas déjà sur le projet pour autoriser l'insertion.

En terme de modélisation des données, un employé peut bel et bien travailler plusieurs fois sur le même projet mais à des dates de début différentes.

[fsmrel]

Bonjour,

c'est moche non ?

Ce qui est moche c’est qu’en plus le bonhomme Null peut ficher la patouille comme il veut.

La théorie de la modélisation des données temporelles veut qu’on isole ce qui est en cours de ce qui est fini, c’est la base (cf. Time and Relational Theory, 2nd Edition).

Selon la représentation ci-dessous, la secrétaire pourra toujours courir, elle ne pourra pas provoquer l’ajout d’une occurrence dans EN_COURS pour une paire <employe, projet> donnée.



Je vous renvoie à au paragraphe 6.4 de l’article sur la normalisation.

[champomy62]

J'avais pense a cela mais avec le sixième chapitre de la forme normale que vous avez rédigé, je comprends mieux.

Par contre, est-ce normale qu'il y ait pas une contrainte dans l'association CLOS qui vérifie que la key {EmployeId, ProjetId, DateDepuis} existe dans l'association EnCours ?

[fsmrel]

est-ce normal qu'il y ait pas une contrainte dans l'association CLOS qui vérifie que la key {EmployeId, ProjetId} existe dans l'association EnCours ?

Passons au niveau relationnel. Supposons que Raoul soit affecté au projet DVP depuis le 20 mars 2015. Quand il en aura fini, disons aujourd’hui 3 juin 2015, on ajoutera un tuple <'Raoul', 'DVP', '2015-03-20', '2015-06-03'> dans la table CLOS et on supprimera dans la table EN_COURS le tuple <'Raoul', 'DVP', '2015-03-20'>. A défaut, si l’on vous suivait, il ne faudrait rien supprimer dans cette table, d’où génération d’une contradiction (à moins qu’on ne se situe dans un monde quantique ^^) : d’une part Raoul en aura fini avec le projet DVP depuis le 3 juin 2015 et paradoxalement, à cette date, il serait encore actif sur ce projet...

En fait, il faudrait mettre en œuvre une contrainte d’exclusion :

Si on veut affecter Raoul au projet DVP à une date D, ça n’est possible que s’il n’existe pas dans la table CLOS une période [Dd,Df] (où Dd = date de début et Df = Date de fin), pendant laquelle Raoul a été affecté à DVP, telle que D ≤ Df.

[champomy62]

Oui j'avais raté l’épisode ou l'on doit supprimer la ligne de la table en cours ...

En tout cas cela répond parfaitement a ma question, merci