Strategien für die Datenverwaltung

Transaktionen mit geographischen Daten können hinsichtlich der Dauer und Komplexität große Unterschiede aufweisen. Die Geodatabase unterstützt zwei Strategien für die Datenverwaltung: mit und ohne Versionen. So wird allen Anforderungen von Benutzern und Anwendungen für die Ausführung kurzer und langer Transaktionen mit einfachen oder komplexen Daten Rechnung getragen.

Die Strategien werden für jede Feature-Class bzw. jede Tabelle einzeln festgelegt. Daher können in einer Geodatabase beide Strategien eingesetzt werden.

Bei beiden Strategien werden die Daten auf ähnliche Art bearbeitet. In beiden Fällen arbeiten Sie in einer Editiersitzung und größtenteils außerdem mit den gleichen Werkzeugen. Unterschiede bestehen jedoch darin, wie die zu Grunde liegenden Datenquellen verwaltet werden. Zudem bestehen Unterschiede darin, welche Daten Sie bearbeiten und welche Art von Workflows Sie ausführen können. Diese Unterschiede werden in diesem Abschnitt erläutert.

Datenverwaltung ohne Versionen

Bei dieser Strategie wird nicht mit mehreren Versionen gearbeitet. Es wird einfach das Transaktionsmodell des zu Grunde liegenden DBMS verwendet. Eine Bearbeitung ohne Versionierung der Daten entspricht der Verwendung von regulären Datenbanktransaktionen.

Zum Bearbeiten der Daten aktivieren Sie im Dialogfeld Editieroptionen das nicht versionierte Bearbeiten. Starten Sie eine Editiersitzung, und führen Sie dann die erforderlichen Vorgänge aus, z. B. Hinzufügen, Löschen oder Verschieben von Features oder Aktualisieren von Attributen. Mit der ersten Bearbeitung in der Editiersitzung beginnt die Transaktion. Beim Speichern werden die einzelnen Bearbeitungsvorgänge zusammen als eine Transaktion in der Datenbank festgeschrieben. Nach dem Speichern wird mit der nächsten Bearbeitung eine neue Transaktion begonnen. Während einer Editiersitzung können Sie je nach Bedarf mehrere Vorgänge gleichzeitig speichern. Allerdings wird empfohlen, häufig zu speichern, damit die bearbeiteten Daten nicht gesperrt werden und der Zugriff auf die Daten oder deren Bearbeitung durch andere Benutzer nicht blockiert wird. Nachdem Sie die Änderungen gespeichert haben, stehen diese allen anderen Benutzern und Anwendungen, die auf die Daten zugreifen, zur Verfügung.

Wenn Sie die Bearbeitungen nicht in der Datenbank festschreiben möchten, beenden Sie die Editiersitzung ohne zu speichern. Alle Bearbeitungen in dieser Transaktion werden verworfen und nicht in der Datenbank festgeschrieben. Dies betrifft alle Bearbeitungen seit dem letzten Speichern oder, falls Sie in der Zwischenzeit nicht gespeichert haben, alle Bearbeitungen seit dem Beginn der Editiersitzung.

Beim Bearbeiten werden alle im DBMS für die Daten definierten eindeutigen Indizes, Einschränkungen und Trigger angewendet. Das Sperrverhalten wird so angewendet, als würden Sie direkt im DBMS Datentransaktionen durchführen. Daher besteht für Benutzer oder Anwendungen, die auf dieselben Daten zugreifen oder diese ändern, die Gefahr, sich gegenseitig zu blockieren. Wenn mehrere Benutzer gleichzeitig nicht versionierte Daten bearbeiten, sollten Sie mit der Funktionsweise von Isolierungsgraden und Sperren im DBMS vertraut sein und bei Bedarf den richtigen Isolationsgrad im DBMS festlegen, bevor Sie mit ArcGIS arbeiten.

Diese Strategie ist für einfache Features geeignet, für die weder der Verlauf noch mehrere Repräsentationen der Daten mit Versionen verwaltet werden müssen. Da für diese Strategie keine Versionen erforderlich sind, ist es sowohl bei GIS- als auch bei anderen Anwendungen vorteilhaft, auf eine gemeinsame Datenbank zuzugreifen.

Potenzielle Anwendungsbereiche

• Problemlose Integration geographischer Daten in vorhandene Anwendungen, indem es Anwendungen von Drittanbietern (die nicht mit Esri Software erstellt wurden) erlaubt wird, dieselben Daten wie ArcGIS-Anwendungen zu lesen und zu ändern
• Verwalten von Projekten mit einfachen Workflows und Bearbeitungsvorgängen. Wenn Transaktionen immer einfach und von kurzer Dauer sind, können Sie die Daten direkt ändern, ohne die Änderungen zusammenführen und regelmäßig zusätzliche Tabellen für Versionen verwalten zu müssen.

Einschränkungen

• Sie können nur einfache Daten bearbeiten – Punkte, Linien, Polygone, Annotations und Beziehungen. Feature-Classes, die Teil einer Topologie, eines Netzwerk-Datasets, eines geometrischen Netzwerkes oder eines Terrains sind, können nicht bearbeitet werden.
• Da Sie die Datenquelle direkt bearbeiten, können Sie eine einzelne Änderung bei Fehlern nicht rückgängig machen oder wiederholen. Die einzige Möglichkeit, Änderungen rückgängig zu machen, besteht darin, sämtliche Änderungen seit dem letzten Speichern zu verwerfen, indem Sie die Editiersitzung beenden, ohne zu speichern.
• Jede Transaktion muss in einer einzelnen Editiersitzung gestartet und beendet werden. Editiersitzungen dauern jeweils nur eine begrenzte Zeit an. In der Regel müssen Sie sie beispielsweise nach einigen Stunden beenden, sodass Sie sich am Ende des Tages abmelden können.
• Bei nicht versionierten Bearbeitungen erfolgt keine Konflikterkennung. Wenn ein Benutzer ein Feature aktualisiert und speichert und anschließend ein anderer Benutzer dasselbe Feature aktualisiert und speichert, wird die erste Aktualisierung von der zweiten überschrieben.

  Weitere Informationen finden Sie unter Kurzer Überblick über das Arbeiten mit nicht versionierten Daten.

Datenverwaltung mit Versionen

Durch eine Geodatabase wird der reguläre DBMS-Transaktionsmechanismus erweitert, indem gleichzeitig mehrere Datenbankzustände zugelassen werden. Diese werden als Versionen bezeichnet. Jede Version kann laufende Vorgänge darstellen, z. B. einen Entwurf oder eine Gruppe von Arbeitsaufträgen – Arbeit, die sich über mehrere Verbindungen und über einen Zeitraum von Wochen oder Monaten erstrecken kann. Versionen ermöglichen das Verwalten früherer, aktueller und vorgeschlagener Änderungen an den Daten in derselben Geodatabase.

Um frühere Änderungen zu verwalten, speichern Sie sämtliche Änderungen an den Daten in separaten Archivtabellen. Sie können diese Änderungen so lange wie erforderlich aufbewahren. Dies ermöglicht es den Benutzern, den Zustand der Datenbank zu einem vergangenen Zeitpunkt einzusehen. Diese Funktion wird als Archivierung bezeichnet und ist in ArcGIS integriert. Es ist keine weitere Entwicklung erforderlich. Wenn Sie diese Funktion aktivieren, werden Änderungen an der DEFAULT-Version, die normalerweise als veröffentlichte Version der Datenbank verwendet wird, automatisch archiviert.

Um aktuelle Änderungen zu verwalten, können Bearbeiter ihre private Version der Geodatabase bearbeiten, um zu verhindern, dass andere Benutzer die laufenden Arbeiten einsehen können. Wenn Sie eine Version der Daten bearbeiten, werden keine Sperren gesetzt. Da andere Benutzer somit dieselben Daten lesen und bearbeiten können, die Sie bearbeiten, blockieren die Benutzer den Zugriff auf die Datenbank nicht gegenseitig, und die Nebenläufigkeit wird maximiert. Wenn ein Bearbeiter die Änderungen abgeschlossen hat, kann er oder sie diese in die veröffentliche Version integrieren.

Um vorgeschlagene Änderungen zu verwalten, können Sie ein Szenario entwickeln oder eine Was-wäre-wenn-Analyse innerhalb einer Version der Datenbank ausführen. Das Szenario kann als einzelne Änderung verwaltet werden, die sich über mehrere Editiersitzungen und Tage, Wochen oder Monate erstreckt. Sie können uneingeschränkt vorgeschlagene Features hinzufügen, geographische Analysen durchführen und Karten erstellen, ohne dass sich dies auf die Datenbank auswirkt, auf die andere Benutzer zugreifen. Wenn die Änderungen vollständig sind und genehmigt wurden, können Sie diese in den restlichen Teil der Geodatabase integrieren.

Eine Geodatabase kann beliebig viele Versionen aufweisen. Die Versionen können in verschiedenen Konfigurationen vorliegen und viele verschiedene Workflows unterstützen. Um die Einfachheit sicherzustellen und Geodatabase-Verwaltungsaspekte zu berücksichtigen, besteht die empfohlene bewährte Vorgehensweise jedoch darin, entweder eine flache Versionsstruktur zu verwenden oder für die Bearbeitung der DEFAULT-Version mehrere Editoren gleichzeitig zu verwenden.

Zur Unterstützung der Versionierungsfunktionen werden Daten in ArcGIS nicht dupliziert. Stattdessen wird jede Feature-Class und Tabelle im ursprünglichen Format belassen, und alle Änderungen werden in Tabellen erfasst, die als Delta-Tabellen bezeichnet werden. Delta-Tabellen bestehen aus einer Adds-Tabelle für Einfügungen und Aktualisierungen sowie aus einer Deletes-Tabelle für Löschungen. Jedes Mal, wenn ein Datensatz in einer der Versionen aktualisiert oder gelöscht wird, werden einer oder beiden Tabellen Zeilen hinzugefügt. Wenn Sie eine Feature-Class oder Tabelle in einer Version abfragen oder anzeigen, fasst ArcGIS die relevanten Zeilen aus den Delta-Tabellen und der ursprünglichen Tabelle zusammen, um eine nahtlose Ansicht der Daten darzustellen.

Bearbeiten einer versionierten Feature-Class

Versionierte Tabellen erfordern die regelmäßige Wartung durch einen Datenbankadministrator. Wenn eine Geodatabase über einen Zeitraum hinweg bearbeitet wird, erhöhen sich die Größe der Delta-Tabellen, was sich auf die Darstellungs- und Abfrage-Performance auswirkt. Um die Datenbank-Performance aufrechtzuerhalten, müssen Datenbankadministratoren versionierte Datenbanken in regelmäßigen Abständen komprimieren, wobei redundante Informationen aus den Delta-Tabellen entfernt werden. Versionierte Datenbanken sollten nach einer Zeit hoher Datenbankaktivität komprimiert werden, z. B. am Ende einer Schicht oder nach dem Laden von Daten. Der Komprimierungsvorgang kann ausgeführt werden, wenn andere Benutzer verbunden sind und die Datenbank verwenden.

Mit ArcGIS können die den Versionen zugrunde liegenden Delta-Tabellen auf eine der folgenden Arten verwaltet werden:

• Speichern aller Änderungen in den Delta-Tabellen, unabhängig von der Version
• Speichern der Änderungen, die in Versionen außer der DEFAULT-Version vorgenommen wurden, in den Delta-Tabellen; alle Änderungen an der DEFAULT-Version werden in den Basistabellen gespeichert.

Die erste Möglichkeit ist ausschließlich zur Unterstützung von ArcGIS-Anwendungen vorgesehen. Die zweite Möglichkeit ist nützlich, wenn Sie die Daten mit ArcGIS-Anwendungen und Anwendungen von Drittanbietern verwalten müssen.

Verwalten der Daten ausschließlich mit ArcGIS-Anwendungen

In einer Umgebung, in der Sie Daten ausschließlich mit ArcGIS-Anwendungen verwalten, empfiehlt sich eine Versionsverwaltung, bei der alle Änderungen in den Delta-Tabellen gespeichert werden. So können Sie die Funktionen der Geodatabase wie die Archivierung und Replikation sowie die Möglichkeit, geometrische Netzwerke und Topologien zu bearbeiten, optimal nutzen.

Um dieses Verhalten für eine Feature-Class oder Tabelle zu aktivieren, registrieren Sie die Daten als versioniert ohne die Option, die Änderungen in die Basistabelle zu verschieben. Wenn Sie Änderungen an einem auf diese Art registrierten Dataset speichern, werden Änderungen in den Delta-Tabellen gespeichert. Bei diesem Ansatz ist kein direkter Zugriff auf die ursprünglichen Tabellen möglich – die Benutzer greifen stets auf eine Version der Daten zu.

Im folgenden Beispiel wird eine Konfiguration veranschaulicht, in der Daten vollständig unter Verwendung von Versionen verwaltet werden. Die Bearbeiter müssen ArcGIS oder eine andere Esri Anwendung verwenden, um Änderungen an den Daten vornehmen zu können. Nicht-GIS-Anwendungen können auf die veröffentlichte Version oder eine andere Version zugreifen, sofern sie an versionierte Ansichten angepasst wurden.

Da Delta-Tabellen und andere Tabellen Unterstützung für Versionen bieten müssen, haben Anwendungen, die ohne Esri Softwarebibliotheken direkt auf die Daten im DBMS zugreifen, nicht die entsprechenden Funktionen zum Lesen der Versionen. ArcGIS bietet versionierte Ansichten, sodass diese Anwendungen Versionen mit SQL lesen können. Mit versionierten Ansichten können Sie sowohl auf Tabellen als auch auf Feature-Classes zugreifen. Für den Zugriff auf die geometrischen Attribute von Feature-Classes in einer versionierten Ansicht müssen SQL-Geometrietypen verwendet werden. Diese werden von ArcGIS vollständig unterstützt.

Diese Vorgehensweise bietet folgende Vorteile:

• Sie können Änderungen rückgängig machen oder wiederholen.
• Da keine Sperren vorhanden sind, können Bearbeitungskonflikte entstehen. ArcGIS bietet die Möglichkeit, Konflikte einfach zu erkennen, abzugleichen und zu lösen.
• Sie können Änderungen automatisch archivieren und dann den Zustand der Datenbank zu einem bestimmten Zeitpunkt abfragen.
• Features in einem geometrischen Netzwerk, einem Netzwerk-Dataset oder einer Topologie können bearbeitet werden.
• Zwei oder mehr Büros an unterschiedlichen Standorten können gleichzeitig an synchronisierten Kopien einer Geodatabase arbeiten. Die Büros müssen ihre Änderungen regelmäßig einander übermitteln, sodass jedes Büro über eine aktuelle View der Geodatabase verfügt. In ArcGIS wird diese Funktion als Replikation von Geodatabases bezeichnet.
• Mobile Benutzer, die nicht mit dem Netzwerk verbunden ist, können einen Teil der Geodatabase auf einem Laptop oder Handheld-Gerät bearbeiten. Wenn die Benutzer in das Büro zurückkehren, integrieren sie ihre Änderungen in die Geodatabase. In ArcGIS wird diese Funktion auch als Replikation von Geodatabases bezeichnet.

Mögliche Anwendungen schließen die folgenden ein:

• Projekte, die die Speicherung und Abfrage archivierter Daten erfordern.
• Projekte, die eine Was-wäre-wenn-Analyse erfordern: Erstellen Sie einen neuen Entwurf in einer separaten Version. Wenn der Entwurf genehmigt wird, können Sie diesen mit dem Rest der Datenbank zusammenführen. Wenn er nicht genehmigt wird, können Sie ihn verwerfen.
• Projekte mit speziellen Maßnahmen zur Qualitätssicherung: Erfassen Sie Änderungen an Daten, wie Massenimporte, in einer von anderen Datenbankbenutzern isolierten Version. Testen und genehmigen Sie Änderungen, bevor diese mit der veröffentlichten Version der Datenbank zusammengeführt werden.
• Projekte, die in funktionale oder geographische Einheiten unterteilt sind: Zum Beispiel kann ein Projekt für den Entwurf und Bau eines neuen Einkaufszentrums unterschiedliche Konstruktionsphasen aufweisen, die in einen Ost- und einen Westabschnitt oder aber nach Konstruktionsarbeiten unterteilt sind, etwa Bau des Gebäudes, Einbau der Versorgungsleitungen und gärtnerische Gestaltung. Jede Arbeitseinheit wird in einer eigenen Version ausgeführt, und bei Fertigstellung jeder Version wird diese in die veröffentlichte Version der Datenbank zurückgeschrieben.
• Projekte, die in einer vorgeschriebenen Abfolge von Phasen durchgeführt werden, wobei jede Phase vor dem Abschluss baulich, behördlich oder rechtlich genehmigt werden muss: In den Workflows für solche Projekte kann jede Phase als separate Version verwaltet werden, z. B. ursprünglicher Entwurf, vorgeschlagene Version, genehmigte Version und Version für die Bauphase. Mit dem Fortschreiten des Projekts über verschiedene Etappen wird jede Phase überprüft und genehmigt und anschließend mit der nächsten Version überschrieben, bis die letzte Phase erreicht und abgeschlossen ist.
• Projekte mit Prüfanforderungen durch Behörden: Führen Sie ein umfassendes Archiv, um Fragen zu Änderungen beantworten zu können.
• Projekte mit Büros an verschiedenen Standorten, die gleichzeitig an derselben Geodatabase arbeiten müssen: Sie müssen ihre Kopien der Daten in regelmäßigen Abständen synchronisieren können.
• Projekte, die Wartungsteams vor Ort erfordern, um Daten mit Mobilcomputern zu aktualisieren.
• Projekte, bei denen Softwareentwickler SQL-Anweisungen und Anwendungslogik in einer privaten Version der Datenbank testen müssen.

Versionen bieten viele Vorteile, weisen jedoch auch einige Einschränkungen auf:

• Anwendungen von Drittanbietern können erst Daten lesen, wenn sie für die Verwendung von versionierten Ansichten angepasst wurden.
• Bei der Arbeit mit versionierten Daten können aktive DBMS-Mechanismen wie Eindeutigkeitseinschränkungen und Trigger nur beschränkt eingesetzt werden. Die Ursache dafür besteht darin, dass durch Einfügungen und Aktualisierungen neue Zeilen in den Delta-Tabellen erstellt werden anstatt Einfügungen und Aktualisierungen in der Basistabelle.

Verwalten von Daten mit ArcGIS- und anderen Anwendungen

In einer heterogenen Computerumgebung, wo verschiedene Abteilungsanwendungen auf dieselbe Datenbank zugreifen, ist möglicherweise die Unterstützung von ArcGIS und Drittanbieteranwendungen erforderlich. Beispiel: In einer Abteilung werden die geographischen Daten in der Datenbank mit ArcGIS gepflegt, und in einer anderen Abteilung werden die Kundendaten in derselben Datenbank mit einer benutzerdefinierten Anwendung bearbeitet. Die benutzerdefinierte Anwendung muss bei den Transaktionen DBMS-Einschränkungen und Trigger anwenden und kann versionierte Tabellen möglicherweise nicht erkennen. Gleichzeitig muss die andere Abteilung die geographischen Daten in einer separaten und isolierten Version bearbeiten. Die Änderungen der Abteilung dürfen hierbei erst freigegeben werden, wenn diese vollständig und genehmigt sind.

Um diese Anforderungen zu erfüllen, ermöglicht es ArcGIS, versionierte Feature-Classes oder Tabellen zu bearbeiten und die Änderungen gleichzeitig mit anderen Anwendungen gemeinsam zu nutzen. Um diese Funktion für eine Feature-Class oder Tabelle zu aktivieren, registrieren Sie die Daten als versioniert mit der Option, die Änderungen in die Basistabelle zu verschieben. Diese Option ist nur im Dialogfeld "Registrierung" verfügbar.

Wenn Sie Daten bearbeiten, die auf diese Weise in der Basistabelle registriert wurden, verhalten sich die Versionen wie bei der zuvor beschriebenen Vorgehensweise, d. h., die Änderungen werden in den Delta-Tabellen gespeichert. Die Ausnahme dazu bildet die DEFAULT-Version. Bei jedem Speichern von Änderungen in der DEFAULT-Version durch direkte Bearbeitung oder durch Zusammenführen mit Änderungen aus einer anderen Version werden die Änderungen in den Basistabellen gespeichert. Die Änderungen verbleiben jedoch nicht in Delta-Tabellen, wie dies der Fall ist, wenn die Option zum Verschieben von Änderungen in die Basistabelle deaktiviert ist.

Auf diese Weise können alle Anwendungen mit derselben Datenbank arbeiten.

• Anwendungen, die ohne Software von Esri geschrieben wurden, können weiterhin mit Standardtransaktionen auf Daten zugreifen und diese bearbeiten. Dies ist selbst dann möglich, wenn die Daten zur gleichen Zeit in der DEFAULT-Version oder einer anderen Version bearbeitet werden.
• Wenn ArcGIS oder eine Anwendung, die mit ArcObjects geschrieben wurde, Änderungen in der DEFAULT-Version speichert oder Änderungen in der DEFAULT-Version zusammenführt, werden alle im DBMS für die Daten definierten eindeutigen Indizes, Einschränkungen und Trigger angewendet.
• Wenn die Daten in einer Anwendung geändert werden, sind die Änderungen sofort für andere Anwendungen verfügbar, die auf die Daten zugreifen. Da die Änderungen an der DEFAULT-Version nicht in Delta-Tabellen gespeichert werden, müssen Anwendungen von Drittanbietern nicht für die Verwendung von versionierten Ansichten angepasst werden, um diese Tabellen lesen zu können.

Potenzielle Anwendungsbereiche

• Projekte, die die Datenbearbeitung durch ArcGIS und andere Anwendungen erfordern – Richten Sie einen Workflow ein, bei dem andere Anwendungen mit regulären DBMS-Transaktionen auf die nicht räumlichen Daten in der Datenbank zugreifen und diese ändern. Andere Benutzer arbeiten an bestimmten Versionen derselben Daten. Deren Transaktionen weisen eine relativ lange Dauer auf und sind von allen anderen Datenbankbenutzern isoliert, bis sie in die DEFAULT-Version zurückgeschrieben werden.
• Die gleichen potenziellen Anwendungsbereiche, die auch beim Verwalten von Daten ausschließlich mit ArcGIS-Anwendungen gelten
  • Projekte, die eine Was-wäre-wenn-Analyse erfordern
  • Projekte mit speziellen Qualitätsanforderungen
  • Projekte, die in funktionale oder geographische Einheiten unterteilt sind
  • Projekte, die in einer vorgeschriebenen und aufeinander abgestimmten Abfolge von Phasen ablaufen
  • Projekte, die Wartungsteams erfordern, um vor Ort Daten mit Mobilcomputern zu aktualisieren
  • Projekte, bei denen Softwareentwickler SQL-Anweisungen und Anwendungslogik testen müssen

Einschränkungen

Wenn Sie ein Dataset mit der Option zum Verschieben der Änderungen in die Basistabelle als versioniert registrieren, sind die Möglichkeiten für die Arbeit mit Versionen eingeschränkt.

• Sie können nur einfache Daten bearbeiten – Punkte, Linien, Polygone, Annotations und Beziehungen. Feature-Classes in einer Topologie, einem Netzwerk-Dataset, einem geometrischen Netzwerk oder einem Terrain können nicht bearbeitet werden.
• Sie können keine Änderungen für das Dataset archivieren.
• Sie können das Dataset nicht replizieren.
• Wenn Sie die DEFAULT-Version bearbeiten oder eine Version in die DEFAULT-Version zurückschreiben, können Sie Konflikte nicht lösen. Deshalb werden die Änderungen anderer Benutzer möglicherweise überschrieben.

Weitere Informationen zu Versionen und deren Funktionen finden Sie unter Versionierung und Versionierungsszenarien.