Der Archivierungsprozess

Wenn Sie die Archivierung für ein versioniertes Dataset aktivieren, wird die Archivklasse mit den aktuellen Daten aus der DEFAULT-Version erstellt und aufgefüllt. Die Archivklasse verwendet "gdb_from_date" und "gdb_to_date", um den Zeitpunkt der Archivierung der Änderung zu verwalten.

Darstellen der Zeit

Sie sollten sich bewusst sein, wie die Zeit beim Aufzeichnen von Änderungen in ArcGIS dargestellt wird. Zeitpunkte in der Vergangenheit können als gültige Zeit oder Transaktionszeit aufgezeichnet werden. Die gültige Zeit ist der eigentliche Moment, in dem eine Änderung tatsächlich geschah. Sie wird üblicherweise von dem Benutzer aufgezeichnet, der die Änderung erfasst. Die Transaktionszeit ist die Zeit, zu der ein Ereignis in der Datenbank erfasst wurde. Transaktionszeiten werden automatisch vom System generiert.

In ArcGIS wird die Transaktionszeit (die auf der aktuellen Serverzeit basiert) verwendet, um Änderungen an den Daten zu aufzuzeichnen, wenn Änderungen gespeichert oder in die Standversion zurückgeschrieben werden. Die Transaktionszeit und die Zeit, zu der das Ereignis tatsächlich eingetreten ist, stimmen selten überein. Zwischen dem tatsächlichen Auftreten eines Ereignisses und dem Erfassen des Ereignisses in der Datenbank verstreicht in der Regel einige Zeit. Beispiel: Ein Flurstück wird am 14. Mai 2006 verkauft. Die Änderung wird jedoch erst am 5. Juni 2006 in den Daten aufgezeichnet. In der Archivklasse wird als Transaktionszeit für diese Änderung der 5. Juni 2006 aufgezeichnet.

Beim Auftreten der Änderung archiviert ArcGIS die Transaktion in der Archivklasse. Die Differenz zwischen dem realen Zeitpunkt des Ereignisses und der Transaktionszeit kann unwesentlich erscheinen, aber es wird deutlicher, wenn Abfragen der archivierten Informationen ausgeführt werden. In Produktionssystemen sind Rückstände beim Bearbeiten und Aktualisieren von Daten nicht selten. Dies führt zu Zeitunterschieden und Verzögerungen zwischen der gültigen Zeit und der Transaktionszeit.

Die Differenz zwischen der gültigen Zeit und der Transaktionszeit stellt auch in Situationen ein Problem dar, in denen vergangene Ereignisse von vielen verschiedenen Benutzern oder Abteilungen aufgezeichnet werden, die gemeinsam eine Datenbank nutzen. Die Reihenfolge, in der die Änderungen in der Datenbank aufgezeichnet werden, stimmt möglicherweise nicht mit der Reihenfolge überein, in der diese Änderungen tatsächlich aufgetreten sind.

Aktivieren der Archivierung

Beim Aktivieren der Archivierung werden alle Zeilen, die die DEFAULT-Version für die betreffende Klasse darstellen, mit demselben Zeitstempel in die Archivklasse kopiert. Das Attribut "gdb_from_date" erhält für alle Zeilen den Zeitstempel mit dem Datum und der Uhrzeit, an dem bzw. zu der die Archivierung aktiviert wurde. Das Attribut "gdb_to_date" erhält für alle Zeilen den Zeitstempel 31.12.9999. Jedes Mal, wenn ein Attribut den Wert 31.12.9999 für "gdb_to_date" aufweist, handelt es sich um die aktuelle Repräsentation des Objekts in der DEFAULT-Version. Wenn Änderungen gespeichert oder in die DEFAULT-Version zurückgeschrieben werden, archiviert die Geodatabase automatisch die Änderungen in der Archivklasse. Dies bedeutet Folgendes:

• In der DEFAULT-Version erstellte Features werden in der Archivklasse als Zeilen mit einem Attributwert für das Attribut "gdb_from_date" dargestellt, der auf den Zeitstempel des Archivierungsvorgangs festgelegt ist, und das Attribut "gdb_to_date" wird auf den 31.12.9999 festgelegt.
• Wenn in der DEFAULT-Version Features aktualisiert werden, wird die zugeordnete Zeile im Archiv aktualisiert, indem der Attributwert für das Attribut "gdb_to_date" auf den Zeitstempel des Archivierungsvorgangs festgelegt wird. Es wird eine neue Zeile eingefügt, in der das Attribut "gdb_from_date" auf den Zeitstempel des Archivierungsvorgangs und das Attribut "gdb_to_date" auf den 31.12.9999 festgelegt wird.
• Wenn in der DEFAULT-Version ein Feature gelöscht wird, wird die zugeordnete Zeile in der Archivklasse aktualisiert, indem das Attribut "gdb_to_date" auf einen Wert festgelegt wird, der dem Zeitstempel des Archivierungsvorgangs entspricht.

Die Aktualisierung der Archivtabelle wird innerhalb einer einzelnen Datenbanktransaktion ausgeführt. Bei Fehlern während der Transaktion wird der gesamte Archivierungsvorgang rückgängig gemacht. Der Speicher- oder Zurückschreibevorgang wird in diesem Fall nicht abgeschlossen. Sobald der Fehler berichtigt wurde, führen Sie den Speicher- oder Zurückschreibevorgang erneut aus.

Bei jedem Archivierungsvorgang wird die historische Kennzeichnung der DEFAULT-Version mit dem Wert des Archivierungsvorgangs aktualisiert. Bei der Arbeit mit einer historischen Version wird auf diese Weise sichergestellt, dass beim Auswählen eines historischen Markers in der DEFAULT-Version die aktuelle Repräsentation der Archivklasse der Repräsentation der versionierten Klassen in der DEFAULT-Version der Transaktion entspricht.

Beim Zugriff auf die Archivklasse werden unter Umständen weniger Datenbankressourcen benötigt als bei der Arbeit mit der entsprechenden versionierten Klasse.

Anwendungsentwickler, die an dem Ereignis interessiert sind, mit dem der Zeitpunkt des Archivierungsvorgangs erfasst wird, finden entsprechende Informationen im Software Developers Kit unter der Iversionevents2-Schnittstelle unter dem OnarchiveUpdated-Ereignis.

Abfragen für historische Versionen erfolgen auf der Archivklasse:

Archivtabelle

Abfragen für transaktionale Versionen erfolgen weiterhin auf den Basis- und Delta-Tabellen:

Basis-, Adds- und Deletes-Tabellen

Hinzufügen eines Features

Dieses Feature in einer Vermessungsdatenbank zeigt die Flurstücknummer 116 und die zugehörige Zeile in der Archivklasse. Das Attribut "gdb_from_date" enthält die Uhrzeit und das Datum der Erstellung, während "gdb_to_date" den 31.12.9999 enthält, weil das Feature seit der Aktivierung der Archivierung nicht geändert oder gelöscht wurde.

Wenn ein Feature (Flurstück 177) eingefügt wird und die Änderungen in die DEFAULT-Version zurückgeschrieben werden, wird in der Archivklasse eine Zeile eingefügt, wobei "gdb_from_date" auf den Zeitstempel dieses Zurückschreibevorgangs festgelegt wird. Das Attribut "gdb_to_date" in der neuen Zeile enthält den 31.12.9999, da dieses Feature noch nicht aktualisiert oder gelöscht wurde.

Aktualisieren eines Features

Wenn ein Feature aktualisiert wird, wird "gdb_to_date" auf den Zeitstempel dieses Archivierungsvorgangs festgelegt, und eine Zeile wird eingefügt, um die aktuelle Repräsentation des Features anzuzeigen. Das Attribut "gdb_from_date" in dieser neuen Zeile wird auf die Uhrzeit des Archivierungsvorgangs festgelegt, während "gdb_to_date" den 31.12.9999 enthält, weil das Attribut noch nicht geändert oder gelöscht wurde.

Im folgenden Diagramm werden zwei Flurstücke, 116 und 117, mit den entsprechenden Attributen "gdb_from_date" und "gdb_to_date" in der Archivklasse vor dem Aktualisierungsvorgang veranschaulicht.

Wenn die Flurstücksgrenze für Flurstück 117 ausgedehnt wird und diese Änderungen in die DEFAULT-Version zurückgeschrieben werden, wird "gdb_to_date" mit dem Zeitstempel des Archivierungsvorgangs aktualisiert, und eine neue Zeile wird eingefügt. Das Attribut "gdb_from_date" in dieser neuen Zeile wird auf das Datum und die Uhrzeit des Archivierungsvorgangs festgelegt.

Bei Abfragen, die Zeiten vor der Aktualisierung (14. 7. 2005, 17:34:22) untersuchen, wird Flurstück 117 in dem Zustand angezeigt, in dem es vor der Aktualisierung vorlag. Wenn Zeiten vor dem 09.07.2005, 14:33:43, abgefragt werden, wird Flurstück 117 nicht angezeigt, da es noch nicht erstellt worden war. Für alle Momentabfragen nach der Aktualisierung (14.07.2005, 3:45:23) wird Flurstück 117 in der aktuellen Repräsentation mit der erweiterten Grenze angezeigt.

Weitere Informationen zum Abfragen der Archivklasse

Löschen eines Features

Wenn ein Feature gelöscht wird, wird "gdb_to_date" mit dem Zeitstempel des Archivierungsvorgangs aktualisiert. Im folgenden Diagramm werden die Flurstücke 116 und 117 mit den entsprechenden Attributen "gdb_from_date" und "gdb_to_date" in der Archivklasse veranschaulicht.

Wenn Flurstück 117 gelöscht wird und diese Änderungen in die DEFAULT-Version zurückgeschrieben werden, wird das Attribut "gdb_to_date" mit dem Zeitstempel des Archivierungsvorgangs aktualisiert.

Technischer Hinweis zum Archivieren

Im folgenden Szenario kann in der Archivklasse eine zeitliche Lücke entstehen:

Ein Bearbeiter bearbeitet die DEFAULT-Version in einer Editiersitzung direkt und löscht ein Objekt.

Anschließend speichert der Bearbeiter die Änderungen, wodurch das Attribut "gdb_to_date" der Archivklasse mit dem Zeitstempel des Löschvorgangs für dieses Objekt aktualisiert wird.

Wenn dasselbe Objekt in einer Child-Version aktualisiert und mit der DEFAULT-Version abgeglichen wird, entsteht ein Konflikt.

Wenn während der Konfliktlösung ein Bearbeiter den Konflikt durch die aktualisierte Repräsentation der Zeile ersetzt, wird die Zeile beim Zurückschreiben der Version in der DEFAULT-Version wiederhergestellt. Mit dem Archivierungsvorgang wird in der Archivklasse eine neue Zeile eingefügt. Das Attribut "gdb_from_date" wird auf den Zeitstempel und "gdb_to_date" auf den 31. 12. 9999 festgelegt.

Wenn der Bearbeiter die Lineage des Objekts über den Zeitraum anzeigt, weisen die Datumsangaben eine Lücke zwischen "gdb_to_date" und "gdb_from_date" auf, als das Objekt in der DEFAULT-Version nicht vorhanden war.