Problème avec un historique

Bonjour !

J'ai reçu une demande de mon maître de stage mais je n'arrive pas à modéliser la base de données pour ce qu'il me demande.


Son souhait est d'obtenir un graphique qui représenterait l'évolution dans le temps d'un nombre de tâches qu'il reste à réaliser pour une personne.
Par exemple :

Marc a reçu 25 tâches le 01/01/2015 et en a accomplit 15 sur cette même journée, ils seraient donc à +10
le 02/01/2015 il en a reçu 17 et en a accomplit 7, il serait donc à +10 +10 (du jour avant)

Pour le moment, mon schéma ressemblait à ceci :

Pièce jointe 208287

Il permet seulement d'avoir, par jour, le nombre de tâches que Marc à reçu mais ne permet pas de faire le cumule.

Mon idée de base est donc de réaliser un historique qui me permettrait de dire :

Pièce jointe 208288

avant-hier marc avait encore 50 tâches qui était dans un état "assigné"
Hier marc avait 45 tâches qui étaient dans un état "assigné"
Aujourd'hui marc a 52 tâches qui sont dans un état "assigné"

Le problème que je rencontre est de savoir comment faire avec ma table de faits, étant donné que je suis obligé de garder l'id de la tâche.
Ma seule idée est d'avoir un lien de ma table de pont vers ma table de fait qui portent sur l'id de la tâche et la date de l'historique mais je ne sais pas s'il existe une meilleure manière de contourner ce problème...

Le plus gros problème que je ne peux pas résoudre avec mon idée sont les dates qui précedente le début de l'historisation. Par exemple, si je commence l'historique aujourd'hui, je n'aurais aucune idée de ce qu'il s'est passé avant. Dans le meilleur des cas, ça serait le top de pouvoir faire ceci, mais je n'ai rien trouvé pour que ça marche :roll:

Avez-vous des idées sur la question ?

Merci,
Wazzouille

Pour avoir des fonctionnalités minimales il y a 2 modèles de données:

- le modèle par intervalle : chaque tâche a une date de début et de fin (null par défaut). Pour avoir le nombre de tâches assignées à 1 date donnée (à la fin de la journée, c'est important), il suffit de faire un select avec une clause

Code:

---

where date début <= [date cherchée] and ([date cherchée] < date fin or date fin is null)

---

Le défaut c'est que vous n'avez pas la traçabilité des statuts dans le temps s'il y a plusieurs types de statuts.

- le modèle de gestion de stock: pour chaque tâche on créé 1 événement "Ouvert" avec la date d'ouverture, 1 événement "Fermé" avec la date de fermeture, et pourquoi pas d'autres événements ("changement de statut", etc.). Pour avoir le nombre de tâches ouvertes à une date donnée, il suffit de faire un select pour sommer le nombre d'événements "Ouvert" - "fermé" avec une clause

Code:

---

where date événement <= [date cherchée]

---

Là où c'est risqué c'est qu'il faut conserver tout l'historique pour avoir un chiffre juste. Après il est possible de conserver des photos (mensuelles par exemple) pour éviter d'avoir à conserver tout l'historique.

Ce qui est sûr c'est qu'agréger les données ne peut que compliquer les choses, il vaut mieux conserver le détail à mon avis.

Bonjour et merci pour votre réponse.

Cependant, les outils que j'utilise ne me permettent pas de réaliser des requêtes, tout ce passe en drag and drop donc je dois pallier ce manque par la modélisation (et je ne trouve rien de mieux, malheureusement).

Effectivement, ça ne fait que compliquer les choses, surtout du côté de l'utilisateur final mais sans les requêtes, je n'ai pas d'autres solutions..

C'est quoi les outils ? Parce que là c'est comme poncer un tank avec une brosse à dent...

Bonjour,

J'utilise la suite SpagoBI et le smart filter.

En somme il se connecte à une source de données, on défini les dimensions et mesures (tout ça en interface utilisateur).
Du coup il génère les query pour l'utilisateur final..

Ah oui mais ça ce n'est pas un souci, les 2 modèles décrits au dessus sont sûrement exploitables avec ce genre d'outil, pas d'inquiétude.