Discussion :

[lolita396]

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.

[escartefigue]

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

[lolita396]

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 ?



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

[escartefigue]

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




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)

[lolita396]

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

[escartefigue]

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.

[lolita396]

Bonjour,

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

[escartefigue]

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).

[lolita396]

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"



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






Merci et bonne journée

[escartefigue]

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.