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 Transaktionsumgebung des Datenbankmanagementsystems zur Verwaltung von Änderungen und Aktualisierungen in Geodatabases nutzen.
GIS-Benutzer stellen im Allgemeinen jedoch auch einige spezielle Anforderungen an Transaktionen. Beispiel:
- 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).
Editoren 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 längere Zeit dauern können, muss die GIS-Datenbank für tägliche Abläufe ununterbrochen verfügbar sein, wobei die einzelnen Benutzer möglicherweise mit eigenen Sichten oder Datenzuständen der gemeinsam verwendeten GIS-Datenbank arbeiten. In Mehrbenutzer-Datenbanken müssen die GIS-Transaktionen in der Umgebung des Datenbankmanagementsystems für kurze Transaktionen abgewickelt werden. Die Geodatabase spielt eine wichtige Rolle bei diesen Abläufen, indem sie die Verwaltung der komplexen GIS-Transaktionen in der Transaktionsumgebung für das Datenbankmanagementsystem ermöglicht.
Lange Transaktions-Workflows sind für ein GIS in vielen Fällen wichtig. Meist werden diese durch die Verwendung einer Enterprise-Geodatabase und ArcGIS 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 Editor muss mit einem individuellen Datenzustand arbeiten, eigene Aktualisierungen anzeigen und von anderen Editoren vorgenommene Aktualisierungen ignorieren. Anschließend müssen die Editoren ihre Aktualisierungen zurückschreiben und abgleichen, damit eventuelle Konflikte ermittelt und gelöst werden können.
- Checkout-/Checkin-Transaktionen: Häufig muss ein Teil einer Geodatabase für einen bestimmten Bereich oder Bezirk auf einem PC ausgecheckt und müssen diese Informationen in einer nicht verbundenen Sitzung aktualisiert werden, die Tage oder Wochen in Anspruch nehmen kann. 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.
- Systemübergreifende lose gekoppelte Replikation des Datenbankmanagementsystems: 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 Datenbankmanagementsysteme unterschiedlich. So werden z. B. Datasets zwischen Microsoft SQL Server, Oracle und IBM Db2 repliziert.
Das Geodatabase-Transaktionsmodell: Herkömmliche Versionierung
Um diese und viele andere GIS-Workflows effizient zu verwalten, werden in der Geodatabase mehrere Zustände aufrechterhalten, und gleichzeitig wird die Integrität der geographischen Informationen, Regeln und Verhalten sichergestellt. Das Verwalten, Bearbeiten und Anzeigen mehrerer Zustände 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 Zustände 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 Zustände der Geodatabase bearbeiten. Das Ziel ist offener Mehrbenutzerzugriff mit hoher Performance. 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 Objektzustände einer Geodatabase werden in zwei Delta-Tabellen erfasst:
- die Adds-Tabelle
- die Deletes-Tabelle
Um einen gewünschten Zustand der Geodatabase anzuzeigen und damit zu arbeiten, werden einfache Abfragen verwendet, z. B. um den Datenbankzustand zu einem bestimmten Zeitpunkt oder die aktuelle Version eines bestimmten Benutzers mit den von diesem Editor vorgenommenen Änderungen anzuzeigen.
Für lange Transaktionen im jeweiligen Datenbankmanagementsystem werden versionierte Geodatabases und Datasets verwendet, indem die Umgebung für kurze Transaktionen der Datenbank genutzt wird.
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 Geodatabase-Systemtabellen 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 Clients mit der Version "Default" arbeiten und einige Editoren 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 Überblick über die traditionelle Versionierung.