Discussion :

[sapoczka]

Bonjour à tous et merci d'avance de l'aide que vous m’apporterez et du temps que vous accorderez à ma requête,

Je dois réaliser un mcd, puis un mld d'un système de gestion et je n'ai pas encore eu de cours sur la modélisation. Je me suis donc formée sur le tas et j'aurais besoin de votre aide pour valider/corriger/optimiser mon schéma :

dont voici le sujet et les règles :

Si le mcd est correct, je voudrais savoir comment passer au mld pour les contraintes d'héritage si possible.

Mille fois merci encore !

[escartefigue]

Bonjour Sapoczka,

Tout d'abord, félicitations, pour une première c'est de bonne facture
D'une part le contexte est expliqué et quelques règles de gestion sont fournies, ce qui n'est pas toujours le cas, malheureusement.
D'autre part, je vois que vous avez consulté d'autre sujets et bénéficié de certains enseignements glanés çà et là, j'en veux pour preuve, l'utilisation de l'identification relative ou l'externalisation des téléphones et des adresses

Quelques observations après un survol rapide de votre MCD :

entité-type Membre et ses sous-types
Les sous-types n'ont aucun attribut spécifique et c'est un héritage de type "Totalité". Du coup, je ne suis pas convaincu de leur intérêt.
À partir du moment où un membre propose un bien, c'est un vendeur
À partir du moment où un membre achète un bien ou le met en favori, c'est un acheteur



association "proposer"
Un même bien peut il être mis en vente dans plusieurs agences ?



association "gérer"
Que représente l'attribut "quantité" ? Certainement pas le nombre de bien gérés puisque c'est le nombre d'occurrences de l'association qui permet de le connaître.
À préciser



entité-type "bien" et ses sous-types
Plutôt que de stocker le nombre de pièces du bien, ce qui n'a pas forcément de sens (ex : garage) et manque de précision, il me semble préférable d'associer à un bien 0 à n pièces, chacune ayant des caractéristiques (type, superficie, exposition, type de revêtement du sol, type de revêtement mural...)
BIEN 0,n --- posseder --- (1,1R) PIECE 1,1 --- 0,n TYPE_PIECE



Le passage du MCD au MLD dépend du logiciel de modélisation utilisé.
Avec Looping qu'il ma semblé reconnaître dans votre modèle, le MLD et le SCRIPT SQL sont construits en temps réel lors de la réalisation du MCD. Mais c'est un MLD textuel (pas de MLD graphique dans la version actuelle)
Avec d'autres logiciels tels que DB-Main ou Power-AMC il faut utiliser des options de menu et ça se fait en quelques clics

[sapoczka]

Bonjour à vous escartefigue,

Tout d'abord, merci beaucoup pour le temps que vous m'accordez et pour toutes ces remarques constructives que je vais pouvoir mettre en œuvre grâce à vous.

- Alors, concernant l'externalisation des téléphones et des adresses, j'ai effectivement suivi les conseils trouvés à droite et à gauche en me renseignant. Cependant, je ne suis pas certain d'avoir bien fait de mettre un numéro de téléphone dans les entités 'agence' et 'agent'. Devrais-je aussi les relier à l'entité téléphone, si l'on part du principe qu'ils ne peuvent avoir qu'un seul numéro ?

A ce sujet, serait-il judicieux de rajouter l'agent aux membres si dans l'application, ils peuvent tous les trois s'authentifier avec des rôles distincts et avoir accès à des fonctionnalités différentes ?

- Pour ce qui est du bien, il ne peut être mis en vente que dans une seule agence. Mais je ne sais pas trop si l'association ternaire est correcte. En effet, je voulais faire ressortir qu'un vendeur propose plusieurs biens à une ou plusieurs agences.

- Pour tout le reste, je vais faire les modifications de ce pas. J'y pensais, mais je n'étais pas certain de devoir le faire. Maintenant, cela me parait évident.

Encore merci pour vos précieux conseils qui m'aident beaucoup à avancer et évoluer !

[SQLpro]

Bonjour à vous escartefigue,

Tout d'abord, merci beaucoup pour le temps que vous m'accordez et pour toutes ces remarques constructives que je vais pouvoir mettre en œuvre grâce à vous.

- Alors, concernant l'externalisation des téléphones et des adresses, j'ai effectivement suivi les conseils trouvés à droite et à gauche en me renseignant. Cependant, je ne suis pas certain d'avoir bien fait de mettre un numéro de téléphone dans les entités 'agence' et 'agent'. Devrais-je aussi les relier à l'entité téléphone, si l'on part du principe qu'ils ne peuvent avoir qu'un seul numéro ?

Oui, le principe est que dans un modèle, une même information (n° de telephone) ne doit figurer qu'une seule fois. Pour cela il faut synthétiser agence/agent/membre en une seule entité avec héritage.

A +

[escartefigue]

- Alors, concernant l'externalisation des téléphones et des adresses, j'ai effectivement suivi les conseils trouvés à droite et à gauche en me renseignant. Cependant, je ne suis pas certain d'avoir bien fait de mettre un numéro de téléphone dans les entités 'agence' et 'agent'. Devrais-je aussi les relier à l'entité téléphone, si l'on part du principe qu'ils ne peuvent avoir qu'un seul numéro ?

Si l'agence possède un et un seul numéro de téléphone, le positionner ici est pertinent.
Idem pour l'agent.
Si au contraire l'agent peut avoir plusieurs numéros de téléphone, alors, il est préférable de faire comme pour les membres.
D'ailleurs, l'agent, comme les membres, étant une personne physique, vous auriez pu utiliser l'héritage pour mutualiser les attributs communs à toutes ces personnes. L'agent possède peut-être des attributs particuliers (matricule par exemple) auquel cas un sous-type pour l'agent se justifie.
Si vous faites ainsi, le téléphone est en relation avec les personnes et donc avec les agents

- Pour les sous-types de membre, je pensais qu'étant donné que chaque sous-type à son rôle et des associations distinctes, je devais mettre en place l'héritage. Sinon, comment faire pour distinguer un vendeur d'un acheteur, ? Rajouter une entité 'type_membre' ?

Comme je le disais précédemment : par requête.
Si un membre propose un bien, alors c'est un vendeur
Si un membre choisit un favori ou effectue une transaction, alors c'est un acheteur

A ce sujet, serait-il judicieux de rajouter l'agent aux membres si dans l'application, ils peuvent tous les trois s'authentifier avec des rôles distincts et avoir accès à des fonctionnalités différentes ?

Oui, voir ce qui précède

Pour ce qui est du bien, il ne peut être mis en vente que dans une seule agence. Mais je ne sais pas trop si l'association ternaire est correcte. En effet, je voulais faire ressortir qu'un vendeur propose plusieurs biens à une ou plusieurs agences.

Il faut modifier la cardinalité en 0,n puisqu'une même agence peut avoir plusieurs propositions (mais de vendeurs différents).

Le MCD est donc le suivant (j'ai également mis 0,n côté personne pour autoriser la mutualisation des vendeurs et des acheteurs dans une entité-type unique)
Pièce jointe 558108

Au niveau tabulaire (MLD ou MPD) la table des biens héritera en clef étrangère de l'identifiant de la personne proposant le bien et de l'identifiant de l'agence à laquelle le bien est proposé
Exemple de script résultant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
CREATE TABLE BI_BIEN(
   BI_ident COUNTER,
   PE_ident INT NOT NULL,
   AG_ident INT NOT NULL,
   PRIMARY KEY(BI_ident),
   FOREIGN KEY(PE_ident) REFERENCES PE_PERSONNE(PE_ident),
   FOREIGN KEY(AG_ident) REFERENCES AG_agence(AG_ident)
);

- Par contre, pour l'association transaction, est-ce bon, ou devrais-je plutôt relier l'association au vendeur et non à l'agence ? Comment faire pour appliquer les frais d'agence si je relie l'association au vendeur ?

Décrivez les règles de gestion associées aux transactions

[sapoczka]

Merci beaucoup pour votre aide et tous ces renseignements. Je vais essayer de me débrouiller pour le reste de mon côté.

Juste avant de marquer le sujet en résolu, pourriez-vous me dire ce que vous pensez de la qualité du modèle ? peut-on optimiser encore plus ou cela suffira-t-il amplement ?

Merci encore pour tout et bon courage pour le confinement !

[escartefigue]

Comme dit plus haut, pour un premier essai, c'est très encourageant