Le MCD appliqué à un SIG ne se résume pas à un diagramme entité-association classique. Dès qu’on introduit des primitives géométriques (point, polyligne, polygone, multi-polygone), des systèmes de référence spatiale et des règles topologiques, le passage du MCD au modèle logique SIG engage des choix structurants que la modélisation relationnelle standard ne couvre pas.
Contraintes topologiques et primitives spatiales : ce que le MCD SIG doit capturer
Un MCD classique décrit des entités, des attributs et des cardinalités. En géomatique, il doit aussi formaliser la dimension spatiale de chaque entité : type de géométrie, système de coordonnées de référence, contraintes d’adjacence ou de non-chevauchement entre classes d’entités.
A voir aussi : MySQL ou NoSQL : quel choix pour vos données ?
Nous observons régulièrement des projets où ces choix sont reportés au modèle logique, voire à l’implémentation physique. Le résultat : des géodatabases où les règles topologiques sont ajoutées après coup, sans cohérence avec le schéma conceptuel initial. Les corrections tardives coûtent plus cher que la modélisation amont.
Le MCD SIG doit donc expliciter, pour chaque entité géographique, au moins trois éléments : la primitive géométrique retenue, le référentiel spatial (EPSG), et les contraintes topologiques inter-classes (adjacence stricte entre parcelles, interdiction de chevauchement entre zones réglementaires, par exemple).
Lire également : Comment organiser vos révisions en vous appuyant sur MyGES ?
Du MCD SIG au modèle logique de géodatabase : les points de rupture
Le modèle logique traduit le MCD en une structure exploitable par un SGBD spatial ou une géodatabase (ArcGIS, PostGIS, GeoPackage). Cette traduction n’est jamais transparente.
Associations N:M et tables de jointure spatiales
Une relation N:M entre deux entités conceptuelles (par exemple, « un tronçon routier traverse plusieurs communes, une commune contient plusieurs tronçons ») se résout classiquement par une table de jointure. En SIG, cette table doit souvent porter elle-même une géométrie (le segment de tronçon découpé par limite communale). Le MCD ne prévoit pas toujours cette géométrie intermédiaire, et le modèle logique doit la créer.
Héritage géométrique et jeux de classes d’entités
La structuration en jeux de classes d’entités (feature datasets) dans une géodatabase repose sur un principe absent du MCD : toutes les classes d’un même jeu partagent le même référentiel spatial et les mêmes règles topologiques. Si le MCD regroupe des entités de référentiels différents sous une même super-entité, le modèle logique impose un éclatement que le concepteur n’avait pas anticipé.
Nous recommandons de valider, dès le MCD, que chaque regroupement d’entités correspond à un référentiel spatial unique. C’est une contrainte logique déguisée en choix conceptuel.
Normes ISO 19100 et conformité réglementaire du modèle SIG
Dans les secteurs soumis à des exigences d’interopérabilité (aéronautique, énergie, infrastructures critiques), les autorités imposent un alignement des modèles de données SIG sur la famille ISO 19101, 19109, 19110, 19115 et 19131. Ces normes encadrent la description des types d’entités géographiques, les catalogues d’objets, les métadonnées et les spécifications de produits de données.
L’écart entre MCD et modèle logique devient alors un risque de non-conformité. Un MCD qui ne respecte pas la structure de catalogue d’objets définie par l’ISO 19110 produira un modèle logique difficile à certifier. Dans un projet géomatique réglementé, le MCD est un livrable auditable, pas un brouillon interne.
- L’ISO 19109 définit les règles de schéma d’application pour les données géographiques : le MCD doit s’y conformer si le projet vise l’interopérabilité INSPIRE ou un référentiel national.
- L’ISO 19115 impose une structure de métadonnées qui conditionne la façon dont les attributs du MCD sont documentés et transmis au modèle logique.
- L’ISO 19131 cadre les spécifications de produits de données : le passage MCD vers modèle logique doit respecter le gabarit de spécification, sous peine de rejet par l’autorité compétente.
Structuration de la géodatabase : traduire le modèle logique en schéma exploitable
Le modèle logique SIG n’est pas un schéma relationnel avec des colonnes géométriques en plus. Il organise les données en classes d’entités, tables attributaires, domaines de valeurs codées, sous-types et règles de relation.
Les domaines de valeurs codées (coded value domains) illustrent bien la rupture avec le MCD. Au niveau conceptuel, on modélise un attribut « type d’occupation du sol » avec une liste de valeurs possibles. Au niveau logique, ce même attribut devient un domaine partagé entre plusieurs classes, avec des contraintes de validité croisées (un sous-type « voirie » n’accepte pas les mêmes valeurs qu’un sous-type « espace vert »).
- Les sous-types permettent de différencier les comportements d’une même classe d’entités sans multiplier les tables, ce que le MCD ne prévoit pas nativement.
- Les règles de relation (relationship classes) formalisent les liens entre classes avec des cardinalités et des règles de suppression en cascade, absentes du MCD Merise classique.
- Les index spatiaux et les règles de nommage des champs relèvent du modèle physique, mais leur anticipation dès le modèle logique évite des restructurations coûteuses.
Workflow projet : articuler MCD et modèle logique sans perte d’information
Dans les formations récentes sur ArcGIS, le MCD est présenté comme base directe pour la création de la géodatabase. Le workflow formalisé prévoit un passage explicite du MCD au modèle logique, puis à la géodatabase prête à l’édition, avec structuration des jeux de classes, classes d’entités, tables, champs et règles de nommage.
Ce workflow suppose que le MCD ait été construit avec la cible logique en tête. Un MCD purement Merise, sans annotation spatiale, génère un modèle logique appauvri. Nous recommandons d’annoter chaque entité du MCD avec le type de géométrie, le SRID cible et les contraintes topologiques attendues, avant toute tentative de dérivation vers le modèle logique.
La documentation du MCD conditionne aussi la maintenabilité du système. Un MCD non documenté produit une géodatabase opaque, difficile à faire évoluer quand les besoins métier changent ou quand un nouveau jeu de données doit être intégré.
Le choix entre un MCD riche (annoté spatialement) et un MCD minimaliste (purement sémantique) dépend du cycle de vie du projet. Pour un SIG patrimonial destiné à durer plusieurs années, l’investissement dans un MCD détaillé se rentabilise dès la première évolution structurelle de la base.
