Geodatabase-Transaktionsmanagement

Transaktionen sind Pakete mit Arbeitsschritten, mit denen Änderungen an Datenbanken vorgenommen werden. GIS-Datenbanken (Geographisches Informationssystem) müssen, wie andere Datenbankanwendungen auch, Update-Transaktionen unterstützen, mit denen die Datenintegrität und das Anwendungsverhalten erzwungen werden. In vielen Fällen können Benutzer die Funktionen in der DBMS-Transaktionsumgebung zur Verwaltung von Änderungen und Aktualisierungen in Geodatabases nutzen.

GIS-Benutzer haben im Allgemeinen jedoch auch einige spezielle Anforderungen an Transaktionen. Beispiele:

• Häufig werden mehrere Datensätze gemeinsam in einer einzelnen Transaktion aktualisiert.
• Zahlreiche Transaktionen erstrecken sich über lange Zeiträume (manchmal Tage oder Monate, nicht nur Sekunden oder Minuten).

Benutzer müssen darüber hinaus die Möglichkeit haben, Änderungen rückgängig zu machen und zu wiederholen. Editiersitzungen können mehrere Stunden und manchmal sogar Tage dauern. Oft werden die Änderungen in Systemen ausgeführt, die nicht mit der zentralen Datenbank verbunden sind.

Da GIS-Workflows Tage oder Monate dauern können, muss die GIS-Datenbank für tägliche Abläufe ununterbrochen verfügbar sein, wobei die einzelnen Benutzer möglicherweise mit verschiedenen Sichten und State-Versionen der gemeinsam verwendeten GIS-Datenbank arbeiten. In Mehrbenutzer-Datenbanken müssen die GIS-Transaktionen in der DBMS-Transaktionsumgebung für kurze Transaktionen abgewickelt werden. Die ArcSDE-Technologie ermöglicht die Verwaltung der komplexen GIS-Transaktionen in der einfachen DBMS-Transaktionsumgebung und spielt somit eine wichtige Rolle bei diesen Abläufen.

Lange Transaktions-Workflows sind für GIS-Benutzer in vielen Fällen wichtig. Meist werden diese durch die Verwendung eines Mehrbenutzer-DBMS und ArcSDE zur Verwaltung von Aktualisierungen der zentralen GIS-Datenbank mithilfe von Versionierung ermöglicht. Weitere Informationen dazu finden Sie weiter unten.

Im Folgenden sind Beispiele für GIS-Datenkompilierungsabläufe aufgelistet, die ein versionsbasiertes Transaktionsmodell erforderlich machen:

• Mehrere Editiersitzungen: Eine Aktualisierung der GIS-Datenbank kann zahlreiche Änderungen erforderlich machen, die sich über mehrere Editiersitzungen über Tage oder Wochen hinweg erstrecken.
• Bearbeitung durch mehrere Benutzer: Oft müssen mehrere Benutzer dieselben räumlich integrierten Features gleichzeitig aktualisieren. Jeder Benutzer muss mit einem individuellen Datenbank-State arbeiten, eigene Aktualisierungen anzeigen und von anderen Bearbeitern vorgenommene Aktualisierungen ignorieren. Anschließend müssen die Benutzer ihre Aktualisierungen zurückschreiben und abgleichen, damit eventuelle Konflikte ermittelt und gelöst werden können.
• Checkout-/Checkin-Transaktionen: Die Daten müssen immer häufiger zu Vor-Ort-Einsätzen mitgenommen und dort über mobile Anwendungen bearbeitet und aktualisiert werden. Diese Aktualisierungen müssen in die Hauptdatenbank zurückgeschrieben werden.
• Verlauf: In einigen Fällen ist es von Vorteil, eine Verlaufsversion der einzelnen Features in der GIS-Datenbank beizubehalten, auch wenn diese Version bereits aktualisiert wurde. So können Sie eine Kopie der alten und geänderten Features archivieren oder den Verlauf eines Features nachverfolgen, z. B. Eigenschaften von Flurstück-Lineages oder Feature-Aktualisierungen.
• Übertragen von Aktualisierungen nur mit Änderungen: Wenn die Informationen in Enterprise-Datenbanken und räumlichen Dateninfrastrukturen von mehreren Organisationen gemeinsam verwendet werden, müssen Aktualisierungen nur mit den geänderten Daten über das Internet in einem genau definierten XML-Schema (Extensible Markup Language) ausgetauscht werden.
• Verteilte Geodatabase-Replikate: Bei einer regionalen Datenbank kann es sich um eine Teilkopie der GIS-Hauptdatenbank für eine bestimmte geographische Region handeln. Diese beiden Datenbanken müssen regelmäßig synchronisiert werden.
• DBMS-übergreifende lose gekoppelte Replikation: GIS-Daten müssen häufig zwischen einer Reihe von Datenbankkopien (Replikaten) synchronisiert werden, die an jedem Standort lokal aktualisiert werden. Oft sind die Datenbanken nicht durchgehend über das Internet verbunden. Es ist erforderlich, die Aktualisierungen auf der Basis eines Zeitplans zwischen den Datenbankreplikaten zu übertragen und den Inhalt der Datenbanken zu synchronisieren. Oft sind die DBMS-Systeme unterschiedlich. So werden z. B. Datasets zwischen Microsoft SQL Server, Oracle und IBM DB2 repliziert.

Das Geodatabase-Transaktionsmodell: Versionierung

Um diese und viele andere GIS-Workflows effizient zu verwalten, werden in der Geodatabase mehrere States aufrechterhalten, und gleichzeitig wird die Integrität der geographischen Informationen, Regeln und Verhalten sichergestellt. Das Verwalten, Bearbeiten und Anzeigen mehrerer States basiert auf der Versionierung. Bei der Versionierung werden verschiedene Versionen einzelner Features und Objekte aufgezeichnet, wenn diese geändert, hinzugefügt oder entfernt werden. Die einzelnen States eines Features oder Objekts werden zusammen mit wichtigen Transaktionsinformationen als Versionen in jeweils einer Tabellenzeile gespeichert. Beliebig viele Benutzer können gleichzeitig eine beliebige Anzahl von Versionen bearbeiten und verwalten.

Durch die Versionierung können alle Transaktionen als Reihe von Änderungen über die Zeit in der Datenbank aufgezeichnet werden. So können mehrere Benutzer verschiedene Sichten oder States der Geodatabase bearbeiten. Das Ziel ist offener Mehrbenutzerzugriff bei hoher Leistung. Die Verarbeitungsgeschwindigkeit muss hoch sein, und das System muss die gleichzeitige Verwendung von Datasets mit Hunderten Millionen von Datensätzen durch Tausende Benutzer unterstützen.

Das auf der Versionierung basierende Geodatabase-Transaktionsmodell ist relativ einfach strukturiert. Die Aktualisierungen werden in Änderungstabellen protokolliert.

Die Objekt-States einer Geodatabase werden in zwei Delta-Tabellen erfasst:

• Die Adds-Tabelle
• Die Deletes-Tabelle

Um einen gewünschten State der Geodatabase anzuzeigen und damit zu arbeiten, werden einfache Abfragen verwendet, z. B. um den Datenbank-State zu einem bestimmten Zeitpunkt oder die aktuelle Version eines bestimmten Benutzers mit den von dieser Person vorgenommenen Änderungen anzuzeigen.

ArcSDE spielt eine wichtige Rolle im Zusammenhang mit versionierten Geodatabase-Anwendungen und wird zur Verwaltung von langen Transaktionen, wobei die DBMS-Transaktionsumgebung für kurze Transaktionen genutzt wird, und für die DBMS-übergreifende Arbeit verwendet.

Im Versionstabellenbeispiel wird dem Flurstück Nummer 45 die Nummer 47 zugewiesen. Mit der Versionierung wird das ursprüngliche Flurstück in der Tabelle "Deletes" und das neue Flurstück in der Tabelle "Adds" gespeichert. In anderen Metatabellen werden die Versionsinformationen zur Transaktion erfasst, wie Zeit und Abfolge der einzelnen Aktualisierungen, Versionsname und State-ID der einzelnen Aktualisierungen. Jede Version weist außerdem eigene Sicherheits- und Zugriffsrechte auf.

So kann festgelegt werden, dass die meisten Benutzer mit der Version "Default" arbeiten und einige Bearbeiter gleichzeitig Aktualisierungen der eigenen Datenbankversionen vornehmen.

Für jede Version können zahlreiche Aktualisierungen vorgenommen werden, und zusätzliche Änderungen werden an der jeweiligen aktualisierten Version vorgenommen. Wenn die Aktualisierungen veröffentlicht werden können, wird ein Abgleichvorgang ausgeführt, und die Änderungen in der aktualisierten Version werden in die Hauptversion (Default) importiert. Zur Ermittlung und Lösung eventueller Konflikte wird ein Konfliktlösungsprozess verwendet.

Weitere Informationen zur Versionierung finden Sie unter Versionierung.