Figure 24 : Schéma conceptuel
entité-relation de l'historisation dans la BDUni (Source : travail
personnel)
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
créés sont reconnus par le fait de posséder un identifiant
encore inconnu dans la base serveur. Ils sont ajoutés à la base
serveur dans la table des objets actuels en tant qu'objets créés.
Les objets possédant un identifiant déjà connu et qui ont
été modifiés sont enregistrés dans la table des
objets actuels. Les objets détruits sont conservés dans la table
des objets courants en remplissant les colonnes « date_destruction »
et « detruit ». La version précédente des objets
modifiés ou détruit est copiée dans la table des objets
historiques (Figure 24). C'est un processus d'historisation de versionnement
par ligne avec partition temporelle.
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.
Pour chaque modification, lors de la réconciliation,
les informations sur celle-ci sont enregistrées dans la table des
réconciliations (colonne « nom », en texte libre) 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'historique29.
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 (Figure 24 et Figure
25).
29 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.
85
Figure 25 : Schéma de structure logique de
l'historisation dans la BDUni (Source : travail personnel)
La Figure 25 montre comment ce système permet des
relations entre les tables. Les flèches de couleurs joignent les
attributs qui se font références. Les colonnes constituant une
clé primaire sont soulignées et en caractère gras dans le
schéma. Une clé primaire est une colonne de la table dont la
valeur ne peut pas exister à l'identique dans deux lignes
différentes de la table.
Dans la table d'historique, la colonne « cleabs »
contient l'identifiant de chaque objet modifié qui est conservé
et renvoie à colonne « cleabs » (flèche rouge) de
l'état successeur de l'objet dans la table des objets actuels,
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).
Ce système permet donc de suivre la filiation entre
les différentes versions d'objets à 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 temporelle30 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.
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. La réconciliation constitue par ailleurs
l'événement reliant entre eux des objets sensés être
concernés par une même évolution. L'historisation de la
BDUni est donc proche du modèle identitaire avec modélisation
d'événement.
30 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)
86
III.C.3.c - Consignes et méthodes de saisie de
la MAJEC
S'appuyant sur de multiples sources
d'informations31, les collecteurs effectuent les modifications sur
leur base clients qu'ils répercutent ensuite sur le serveur grâce
aux outils du GCVS.
Il leur est demandé de suivre des consignes de saisie.
Une zone de réconciliation doit prendre en compte un ensemble
homogène ou cohérent de modifications que l'opérateur doit
décrire dans la colonne « nom » de la table des
réconciliations afin d'en faciliter l'exploitation. Cette zone doit
être suffisamment grande pour intersecter tous les objets modifiés
mais pas trop au risque de ralentir inutilement le temps de calcul du
traitement de la mise à jour (IGN, 2012-B, p. 45).
De nombreux contrôles sont réalisés
obligatoirement avant chaque réconciliation. Leur rôle est
d'éviter d'enregistrer des informations aberrantes dans la base centrale
qui, sans ces contrôles, ne seraient pas détectée.
Si une erreur apparait, mais qu'elle est justifiée, il
est possible de faire basculer l'erreur en exception légitime. La
colonne « exception_legitime » est alors remplie en fonction de
l'erreur et le contrôle associé ne sera plus effectué pour
l'objet en question. Un péage est un bon exemple d'exception
légitime à l'intersection : c'est un bâtiment qui coupe une
route, mais de fait il est au-dessus de celle-ci. La colonne «
exception_legitime » est régulièrement vidée de son
contenu pour effectuer à nouveau les contrôles afin de
vérifier la qualité des données.
