Discussion :

[Belinformatic]

Bonjour,

Je travaille actuellement sur un MCD de gestion immobilière.
Mais il y a un détail que je ne parviens pas à modéliser:

Je comptais faire une entité "BIEN" et une entité "DOSSIER", de cette manière, si un bien se retrouve en vente plusieurs fois, il suffit de créer un nouveau dossier.
Cependant, imaginons qu'un bien, entre deux ventes, évolue (une pièce en plus/moins par exemple), il faut que l'état du bien lors de la vente précédente soit conservé (relativement au dossier).
Or dans ce cas de figure, je ne vois pas comment faire sinon créer un nouveau bien...
Sinon, je pourrais avoir uniquement la table "DOSSIER" contenant les informations du bien, mais j'ai l'impression ça serait mieux séparé (ai-je tort?)

Merci à ceux qui essaieront de m'éclairer.

[Richard_35]

Bonjour Belinformatic,

C'est une problématique qui revient souvent : le stockage des informations à un instant donné (exemple : les factures dont il faut conserver le taux de TVA au moment de l'édition de la facture, et non pas prendre celui du jour où nous voulons re-éditer cette facture).

Dans ton cas, si j'ai bien compris, tu as les entités suivantes :

BIENS
- Id_bien (PK)
- Libelle
...

DOSSIERS
- Id_bien (PK)
- Id_dossier (PK)
- Date_dossier
...

Relation
BIENS ---(0,n)---[a pour dossier]---[est le dossier de]---(1,1), via Id_Bien.


Suggestion : 2 méthodes :

1. - lister, exhaustivement, les informations de BIENS à conserver à la date du dossier, et les recopier dans la table DOSSIERS ;
2. - gérer un historique des modifications de BIENS pour pouvoir "pointer" sur l'état du bien à une date donnée.

Dans le premier cas, cela donnerait :
BIENS
- Id_bien (PK)
- Libelle
- Nombre_pieces
...

DOSSIERS
- Id_bien (PK)
- Id_dossier (PK)
- Date_dossier
- Nombre_pieces
...

Relation
BIENS ---(0,n)---[a pour dossier]---[est le dossier de]---(1,1), via Id_Bien.


Dans le second cas, cela donnerait :
BIENS
- Id_bien (PK)
- Libelle
...

BIENS_HISTORIQUE
- Id_bien (PK)
- Date_evenement (PK)
- Nombre_pieces
...

DOSSIERS
- Id_bien (PK)
- Id_dossier (PK)
- Date_dossier
...

Relation
BIENS ---(0,n)---[a pour dossier]---[est le dossier de]---(1,1), via Id_Bien ;
BIENS ---(1,n)---[a pour historique]---[est l'historique de]---(1,1), via Id_Bien.

Tu vois, à peu près, le principe.

[Belinformatic]

Merci de répondre aussi rapidement!

Alors si j'ai bien compris:

- Dans le premier cas, j'ai dans mon entité "DOSSIER" toutes les informations relatives au biens, ce qui revient donc à la même chose que de ne pas avoir d'entité "BIEN", sauf qu'on n'a pas a retaper les informations du biens en cas de nouvelle vente.

- Dans le deuxième cas, j'utilise une entité supplémentaire qui ne sert qu'en cas de modification du bien.

C'est bien ça?
Si oui j'ai l'impression que la deuxième solution est meilleure, dans le sens où elle évite de surcharger "DOSSIER", et elle est remplie uniquement quand c'est utile.

(Je serai de retour lundi, en attendant... Bon Week End )

[Richard_35]

- Dans le premier cas, j'ai dans mon entité "DOSSIER" toutes les informations relatives au biens, ce qui revient donc à la même chose que de ne pas avoir d'entité "BIEN", sauf qu'on n'a pas a retaper les informations du biens en cas de nouvelle vente.

Pas tout à fait :

- lister, exhaustivement, les informations de BIENS à conserver à la date du dossier, et les recopier dans la table DOSSIERS ;

==> pas toutes les informations, uniquement celles qui doivent être mémorisées à une date donnée.

- Dans le deuxième cas, j'utilise une entité supplémentaire qui ne sert qu'en cas de modification du bien.

C'est bien cela : attention, il faut alimenter l'historique également à la création du bien (données initiales).

Si oui j'ai l'impression que la deuxième solution est meilleure, dans le sens où elle évite de surcharger "DOSSIER", et elle est remplie uniquement quand c'est utile..

Effectivement, c'est plus propre... mais, c'est plus compliqué... Dans mon exemple de facture, les logiciels commerciaux recopient les données à stocker pour une date donnée.

[Belinformatic]

pas toutes les informations, uniquement celles qui doivent être mémorisées à une date donnée.

Oui bien sûr, mais dans mon cas, je dois mémoriser presque toutes les informations (sur environ 25 propriétés, j'en ai une ou deux qui ne changeront jamais).

Du coup, avec la première solution, je pourrais carrément me passer de l'entité "BIEN" non?

J'avais commencer mon MCD de cette manière (voir pièce jointe)

J'ai donc 3 entités reliées à "BIEN".
En adaptant mon MCD avec les méthodes suggérées, ces 3 entités seront reliées à "DOSSIER" dans le premier cas, et "BIEN_HISTORIQUE" dans le deuxième?

("LOT" représente les éventuels caves, parking etc... liés au bien)

[Richard_35]

Bonjour Belinformatic,

Du coup, avec la première solution, je pourrais carrément me passer de l'entité "BIEN" non?

==> surtout pas !... En effet, tu n'aurais plus de table comportant 1 ligne par bien, ce qui serait regrettable pour deux raisons, entres autres :
- si, par la suite, tu a besoin de stocker des informations au niveau d'un bien et non de ses dossiers, ce sera impossible ;
- tu devras procéder, uniquement, par requêtes de regroupement, pour avoir 1 ligne par bien.
Cela répond à ta question :

En adaptant mon MCD avec les méthodes suggérées, ces 3 entités seront reliées à "DOSSIER" dans le premier cas

La seconde solution est, comme tu l'as compris, plus propre. Donc, ton MCD semble correct avec les 3 entités supplémentaires. Il manque juste :
BIENS
- Id_bien (PK)
- Libelle
...

BIENS_HISTORIQUE
- Id_bien (PK)
- Date_evenement (PK)
- Nombre_pieces
...

Relations
BIENS ---(0,n)---[a pour dossier]---[est le dossier de]---(1,1), via Id_Bien ;
BIENS ---(1,n)---[a pour historique]---[est l'historique de]---(1,1), via Id_Bien.

Quant à la relation entre DOSSIERS et BIENS_HISTORIQUE, nous pourrions la représenter ainsi :
BIENS_HISTORIQUE ---(0,n)---[a pour dossier]---[est le dossier de]---(1,1)--- DOSSIERS, via Id_Bien et 1ère Date_evenement inférieure ou égale à Date_Dossier.

[Belinformatic]

Merci beaucoup pour ces précisions, je comprends mieux.

Cependant, je viens d'aborder le sujet avec ma direction, et finalement, on ne va pas prendre en compte l'historique de l'évolution du bien.
Je suis quand même content d'en avoir appris un peu plus ^^

Je posterai mon MCD quand j'aurai avancé un peu plus.

[Belinformatic]

Bonjour,

Alors voilà la première version du MCD.

Je ne vais aborder pour l'instant que les parties me posant de problèmes.

Au niveau des mariages, j'ai créé une entité "CONJOINT", le problème est que le conjoint peut être un "VENDEUR", mais pas forcément. Je ne vois pas trop comment le modéliser...

J'ai des entité reliées au "DOSSIER" alors qu'elles le seraient logiquement au "BIEN" ("TYPE BIEN", "LOT" etc), mais vu que la notion d'historique n'a pas été retenue, ça permettrait, je pense, de garder quand même certains changements potentiels. Mais je ne suis pas sûr de bien faire...

Sinon, y'a-t-il des "monstruosités" dans mon MCD à première vue? ou même de simples erreurs?

[Belinformatic]

Voilà une deuxième version.

Avec des sous-types de "PERSONNE", permettant d'alléger un peu le tout, et surtout de régler le problème du mariage (je crois).

Finalement, j'ai relié les entités me faisant douter au "BIEN", la modélisation est plus logique.

Je pense que ça commence à ressembler à quelque chose.

[Richard_35]

Bonjour Belinformatic,

En supprimant la notion d'historique du bien, tu supprimes l'objet de ce fil... non ?

Par contre, désolé, je ne peux pas me pencher sur ton MCD global. Je préfère que tu isoles les parties qui te posent problèmes et que nous les étudiions ensemble.

[Belinformatic]

Bonjour Richard_35,

En supprimant la notion d'historique du bien, tu supprimes l'objet de ce fil... non ?

Le sujet est la gestion de ventes immobilières, donc je voyais plutôt ça globalement. L'historique étant le point qui me bloquait dans la réalisation du MCD, j'ai ouvert la discussion à ce propos, désolé si j'ai eu tort.

Par contre, désolé, je ne peux pas me pencher sur ton MCD global

C'est déjà sympa de me répondre ^^ (t'es quand même le seul à le faire)

Pour parler de parties précises:

- Il reste des problèmes par rapport au "NOTAIRE".
Du côté "ACHETEUR", il ne peut y avoir qu'un seul "NOTAIRE" (ce n'est pas le cas dans mon MCD).
Du côté "VENDEUR", il peut y avoir différents "NOTAIRE", mais pas forcément (le MCD me semble correct à ce niveau).
Comment puis-je corriger ça?

- En ce qui concerne l'entité "ACQUISITION", qui représente la façon dont le bien a été acquis par le vendeur (achat, succession etc...), je l'ai reliée directement au dossier, mais je pense que ça serait plus propre s'il y avait un lien direct avec le vendeur. A première vue, je la relierais à l'association "Vendre", mais je ne suis pas sûr de moi...

[Belinformatic]

Pour résoudre ces problèmes, j'ai modifier mon MCD de cette façon



Cependant, j'ai "Gérer achat" qui est porteuse alors que c'est une association père/fils.

[Richard_35]

Bonjour Belinformatic,

Je ne comprends pas bien.

Tu indiques la relation :
BIEN ---(0,n)---[a, pour dossier]---[est le dossier de]---(0,1)--- DOSSIER
Il me semble que c'est plutôt :
BIEN ---(0,n)---[a, pour dossier]---[est le dossier de]---(1,1)--- DOSSIER
==> je suppose qu'il n'existe pas de dossier qui ne concerne aucun bien, non ?

D'autre part, une personne peut avoir un notaire "par défaut" et passer par un autre notaire pour une opération particulière.

Enfin, sur un même dossier, il ne devrait y avoir qu'un seul notaire "acheteur" et un seul notaire "vendeur", non ?

[Belinformatic]

Oui en effet, je me suis pas trop penché sur les cardinalités encore, par défaut je mets tout à 0 en minimum.

Enfin, sur un même dossier, il ne devrait y avoir qu'un seul notaire "acheteur" et un seul notaire "vendeur", non ?

Il ne peut y avoir qu'un seul notaire "acheteur", mais ce ne pas forcément les cas des vendeurs (notamment en cas de divorce, chaque partie peut avoir son propre notaire).

[Belinformatic]

Après reflexion, cette version me semble plus adaptée



L'association "Rédiger" représente le notaire qui a rédigé l'acte de vente.
Il faut juste que je précise qu'il est le notaire "acheteur" ou un des notaires "vendeurs".
Je pensais a une contrainte d'inclusion, je vais chercher un peu.

Sinon globalement la modélisation me semble plus propre de cette façon.

[Richard_35]

Nous obtenons donc :

DOSSIERS
- Id_bien (PK)
- Id_dossier (PK)
- Id_Notaire_Acheteur
...

DOSSIERS_NOTAIRES_VENDEURS
- Id_bien (PK)
- Id_dossier (PK)
- Id_Notaire_Vendeur (PK)
...

Relations :
DOSSIERS ---(1,1)---[a, pour notaire acheteur]---[est le notaire acheteur de]---(0,n)---NOTAIRES
DOSSIERS ---(1,n)---[a, pour notaire vendeur]---[est le notaire vendeur de]---(0,n)---NOTAIRES

[Belinformatic]

Je ne comprends pas très bien.

qu'est ce que "DOSSIERS_NOTAIRES_VENDEURS"?

Relations :
DOSSIERS ---(1,1)---[a, pour notaire acheteur]---[est le notaire acheteur de]---(0,n)---NOTAIRES
DOSSIERS ---(1,n)---[a, pour notaire vendeur]---[est le notaire vendeur de]---(0,n)---NOTAIRES

Il n'y a pas de relation entre "VENDEUR" et "NOTAIRE"?
Comment sait-on quelle notaire est associé à un vendeur?

[Richard_35]

Eh bien, la réponse est dans les relations :
DOSSIERS ---(1,1)---[a, pour notaire acheteur]---[est le notaire acheteur de]---(0,n)---NOTAIRES
DOSSIERS ---(1,n)---[a, pour notaire vendeur]---[est le notaire vendeur de]---(0,n)---NOTAIRES

Il n'y a pas de relation entre "VENDEUR" et "NOTAIRE"?

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

Comment sait-on quelle notaire est associé à un vendeur?

==> Voir réponse précédente.

[Belinformatic]

Alors peut être que j'ai du mal à comprendre, mais dans le cas où il y ait plusieurs vendeurs avec des notaires différents, si le seul lien entre notaire et vendeur se situe au niveau du dossier, on ne sait plus quel notaire va avec quel vendeur non?

[Richard_35]

Dans un dossier (qui est une affaire achat/vente), tu considères donc :
- qu'il n'y a qu'1 et 1 seul acheteur : vrai ?
- qu'il y a 1 ou plusieurs vendeurs : vrai ?