Introduction
Ce document porte sur l'historisation des données de la
BDUni (Base de Données Unifiée). Il s'inscrit dans un travail de
recherche, au cours d'un stage de février à mai 2013 sur
l'intégration de la dimension temporelle aux données pour la
future mise à jour du RGFor (Référentiel
Géographique Forestier), dans le cadre du projet OCS GE (OCcupation du
Sol à Grande Échelle). Il doit répondre par ailleurs
à un besoin interne de documentation sur l'historisation dans la
BDUni.
Nous commencerons par décrire le système de la
base de données BDUni et son processus d'historisation, en termes de
contenu, de structure, d'architecture et de production des données. Puis
nous évaluerons ses outils de mise à jour et d'intégration
de la dimension temporelle, les avantages et les inconvénients de ce
modèle, notamment afin d'envisager son adaptabilité aux besoins
spécifiques d'une base d'occupation du sol telle que le RGFor.
I - Système de base de données et processus
d'historisation
Bien que l'intégration de la dimension temporelle soit
une préoccupation relativement nouvelle pour les bases de données
d'informations géographiques (Bordin, 2002, p. 90), des
expériences de mises en place de processus d'intégration et
d'outils de gestion de la dimension temporelle ont déjà
été conduites, comme les projets GéoPeuple41 et
GéOpenSim42 au laboratoire COGIT (Conception Objet et
Généralisation de l'Information Topographique) de l'IGN. Les
recherches sur les modèles théoriques ont en effet apporté
des réponses à cette question et les problèmes liés
aux limites matérielles ont pu, du moins en partie, se résoudre
du fait des progrès techniques. Par ailleurs, ces expériences
répondent à un besoin croissant en informations
spatio-temporelles (Paque, 2004, p. 2).
Un modèle d'historisation a ainsi déjà
été développé au sein de l'IGN dans le cadre du
projet d'unification des bases de données, ou BDUni, afin de
répondre à ce besoin. Un des thèmes de cette base de
données, la couche végétation, est une couche d'occupation
du sol, dont la création est intégrée à la
chaîne de production du RGFor depuis la mise en place du partenariat
entre l'IFN et l'IGN (Guinaudeau, 2006) et la fusion des deux instituts au
premier janvier 2012. Cette couche comprend les milieux arborés et les
landes.
Plus précisément, la nomenclature de la couche
végétation inclut (IGN, 2011, p. 122) :
- les bois : bosquets, arbres épars, et espaces verts
- les vergers
- les landes ligneuses43
- les haies
- les vignes
- les bananeraies
- les mangroves
- les plantations de canne à sucre
- les peupleraies
41 http://geopeuple.ign.fr/
42 http://geopensim.ign.fr/
43 Les formations herbacées ont été
intégrées à la BDUni mais n'ont jamais été
diffusées avec la base produit BDTopo. Elles doivent être
supprimées de la BDUni au moment de l'archivage de mars 2013.
xxxii
- les forêts, divisées en cinq postes
(simplification de la nomenclature du RGFor) :
o forêt fermée ? feuillu, ? conifère,
? mixte
o forêt ouverte
Comprendre le processus de mise à jour et la prise en
compte de la dimension temporelle dans la BDUni en étudiant une
méthodologie interne à l'IGN est particulièrement
intéressant pour tenter de répondre en première approche
à la problématique de l'historisation dans le cadre du RGFor.
Reprendre le modèle de la BDUni pour le RGFor représente en effet
pour l'IGN la solution a priori la plus simple, celle qui demanderait
le moins de développement et qui pourrait être la plus avantageuse
en termes de coûts et d'investissement. Cela demande donc de
décrire ce modèle, d'évaluer ses capacités et son
adaptabilité.
I.A - Contenu et structure de la BDUni
La BDUni est une base de production44 de
données vecteurs sur la France entière contenant l'ensemble des
domaines45 (également appelés thèmes ou encore
couches) qui constituent les produits commerciaux de l'IGN tels que la BD
Carto® et le RGE® (Référentiel à Grande
Échelle) vecteur qui est constitué de la BD Topo®
et de la BD Adresse®. Comme la majorité des bases
de données actuelles, la BDUni est une base de données
relationnelles, c'est-à-dire que les données sont
réparties dans des tables, divisées en colonnes et en
lignes46 auxquelles il est possible d'accéder à l'aide
de requêtes SQL (Date, 2004, p. 27).
La structure de la BDUni se divise en trois tables
attributaires, séparées pour des raisons de performances
techniques :
· Deux tables pour chaque classe d'objets :
1. Table des objets actuels et des objets supprimés ;
2. Table des anciennes versions des objets, ou table
d'historique ;
· Une table documentaire, pour tous les domaines,
contenant les informations sur les mises à jour
considérées par ensembles et appelées
réconciliations :
3. Table des réconciliations.
44 Les données produites à l'IGN sont
réparties en plusieurs bases - base d'acquisition, base de production,
base d'exploitation - en fonction des étapes de la chaîne de
production, allant de l'opérateur de saisie jusqu'à
l'utilisateur.
45 La BDUni regroupe les informations géographiques
appartenant à 10 domaines : le réseau routier, les voies
ferrées et autres moyens de transport terrestre, les réseaux de
distribution, le réseau hydrographique terrestre, le bâti, la
végétation, l'orographie, les zonages administratifs, les zones
d'activité ou d'intérêt, les adresses (IGN, BDUni V1.1
Grande Échelle : spécifications de contenu, 2011, p. 10).
46 Plusieurs terminologies sont employées pour
décrire le contenu d'une base de données : fichiers,
enregistrements, champs ; relations, n-uplets, attributs ; tables, lignes,
colonnes. Par souci de cohérence et de simplicité, nous
n'emploierons que la troisième terminologie, celle associée au
langage SQL (Date, 2004, p.6).
xxxiii
Ces tables dans la couche végétation contiennent
plusieurs colonnes :
- Pour les tables 1 et 2, respectivement appelée «
zone_de_vegetation » et « zone_de_vegetation_h » :
o La géométrie :
n « geometrie »47
n « empreinte »
o La sémantique : « nature »
o Un numéro d'identifiant de l'objet : « cleabs
»
o L'état de l'objet : « detruit »
o Colonnes temporelles :
n « date_creation »
n « date_modification »
n « date_destruction »
o Le mécanisme de réconciliation :
n « numrec »
n « numrecmodif » (uniquement pour la table
d'historique)
o Des colonnes documentaires :
n « nom »
n « source_de_la_geometrie_2d »
n « nom_lot »
n « metadonnees_vegetation »
o Des colonnes documentaires communes à toutes les
tables utilisées pour suivre la production en MAJEC (non utilisés
pour la production actuelle de la végétation BDUni)48
:
n « etat_de_l_objet »
n « identifiant_gestionnaire »
n « commentaire_collecteur »
n « exception_legitime »
n « conventions »
n « liens_vers_evolutions »
- Pour la table 3, table des réconciliations
appelé « reconciliations »49:
o La géométrie de la zone de réconciliation
: « geometrie »
o La colonne temporelle : « daterec »
o Sur la réconciliation :
n « ordrefinevol »
n « numrec »
n « classeimpactees »
n « est_une_montee_en_base »
n « dureerec »
n « nbobjrec »
47 Cette colonne contient une description de l'objet (point,
ligne, polygone, polyligne, polypoint) et les coordonnées de ses points,
le tout en codage hexadécimal (6 lettres et dix chiffres).
48 Ces colonnes sont utilisées pour les tâches de
collecte de la MAJEC.
49 Il existe plusieurs tables des réconciliations
actuellement dans la BDUni. Les tables supplémentaires ont
été créées pour effectuer des manipulations et des
tests et n'ont jamais été supprimées.
o
xxxiv
Documentaires :
· « operateur »
· « commentaire »
· « numclient »
· « version_gcvs »
· « profil »
· « date_du_dernier_controle »
· « nature_operation »
o Autres :
· « changement »
· « complement_bdcarto_ texte »
· « complement_bdcarto_liste »
· « incoherences_detectees »
· « lien_vers_evolution_ponctuelle »,
o Colonnes documentaires communes à toutes les tables
:
· « nom »
· « conventions »
Enfin, il est possible d'établir des relations entre
les tables de la BDUni grâce au fonctionnement de la
réconciliation qui sera décrit avec plus de précision par
la suite. Les relations entre les tables passent par la colonne d'identifiant
« cleabs » et les colonnes de réconciliation « numrec
» et « numrecmodif » (voir schéma de structure de la
BDUni, ci-dessous).
Figure 1 : schéma de structure logique de
l'historisation dans la BDUni.
Les colonnes d'identifiant (« cleabs ») et
d'historique des réconciliations (« numrec », «
numrecmodif ») constituent des clés primaires, et des clés
étrangères. Une clé primaire, soulignée et en
caractère gras dans le schéma, est une colonne de la table dont
la valeur ne peut pas exister à l'identique dans deux lignes
différentes de la table50. C'est ce qu'on appelle la
contrainte d'unicité. Par ailleurs, cette colonne doit être
remplie obligatoirement pour toutes les lignes : c'est la contrainte
d'intégrité d'entité. Les clés
étrangères sont des copies d'une clé cible dans une table
cible. Dans le schéma, les flèches représentent les
liaisons entre les tables : la colonne de départ correspond à une
clé étrangère, la colonne d'arrivée correspond
à la cible de la relation. Ce procédé permet de mettre en
relation des tables distinctes (Hainaut, 2009, chapitre 2). Pour bien jouer
leurs
50 Dans la table des réconciliations, c'est la colonne
« ordrefinevol » qui remplit réellement la fonction de
clé primaire. Bien que le « numrec » respecte aussi les
contraintes d'intégrité et d'unicité.
xxxv
rôles, toutefois, les relations fondées sur les
clés étrangères doivent répondre à des
contraintes et posséder des fonctionnalités qui ne sont pas
implémentées dans le système de la BDUni. Ce
système permet simplement des relations grâce au contenu de ses
tables (Figure 1). Nous utilisons néanmoins cette terminologie car elle
facilite la description de la structure d'une base de données.
Dans la table « zone_de_vegetation », l'identifiant
unique de chaque objet, la « cleabs », est la clé primaire. La
clé primaire de la table « zone_de_vegetation_h » est
constituée de deux colonnes : la « cleabs », ou clé
absolue, et le « numrecmodif », ou numéro de
réconciliation lors de la modification. Dans la table d'historique, la
colonne « cleabs » contient l'identifiant de chaque objet
modifié qui est conservé et renvoie à colonne «
cleabs » de la table « zone_de_vegetation » (flèche
rouge) de l'état successeur de l'objet, c'est-à-dire sa nouvelle
version. Le second correspond au « numrec », ou numéro de
réconciliation, de la table « zone_de_vegetation »
(flèche bleue). Enfin, chaque réconciliation est
enregistrée dans la table « reconciliations » par un «
numrec » unique auquel renvoient le « numrec » de la table
« zone_de_vegetation », ainsi que le « numrec » et le
« numrecmodif » de « zone_de_vegetation_h » (flèches
mauve, verte et seconde flèche bleue).
Cette structure est également illustrée par la
Figure 1. L'entité objet actuel est contenu dans la table
« zone_de_vegetation ». Ces versions
antérieures sont contenues dans la table
« zone_de_vegetation_h
». Il est possible de lier le contenu des deux tables grâce aux
colonnes « cleabs », « numrec » et « numrecmodif
».
| 
