Le processus d'archivage

L'activation de l'archivage sur un jeu de données versionné crée et alimente la classe d'archive avec les données actuellement présentes dans la version DEFAULT. La classe d'archive utilise les attributs gdb_from_date et gdb_to_date pour consigner le moment où la modification a été archivée.

Représentation du temps

Il est important de comprendre comment ArcGIS représente le temps lorsqu'une modification est enregistrée. L'historique peut être enregistré sous la forme d'une date valide ou d'une date de transaction. La date valide correspond au moment réel où la modification a été effectuée dans le monde réel, enregistré généralement par l'utilisateur qui applique la modification. La date de transaction représente le moment où un événement a été enregistré dans la base de données. Les dates de transaction sont automatiquement générées par le système.

ArcGIS utilise la date de transaction, basée sur la date actuelle du serveur, pour enregistrer la modification apportée aux données lorsque des modifications sont enregistrées ou réinjectées dans la version DEFAULT. La date de transaction et la date à laquelle l'événement s'est produit dans le monde réel sont rarement identiques. Cette valeur correspond à la période séparant le déclenchement d'un événement dans le monde réel et le moment où l'événement est enregistré dans la base de données. Par exemple, une parcelle est vendue le 14 mai 2006 ; cependant, la modification n'est pas appliquée aux données avant le 5 juin 2006. La date de transaction du 5 juin 2006 est enregistrée dans la classe d'archive pour cette modification.

Lorsque la modification intervient, ArcGIS archive la transaction dans la classe d'archive. La différence entre la date de l'événement dans le monde réel et la date de transaction peut paraître insignifiante mais elle devient plus évidente lorsque des requêtes sont exécutées par rapport aux informations archivées. Les retards souvent accumulés par les systèmes de production dans la modification et la mise à jour des données expliquent l'écart et l'intervalle qui séparent l'heure valide et l'heure de transaction.

La différence entre la date valide et la date de transaction pose également problème dans les cas où l'historique est enregistré dans un environnement comportant de nombreux utilisateurs ou départements différents qui modifient la base de données. L'ordre dans lequel les modifications sont appliquées et consignées dans la base de données peut ne pas être identique à celui dans lequel ces modifications se sont produites dans le monde réel.

Activation de l'archivage

Lors de l'activation de l'archivage, toutes les lignes représentant la version DEFAULT pour la classe donnée sont copiées dans la classe d'archive avec la même position. Pour toutes les lignes, l'attribut gdb_from_date est daté avec la date et l'heure d'activation de l'archivage. Pour toutes les lignes, l'attribut gdb_to_date est daté avec la date 12/31/9999. Un attribut gdb_to_date affichant la valeur 12/31/9999 désigne la représentation actuelle de l'objet dans la version DEFAULT. Lorsque des modifications sont enregistrées ou réinjectées dans la version DEFAULT, la géodatabase les archive automatiquement dans la classe d'archive. En conséquence :

• Les entités créées dans la version DEFAULT sont représentées dans la classe d'archive sous forme de lignes avec la valeur attributaire gdb_from_date définie sur la date de l'opération d'archivage et l'attribut gdb_to_date défini sur 12/31/9999.
• Les entités mises à jour dans la version DEFAULT actualisent la ligne associée dans l'archive en définissant la valeur attributaire gdb_to_date sur la date de l'opération d'archivage, et ajoutent une nouvelle ligne avec la valeur attributaire gdb_from_date définie sur la date de l'opération d'archivage et l'attribut gdb_to_date défini sur 12/31/9999.
• Les entités supprimées de la version DEFAULT actualisent la ligne associée dans la classe d'archive en définissant la valeur attributaire gdb_to_date comme étant égale à la position de l'opération d'archivage.

L'actualisation de la table d'archive s'effectue dans une seule transaction de base de données. Si des erreurs surviennent lors de la transaction, toute l'opération d'archivage est annulée et l'opération de sauvegarde ou de réinjection reste donc inachevée. Une fois l'erreur corrigée, exécutez de nouveau la sauvegarde ou la réinjection.

Pour chaque opération d'archivage, le repère chronologique DEFAULT est actualisé avec la valeur de l'opération d'archivage. Ainsi, lorsque vous sélectionnez le repère chronologique DEFAULT lors de l'utilisation d'une version historique, la représentation actuelle de la classe d'archive correspond à la représentation de la classe versionnée dans la version transactionnelle DEFAULT.

L'accès à la classe d'archive peut nécessiter moins de ressources de base de données que l'utilisation de la classe versionnée équivalente.

Les développeurs d'applications intéressés par l'événement permettant de capturer le moment de l'opération d'archivage peuvent consulter l'événement OnarchiveUpdated dans l'interface Iversionevents2 du kit de développement de logiciels.

Les requêtes sur les versions historiques sont effectuées au niveau de la classe d'archive :

Table d'archive

Les requêtes sur les versions transactionnelles sont toujours effectuées au niveau des tables de base et delta :

Tables de base, des ajouts et des suppressions

Ajout d'une entité

Cette entité d'une base de données cadastrale affiche la parcelle 116 et sa ligne correspondant dans la classe d'archive. L'attribut gdb_from_date indique l'heure et la date de création tandis que l'attribut gdb_to_date affiche la valeur 12/31/9999, car l'entité n'a pas été modifiée ni supprimée depuis l'activation de l'archivage.

Lorsqu'une entité (la parcelle 117) est insérée et que les mises à jour sont réinjectées dans la version DEFAULT, une nouvelle ligne est insérée dans la classe d'archive avec l'attribut gdb_from_date actualisé selon la date de cette opération de réinjection. L'attribut gdb_to_date de la nouvelle ligne affiche 12/31/9999 car cette entité doit encore être actualisée ou supprimée.

Remarque :

Certaines opérations de mise à jour, telles que la création d'entités avec l'outil Polygone automatique et la validation d'une topologie de géodatabase, insèrent des sommets dans les entités existantes pour conserver la coïncidence entre les entités adjacentes. Par exemple, si vous utilisez l'outil Polygone automatique pour créer un nouveau polygone adjacent à un polygone existant, des sommets sont ajoutés au polygone existant aux emplacements où la construction de la nouvelle entité traverse l'entité existante.

Actualisation d'une entité

Lorsqu'une entité est actualisée, l'attribut gdb_to_date est défini en fonction de la date de l'opération d'archivage et une ligne est insérée pour afficher la représentation actuelle de l'entité. L'attribut gdb_from_date de cette nouvelle ligne est défini selon la date de l'opération d'archivage tandis que l'attribut gdb_to_date affiche 12/31/9999 car il doit encore être modifié ou supprimé.

Le diagramme suivant montre deux parcelles, 116 et 117, avec leurs attributs gdb_from_date et gdb_to_date correspondants dans la classe d'archive, avant la mise à jour.

Si la limite de la parcelle 117 est étendue et que ces mises à jour sont réinjectées dans la version DEFAULT, l'attribut gdb_to_date est actualisé en fonction de la date de l'opération d'archivage et une nouvelle ligne est créée. L'attribut gdb_from_date de cette nouvelle ligne est défini selon l'heure et la date de l'opération d'archivage.

Par exemple, les requêtes qui recherchent des moments antérieurs à la mise à jour (7/14/2005 5:34:22 PM) affichent la parcelle 117 telle qu'elle était avant la mise à jour. La recherche de moments antérieurs à 7/9/2005 2:33:43 PM n'affiche pas la parcelle 117 car elle n'avait pas été créée. Toutes les requêtes d'historiques postérieures à la mise à jour (7/14/2005 3:45:23 AM) affichent la parcelle 117 dans sa représentation actuelle avec la limite étendue.

Pour en savoir plus sur l'interrogation de la classe d'archive

Suppression d'une entité

Lorsqu'une entité est supprimée, l'attribut gdb_to_date est actualisé en fonction de la date de l'opération d'archivage. Le diagramme ci-dessous affiche les parcelles 116 et 117, ainsi que leurs attributs gdb_from_date et gdb_to_date correspondants dans la classe d'archive.

Si la parcelle 117 est à présent supprimée et que ces mises à jour sont réinjectées dans la version DEFAULT, l'attribut gdb_to_date est actualisé en fonction de la date de l'opération d'archivage.

Remarque technique concernant l'archivage

Le scénario suivant risque de créer un écart de temps dans la classe d'archive :

Un éditeur modifie directement la version DEFAULT et supprime un objet dans une session de mise à jour.

Il enregistre ensuite les mises à jour pour actualiser l'attribut gdb_to_date de la classe d'archive en fonction de la date de suppression de cet objet.

Un conflit survient si le même objet est actualisé dans une version enfant et réconcilié avec la version DEFAULT.

Si, lors du processus de résolution des conflits, l'éditeur choisit de remplacer le conflit par la représentation mise à jour de la ligne, la ligne est restaurée dans la version DEFAULT lors de la réinjection de la version. L'opération d'archivage insère une nouvelle ligne dans la classe d'archive et définit l'attribut gdb_from_date sur la position, et l'attribut gdb_to_date sur 12/31/9999.

En conséquence, lorsque l'éditeur observe la généalogie de l'objet dans le temps, les dates affichent un écart entre les attributs gdb_to_date et gdb_from_date si l'objet n'existait pas dans la version DEFAULT.