Memoire Online - Recherche d'un processus d'historisation de base de données d'occupation des sols appliqué au référentiel géographique forestier de l'IGN

Le dernier mécanisme permet d'effectuer une mise à jour concernant à la fois un volume important de données et une base existante. Il permet donc de résoudre le problème d'une mise à jour ciblée sur une surface importante, cas de la végétation. Une centaine d'objets dispersés dans l'espace peuvent en effet connaître la même évolution. Par exemple, la mise à jour des donnés de la BD Forêt® après une tempête entraîne la création de nombreux nouveaux polygones de « coupes rases ou incidents > et la destruction ou la modification des polygones de forêt existant auparavant. Ces

évolutions ont toutes la même origine et constitue donc un ensemble cohérent qu'il serait judicieux de lier par une seule réconciliation.

Pour une liste d'identifiants d'objet, la simulation de GCVS en script SQL sur la machine client permet de générer un historique de réconciliation répercuté en base serveur avec la mise à jour. Dans le cas de notre exemple, il faudrait connaître les identifiants de l'ensemble des objets concernés, puis écrire une requête SQL qui simule le fonctionnement normal de GCVS. Cet outil reste cependant aussi limité en volume, et il ne permet que la modification de la valeur d'une colonne attributaire d'un objet, pas sa géométrie.

I.C.2 - L'historique : conservation de l'identifiant et mécanisme de liste chaînée

Figure 5 : schéma conceptuel entité-relation de l'historisation dans la BDUni⁵⁶.

Le processus d'historisation de la BDUni est géré grâce à GCVS lors des réconciliations. Comme cela a été décrit dans la section sur l'architecture du système de la base de données (p. xxxv), GCVS réalise un appariement entre les données de la base client en cours de réconciliation et les données du serveur à l'aide des identifiants des objets. Les objets possédant un nouvel identifiant sont ajoutés à la base serveur dans la table des objets actuels. Les objets possédant un identifiant déjà connu et qui ont été modifiés ou détruits sont enregistrés dans la table des objets actuels. Leur version précédente est copiée dans la table d'objet historique.

Le même identifiant « cleabs » est conservé pour chaque version historisée après une modification. La conservation de l'identifiant constitue la base de la création d'un historique et du suivi des objets dans le temps. Il s'agit d'un modèle d'historisation de type « tuple-level versioning⁵⁷ » (Langran, 1992,

p. 60). Pour chaque modification, lors de la réconciliation, les informations sur celle-ci sont

56 Cardinalités : 0,1 = de zéro à un seul ; 1,1 = un seul ; 1,n = de un à plusieurs ; 0,n = de zéro à plusieurs.

enregistrées dans la table des réconciliations et la ou les lignes du ou des objets concernés par la mise à jour sont copiées dans leur intégralité dans la table d'historique⁵⁸.

Contrairement aux objets ayant été modifié mais existant toujours, les objets détruits sont conservés dans la table des objets courant en remplissant les colonnes « date_destruction » et « detruit ». Cette règle ne repose pas sur une contrainte de référence mais sur une exigence technique due à l'architecture client-serveur : la base client est synchronisée avec la base actuelle, si un objet détruit était supprimé de celle-ci, la modification ne serait pas répercutée sur la base client.

A la conservation de l'identifiant s'ajoute la liste chaînée des réconciliations. Pour chaque réconciliation, la colonne « numrecmodif » est remplie avec le numéro de la réconciliation en cours dont on connait le numéro (le « numrec »). Ce numéro est le même que le « numrec » de l'objet successeur, la dernière version de l'objet, dans la table des objets courants qui vient alors écraser dans cette table l'objet modifié désormais stocké. La liste ordonnée des versions successives d'un même objet contenu dans la table d'historique se retrouve de façon similaire de « numrecmodif » à « numrec » s'enchaînant.

Ce système, illustré par la Figure 5, permet donc de suivre la filiation entre les différentes versions d'objet à chaque mise à jour et, de ce fait, est ce qui permet la prise en compte de la dimension temporelle dans la BDUni. En effet, ces opérations s'accompagnent d'un enregistrement dans les colonnes d'historique - « date_creation », « date_modification », « date_destruction », « daterec » - du temps de la transaction informatique selon l'horloge du serveur. Ces dates, indiquées en années, mois, jours et heures avec une résolution temporelle⁵⁹ de 1/100000^ème de seconde, sont générées automatiquement. Elles prennent en compte l'instant de l'opération de réconciliation de la mise à jour de la base de données : les ajouts (« date_creation »), suppressions (date_destruction), modifications (« date_modificaiton »). Les « daterec », c'est-à-dire les dates de réconciliation, marquent les bornes de la durée de vie des objets : le « numrec » est la date de début, et le « numrecmodif » la date de fin.

Nous allons illustrer concrètement ce mécanisme à l'aide d'un exemple fictif d'un objet créé, modifié, puis détruit. Nous n'indiquerons que les colonnes essentielles à cet exemple.

58 La totalité des informations de l'objet est stockée afin d'éviter les bugs et de devoir effectuer des recherches de différentiel pour extraire les anciennes versions afin de connaître l'intégralité des informations concernant l'objet.

59 La résolution temporelle est similaire à la résolution spatiale. Elle désigne la plus petite unité atomique qu'il est possible de représenter par un intervalle dans la base de données (Langran, 1992, p. 84)

? Étape 1 : création de l'objet : réconciliation 1. La colonne « date_creation » est remplie.

cleabs⁶⁰	nature	geometrie	date_creation	date_modifi cation	date_destruction	numrec		detruit	ZONEVEGE000 0000000000001
Forêt fermée de conifères	xxx	01/01/12			1

nature	geo metrie	date_creation	date_modification	date_destruc tion	cleabs	numrec		num recmodif

cleabs	nature	geometrie	date_creation	date_modifi cation	date_destruction	numrec		detruit	ZONEVEGE000 0000000000001
Forêt fermée mixte	x, y	01/01/12	08/01/12		2

nature	geo- metrie	date_creation	date_modification	date_destruc tion	cleabs	numrec		num recmodif	Forêt fermée de conifère
x, y	01/01/12			ZONEVEGE0000 000000000001	1	2

cleabs	nature	geometrie	date_creation	date_modifi cation	date_destruction	numrec		detruit	ZONEVEGE000 0000000000001
Forêt fermée mixte	x, y	01/01/12	08/01/12	15/01/13	3	detruit

nature

geome trie

date_creation

date_modification

date_destruc tion

cleabs

numrec

numrecmodif

Forêt
fermée
mixte

x, y

01/01/12

08/01/12

ZONEVEGE0000

000000000001

Forêt

fermée de
conifère

x, y

01/01/12

ZONEVEGE0000

000000000001

Grâce à ce système, l'ensemble des versions antérieures des objets est donc conservé et les versions successives d'un objet identifié par sa « cleabs » unique sont reliées en liste chaînée par leur « numrec » et le « numrecmodif ». La temporalité des événements associés aux objets (création, modification, destruction) et leur durée de vie (« daterec » associé au « numrec » et au « numrecmodif ») est enregistrée. Dans notre exemple, on obtient ainsi trois états successifs d'objet⁶¹ :

nature	date_creation	date_modification	date_destruction	detruit	numrec/daterec	numrecmodi f/daterec	objet version
Forêt	01/01/12	08/01/12	15/01/13	detruit	3		3
fermée mixte					15/01/13
Forêt	01/12/12	08/01/12			2	3	2
fermée mixte					08/01/12	15/01/13
Forêt	01/12/12				1	2	1
fermée de conifère					01/01/12	08/01/12

61 Le tableau présenté comme résultat final de notre exemple peut être obtenu à l'aide d'une requête SQL réalisant l'unione de la table actuelle et historique et joignant la table des réconciliations sur la colonne « numrec » puis « numrecmodif » afin d'obtenir les intervalles de durée de vie des objets. Cette manipulation est décrite dans la partie II et en annexe.

Recherche d'un processus d'historisation de base de données d'occupation des sols appliqué au référentiel géographique forestier de l'IGN

I.C.1.c - La simulation GCVS en script SQL