Nous utilisons des cookies pour vous garantir la meilleure expérience sur notre site. Si vous continuez à utiliser ce dernier, nous considèrerons que vous acceptez l'utilisation des cookies. J'ai compris ! ou En savoir plus !.
banniere

Le portail francophone de la géomatique


Toujours pas inscrit ? Mot de passe oublié ?
Nom d'utilisateur    Mot de passe              Toujours pas inscrit ?   Mot de passe oublié ?

Annonce

Printemps des cartes 2024

#1 Thu 11 January 2018 15:42

ChristopheV
Membre
Lieu: Ajaccio
Date d'inscription: 7 Sep 2005
Messages: 3169
Site web

MCD données cadastrales françaises

Bonjour,

Comme il y a des choses qui m'horripilent cf : https://georezo.net/forum/viewtopic.php?id=109219

et que beaucoup doivent penser que je passe mon temps à critiquer, je vous propose de vous livrer le MCD que j'ai conçu et que j'utilise depuis longtemps. Les valeurs attributaires ne sont pas mentionnées c'est voulu, ça sert à rien en matière de relations.

Vous pouvez comparer avec les modèles existants.

J'attends vos critiques argumentées, particulièrement de la part des concepteurs des autres modèles.


Fichier(s) joint(s) :
Pour accéder aux fichiers vous devez vous inscrire.

Christophe
L'avantage d'être une île c'est d'être une terre topologiquement close

Hors ligne

 

#2 Thu 11 January 2018 16:58

Jean-Yves G
Membre
Lieu: toulouse
Date d'inscription: 12 Oct 2005
Messages: 516

Re: MCD données cadastrales françaises

Bonjour,

je rebondis sur la colère de Christophe, toujours présent sur les questions de MCD !!! Car je suis aussi souvent effaré par la méconnaissance des BD relationnelles chez les géomaticiens ... J'ai même rencontré récemment un administrateur BD qui se savait pas ce qu'était une jointure !! Voici donc quelques défauts souvent rencontrés chez les geo-informaticiens

1 - Le modèle de données est celui des données sources .... En gros le modèle de la BD colle directement à la structure des infos reçues .... Le risque est d'avoir ensuite une BD avec plein de redondances partout .... générant un très gros boulot de mise en cohérence et surtout des requêtes compliquées ... Toute redondance est source d'incohérence (axiome No1 de la modélisation)

2 - Le SGBD est globalement utilisé comme un stockage de fichiers à plats (une table == un fichier) , avec possibilité de charger ses propres données .. ;donc modifier le modèle de la BD par n'importe qui .... Ceci génère encore une montagne d'incohérences et surtout une maintenance complexe de la BD ...  En général, au bout de 2 ans d'exploitation, il faut faire le ménage ... et là ça devient compliqué !!!

3 - On appelle MCD un modèle de tables (MLD en MERISE) , ça c'est hypercourant, ça m'énerve mais je me suis habitué !!! Relisez MERISE ....

Ce qu'il faut retenir, c'est qu'un modèle de données est surtout élaboré en regard des fonctions et traitements qui s'y appliquent (définition de vues, index et tout un tas de choses pensées par les concepteurs du modèle relationnel) ... et dans la plupart des cas, ce sont malheureusement les données sources qui imposent leur modèle pour les géo-informaticiens.

Voilà ...
JY

Hors ligne

 

#3 Thu 11 January 2018 17:19

ChristopheV
Membre
Lieu: Ajaccio
Date d'inscription: 7 Sep 2005
Messages: 3169
Site web

Re: MCD données cadastrales françaises

Bonjour,

Je rejoins JY sur la question du modèle de tables. Pour ma part j'utilise UML dans sa globalité, mais je voulais pas compliquer les choses pour les jeunes padawan.
Sur la simplicité et la redondance aussi, j'ajoute qu'avec trois tables supplémentaires au modèle présenté vous avez les données DVF en prime.
Que nous utilisons en réalité un modèle légèrement différent qui permet la gestion topologique (au sens postgis) des parcelles, sections, communes, fleuves et linéaire de voie publique. Et que nous le faisons évoluer pour prendre en compte l'intégration différentielle de différents millésimes.

Que les algorithmes sot décrits par des schémas UML, de type diagramme d'activité ou de séquence. Que le contrôle d'intégrité des données et le code erreur sont réalisés à l'intégration.

Et si je n'ai pas mentionné les valeurs attributaires je précise que les acronymes nécessaire au temps de MAJIC (l'application pas les données) sont traduit en français les DNUMPER et autres KKWWZZ deviennent des numero_personne, nature_culture, contenance,  ...
Car l'un des fondement de la modélisation c'est de parler le langage du client.

J'ajoute qu'allié à la simplicité cela permet d'écrire les requêtes de tête assez rapidement. Car c'est facile :
une commune est composée de section qui sont composées ...

SELECT * FROM cadastre.commune INNER JOIN cadastre.section ON idcommune=ptrcommune ...


Christophe
L'avantage d'être une île c'est d'être une terre topologiquement close

Hors ligne

 

Pied de page des forums

Powered by FluxBB