# Gnral Dveloppement > ALM > Modlisation > Schma >  Demande d'aide MCD

## GasconWarrior

Bonjour, 

Je crer un site pour un groupement d'artisants. Les visiteurs du site peuvent prendre contact avec les artisants via un formulaire de contact. Les visiteurs peuvent accder  la fiche de chaque artisant et dans cette fiche il doit y avoir trois suggestions d'artisants avec lesquels il aime ou a l'habitude de travailler. Pour pouvoir faire les suggestions j'ai pens faire un systme de tag mais je ne suis pas sr que ce soit la bonne manire de faire.

L'administrateur doit pouvoir poster des actualits en relation ou pas avec les artisants, par exemple la prsentation d'un chantier ralis.

C'est mon premier projet en autonomie et je me demande si mon mcd est ok ou pas.

Est ce que l'un ou l'une d'entre vous pourrait me dire si ce que j'ai fait est bon?

Merci d'avance

----------


## escartefigue

Bonjour et bienvenue sur ce forum  ::): 

C'est une excellente dmarche de commencer par le MCD, bravo.

Il faut prciser la nature de certains acteurs de votre modle. 
Par exemple les clients peuvent-ils tre des personnes physiques, morales, les deux ?  prciser.
Egalement, le type qui est en lien  la fois avec l'artisan, le mtier et l'entreprise peut paraitre suspect.
N'hsitez pas  fournir des exemples concrets pour illustrer vos explications  :;): 

Pour s'assurer que le MCD est conforme aux besoins, il est prfrable de rdiger les rgles de gestion et de les faire valider par les gens du mtier.
Les rgles de gestion doivent se prsenter sous la forme d'un identifiant unique (un numro de rgle) et d'une phrase sous la forme sujet, verbe, complment.

Par exemple 

R001 : un client est une personne qui a contact *au moins* un artisan
R002 : un artisan *peut* tre contact par plusieurs clients

Ces deux rgles permettent de valider l'association (contacter) que vous avez modlise entre [artisan] (attention, sans "t" final  :;): ) et [client]
*"au moins"* justifie la cardinalit minimale de 1 cot client
*"peut"* justifie la cardinalit minimale de 0 ct artisan.

Pour que ce soit complet, il faut que chaque "patte" d'association soit justifie par une rgle de gestion.
Il peut dans certains cas y avoir plus de rgles, nous y reviendrons plus tard.


Par ailleurs, seuls les types d'entit doivent bnficier d'un identifiant. L'association (contacter) ne doit donc pas avoir d'identifiant, mme si elle est porteuse d'attributs.

----------


## SQLpro

Parmi les erreurs classiques l'absence d'entit gnrique "personne" avec nom et prnom...  En effet est il strictement impossible qu'un artisan puisse tre aussi un client ? (notamment d'un autre artisan que lui mme ?)

En dehors de toute thorie, les rgles basiques de modlisation sont les suivantes :
1) toute entit doit tre pourvue d'une cl
2) tout attribut ne doit contenir que des donnes smantiquement atomiques
3) pas de redondance
4) pas de NULL (vide, inconnu, absence d'information...)
5) la modification d'une information, ne doit pas conduire  impacter plus d'une ligne. 
6) toute information doit tre identifi par un nom unique au sein du modle
Fort de ces 6 rgles, votre modle possde de nombreux inconvnients...

1) utilisation des attributs de nom "id", "nom", "prenom", "telephone", "libelle" plusieurs fois dans le modle !
2) les entits artisan (pas de t) et client (avec un t) devrait hriter d'une entit gnrique "personne"
voyez les articles que j'ai crit  ce sujet
https://sqlpro.developpez.com/cours/...tion/heritage/
https://blog.developpez.com/exercice...n_de_personnes

3) inutilit de l'entit Date

4) une entreprise devrait aussi tre hrit de l'entit "Personne". En effet c'est une personne *morale*

A +

----------

