Discussion :

[Revy2H]

Bonjour à tous,

J'aimerai avoir votre avis sur le MCD que j'ai créé.

Le but est de créer une application (VBA) permettant de saisir ses imputations.
On doit pouvoir faire la liste des imputations par projet, par utilisateur, par jour ...

Mon problème ici étant le cycle entre Tache, Users et Imputations.

Lorsqu'un Utilisateur s'impute, il doit avoir la liste des taches qui lui ont été affectées en amont.
L'imputation est donc reliée à un utilisateur ainsi qu'à une tâche.

J'avais pensé à créér une table de liaison entre les les 3 entités, cependant, cela créait beaucoup de duplications de données, étant donné qu'un utilisateur peut saisir jusqu'à 4 imputations par jour.






Je reste à votre écoute pour d'éventuelles questions/remarques.

[escartefigue]

Bonjour,

Le but est de créer une application (VBA) permettant de saisir ses imputations.
On doit pouvoir faire la liste des imputations par projet, par utilisateur, par jour ...

Qui dit MCD dit règles de gestion, où sont elles...
Vous parlez de projet mais vous n'avez pas modélisé d'entité-type correspondante, est-ce un oubli ?

Mon problème ici étant le cycle entre Tache, Users et Imputations.

Je ne vois aucun cycle.

Lorsqu'un Utilisateur s'impute, il doit avoir la liste des taches qui lui ont été affectées en amont.

Ce que vous mentionnez là est du ressort des traitements,

L'imputation est donc reliée à un utilisateur ainsi qu'à une tâche.

Non : les liens entre les types d'entité ne sont pas la conséquence des traitements mais des règles de gestion
Exemples de règles :
R001a : une imputation concerne un et un seul utilisateur
R001b : un utilisateur peut être concerné par plusieurs imputations

J'avais pensé à créér une table de liaison entre les les 3 entités, cependant, cela créait beaucoup de duplications de données, étant donné qu'un utilisateur peut saisir jusqu'à 4 imputations par jour.

Il ne faut pas réfléchir en termes de tables, mais en termes de types d'entité et d'associations et donc au préalable en posant les règles de gestion.
Les tables concernent le MLD et le MPD, ces schémas tabulaires sont générés automatiquement à partir du MCD par n'importe quel logiciel de modélisation


Par ailleurs, bizarrement, seule l'association "lia_user_tache" est de type MCD, le reste du schema est plutôt un MLD qu'un MCD.
Enfin, choisir un type varchar comme identifiant primaire, qui plus est de 255 de long, est dangereux et contre-performant (T_Ref_Val_Activite).

[Revy2H]

Bonjour escartefigue, et tout d'abord merci de ta réponse.

Qui dit MCD dit règles de gestion, où sont elles...
Vous parlez de projet mais vous n'avez pas modélisé d'entité-type correspondante, est-ce un oubli ?

Effectivement, je n'ai pas pensé à écrire les règles de gestions, mais elles sont implicites et apparaissent dans mes relations, voir capture d'écran ci-après.
Pour la partie projet je l'ai exclue volontairement de l'affichage.

Je ne vois aucun cycle.

Au temps pour moi alors

Ce que vous mentionnez là est du ressort des traitements,
Non : les liens entre les types d'entité ne sont pas la conséquence des traitements mais des règles de gestion
Exemples de règles :
R001a : une imputation concerne un et un seul utilisateur
R001b : un utilisateur peut être concerné par plusieurs imputations

Voici une capture d'écran du logiciel PowerDesigner :



Je me sers donc bien des règles de gestion pour faire le liens entre les diverses entités.

Il ne faut pas réfléchir en termes de tables, mais en termes de types d'entité et d'associations et donc au préalable en posant les règles de gestion.
Les tables concernent le MLD et le MPD, ces schémas tabulaires sont générés automatiquement à partir du MCD par n'importe quel logiciel de modélisation

J'ai trop tendance à vouloir tout faire d'un coup. J'ai fait ce "MCD" via PowerDesigner.

Par ailleurs, bizarrement, seule l'association "lia_user_tache" est de type MCD, le reste du schema est plutôt un MLD qu'un MCD.
Enfin, choisir un type varchar comme identifiant primaire, qui plus est de 255 de long, est dangereux et contre-performant (T_Ref_Val_Activite).

C'est marrant parce que pour moi cette association serait plutôt du genre MPD dans le sens ou elle serait créée automatiquement au vue des cardinalités (0,n/0,n) entre utilisateur et tâche.
Pour ce qui est de l'entité T_REF_VAL_Activité, elle correspond à un référentiel de valeur (ici CREA, EVOL, ANO etc...) je ne voyait pas vraiment l'interêt de rajouter un champ identifiant.

[escartefigue]

Effectivement, je n'ai pas pensé à écrire les règles de gestions, mais elles sont implicites et apparaissent dans mes relations, voir capture d'écran ci-après.
Pour la partie projet je l'ai exclue volontairement de l'affichage.

Effectivement les règles impliquent les cardinalités, mais pas seulement, elles peuvent aller au delà, par exemple, révéder des contraintes d'intégrité fonctionnelles (CIF)
De plus, les règles sont ce qui permet à la maitrise d'ouvrage de valider le document avant de modéliser. Ca évite les erreurs.

Je me sers donc bien des règles de gestion pour faire le liens entre les diverses entités.

Certes, mais je réagissais à ce propos (et notamment le "donc" qui établit à tort un lien de cause à effet entre traitement et liens d'association :

Lorsqu'un Utilisateur s'impute, il doit avoir la liste des taches qui lui ont été affectées en amont.
L'imputation est donc reliée à un utilisateur ainsi qu'à une tâche.

J'ai trop tendance à vouloir tout faire d'un coup. J'ai fait ce "MCD" via PowerDesigner.

Bon produit mais malheureusement trop couteux pour un usage privé :/

C'est marrant parce que pour moi cette association serait plutôt du genre MPD dans le sens ou elle serait créée automatiquement au vue des cardinalités (0,n/0,n) entre utilisateur et tâche.

Non car dans le MLD et le MPD, la notion d'association a disparu, les associations sont devenues soit des clefs étrangères (FK) ajoutées dans la table coté cardinalité maxi 1 de la relation, soit une nouvelle table si l'association avait des cardinalités maxi n de chaque côté. La différence entre MLD et MPD est que le MPD tient compte du choix du SGBD au contraire du MLD qui reste - comme son nom l'indique - au niveau logique et donc indépendant de ce choix.
La modélisation de type RECTANGLE / OVALE avec cardinalités mentionnées est bien le modèle entité-association, c'est à dire un MCD
La modélisation de type RECTANGLES reliés par des flèches est soit un MLD, soit un MPD

Pour ce qui est de l'entité T_REF_VAL_Activité, elle correspond à un référentiel de valeur (ici CREA, EVOL, ANO etc...) je ne voyait pas vraiment l'interêt de rajouter un champ identifiant.

Une colonne identifiante (on ne parle pas de "champ" dans une base de données ) d'un type approprié (integer en général) est très importante, car :
- les types char et varchar sont sémantiques, donc les valeurs sont potentiellement instables. Si un jour une valeur change, vous risquez de propager via les contraintes de type "reference" des mise à jour en cascade dans un très grand nombre de lignes filles. Dans les cas extrèmes, ça peut mettre par terre le moteur de la BDD.
même si les modifications ne sont pas très fréquentes, elles arrivent (communes qui fusionnent, département renumérotés (la corse dans les années 80, la seine et oise dans les années 60), pays qui changent de nom et donc de code (ex la haute volta devenue burkina faso) etc...
- les types char et varchar sont beaucoup plus encombrants que de l'integer pour un même nombre de valeurs possibles. Espace disque et réseau en sont inutilement encombrés.
- les types char et varchar sont sensibles à la collation : les instructions order by, group by, distinct présenteront des résultats différents selon telle ou telle table si la collation est différente.
- le varchar provoque des déplacements de pages de data et d'index en cas de changement de longueur, là encore c'est très couteux en terme de perfs.
A l'inverse un type integer, attribué par le SGBD est à la fois stable car dénué de sens, insensible à la collation et très concis. Idéal donc pour une PK