WOW !! MUCH LOVE ! SO WORLD PEACE !
Fond bitcoin pour l'amélioration du site: 1memzGeKS7CB3ECNkzSn2qHwxU6NZoJ8o
  Dogecoin (tips/pourboires): DCLoo9Dd4qECqpMLurdgGnaoqbftj16Nvp


Home | Publier un mémoire | Une page au hasard

 > 

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

( Télécharger le fichier original )
par Romain Louvet
Université Paris Diderot - Paris 7 - M1 Géographie et Sciences des territoires 2013
  

précédent sommaire suivant

Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy

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

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

55 Source : ortho-photographies et BD Forêt v2 des Hautes-Pyrénées.

xxxix

é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 BDUni56.

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 versioning57 » (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.

57 Versionnement par ligne, qui s'oppose au versionnement par colonne.

xl

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'historique58.

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 temporelle59 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)

xli

Exemple du fonctionnement de l'historisation dans la BDUni :

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

o Table actuelle « zone_de_vegetation »

cleabs60

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

 
 

o Table des réconciliations

numrec

daterec

nom

1

01/01/12

Montée en base

 

o Table d'historique « zone_de_vegetation_h »

nature

geo metrie

date_creation

date_modification

date_destruc tion

cleabs

numrec

num recmodif

 
 
 
 
 
 
 
 
 

? Étape 2 : modification sémantique de l'objet évoluant d'une forêt fermée de conifère vers une forêt mixte : réconciliation 2. La première version de l'objet est copiée dans la table d'historique. La colonne « date_modification » est remplie.

o Table actuelle « zone_de_vegetation »

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

 
 

o Table des réconciliations

numrec

daterec

nom

2

08/01/12

Correction

1

01/01/12

Montée en base

 

o Table d'historique « zone_de_vegetation_h »

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

 

60 Le système GCVS octroie un identifiant, dont le caractère unique et la stabilité sont garantis. C'est la clé absolue. Celle-ci est composée d'une chaîne de 24 caractères : 8 caractères alphanumériques qui correspondent au domaine de l'objet et 16 chiffres (Bonneau, 2008, p. 10).

xlii

? Étape 3 : destruction de l'objet : réconciliation 3. La deuxième version de l'objet est également copiée dans l'historique. Les colonnes « date_destruction » et « detruit » sont remplies.

o Table actuelle « zone_de_vegetation »

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

 

o Table des réconciliations

numrec

daterec

nom

3

15/01/13

Destruction

2

08/01/12

Correction

1

01/01/12

Montée en base

 

o Table d'historique « zone_de_vegetation_h »

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

2

3

Forêt

fermée de
conifère

x, y

01/01/12

 
 

ZONEVEGE0000

000000000001

1

2

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'objet61 :

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.

xliii

précédent sommaire suivant






Bitcoin is a swarm of cyber hornets serving the goddess of wisdom, feeding on the fire of truth, exponentially growing ever smarter, faster, and stronger behind a wall of encrypted energy








"Il ne faut pas de tout pour faire un monde. Il faut du bonheur et rien d'autre"   Paul Eluard