Discussion :

[Sieldev]

Salut,

Dans le cadre de mon stage il m'est demandé de concevoir une application de gestion des projets.
Mais dans une partie de mon MCD je doute, je ne sais pas quelle est la meilleure solution.

L'utilisateur represente une personne affecté à une tâche.
Une tâche est effectué par un ou plusieurs utilisateur
Une session de travail compte le temps dédié à une tâche et calcul la progression d'une tâche.
Un utilisateur peut commencer une tâche ouvrant par la même occasion une session de la tâche, arreter son travail donc fermer la session de la tâche. Puis peut reprendre son travail ultérieurement en ouvrant une session de la tâche qui reprendra alors le temps passé sur la tâche.
On peut se mettre d'accord sur un point, le temps écoulé dépend de l'utilisateur et de la tâche.

Je penche vraiment pour l'utilisation d'un agrégat mais je doute.
Je vous mets les hypotheses:

Utilisation en ternaire avec une porteuse de donnée "temps ecoulé", mais je ne pense pas que la ternaire a lieu d'être car je pense qu' elle ne se justifie pas.



Une autre supposition mais je pense que ce schéma n'est pas bon:



Utilisation d'un agrégat:



En esperant que vous pouvez m'aider, n'hesitez pas à demander des précisions.

Cordialement Sieldev,

[fsmrel]

Bonsoir Sieldev,

Un utilisateur peut-il être affecté simultanément à plusieurs tâches ?

Concernant les sessions : se contente-t-on de cumuler le temps passé par un utilisateur sur une tâche, ou bien suit-on aussi les dates/heures ? (Effet historique).

[Sieldev]

Merci pour ta réponse.

Un utilisateur peut être affecté à aucune ou plusieurs taches mais pas silmutanément.
Pour une session on compte le temps ecoulé et il y aussi la date et l'heure

[fsmrel]

Ça vient !

Je propose que l’on traite d’une part des tâches en cours et d’autre part des tâches terminées.

Tâche en cours :

Puisqu’un utilisateur n’est affecté qu’à une seule tâche à un instant donné, on modélise la chose avec une relation TacheEnCours reliant l’utilisateur à la tâche, telle qu’à un utilisateur correspond donc une seule tâche en cours. Le problème est que cette tâche peut être segmentée en sessions : De cette relation on fait une entité-type, à laquelle on rattache une entité-type TacheDetail, identifiée relativement à TacheEnCours et qui donne le détail des sessions. Le cumul reste au niveau de TacheEnCours. Il s’agit manifestement d’une donnée calculée : à vous de voir si vous conserver l’attribut Cumul. Cela dit, l’entité-type TacheEnCours peut être porteuse d’autres données.

Tâches terminées :

Le principe de modélisation est le même, sinon qu’un utilisateur pet avoir plusieurs tâches terminées contre une seule en cours.

Je vous propose le MCD suivant (version RM/T avec graphique Entité/Relation, façon PowerAMC) :




Version Merise :






Version Diagramme de classes :






Passage au MLD :






Quelques contraintes d’unicité sont à rajouter (clés candidates) :
Table TacheEnCours : {UtilisateurId, DateDebut, HeureDebut}
Etc.

[Sieldev]

Merci pour ta réponse trés bien expliqué fsmrel.
J'en aurai surement d'autres.

[david1992]

svp quelqu'un a une aidée pour la contruction de l'MCD de la gestion des vente de pieces détachées ???

La Société VENPIECE fabrique et commercialise des pièces détachées pour automobiles qu'elle

vend à des garagistes, des grossistes, des constructeurs automobiles.



On veut construire le MCD



- A l'arrivée d'une commande d'un client, le Service Commercial enregistre à partir d'un terminal la

commande avec un numéro d'arrivée et la date d'arrivée.

- Le magasinier dispose d'un terminal. Durant la journée, il consulte la base de données pour

visualiser la liste de commandes à livrer. En fonction de la quantité en stock d'un produit

commandé, il enregistre la quantité réelle pouvant être livrée. Il édite un bon de livraison qui

servira à préparer le(s) colis.

- A partir du bon de livraison édité, le service préparation prépare le(s) colis, note sur le bon : le

poids, le nombre de colis, le nom du préparateur et rectifie la quantité livrée s'il a constaté une

anomalie dans le stock.

- Quand la préparation est terminée, le magasinier enregistre le poids, le nombre de colis, rectifie

la quantité livrée si nécessaire. Il édite le bon de livraison définitif à joindre au colis.

- En fin de journée, le Service Commercial lance la facturation des commandes préparées par le

magasinier. Il édite 2 exemplaires qu'il transmet au magasinier. Le magasinier joint les

exemplaires de facture aux colis; ils sont alors prêts à être expédiés.

- Chaque fin de journée, le magasinier édite la liste des produits en rupture de stock et à

réapprovisionner; il l'adresse au Service Approvisionnement.

- Chaque fin de mois, le Service Commercial édite le relevé des factures du mois de chaque client

et le lui adresse. Le client est tenu de régler le total des factures pour la date d'échéance en une

ou plusieurs fois au Service Comptabilité.

- En fin de journée, le magasinier enregistre les produits livrés; cette opération provoque la mise à

jour des quantités en stock. Il visualise ensuite les commandes incomplètement livrées par ordre

chronologique d'arrivée; il peut alors éditer de nouveaux bons de livraisons servant à la

préparation des colis.

- Le Service Comptabilité enregistre les règlements dès leur arrivée sur un terminal et met à jour

les comptes des clients. Si le relevé n'est pas payé 30 jours après la date d'échéance, on

déclenche une relance.

- Chaque semaine, on édite les relances des relevés non réglés dans le délai de 30 jours.

- A tout moment, le Service Commercial doit pouvoir répondre à une demande de renseignements

sur l'expédition d'une commande.

- Le Service Comptabilité souhaite avoir la possibilité d'imprimer l'état d'un compte client (relevé de

factures, règlements qui s'y rapportent) à la demande.

En esperant que vous pouvez m'aider, n'hesitez pas à demander des précisions.

Cordialement david