IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
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 :

Avis du schéma MCD "déménagement"


Sujet :

Modélisation

  1. #1
    Membre du Club
    Femme Profil pro
    Étudiant
    Inscrit en
    Décembre 2022
    Messages
    7
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Âge : 25
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Décembre 2022
    Messages : 7
    Par défaut Avis du schéma MCD "déménagement"
    Bonjour,

    J'ai un projet à faire avec ces consignes : J'ai déjà fais un MCD et j'aimerais vos avis.

    Sujet : Société de déménagement :
    Pièce jointe 631214Pièce jointe 631215
    • Un client sollicite l’entreprise pour réaliser un déménagement.
    • Un déménagement est identifié par un numéro, la date de demande. La date début prévue, la date fin prévue, la date début réelle, la date fin réelle. Ces dates permettront de calculer les écarts et ainsi connaître le taux de satisfaction client. On a besoin de connaître l’adresse du lieu à déménager et l’adresse de destination, la distance entre les deux villes. Il est nécessaire de connaître le volume en m3 des objets à déménager.

    • Le montant facturé pour un déménagement dépend aussi des prestations demandées. Un déménagement nécessite une ou plusieurs prestations. Il y a ici une CIM (une FORMULE contient une ou plusieurs PRESTATIONS, une PRESTATION est contenue dans une ou plusieurs FORMULES). Une prestation peut être par exemple. Le client choisit une formule de déménagement. Une formule est identifiée par un code, un libellé et un montant forfaitaire.
    • Le tarif M3 dépend de la FORMULE de déménagement. Mais je vous suggère de simplifier le traitement en considérant que le tarif M3 dépend uniquement du volume indiqué par le client.
    • Le tarif kilométrique est par exemple de 3,5€.
    • La facture est donc calculée ainsi : Tarif de la formule choisie + Montant € m3 (volume indiqué par le client x prix) + Kilomètres (nombre de kms x tarif kilométrique).
    • Le déménagement est assuré par du personnel à l’aide d’un ou plusieurs véhicules.
    • Un client règle sa facture à l’aide d’un mode de paiement : chèque, CB ou virement.

    Les entités :
    1. CLIENT
    2. FORMULE
    3. PRESTATION
    4. TARIF
    5. PERSONNEL
    6. VEHICULE
    7. MODE DE PAIEMENT

    Il y aura des CIF et au minimum une CIM (FORMULE – PRESTATION). Vous avez donc 8 tables minimum.
    Je dois faire un MCD et MLD à partir de ces consignes.

    Nom : Capture.PNG
Affichages : 343
Taille : 138,4 Ko
    Images attachées Images attachées
    • Type de fichier : pdf dem.pdf (401,6 Ko, 43 affichages)
    Fichiers attachés Fichiers attachés

  2. #2
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 541
    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 : 10 541
    Billets dans le blog
    10
    Par défaut
    Bonjour lolita396 et bienvenue dans ce forum

    quelques remarques d'ordre général
    Tous vos identifiants sont des varchar(50).
    L'identifiant d'un type d'entité devient la clef primaire de la table correspondante.
    Or une clef primaire doit avant tout être stable, car elle se propage dans les tables liées à cause des contraintes d'intégrité.
    Et les colonnes de type char ou varchar contiennent le plus souvent des valeurs signifiantes, qui sont susceptibles de changer.
    Typiquement, l'immatriculation d'un véhicule peut changer, c'était le cas autrefois avec les anciennes plaques d'immatriculation qui changeaient à chaque nouveau propriétaire du véhicule. Il en existe encore en circulation susceptibles de changer. Il ne faut donc surtout pas utiliser l'immatriculation comme identiant.
    De plus, les clefs primaires servent dans la plupart des jointures, elles se doivent donc d'être concises pour être performantes.
    Ces deux raisons font qu'on choisit le plus souvent une colonne technique, dénuée de sens et de type integer, comme identifiant du type d'entité et donc comme PK. Tous les SGBD proposent des identifiants attribués automatiquement, ils en gèrent tout seul l'unicité, ce qui est à la fois bien pratique, performant et fiable.

    Le typage des données et le choix de la longueur ne doivent pas être faits au hasard.
    Par exemple le volume en m3 de type varchar(50), les téléphones de type integer ou le code postal de type byte ne conviennent pas.
    Le volume, c'est du numérique avec ou sans décimales selon le besoin.
    Le téléphone et le code postal ne sont pas des nombres sur lesquels on fait des calculs, il faut donc utiliser un type char. Comme il s'agit de colonnes de petite taille, on préférera du char fixe plutôt que du varchar.

    Certaines données sont normalisées, comme les adresses postales et les adresses courriel. Il est préférable de respecter ces normes pour éviter les erreurs. Ces normes sont faciles à trouver sur le web en quelques clics.


    Pour ce qui concerne les clients et les paiements
    Comme la cardinalité est de 0,1 de client vers paiement, un client ne peut payer qu'une seule fois.
    Ce qui signifie que si la même personne fait appel à l'entreprise pour plusieurs déménagements, elle ne pourra plus payer, sauf si on doublonne le client sous un autre identifiant, c'est quand même ballot.
    Par ailleurs, qui dit paiement, dit facture, c'est obligatoire. Or, vous n'avez pas modélisé l'entité-type facture, pas plus que les lignes de facture...


    Pour ce qui concerne les clients et le personnel
    Vu les attributs retenus, tous vos clients sont des personnes physiques, vous n'avez pas à gérer des clients personnes morales, vous confirmez ?
    Vu que le personnel est aussi un ensemble de personnes physique, on comprend pourquoi la plupart des attributs sont communs entre ces deux types d'entité. Aussi, on peut utiliser l'héritage et la spécialisation : on crée un sur-type personne avec les attributs communs (nom, prénom, adresse, téléphone...) et un sous-type client et un sous-type employé pour ce qui est spécifique à l'un ou à l'autre.


    Au sujet des déménagements
    Un déménagement c'est a minima une adresse de départ et une adresse d'arrivée.
    Il arrive aussi qu'il y ait des ramassages intermédiaires et donc d'autres adresses.
    Il faut donc prévoir des adresses successives, avec un ordre de ramassage, et bien sûr ces adresses respecteront la norme de la poste.
    Même remarque que pour les paiements : la cardinalité 0,1 de client vers déménagement ne permet à un client de ne déménager qu'une seule fois...

    Liste non exhaustive

  3. #3
    Membre du Club
    Femme Profil pro
    Étudiant
    Inscrit en
    Décembre 2022
    Messages
    7
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Âge : 25
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Décembre 2022
    Messages : 7
    Par défaut
    Bonjour,

    Tout d'abord, merci pour la réponse, ça m'aide beaucoup à avancer.

    Les clients seront uniquement des particuliers pour simplifier l'application. J'ai modifié les cardinalités pour plus de cohérence.

    J'ai refait mon MCD avec des corrections, est-ce que vous pouvez me dire si c'est cohérent ?

    Nom : mcd capture.PNG
Affichages : 269
Taille : 30,7 Ko

    Merci
    Bonne fêtes de fin d'années

  4. #4
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 541
    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 : 10 541
    Billets dans le blog
    10
    Par défaut
    Bonjour,

    Voici une proposition qui me semble plus cohérente

    Comme indiqué précédemment, les employés et les clients partagent l'essentiel de leurs attributs, aussi (et à des fins didactiques), j'utilise ici l'héritage.
    J'ai considéré qu'un employé pouvait aussi occasionnellement être client, après tout pourquoi ne pourrait il pas utiliser les services de son entreprise pour déménager. D'où l'héritage de type "T" (totalité sans exclusion).

    Dans ma proposition, un même client peut commander plusieurs déménagements.
    Chaque déménagement est constitué d'au moins deux étapes (départ et arrivée), voire plus, il suffit d'en ajouter autant que nécessaire.

    L'association AF_affecter permet d'affecter un ou plusieurs employés à chaque étape d'un déménagement et connaître ainsi les disponibilités du personnel en fonction des dates des différentes étapes.

    À chaque étape, on a comme attribut le poids et le volume, ce qui permet de dimensionner le camion nécessaire au transport.
    Chaque étape est associée à une adresse, adresse aux normes de la poste (lignes de 38 caractères)
    Et chaque adresse est associée d'un coté à une ville (ce qui évite les redondances de villes avec des graphies différentes) et d'un autre au code postal.
    On ne peut pas associer directement le code postal à la ville, puisque certaines grandes villes ont plusieurs codes alors que les petites partagent un même code. La contrainte d'inclusion (cercle avec le I) permet de contrôler que le code postal choisi pour l'adresse correspond bien à l'une des villes qui utilisent ce code postal.

    Le déménagement fait l'objet d'une facture.
    J'ai choisi de permettre un règlement en plusieurs fois de cette facture (l'énoncé ne précisant rien à ce sujet), d'où le 0,n de facture vers règlement.
    Le règlement est d'un certain type (chèque, virement, carte, espèces...), grâce à un lien vers une typologie de règlements.
    Evidemment, le client peut effectuer plusieurs règlements, d'une part puisqu'il peut payer en plusieurs fois une même facture, d'autre part puisqu'il peut commander plusieurs déménagements .

    Voici donc le MCD correspondant

    Nom : MCD.png
Affichages : 267
Taille : 226,0 Ko


    Et le script SQL ici décliné à la sauce SQL server (notez le code correspondant à la contrainte d'inclusion tout à la fin) :

    Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    68
    69
    70
    71
    72
    73
    74
    75
    76
    77
    78
    79
    80
    81
    82
    83
    84
    85
    86
    87
    88
    89
    90
    91
    92
    93
    94
    95
    96
    97
    98
    99
    100
    101
    102
    103
    104
    105
    106
    107
    108
    109
    110
    111
    112
    113
    114
    115
    116
    117
    118
    119
    120
    121
    122
    123
    124
    125
    CREATE TABLE PE_personne(
       PE_ident INT IDENTITY,
       PE_nom VARCHAR(50) NOT NULL,
       PE_prenom VARCHAR(50) NOT NULL,
       PRIMARY KEY(PE_ident)
    );
     
    CREATE TABLE CL_client(
       PE_ident INT,
       CL_numero SMALLINT NOT NULL,
       PRIMARY KEY(PE_ident),
       UNIQUE(CL_numero),
       FOREIGN KEY(PE_ident) REFERENCES PE_personne(PE_ident)
    );
     
    CREATE TABLE EM_employe(
       PE_ident INT,
       EM_matricule CHAR(8) NOT NULL,
       EM_dtemb DATE NOT NULL,
       PRIMARY KEY(PE_ident),
       UNIQUE(EM_matricule),
       FOREIGN KEY(PE_ident) REFERENCES PE_personne(PE_ident)
    );
     
    CREATE TABLE DM_demenagement(
       DM_ident INT IDENTITY,
       DM_date DATE,
       PE_ident INT NOT NULL,
       PRIMARY KEY(DM_ident),
       FOREIGN KEY(PE_ident) REFERENCES CL_client(PE_ident)
    );
     
    CREATE TABLE VI_ville(
       VI_ident INT IDENTITY,
       VI_insee CHAR(5) NOT NULL,
       VI_nom VARCHAR(50) NOT NULL,
       PRIMARY KEY(VI_ident)
    );
     
    CREATE TABLE CP_code_post(
       CP_ident INT IDENTITY,
       CP_code CHAR(5) NOT NULL,
       PRIMARY KEY(CP_ident),
       UNIQUE(CP_code)
    );
     
    CREATE TABLE FA_facture(
       FA_ident INT IDENTITY,
       FA_date DATE NOT NULL,
       FA_HT DECIMAL(7,2) NOT NULL,
       FA_TVA DECIMAL(7,2) NOT NULL,
       FA_TTC DECIMAL(7,2) NOT NULL,
       DM_ident INT NOT NULL,
       PRIMARY KEY(FA_ident),
       UNIQUE(DM_ident),
       FOREIGN KEY(DM_ident) REFERENCES DM_demenagement(DM_ident)
    );
     
    CREATE TABLE YG_type_regl(
       YG_ident INT IDENTITY,
       YG_code CHAR(4) NOT NULL,
       YG_libelle VARCHAR(50) NOT NULL,
       PRIMARY KEY(YG_ident),
       UNIQUE(YG_code)
    );
     
    CREATE TABLE AD_adresse(
       AD_ident INT IDENTITY,
       AD_ligne1 VARCHAR(38) NOT NULL,
       AD_ligne2 VARCHAR(38) NOT NULL,
       AD_ligne3 VARCHAR(38) NOT NULL,
       AD_ligne4 VARCHAR(38) NOT NULL,
       AD_ligne5 VARCHAR(38) NOT NULL,
       CP_ident INT NOT NULL,
       VI_ident INT NOT NULL,
       PRIMARY KEY(AD_ident),
       FOREIGN KEY(CP_ident) REFERENCES CP_code_post(CP_ident),
       FOREIGN KEY(VI_ident) REFERENCES VI_ville(VI_ident)
    );
     
    CREATE TABLE RG_reglement(
       FA_ident INT,
       RG_ident SMALLINT,
       RG_date DATE NOT NULL,
       RG_mnt DECIMAL(7,2) NOT NULL,
       YG_ident INT NOT NULL,
       PE_ident INT NOT NULL,
       PRIMARY KEY(FA_ident, RG_ident),
       FOREIGN KEY(FA_ident) REFERENCES FA_facture(FA_ident),
       FOREIGN KEY(YG_ident) REFERENCES YG_type_regl(YG_ident),
       FOREIGN KEY(PE_ident) REFERENCES CL_client(PE_ident)
    );
     
    CREATE TABLE ET_etape(
       DM_ident INT,
       ET_seq SMALLINT,
       ET_poids DECIMAL(5,2) NOT NULL,
       ET_volume DECIMAL(5,2) NOT NULL,
       ET_dth DATETIMEOFFSET NOT NULL,
       AD_ident INT NOT NULL,
       PRIMARY KEY(DM_ident, ET_seq),
       FOREIGN KEY(DM_ident) REFERENCES DM_demenagement(DM_ident),
       FOREIGN KEY(AD_ident) REFERENCES AD_adresse(AD_ident)
    );
     
    CREATE TABLE VP_ville_cp(
       VI_ident INT,
       CP_ident INT,
       PRIMARY KEY(VI_ident, CP_ident),
       FOREIGN KEY(VI_ident) REFERENCES VI_ville(VI_ident),
       FOREIGN KEY(CP_ident) REFERENCES CP_code_post(CP_ident)
    );
     
    CREATE TABLE AF_affecter(
       PE_ident INT,
       DM_ident INT,
       ET_seq SMALLINT,
       PRIMARY KEY(PE_ident, DM_ident, ET_seq),
       FOREIGN KEY(PE_ident) REFERENCES EM_employe(PE_ident),
       FOREIGN KEY(DM_ident, ET_seq) REFERENCES ET_etape(DM_ident, ET_seq)
    );
     
    alter tabble AD_adresse
    foreign key (VI_ident, CP_ident)
    references VP_ville_cp (VI_ident, CP_ident)

  5. #5
    Membre du Club
    Femme Profil pro
    Étudiant
    Inscrit en
    Décembre 2022
    Messages
    7
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Âge : 25
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Décembre 2022
    Messages : 7
    Par défaut
    Bonjour,

    Bonne année 2023

    Merci pour cette réponse hyper complet et compréhensible. J'ai une question :

    - pour générer une facture, est-ce que je dois créer une table "facture" ou ça sera générer tout seul ?
    De même pour archiver les facture, est-ce que je dois créer une table ?

    Merci pour la réponse et de votre aide

  6. #6
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 541
    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 : 10 541
    Billets dans le blog
    10
    Par défaut
    Il faut non seulement créer une table "facture", mais aussi une table "ligne_facture" dont je n'ai pas modélisé le type d'entité dans mon MCD, celui-ci n'étant qu'une base de travail à compléter.

    Bien évidemment, il serait possible de créer une facture sans l'enregistrer dans des tables, mais ce serait illégal.

  7. #7
    Membre du Club
    Femme Profil pro
    Étudiant
    Inscrit en
    Décembre 2022
    Messages
    7
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Âge : 25
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Décembre 2022
    Messages : 7
    Par défaut
    Bonjour,

    D'accord, merci beaucoup, je vais le rajouter.
    Merci beaucoup pour votre aide
    Je vous souhaite une bonne année 2023

  8. #8
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 541
    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 : 10 541
    Billets dans le blog
    10
    Par défaut
    Merci et meilleurs voeux également

    La bonne modélisation pour facture et lignes de factures consiste à identifier les lignes relativement à la facture (présence du (R) près des cardinalités), ce qui donne pour cette partie, au niveau MCD :

    [FACTURE] 1,n --- (contenir) --- 1,1(R) [LIGNE_FACTURE] 1,1 --- (taxer) --- 0,n [TVA]
    dans [FACTURE] on trouvera comme attributs, l'identifiant technique, le numéro fonctionnel de la facture, la date, le montant HT total, le montant total de TVA, le montant total TTC etc.
    Dans [LIGNE_FACTURE], on trouvera le numéro de ligne, les montants HT, TVA et TTC ligne, etc.
    Dans [TVA] on aura un identifiant technique, un code, un taux, une date de début et une date de fin de validité

    L'intérêt d'avoir des dates de validité des taux de TVA dans [TVA] c'est que les taux changent de temps à autre (décisions gouvernementales).

  9. #9
    Membre du Club
    Femme Profil pro
    Étudiant
    Inscrit en
    Décembre 2022
    Messages
    7
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Âge : 25
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Décembre 2022
    Messages : 7
    Par défaut Formulaire MS ACCESS MAJ Ville
    Bonjour,

    Un ami doit rendre un projet sur MS ACCESS. Le but était de créer une application fictive, rien n'est réelle. C'est une entreprise de déménagement.

    Il essaye dans le formulaire "Saisie Déménagement" qu' à partir d'une liste déroulante ou les valeurs sont des codes postaux. La ville se met automatiquement. Il n'est pas doué en VBA est galère avec son code :
    If Code_postal.Value = "10000" Then Villes.Value = "Troyes"

    Nom : Capture d’écran 2023-02-03 152705.jpg
Affichages : 216
Taille : 36,7 Ko

    Est-ce que vous pouvez l'aider à automatiser ceci et tester son application aussi.

    Nom : MCD1.jpg
Affichages : 227
Taille : 131,8 Ko
    Nom : 1.jpg
Affichages : 215
Taille : 221,3 Ko
    Nom : 2 .jpg
Affichages : 222
Taille : 217,8 Ko
    Nom : 3 .jpg
Affichages : 228
Taille : 24,9 Ko

    Merci et bonne journée

  10. #10
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 541
    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 : 10 541
    Billets dans le blog
    10
    Par défaut
    On sort de la modélisation conceptuelle des données pour aborder l'aspect traitement.
    Nous sommes donc hors sujet avec le domaine de cette partie du forum , il faut poser ce type de questions dans le forum consacré à MS Access

    Notez toutefois qu'il n'y a pas bijection entre code postal et ville :
    • certaines villes ont plusieurs codes postaux (les très grandes villes)
    • certains codes postaux sont partagés par plusieurs petites villes


    Le formulaire est donc inadapté en l'état : il doit proposer une liste de villes pour un code et non pas une ville unique

    De plus, code "en dur" la correspondance est un travail fastidieux et inutile, c'est par requête qu'il faut récupérer cette correspondance.

+ Répondre à la discussion
Cette discussion est résolue.

Discussions similaires

  1. [AC-2013] Valider un schéma MCD
    Par rcoadou dans le forum Modélisation
    Réponses: 0
    Dernier message: 15/04/2016, 09h48
  2. Proposition de schéma "MCD"
    Par Micmaya dans le forum Merise
    Réponses: 4
    Dernier message: 25/05/2015, 19h55
  3. [MCD] Votre avis sur un MCD de station service
    Par Psychique dans le forum Schéma
    Réponses: 4
    Dernier message: 28/11/2009, 12h27
  4. Avis concernant mon MCD
    Par Invité dans le forum Schéma
    Réponses: 16
    Dernier message: 21/05/2007, 18h02

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