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. L'activation de l'archivage sur des données non versionnées crée les champs gdb_from_date et gdb_to_date directement dans la table de base de la classe.

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, d'une date de transaction ou d'un temps universel coordonné (UTC). La date valide correspond au moment réel où la modification a été effectuée dans le monde réel, enregistrée 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. UTC est la norme principale utilisée pour réguler les horloges et l'heure sur Internet.

Pour l'archivage sur des données non versionnées, ArcGIS utilise la date de transaction, basée sur la date actuelle du serveur, pour enregistrer les modifications apportées 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ù il 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. Le retard souvent accumulé par les systèmes de production dans l'édition et la mise à jour des données explique l'écart et l'intervalle qui sépare 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.

L'archivage sur des données non versionnées utilise l'heure UTC pour représenter le temps. Les modifications apportées aux données sont consignées lorsque les mises à jour sont enregistrées lors d'une session de mise à jour.

Activation de l'archivage sur des données non versionnées

Lors de l'activation de l'archivage, les attributs gdb_from_date et gdb_to_date sont ajoutés à la table de base. Pour toutes les lignes, l'attribut gdb_from_date est positionné à la date et à l'heure d'activation de l'archivage. Pour toutes les lignes, l'attribut gdb_to_date est positionné à 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. Lorsque des modifications sont enregistrées, la géodatabase les archive automatiquement comme suit :

• Les entités récemment créées sont représentées avec la valeur attributaire gdb_from_date définie sur la position de l'opération d'archivage et l'attribut gdb_to_date défini sur 12/31/9999.
• Les entités actualisées dans une session de mise à jour actualisent la ligne associée dans la table de base en définissant la valeur attributaire gdb_to_date sur la position de l'opération d'archivage, et ajoutent une nouvelle ligne avec la valeur attributaire the gdb_from_date définie sur la position de l'opération d'archivage et l'attribut gdb_to_date défini sur 12/31/9999.
• Les entités supprimées dans une session de mise à jour actualisent la ligne associée dans la table de base en définissant la valeur attributaire gdb_to_date comme étant égale à la position de l'opération d'archivage.

Activation de l'archivage sur des données versionnées

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 positionné à la date et à l'heure d'activation de l'archivage. Pour toutes les lignes, l'attribut gdb_to_date est positionné à 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. La signification est la suivante :

• 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 position 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 la classe d'archive en définissant la valeur attributaire gdb_to_date sur la position de l'opération d'archivage, et ajoutent une nouvelle ligne avec la valeur attributaire the gdb_from_date définie sur la position 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 la sauvegarde ou la 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 DEFAULT transactionnelle.

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 bases, d'ajouts et de suppressions

Ajout d'une entité

Cette entité d'une base de données cadastrale affiche la parcelle 116 et sa ligne correspondante. Pour les données versionnées, cette ligne apparaît dans la classe d'archive. Pour les données non versionnées, cette ligne apparaît dans la table de base des parcelles. 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é est insérée (parcelle 117), une ligne est insérée avec l'attribut gdb_from_date actualisé tenant compte de la position 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 des 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é croise 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 position 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, avant la mise à jour.

Si la limite de la parcelle 117 est prolongée, l'attribut gdb_to_date est actualisé en fonction de la position 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/12/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:23: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 position de l'opération d'archivage. Le diagramme suivant affiche les parcelles 116 et 117, ainsi que leurs attributs gdb_from_date et gdb_to_date correspondants.

Si la parcelle 117 est maintenant supprimée, l'attribut gdb_to_date est actualisé en fonction de la position de l'opération d'archivage.

Remarque technique concernant l'archivage avec des données versionnées

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 modifications pour actualiser l'attribut gdb_to_date de la classe d'archive en fonction de la position de la 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 sera restaurée dans la version DEFAULT réinjectée. 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.