Discussion :

[Ktalyst]

Bonjour à tous,

Après pas mal de recherches et de 'refactoring', je bloque sur une partie de mon MCD et toute aide est la bienvenue !

J'expose mon problème :

• Un employé peut travailler sur plusieurs taches en même temps,
• Une tache est attribuée à un seul employé à un moment donné mais peut être attribuée à un autre employé au cours du projet,
• Un employé doit enregistrer une charge de travail par jour pour charque tache qui lui est assignée,
• Une tache a une charge initiale. Son RAF (reste à faire) est égal à la charge init lors de la création de la tache,
• Un employé rempli un "step" en fin de semaine qui est initialisé avec toutes les taches qui lui sont attribuées et dont le RAF (reste à faire) est différent de zéro,
• En fin de semaine, le système doit enregistrer le nouveau RAF de la tache,

J'espère que vous me suivez toujours
Voici un premier "jet" de mon mcd :

Merci d'avance pour votre aide

[fatbob]

En premier lieu, une petite remarque sans grande importance : je n'ai rien contre les modèles en français ni ceux en anglais, par contre, j'éviterais de mixer les deux (step/employee). De même dans "jour ouvré" on a deux mots séparés par un espace alors que HistoStep est en camel case et travailleHisto est en plus dans l'autre sens. Je pense qu'un choix normalisé est avantageux ne serait-ce que pour l'impression qui se dégage du modèle.
Sinon :
- Je n'ai pas très bien saisi ce qu'était un step ni en quoi consiste le fait de le remplir. Du coup, j'ai un peu de mal à cerner si ce qui l'entoure est bien modélisé mais je pense que le numéro_semaine serait mieux placé dans le step que dans la relation "rempli".
- Je ne vois pas à quoi sert le raf dans "travaille". Celui de la tâche suffit, non ?
- A quoi sert la table "jourOuvré" Une date est une date. La plupart des moteurs ou langages fournissent les fonctions permettant de savoir le jour de la semaine ou si le jour est ouvré ou non. Dans ce modèle, il va falloir créer un enregistrement dans cette table pour chaque jour et cela me semble bien inutile.
Par ailleurs, je ne vois pas tellement l'intérêt des "histo". Si les "step" et les "travaille" sont datés, l'historique se construira de lui même sans nécessité de transvaser les enregistrements dans d'autres tables.

[Ktalyst]

Déjà, merci de me répondre !

Désolée, c'est du brouillon et le modèle final sera beaucoup plus propre.

Pour vous répondre, un step permet d'enregistrer les charges de travail pour chaque tache. Je mets un exemple en pièce jointe.
Celà permet un suivi des taches. Quand on crée une tache, on lui attribue une charge initiale. Si lundi j'ai travaillé sur la tache, j'attribue 1 à la charge pour lundi. Et ainsi de suite. En fin de semaine, le RAF de la tache vaut alors la charge init - les charges.
Ce qui me pose problème c'est que tout doit être enregistré pour d'autres besoins.
Et chaque fin de semaine, un employé doit avoir rempli son step.

[Ktalyst]

J'ai modifié mon mcd d'après ce que vous m'avez dit :

[fatbob]

Bien. En fait, le step, c'est un rapport d'activité. C'est ce que je soupçonnais mais je suis dur à la comprenette et, quand il s'agit de modèles, j'aime bien être sûr.
Le modèle est déjà plus simple :-) Mais on peut encore le simplifier, à mon avis.

Questions :
- un step ne concerne bien qu'un et un seul employé ?
- qu'est ce que veut dire "constaté". Est-ce la somme des temps passés à la tâche pendant la semaine ? Si c'est le cas, il n'est pas utile de la stocker.

Options que je choisirais (ce n'est bien sûr pas obligatoire)
Désolé pour le formalisme, je n'ai pas d'outil très adapté.


J'enlève l'entité "jour ouvré". Je ne vois pas à quoi ça sert. Il s'agit d'un simple calcul à partir de la date.
De même, j'ai mis "numéro de semaine" dans step car un step correspond à une semaine (si j'ai bien compris). On pourrait remplacer ce numéro par les dates de début et de fin de semaine, le premier pouvant être calculé à partir des dernières et inversement.
De cette façon, les travaux effectués dans la semaine sont les enregistrements de "effectue" dont la date est comprise entre celles de la semaine en question.
Il est aussi possible de matérialiser cette affectation par une relation entre "step" et "effectue" mais cela ne me semble pas vraiment judicieux car cela implique de vérifier que la date du travail est cohérente avec le numéro de la semaine du step.

Toutes ces remarques sont à considérer comme des suggestions correspondant à ma compréhension du problème.
Chacune peut (doit) être discutée car je n'ai peut-être pas saisi certaines subtilités.

[fsmrel]

Bonsoir Ktalyst,


Si le reste à faire pour une tâche est calculable, alors il est redondant et l’attribut Raf doit disparaître de l’entité-type TACHE.

Si les données correspondant à un step sont calculables, toujours au nom de la redondance, on ne les modélise pas.


Vous noterez que, dans le MCD ci-dessous, les codes définis par l’utilisateur (matricule de l’employé, code de la tâche) ont été ravalés au rang d’identifiants alternatifs. Les motifs invoqués à ce sujet figurent notamment ici, vous y trouverez les observations d’Yves Tabourier).

Pour le moment, le MCD ressemble à ceci :






Vous remarquerez que la date d’affectation ne dépend que de l’employé et de la tâche, elle doit donc sortir de la ternaire et intégrer l’association AFFECTATION.

Conformément à la représentation des contraintes en Merise, La flèche rouge connectant AFFECTATION et GALERE (conservez vos propres noms !) représente une contrainte d’inclusion : un employé ne peut passer du temps sur une tâche que s’il y a d’abord été affecté. La flèche rouge connectant l’entité-type EMPLOYE et l’association GALERE symbolise une CIF (contrainte d’intégrité fonctionnelle), laquelle représente la règle selon laquelle, pour une tâche, à une date donnée, il n’y a qu’un seul employé.

Les mickeys <pi> symbolisent les identifiants des entités-types. Les mickeys <ai> symbolisent les identifiants alternatifs.



Le MLD correspondant :




Les mickeys <pk> symbolisent les clés primaires des tables. Les mickeys <ak> symbolisent les clés alternatives. Les mickeys <fk> symbolisent les clés étrangères, c'est-à-dire les contraintes d’inclusion (contraintes référentielles) entre les tables.



Variante MySQL Workbench :



MWB laisse cachées les clés alternatives.

A quoi sert la table "jourOuvré"

C’est une contrainte de MCD en Merise. Voyez la discussion avec wafiwafi. Cela dit, un AGL comme DB-MAIN permet de s’en passer (voyez à nouveau la discussion avec wafiwafi).

[Ktalyst]

Bonjour et merci pour vos réponses !

Je confirme que le Raf et les données du Step sont calculables.

Vos remarques et conseils m'ont beaucoup aidée. Je vais enfin pouvoir finir mon MCD et donc débloquer ma situation !
Merci fsmrel, j'ai beaucoup appris grâce à ta réponse !