Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Modélisation Discussion :

MCD Saisie d'imputations


Sujet :

Modélisation

  1. #1
    Futur Membre du Club
    Homme Profil pro
    Développeur VBA débutant
    Inscrit en
    octobre 2017
    Messages
    10
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 28
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Développeur VBA débutant

    Informations forums :
    Inscription : octobre 2017
    Messages : 10
    Points : 7
    Points
    7
    Par défaut MCD Saisie d'imputations
    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.




    Nom : mcd_projet.png
Affichages : 88
Taille : 38,1 Ko

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

  2. #2
    Expert éminent sénior

    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    5 414
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 5 414
    Points : 16 331
    Points
    16 331
    Billets dans le blog
    1
    Par défaut
    Bonjour,

    Citation Envoyé par Revy2H Voir le message
    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 ?


    Citation Envoyé par Revy2H Voir le message
    Mon problème ici étant le cycle entre Tache, Users et Imputations.
    Je ne vois aucun cycle.


    Citation Envoyé par Revy2H Voir le message
    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,


    Citation Envoyé par Revy2H Voir le message
    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


    Citation Envoyé par Revy2H Voir le message
    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).

  3. #3
    Futur Membre du Club
    Homme Profil pro
    Développeur VBA débutant
    Inscrit en
    octobre 2017
    Messages
    10
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 28
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Développeur VBA débutant

    Informations forums :
    Inscription : octobre 2017
    Messages : 10
    Points : 7
    Points
    7
    Par défaut
    Bonjour escartefigue, et tout d'abord merci de ta réponse.


    Citation Envoyé par escartefigue Voir le message
    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.


    Citation Envoyé par escartefigue Voir le message
    Je ne vois aucun cycle.
    Au temps pour moi alors



    Citation Envoyé par escartefigue Voir le message
    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 :

    Nom : powerdesigner.png
Affichages : 67
Taille : 17,8 Ko

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





    Citation Envoyé par escartefigue Voir le message
    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.

    Citation Envoyé par escartefigue Voir le message
    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.

  4. #4
    Expert éminent sénior

    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    5 414
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 5 414
    Points : 16 331
    Points
    16 331
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par Revy2H Voir le message
    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.


    Citation Envoyé par Revy2H Voir le message
    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 :
    Citation Envoyé par Revy2H Voir le message
    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.

    Citation Envoyé par Revy2H Voir le message
    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é :/


    Citation Envoyé par Revy2H Voir le message
    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


    Citation Envoyé par Revy2H Voir le message
    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

Discussions similaires

  1. Confirmer la valeur saisie dans un imput
    Par lio908 dans le forum Interfaces Graphiques
    Réponses: 3
    Dernier message: 03/06/2012, 20h04
  2. Réponses: 3
    Dernier message: 19/03/2003, 16h19
  3. [debutant]Limiter le temps de saisi
    Par Nasky dans le forum C
    Réponses: 5
    Dernier message: 17/03/2003, 16h47
  4. [Kylix] saisie d'@ IP kylix2 OE
    Par sdoura2 dans le forum EDI
    Réponses: 1
    Dernier message: 10/11/2002, 02h54
  5. [Kylix] crypter la saisie sous kylix
    Par nahmsath dans le forum EDI
    Réponses: 2
    Dernier message: 15/10/2002, 14h16

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo