Un modèle conceptuel de données (MCD) décrit les entités, leurs attributs et leurs associations sans présumer du logiciel qui les hébergera. Un système d’information géographique (SIG) stocke ces mêmes informations dans une géodatabase où chaque enregistrement porte une géométrie. Passer du premier au second suppose des choix de traduction précis, faute de quoi la base géographique produit des résultats incohérents dès la première requête spatiale.
Contraintes géométriques absentes du MCD : ce que le schéma théorique ne dit pas
Le MCD, issu de la méthode Merise ou d’un formalisme entité-association équivalent, ignore la composante spatiale. Une entité « Parcelle » y figure avec un identifiant, une surface et un propriétaire, mais rien n’indique si la géométrie attendue est un polygone, un multipolygone ou un simple centroïde.
Lire également : Comment convertir des Ko en Mo facilement : le guide
Cette lacune devient critique au moment de créer les classes d’entités dans la géodatabase. Le type de géométrie conditionne les règles topologiques applicables : interdire les chevauchements entre polygones adjacents, imposer la connexité d’un réseau linéaire, ou forcer un point à tomber sur un tronçon.
Pour éviter les allers-retours tardifs, la bonne pratique consiste à annoter le MCD avant toute traduction. Chaque entité porteuse d’une localisation reçoit, directement sur le diagramme, une mention du type géométrique cible et du système de coordonnées de référence. Ce complément ne modifie pas la sémantique du modèle, mais il fournit au concepteur de la géodatabase une spécification exploitable sans ambiguïté.
A lire en complément : Des exercices pour taper plus vite au clavier peuvent transformer votre productivité
Passage du MCD au modèle logique de données pour un SIG
Les règles classiques de traduction restent le socle du processus. Les entités deviennent des tables, les propriétés des colonnes, et les identifiants des clés primaires. Une association de type « un-à-plusieurs » se traduit par une clé étrangère dans la table côté « plusieurs ». Une association « plusieurs-à-plusieurs » génère une table intermédiaire.
Cardinalités et tables de jointure spatiale
Dans un SIG, la table intermédiaire peut elle-même porter une géométrie. Un réseau d’adduction d’eau, par exemple, relie des nœuds (vannes, compteurs) par des tronçons. Le MCD modélise cette relation par une association entre deux entités. Au passage en modèle logique, la table de jointure devient une classe d’entités linéaire, reliant géométriquement les deux nœuds qu’elle associe.
Omettre cette géométrie sur la table intermédiaire produit une base où les jointures attributaires fonctionnent, mais où aucune analyse de réseau (plus court chemin, zone de desserte) n’est possible.
Attributs hérités et sous-types
Le MCD recourt parfois à la spécialisation : une entité « Bâtiment » se décline en « Bâtiment industriel » et « Bâtiment résidentiel ». Deux options existent dans la géodatabase :
- Créer des sous-types au sein d’une même classe d’entités, ce qui simplifie la gestion mais impose un champ discriminant unique.
- Créer des classes distinctes liées par une relation d’héritage, ce qui autorise des attributs spécifiques à chaque sous-classe au prix d’une structure plus complexe.
- Fusionner toutes les sous-entités dans une seule table avec des colonnes nullables, solution rapide mais qui dégrade la lisibilité et complique la validation.
Le choix dépend du volume d’attributs spécifiques. Si chaque sous-entité n’ajoute qu’un ou deux champs, le sous-type suffit. Au-delà, la séparation en classes distinctes réduit le bruit dans les formulaires de saisie et les exports.
Alignement du MCD SIG avec les standards CNIG et INSPIRE
Les standards CNIG (Conseil national de l’information géographique) et la directive INSPIRE imposent des classes, des attributs et des listes de valeurs normalisées. Chaque entité du MCD doit être mise en correspondance avec la classe du standard applicable, et les écarts documentés explicitement.
Cette correspondance prend la forme d’un tableau livré avec le modèle. Le tableau liste, pour chaque entité du MCD, la classe INSPIRE ou CNIG équivalente, les attributs alignés et ceux qui constituent des extensions locales. Les attributs manquants par rapport au standard y figurent aussi, avec la justification de l’écart.
Sans ce tableau, un audit d’interopérabilité oblige à reconstituer la logique de modélisation a posteriori, ce qui rallonge la validation et génère des corrections en cascade dans la géodatabase déjà alimentée.
Métadonnées d’acquisition intégrées au modèle de données
Les guides de modélisation récents recommandent d’inscrire les métadonnées d’acquisition directement dans le MCD plutôt que de les reléguer dans un catalogue externe. Concrètement, cela revient à ajouter une entité dédiée (ou des attributs rattachés à chaque entité spatiale) pour enregistrer la source, la méthode de collecte, la date d’acquisition et la précision géométrique estimée.
Tracer la provenance de chaque objet géographique dès le MCD évite les doublons silencieux lors des mises à jour. Quand deux jeux de données couvrent la même zone avec des précisions différentes, l’attribut de précision permet de prioriser la source la plus fiable sans intervention manuelle.
Documenter le MCD SIG comme du code source avec Git
Plusieurs équipes SIG gèrent désormais le MCD et sa documentation dans un dépôt Git, selon une approche dite docs-as-code. Le diagramme est décrit dans un format textuel (PlantUML ou équivalent), versionné comme du code applicatif.
Chaque modification du modèle passe par une revue (pull request) où les impacts sur la géodatabase et les traitements en aval sont évalués avant fusion. Le journal des changements lie chaque évolution du MCD à un besoin métier identifié, ce qui simplifie la maintenance sur le long terme.
Les avantages concrets de cette approche :
- Le diff textuel entre deux versions du diagramme montre précisément les entités ajoutées, les attributs renommés ou les cardinalités modifiées.
- La génération automatique du diagramme à partir du fichier source garantit que la documentation reste synchronisée avec le modèle réel.
- L’historique Git remplace les documents Word versionnés manuellement, réduisant le risque de travailler sur un schéma obsolète.
Cette méthode demande un investissement initial (choix de l’outil, conventions de nommage, formation des contributeurs), mais elle supprime la dérive habituelle entre le MCD théorique et la géodatabase en production. Un schéma qui évolue sans trace finit par ne plus correspondre à rien. Versionner le MCD rend chaque décision de modélisation auditable, du premier brouillon jusqu’au dernier ajustement en exploitation.
