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

84

III.C.3.b - Conservation de l'identifiant et mécanisme de liste chaînée

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.

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








"Et il n'est rien de plus beau que l'instant qui précède le voyage, l'instant ou l'horizon de demain vient nous rendre visite et nous dire ses promesses"   Milan Kundera