Discussion :

[Belinformatic]

- qu'il n'y a qu'1 et 1 seul acheteur : vrai ?

Non, il peut y avoir plusieurs acheteurs, mais un seul notaire pour tous les acheteurs.

- qu'il y a 1 ou plusieurs vendeurs : vrai ?

Oui, mais à la différence des acheteurs, les vendeurs peuvent avoir des notaires différents.

[Richard_35]

Donc, pour un même DOSSIER :

Il n'y a qu'1 et 1 seul acheteur : vrai ?

Non, il peut y avoir plusieurs acheteurs, mais un seul notaire pour tous les acheteurs.

DOSSIERS ---(1,n)---[a, pour acheteurs]---[est/sont le(s) acheteur(s) du dossier]---(0,n)---PERSONNES ==> table intermédiaire pour gérer le n---n
DOSSIERS ---(1,1)---[a, pour notaire acheteurs]---[est le notaire acheteurs de]---(0,n)---NOTAIRE.



Il y a 1 ou plusieurs vendeurs : vrai ?

Oui, mais à la différence des acheteurs, les vendeurs peuvent avoir des notaires différents.

DOSSIERS ---(1,n)---[a, pour vendeurs]---[est/sont le(s) vendeurs(s) du dossier]---(0,n)---PERSONNES
DOSSIERS ---(1,n)---[a, pour notaire vendeur]---[est le notaire vendeur de]---(0,n)---NOTAIRES ==> table intermédiaire pour gérer le n---n

[Belinformatic]

D'après ce que je comprends, maintenant, on peut bien avoir plusieurs vendeurs et plusieurs notaires "vendeurs".
Par contre, je ne vois toujours pas comment faire, si par exemple, pour un dossier donné, on cherche le notaire associé au 3ème vendeur.
Pour moi, dans l'état actuel des choses, on a une liste de vendeurs et une listes de notaires "vendeurs", mais on peut pas connaître le détail.
Désolé d'insister, mais si j'ai tort, j'ai vraiment du mal à comprendre

Ce que j'ai fait ici n'est pas bon? (si on ne tient pas compte d'ACQUISITION)

Pièce jointe 75610

L'association "Rédiger" représente le notaire qui a rédigé l'acte de vente.

[Richard_35]

Par contre, je ne vois toujours pas comment faire, si par exemple, pour un dossier donné, on cherche le notaire associé au 3ème vendeur.
Pour moi, dans l'état actuel des choses, on a une liste de vendeurs et une listes de notaires "vendeurs", mais on peut pas connaître le détail.

==> Exact. Mais la réponse est (un peu) là

==> table intermédiaire pour gérer le n---n

DOSSIERS
- Id_bien (PK)
- Id_dossier (PK)
- Id_Notaire_Acheteur
...
==> table des dossiers (achat/vente). 1 ligne par bien/dossier. 1 seul notaire acheteur(s).

DOSSIERS_VENDEURS
- Id_bien (PK)
- Id_dossier (PK)
- Id_Vendeur (PK)
...
==> tables de vendeurs pour un dossier. 1 ligne par bien/dossier/vendeur.

DOSSIERS_VENDEURS_NOTAIRES
- Id_bien (PK)
- Id_dossier (PK)
- Id_Vendeur (PK)
- Id_Notaire_Vendeur (PK)
...
==> tables des notaires des vendeurs pour un dossier. 1 ligne par bien/dossier/vendeur/notaire.

Bien entendu, les clés du père se reportent, intégralement, sur les clés du fils, avec un champ clé supplémentaire pour établir l'unicité.

Je te laisse rédiger les relations ?

[Belinformatic]

Bon alors là je comprends plus rien...

Je ne suis pas très à l'aise avec MERISE, mais avec ce type de notation en plus je n'arrive plus à suivre.

Donc maintenant on parle de clés étrangères, mais alors que fait Id_Bien partout puisque le bien n'est lié qu'au dossier?
Du coup je ne comprends pas les "1 ligne par bien/dossier/vendeur", "1 ligne par bien/dossier/vendeur/notaire".

Bref, je suis perdu.

Si on pouvait repartir de l'extrait de MCD que j'ai cité dans le message précédent, pour voir ensemble ce qui ne va pas et pourquoi, je pense que ça serait plus simple.

Merci

[Richard_35]

Donc maintenant on parle de clés étrangères

==> non, non, il s'agit de reporter la clé unique du père sur ses fils : logique.

mais alors que fait Id_Bien partout puisque le bien n'est lié qu'au dossier?

==> c'est vrai, donc il fait bien partie de la clé primaire des fils (c'est une clé primaire multi-champs).

Du coup je ne comprends pas les "1 ligne par bien/dossier/vendeur", "1 ligne par bien/dossier/vendeur/notaire".

==> la clé primaire de DOSSIERS_VENDEURS est Id_bien et Id_dossier et Id_vendeur (multi-champs) ;
la clé primaire de DOSSIERS_VENDEURS_NOTAIRES est Id_bien et Id_dossier et Id_vendeur et Id_Notaire (multi-champs).



Je suis descendu au niveau des tables justement parce que je croyais que ce serait plus clair. Et j'ai nommé la table de telle manière que nous voyions l'arborescence.

Si on pouvait repartir de l'extrait de MCD que j'ai cité dans le message précédent, pour voir ensemble ce qui ne va pas et pourquoi, je pense que ça serait plus simple.

==> OK.
DOSSIERS ---1,n---[vendre]---1,1 VENDEURS ;
VENDEURS ---1,n---[notaires vendeur]---1,1 NOTAIRES.



Est-ce plus clair ?

[Belinformatic]

Bonjour Richard_35,

Merci beaucoup, en effet c'est plus clair pour moi

Par contre, le problème maintenant, c'est qu'un notaire est lié à un vendeur pour un dossier donné. Or ici, le notaire est lié au vendeur sans prendre en compte le dossier.
C'est pour ça que j'ai fait une relation ternaire, les 3 entités sont liées (il faudra peut-être juste une contrainte d'unicité puisqu'un vendeur, pour un dossier donné, ne peut avoir qu'un seul notaire).
En quoi ma relation ternaire ne convient pas?

il s'agit de reporter la clé unique du père sur ses fils

C'est justement le principe des clés étrangères non?

[Richard_35]

Bonjour Belinformatic,

En quoi ma relation ternaire ne convient pas?

==> Si, elle convient. Il s'agit, en fait de ma remarque du post #18 :

==> Si, mais elle se situe au niveau d'une affaire (d'un dossier) puisque le vendeur peut changer de notaire à sa prochaine vente. Donc, en fait, il me semble qu'une personne a un notaire par défaut (le notaire de famille, par exemple), mais lors d'une vente elle peut décider de passer par un autre notaire (celui qui sera indiqué dans le dossier).

D'autre part,

il s'agit de reporter la clé unique du père sur ses fils

C'est justement le principe des clés étrangères non?

==> Très intéressante remarque de fond !
Eh bien, non, justement : il y a une différence entre une clé étrangère, qui se représente, dans l'application, par une liste déroulante (avec choix vide ou non), et une clé de type père-fils qui est, en fait, une arborescence dans laquelle "on rentre par le père" (si j'ose dire), pour accéder au fils.

[Belinformatic]

Si, elle convient. Il s'agit, en fait de ma remarque du post #18

Ah d'accord ^^

En ce qui concerne les clés étrangères, je faisais bien la différence entre les 2, sauf que je pensais qu'on parlait de clé étrangère dans les 2 cas, partant du principe qu'elle vient d'une autre table.
Bon à savoir.

Donc à priori, ma modélisation te semble correcte maintenant?

[Richard_35]

En incluant toutes les remarques validées depuis ton post #23, oui.
Sauf, peut-être, pour l'entité ACQUISITION dont je ne connais pas la signification.

[Belinformatic]

Ah oui, au niveau d'ACQUISITION, j'ai remodéliser:



L'acquisition représente comment le vendeur a acquis le bien qu'il vend (donation, achat, succession...)
pour un dossier donné, les vendeurs peuvent ne pas avoir acquis le bien de la même manière.
Je rajouterai une contrainte d'unicité puisque pour un dossier donné, un vendeur ne peut avoir qu'un seul type d'acquisition.

Ca me semble correct, on est d'accord?

[Richard_35]

OK, donc pour chaque vendeur, à l'occasion de la vente (DOSSIER), tu indiques comment il a acquit le bien (ou la part du bien).

Sinon, oui, ça paraît pas mal : je te suggère de vérifier, quand même, l'ensemble des entités/relations que tu as validées, éventuellement de confirmer ta validation (pour toi-même) et de bien contrôler leur représentation graphique.

Ensuite, eh bien, bon développement !...

[Belinformatic]

Ok! Merci beaucoup pour ta patience!
Je me lance dans la suite!

A bientôt!