Modélisation de la propriété d'une parcelle

**LudoSIGMA** · 22/02/2012, 12h00

Bonjour

Voici mon problème, je cherche à modéliser la propriété d'une parcelle à différentes dates

Si on considère l'entité propriétaire et l'entité parcelle :
un propriétaire possède de 1 à n parcelle
une parcelle est possédé par 1 à n propriétaire
On souhaite connaître la date de début et de fin de propriété ainsi que la "transmission" c'est à dire si l'acquisition est une vente ou un héritage.
Déjà est ce que ce modèle vous parait cohérent ?
y aurait il un intérêt à sortir les dates de l'association pour faire un lien avec une table date ?

Ensuite comment modéliser le fait qu'il existe un propriétaire précédent ?

En vous remerciant

Ludovic

**CinePhil** · 22/02/2012, 14h39

Déjà est ce que ce modèle vous parait cohérent ?

C'est pas mal !
Un petit détail toutefois : le fait de stocker la date de fin fait qu'il pourrait y avoir un trou entre une date de fin d'un propriétaire de la parcelle et la date de début du propriétaire suivant, alors qu'on peut théoriquement déduire la date de fin de la date de début suivante. En plus, ça oblige à rendre nullable la date de fin et le bonhomme NULL est un parasite dans les tables SQL sur lequel fsmrel tire à vue.
La date de début est suffisante, tu peux supprimer la date de fin.

Concernant la transmission, elle pourrait être externalisée dans une table de référence. La vente et l'héritage sont-elles les deux seules possibilités ? Ne peut-il y avoir la saisie, la réquisition, la transmission d'actifs... ?

Un autre détail me vient à l'esprit : le propriétaire peut être, il me semble, une personne morale qui n'a pas un nom et un prénom mais un nom et un identifiant du genre numéro de SIRET.

y aurait il un intérêt à sortir les dates de l'association pour faire un lien avec une table date ?

Il n'y a d'intérêt à faire cela que lorsuqe tu veux gérer un calendrier pour des besoins de planning ou de statistiques par dates (par exemple : combien de commande obtenues pour chaque jour du mois de janvier 2012).

Ensuite comment modéliser le fait qu'il existe un propriétaire précédent ?

On le trouve par requête dans la table... ou bien il est inconnu de la base de données !
Dans ton cas, cela me semble superflu. Les parcelles appartiennent toujours à quelqu'un, quelle que soit la date.

**LudoSIGMA** · 22/02/2012, 15h02

Merci pour ta réponse !

Envoyé par CinePhil

C'est pas mal !
Un petit détail toutefois : le fait de stocker la date de fin fait qu'il pourrait y avoir un trou entre une date de fin d'un propriétaire de la parcelle et la date de début du propriétaire suivant, alors qu'on peut théoriquement déduire la date de fin de la date de début suivante. En plus, ça oblige à rendre nullable la date de fin et le bonhomme NULL est un parasite dans les tables SQL sur lequel fsmrel tire à vue.
La date de début est suffisante, tu peux supprimer la date de fin.

Ok on considère donc que la date de fin est la date de début du propriétaire suivant c'est ça ?

Envoyé par CinePhil

Concernant la transmission, elle pourrait être externalisée dans une table de référence. La vente et l'héritage sont-elles les deux seules possibilités ? Ne peut-il y avoir la saisie, la réquisition, la transmission d'actifs... ?

En fait ce qui nous intéresse dans la transmission c'est uniquement de savoir si il y a de l'argent en jeux, donc argent ou pas d'argent (désolé j'aurai du le préciser)

Envoyé par CinePhil

Un autre détail me vient à l'esprit : le propriétaire peut être, il me semble, une personne morale qui n'a pas un nom et un prénom mais un nom et un identifiant du genre numéro de SIRET.

Effectivement, je me renseigne pour savoir si cela concerne notre projet ou si on ne s'intéresse qu'aux personnes physiques.

Envoyé par CinePhil

Il n'y a d'intérêt à faire cela que lorsuqe tu veux gérer un calendrier pour des besoins de planning ou de statistiques par dates (par exemple : combien de commande obtenues pour chaque jour du mois de janvier 2012).

OK

Envoyé par CinePhil

On le trouve par requête dans la table... ou bien il est inconnu de la base de données !
Dans ton cas, cela me semble superflu. Les parcelles appartiennent toujours à quelqu'un, quelle que soit la date.

Tu veux dire que pour connaître le ou les proprio précédents, il faudrait faire une requête du genre :
Sélection des propriétaires possédants telle parcelle et dont la date d'acquisition est la première inférieur à la date d'acquisition de la même parcelle par un autre propriétaire
C'est bien ça ? Comment préciser qu'on ne veut que la date inférieur la plus proche ? C'est ce même genre de requête qui pourrait nous donner la date de fin de propriété d'une parcelle par un propriétaire ?

Merci beaucoup

**Richard_35** · 22/02/2012, 15h25

Bonjour LudoSIGMA et CinePhil,

Je me permets de m'immiscer, CinePhil, sur une problématique intéressante qui revient souvent.

LudoSIGMA, je rejoins, en partie, CinePhil :

Code :

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

1
2
3
Personne ---0,n---[transmettre (vendeur)]---0,n--- Parcelle
   |                                                   |
   ---------0,n---[recevoir (acheteur)]-----0,n---------

ce qui donnerait :

Personne(IdPersonne, ...) ;
Parcelle(IdParcelle, ...) ;
Transaction(#IdPersonneVendeur, #IdParcelle, DateTransaction, TypeTransaction, #IdPersonneAcheteur, ...).
==> trigger IdPersonneVendeur<>IdPersonneAcheteur
==> index unique IdPersonneAcheteur, IdParcelle, DateTransaction

Donc, la période de propriété de X, pour la parcelle Y, via Transaction est :

de {IdPersonneAcheteur=X/IdParcelle=Y/DateTransaction}
à {IdPersonneVendeur=X/IdParcelle=Y/DateTransaction - 1jour}

Seulement, je ne sais pas si ce schéma est bien "dans la norme"...

**LudoSIGMA** · 22/02/2012, 15h37

Merci pour ta réponse

Envoyé par Richard_35

Personne(IdPersonne, ...) ;
Parcelle(IdParcelle, ...) ;
Transaction(#IdPersonneVendeur, #IdParcelle, DateTransaction, TypeTransaction, #IdPersonneAcheteur, ...).
==> trigger IdPersonneVendeur<>IdPersonneAcheteur

J'avais un peu pensé à cela également mais je ne voyais vraiment pas comment le représenter dans mon modèle (j'ai bien tenté une relation partant de mon association "possèdeParcelle" vers l'entité "propriétaire" mais ce n'est pas possible dans analyse si, je me suis donc un peu demandé si j'avais le droit de faire des choses comme cela.

Merci

**CinePhil** · 22/02/2012, 16h12

Envoyé par LudoSIGMA

Ok on considère donc que la date de fin est la date de début du propriétaire suivant c'est ça ?

Oui.

En fait ce qui nous intéresse dans la transmission c'est uniquement de savoir si il y a de l'argent en jeux, donc argent ou pas d'argent (désolé j'aurai du le préciser)

Change le nom de la propriété/colonne et passe au type booléen alors.

Tu veux dire que pour connaître le ou les proprio précédents, il faudrait faire une requête du genre :
Sélection des propriétaires possédants telle parcelle et dont la date d'acquisition est la première inférieur à la date d'acquisition de la même parcelle par un autre propriétaire
C'est bien ça ?

Oui.

Comment préciser qu'on ne veut que la date inférieur la plus proche ?

On sort du schéma pour entrer dans le SQL là !
Ce genre de cas a déjà été abordé dans les forums SGBD.

C'est ce même genre de requête qui pourrait nous donner la date de fin de propriété d'une parcelle par un propriétaire ?

Oui, sauf que cette fois on cherche la plus petite date de transaction supérieure à celle de la transaction du propriétaire actuel pour la même parcelle.

Les deux requêtes se font par auto-jointure.

Envoyé par Richard_35

Code :

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

1
2
3
Personne ---0,n---[transmettre (vendeur)]---0,n--- Parcelle
   |                                                   |
   ---------0,n---[recevoir (acheteur)]-----0,n---------

Il me semble que ton schéma comporte deux associations indépendantes.
Il n'y a a priori pas de correspondance entre la transmission et la réception. La transmission ne permet pas de savoir à qui la parcelle a été transmise et la réception ne permet pas de savoir de qui vient la parcelle.
Ces deux associations donnent lieu normalement à deux tables associatives et si on les remplit correctement, il y a une certaine redondance de données sur les dates et une incohérence potentielle de celles-ci.

ce qui donnerait :
Personne(IdPersonne, ...) ;
Parcelle(IdParcelle, ...) ;
Transaction(#IdPersonneVendeur, #IdParcelle, DateTransaction, TypeTransaction, #IdPersonneAcheteur, ...).

Ce MPD serait plutôt issu de ce MCD :
personne -0,n----effectuer----(1,1)- transmission -(1,1)----concerner----0,n- parcelle
|---------------0,n----bénéficier----1,1----------| |------------(1,1)----avoir-lieu----0,n- (Date)

L'entité type Date est ici fictive pour matérialiser la participation de la date à l'identification de la transaction.

==> trigger IdPersonneVendeur<>IdPersonneAcheteur
==> index unique IdPersonneAcheteur, IdParcelle, DateTransaction

OK là dessus pour ton MPD.

Note aussi que ton schéma fait qu'une transaction ne peut se passer qu'entre une seule personne acheteuse et une seule personne vendeuse ou bien qu'on doive multiplier les lignes pour les propriétaires multiples, avec là encore un risque d'incohérence de données.

Le schéma de LudoSigma est-il meilleur ?
Je le reprends ici en format texte :
Propiétaire -1,n----posséder----1,n- parcelle

Traduction :
Un propriétaire possède de une à plusieurs parcelles et une parcelle est possédée par un à plusieurs propriétaires.

Cela semble meilleur mais rien n'empèche que la parcelle P soit possédée par A et B à des dates différentes alors qu'ils sont réellement co-propriétaires si on fait une erreur de date.

Il serait peut-être alors meilleur de reconsidérer la transaction en tant qu'entité propre.

Règles de gestion :
1) Une transaction est signée à une seule date et une date peut voir signer plusieurs transactions.
2) Une transaction concerne de une à plusieurs parcelles et une parcelle peut être concernée par plusieurs transactions.
3) Une transaction est vendue par une à plusieurs personnes et une personne peut vendre plusieurs transactions.
4) Une transaction est achetée par une à plusieurs personnes et une personne peut acheter plusieurs transactions.

MCD :
personne -0,n----vendre----1,n- transaction -1,n----concerner----0,n- parcelle
|---------------0,n----acheter----1,n-------| |-----------1,1----signer----0,n- (Date)

Tables :
personne (prs_id, prs_nom...)
parcelle (prc_id, prc_numero, prc_section, prc_geom, prc_surface)
transaction (trs_id, trs_date, trs_est_financiere)
prs_acheter_trs (pat_id_acheteur, pat_id_transaction)
prs_vendre_trs (pvt_id_vendeur, pvt_id_transaction)
trs_concerner_prc (tcp_id_transaction, tcp_id_parcelle)

Tous ceux qui sont co-propriétaires d'une parcelle le sont bien en même temps et s'ils sont co-propriétaires en même temps de plusieurs parcelles, ça marche aussi.

**Richard_35** · 22/02/2012, 16h31

Envoyé par CinePhil

.../... une transaction ne peut se passer qu'entre une seule personne acheteuse et une seule personne vendeuse .../...

==> exact. La multi-propriété énoncée par LudoSIGMA m'avait échappé. Ce qui justifie :

personne (prs_id, prs_nom...)
parcelle(prc_id, prc_numero, prc_section, prc_geom, prc_surface)
transaction(trs_id, trs_date, trs_est_financiere)
prs_acheter_trs (pat_id_acheteur, pat_id_transaction)
prs_vendre_trs(pvt_id_vendeur, pvt_id_transaction)

mais, à mon avis, une transaction ne concerne qu'une parcelle, non ?
si oui, alors :

transaction(trs_id, prc_id, trs_date, trs_est_financiere)

si non, alors :

transaction(trs_id, trs_date, trs_est_financiere)
trs_concerner_prc (tcp_id_transaction, tcp_id_parcelle)

La balle est dans le camp de LudoSIGMA...

NB : Perso, mais c'est un détail, je préfère "#" à l'italique pour les clés étrangères car, sous Chrome, impossible de conserver la mise en forme lors d'un copier/coller.

**LudoSIGMA** · 23/02/2012, 09h41

Bonjour et tout d'abord un grand merci à vous deux.
J'ai repris les différents modèles proposés en intégrant vos suggestions de modification :
1 - Le modèle de départ modifié par vos soins
2 - Le modèle proposé par CinePhil avec une transaction qui concerne de 1 à n parcelles
3 - Le modèle proposé par CinePhil modifié par Richard_35 avec une transaction qui concerne 1 et 1 seule parcelle.

Je pense qu'en théorie, une transaction doit pouvoir concerner 1 à plusieurs parcelles, mais en pratique, je ne suis pas sur que nous ayons l'information et probablement que par rapport aux informations que nous avons on risque gérer cela en considérant qu'une transaction ne concerne qu'une et une seule parcelle. (il faut que je me renseigne pour pouvoir trancher)

J'ai bien sur d'autres interrogations

A quoi sert l'association signer ? pour moi elle est identique à l'association concerne ? Je me trompe ?
Si je pars du 3 ème modèle, j'obtiens ce MLD

Personne (idPersonne, Nom, Prenom)
Parcelle (idParcelle, numeroPar, numeroSection, Geom, Surface)
transaction (idTransaction, DateTransaction, presenceArgent, #idParcelle, #idParcelle_signer)
vendre (idPersonne, idTransaction)
acheter (idPersonne, idTransaction)

Si je reprends les règles de gestion énoncé pour la transaction :

1) Une transaction est signée à une seule date et une date peut voir signer plusieurs transactions. (ici si je ne me trompe le fait qu'une date peut voir signer plusieurs transactions n'apparait pas dans le modèle, pour cela il faudrait créer une entité date ? (dans l'hypothèse où cela aurait un intérêt comme vu précédemment) - en relisant cette règle, je me demande si quelque chose ne pas un peu échappé au niveau de l'association signer ... ?
2) Une transaction concerne de une à plusieurs parcelles et une parcelle peut être concernée par plusieurs transactions. (ici on simplifierai peut être en considérant qu'une transaction concerne 1 et 1 seule parcelle)
3) Une transaction est vendue par une à plusieurs personnes et une personne peut vendre plusieurs transactions.
4) Une transaction est achetée par une à plusieurs personnes et une personne peut acheter plusieurs transactions.

Du coup, hormis mes interrogations concernant l'association signer que j'ai surement mal compris, je trouve ce modèle plutôt très satisfaisant.

Si vous pouviez me préciser cette association "signer", cela serait formidable

Merci beaucoup

PS : désolé pour la question SQL, en effet ce n'est pas le lieu, ma question était plus dans le sens est ce possible, ça semble l'être, c'est donc parfait, j'irai chercher comment plus tard.

**CinePhil** · 23/02/2012, 10h19

A quoi sert l'association signer ? pour moi elle est identique à l'association concerne ? Je me trompe ?

L'association signer matérialise ma première règle de gestion entre la date (entité type fictive) et la transaction.

Mais c'est vrai que, maintenant qu'on a fait de Transaction une vraie entité type et non plus une entité associative, la date peut simplement être une propriété de l'entité type Transsaction.

Mon MCD devient alors celui-ci :

personne -0,n----vendre----1,n- transaction -1,n----concerner----0,n- parcelle
|---------------0,n----acheter----1,n-------|

1) Une transaction est signée à une seule date et une date peut voir signer plusieurs transactions. (ici si je ne me trompe le fait qu'une date peut voir signer plusieurs transactions n'apparait pas dans le modèle, pour cela il faudrait créer une entité date ? (dans l'hypothèse où cela aurait un intérêt comme vu précédemment) - en relisant cette règle, je me demande si quelque chose ne pas un peu échappé au niveau de l'association signer ... ?

Ce que je viens d'écrire doit rendre les choses bien plus claires.

2) Une transaction concerne de une à plusieurs parcelles et une parcelle peut être concernée par plusieurs transactions. (ici on simplifierai peut être en considérant qu'une transaction concerne 1 et 1 seule parcelle)

À toi de voir quel est le cas réel et donc la bonne règle de gestion.

**LudoSIGMA** · 23/02/2012, 10h32

Cela me semble parfait ainsi !
Un très grand merci à tous les deux, je passe en résolu le sujet mais je reviendrai poster le modèle définitif lorsque j'aurai tranché concernant la règle numéro 2. (je ne peux pas trancher tout seul)

**asfort** · 25/02/2012, 10h37

Bonjour,
connaissant un peu le sujet, je me permet de glisser une petite suggestion à ta modélisation.

Lorsque tu gères des parcelles cadastrales, il te faut tenir compte de la vie de ta parcelle.
En effet une parcelle est créée à une date donnée et est rendue "inactive" à une date donnée.
Il te faut tenir compte de cela car une parcelle cadastrale peut être renommée pour une raison d'arpentage, ou de corrections de limites, ou divisée en plusieurs parcelles, ou réunie avec d'autres parcelles, voir même disparaitre par suite d'incorporation au Domaine Public.
Il te faut pouvoir faire (dans le cadre de recherches sur l'historique) le lien entre les générations de parcelles "mère" et "fille".

exemple: Une parcelle AN 200 est arpentée à la demande de son propriétaire, elle sera alors renumérotée en AN 350.
Si tu ne fais pas de lien entre les deux tu n'auras pas d' actes d'aquisition de la parcelle 350, et si tu renommes ta parcelle AN 200 en AN 350 tu perdras l'historique et ta transaction ne correspondra plus au actes de vente-acquisition.

Tu dois gerer ce lien création, filiation, sinon ta base d' "actes" (vocabulaire plus officiel que celui de "transactions") deviendra très vite, ingérable.

**Richard_35** · 25/02/2012, 12h33

Bonjour Asfort,

Intéressantes remarques "métier".

La discussion ouverte par LudoSIGMA concerne la vente de parcelles donc, en quelque sorte, en aval du sujet que tu abordes : une parcelle A est cédée à X par Y.

Mais, effectivement, en amont, il y "une vie" des parcelles qu'il faut nécessairement gérer, à l'étude de tes remarques. LudoSIGMA possède, peut-être, l'application qui va bien.

Sinon, il s'agit d'une autre histoire...

**LudoSIGMA** · 02/05/2012, 11h56

Bonjour

Cela fait un moment que je ne suis pas passé par ici, tout d'abord, je vous joins le modèle que nous avons retenu.

Merci pour les autres retours, pour l'étude qui nous concerne, nous avons choisi de ne pas prendre en compte la vie de la parcelle, en effet, l'étude se base sur la numérisation des parcelles cadastrales napoléoniennes et nous n'avons pas la possibilité de suivre la vie d'une parcelle dans le temps, nous partons donc sur ce référentiel en gardant en tête que certains problèmes pourront peut être apparaître et nous les gérerons au cas par cas (en espérant qu'ils ne seront pas trop nombreux).

En fait la gestion des parcelles n'est qu'une partie de notre modèle.

Merci à tous pour votre aide