Discussion :

[viny1976]

Bonjour,

Voilà ma problématique :
je dois modéliser l'activité de saisie de X utilisateurs (agents et cadres) d'un même service répartis dans deux centres (Nord et Sud).
Chaque jour X agents enregistrent leurs activités.
Les activités sont :
PRN, AUTRES, NON SUBRO, RECLAMATIONS, DSIJ, SUBRO, COURRIERS, KDC et ECHEANCIER.
Chaque activité devient une table avec id et des propriétés.
Voila le diagramme issu de workbench
1.pdf

Comme vous le voyez à chaque utilisateurs je crée des doublons pour la date de saisie.
Comment dois je procéder pour éviter cela?
D'autres part je voudrais pouvoir faire des statistiques par semaines, mois, trimestre, semestre et année sans passer par une requete calculee dans ma programmation. Ainsi optimiser la performance de mon système comme dois je procéder?

Merci de votre aide.

[escartefigue]

bonjour,

La base de données est elle déjà en production, ou bien est elle en phase d'étude ?

[viny1976]

Bonjour escartefigue

elle est en étude.
J'ai positionné qq exemples.

[escartefigue]

En ce cas vous pouvez simplifier de beaucoup votre modèle, je reviens vers vous dès que j'ai le temps de faire une ébauche MCD

[escartefigue]

Les activités sont :
PRN, AUTRES, NON SUBRO, RECLAMATIONS, DSIJ, SUBRO, COURRIERS, KDC et ECHEANCIER.
Chaque activité devient une table avec id et des propriétés.

Il n'est pas nécessaire de faire une table par activité, il est par contre nécessaire de typer les activités, voici donc une proposition qui va dans ce sens
Les propriétés sont mises à minima, à enrichir bien sur

[viny1976]

Peux tu définir la table et la relation typer?
Quid imputation?

[escartefigue]

Les types d'activité sont ceux que vous avez définis, à savoir : PRN, AUTRES, NON SUBRO, RECLAMATIONS, DSIJ, SUBRO, COURRIERS, KDC et ECHEANCIER.
Une activité est de l'un de ces types, le libellé du type est dans l'entité-type "type activité"
J'ai ajouté l'entité-type "imputation" car le plus souvent, dans les entreprises, les activités sont associées à des codes imputation budgétaires.
Si toutefois vous n'en avez pas besoin, supprimez la ainsi que la relation "affecter"

[viny1976]

D'abord merci pour ton aide

Je vais essayer ta proposition.
Mais je vais devoir te contacter à nouveau car je n'ai pas saisi tout ton schéma

A bientôt

[viny1976]

Bonjour,

J'ai suivi au mieux tes conseils.
Voici ce que j'en ai déduit : test1.xlsx

Peux tu me dire si c'est correcte?
Par contre je ne comprends pas comment implémenter la partie "exercer".
Peux tu me donner un conseil?

D'avance je te remercie.

[escartefigue]

je dois modéliser l'activité de saisie de X utilisateurs (agents et cadres) d'un même service répartis dans deux centres (Nord et Sud).
Chaque jour X agents enregistrent leurs activités.

Par contre je ne comprends pas comment implémenter la partie "exercer".

L'association "exercer" est justement le cœur de votre MCD, ce sera le support de l'enregistrement par les agents de l'activité qu'ils ont exercée :
Un agent a exercé de telle date (Ex_Deb) à telle date (Ex_Fin), une activité, pour une durée (Ex_Durée) exprimée en unité de mesure (Ex_UM) qui pourra être des jours, heures, minutes ou autre.
Après génération du MLD, il faudra ajouter la date de début aux identifiants agent et activité dans la clef unique de la table générée (afin de permettre la saisie de plusieurs périodes pour un même agent et une même activité)

Peux tu me donner un conseil?

Le meilleur conseil que je puisse donner est de ne pas publier de document qui contient des mots de passe, même cryptés !
Pour le reste, quel est le but de ce document ?

[viny1976]

Rassurez vous pour les mots de passe, ce ne sont que des exemples que j'ai crée moi-même.

Quand vous dites "quel est le but de ce document" parlez vous du document test1.xlsx?
Si c'est le cas:
je voulais formaliser par des exemples ce que vous m'avez proposé.

Je vais formaliser mieux le but de ma BD.
Voici les règles de gestion :
RG1 : un agent appartient à un service
RG2 : un cadre est responsable de plusieurs agents.
RG3 bis :un cadre entre les soldes chaque matin.
RG4 : un agent enregistre ses activités chaque jour.
RG5 : Les activités sont de 12 types
1 prn
2 autres
3 pe_non_subro
4 réclamations
5 dsij
6 pe_subro
7 courriers
8 kdc
9 echeancier
10 absence
11 dysfonctionnement_panne_info
12 observations
RG6 : chaque type d'activité contient des taches bien précises
Pour le type activité PRN on a prn_aas,prn_pas,prn_personnel,prn_rejet,prn_sigmt
Pour le tupe activité autres on a autres_pj_diad,autres_lm2a,autres_destin,autres_ij_amexa,autres_indus,autres_rejet_diad,autres_solde_papier
etc...
RG7: le cadre doit obtenir les statistiques selon le type d'activité par jours, semaines, mois, trimestres, semestres et années.
Voilà est ce que c'est un peu plus clair

[escartefigue]

Du coup, on peut partir de ce modèle ci dans lequel j'ai ajouté l'entité-type "service" ainsi qu'une entité-tpe Rdate qui permet d'hériter de l'identifiant date dans la relation "exercer" sans avoir à bidouiller le MLD. Il faudra juste penser à ne pas génerer de table à partir de cette entité type (si vous utilisez Power-AMC, c'est en décochant la case "générer" dans l'onglet "général" de l'entité)


Concernant vos règles, ce qui compte au niveau conceptuel c'est de définir le vocabulaire, le rôle de chaque acteur, les relations entre ces acteurs et les contraintes d'intégrité fonctionnelles.

Les règles telles que "RG3 bis :un cadre entre les soldes chaque matin." ou "RG7: le cadre doit obtenir les statistiques selon le type d'activité par jours, semaines, mois, trimestres, semestres et années." sont de niveau traitement, et n'ont pas à être prise en considération pour le moment.

Pour les cardinalités, il vaut mieux ne laisser aucun doute, par exemple plutôt que d'écrire
"RG2 : un cadre est responsable de plusieurs agents"
Je préfère une formulation sans équivoque telle que
"RG2 : un cadre est responsable d'au moins un agent" si tout cadre encadre au moins un agent
Ou bien
"RG2 : un cadre peut être responsable de zéro à plusieurs agents", si certains cadres n'ont pas de responsabilité hiérarchique.

Complétez les RG pour chaque association en précisant les cardinalités mini et maxi

J'ai ajouté une date dans la relation entre utilisateur et service, en supposant qu'une personne puisse changer de service.
Peut être en est il de même entre les services et les centres. Si un service peut changer de centre, alors il faut une date de début d'effet identifiante dans la relation entre l'un et l'autre (en utilisant la même astuce que pour la relation "exercer", c'est à dire l'entité-type "Date" qui n'a que pour seul attribut, son identifiant, la date.