Discussion :

[GasconWarrior]

Bonjour,

Je créer 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 accéder à 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 système de tag mais je ne suis pas sûr que ce soit la bonne manière de faire.

L'administrateur doit pouvoir poster des actualités en relation ou pas avec les artisants, par exemple la présentation d'un chantier réalisé.

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 démarche de commencer par le MCD, bravo.

Il faut préciser la nature de certains acteurs de votre modèle.
Par exemple les clients peuvent-ils être des personnes physiques, morales, les deux ? À préciser.
Egalement, le type qui est en lien à la fois avec l'artisan, le métier et l'entreprise peut paraitre suspect.
N'hésitez pas à fournir des exemples concrets pour illustrer vos explications

Pour s'assurer que le MCD est conforme aux besoins, il est préférable de rédiger les règles de gestion et de les faire valider par les gens du métier.
Les règles de gestion doivent se présenter sous la forme d'un identifiant unique (un numéro de règle) et d'une phrase sous la forme sujet, verbe, complément.

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 règles permettent de valider l'association (contacter) que vous avez modélisée 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 côté artisan.

Pour que ce soit complet, il faut que chaque "patte" d'association soit justifiée par une règle de gestion.
Il peut dans certains cas y avoir plus de règles, nous y reviendrons plus tard.


Par ailleurs, seuls les types d'entité doivent bénéficier d'un identifiant. L'association (contacter) ne doit donc pas avoir d'identifiant, même si elle est porteuse d'attributs.

[SQLpro]

Parmi les erreurs classiques l'absence d'entité générique "personne" avec nom et prénom... En effet est il strictement impossible qu'un artisan puisse être aussi un client ? (notamment d'un autre artisan que lui même ?)

En dehors de toute théorie, les règles basiques de modélisation sont les suivantes :
1) toute entité doit être pourvue d'une clé
2) tout attribut ne doit contenir que des données sémantiquement 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 modèle
Fort de ces 6 règles, votre modèle possède de nombreux inconvénients...

1) utilisation des attributs de nom "id", "nom", "prenom", "telephone", "libelle" plusieurs fois dans le modèle !
2) les entités artisan (pas de t) et client (avec un t) devrait hériter d'une entité générique "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 hérité de l'entité "Personne". En effet c'est une personne morale

A +