Versionierungsszenarien

In diesem Abschnitt wird die Anwendung der Versionierung beschrieben, d. h., wie diese Technologie in einer Organisation verwendet werden kann. Außerdem werden die verfügbaren Versionskonfigurationen erläutert.

Workflows unterscheiden sich von Organisation zu Organisation oft stark. Häufig verlaufenen sie in getrennten Phasen, wobei jede Phase die Zuordnung unterschiedlicher Ressourcen und Geschäftsregeln erfordert. Meist stellen die einzelnen Phasen im Gesamtprozess eigenständige Arbeitseinheiten dar, z. B. Arbeitsaufträge. Zur besseren Bearbeitung der einzelnen Arbeitsaufträge können Sie jeweils eine eigene, isolierte Version erstellen und diese bearbeiten. Wenn Sie mit der abgeschlossenen Arbeit zufrieden sind, können Sie die Änderungen in die veröffentlichte Version der Datenbank integrieren. Eine solche Arbeit mit Versionen ermöglicht ihnen, die einfachsten ebenso wie die komplexesten Prozesse des Workflows zu integrieren.

Im wahrscheinlichsten Fall wird die veröffentlichte Datenbank durch gleichzeitige Änderung der Default-Version durch viele Bearbeiter oder aber mit einer Kombination der anderen Konfigurationen bearbeitet. Grundkenntnisse der Organisations- und Geschäftsanforderungen sowie ein Bewusstsein für die Vor- und Nachteile jeder Konfiguration sind bei der Auswahl des optimalen Vorgehens in der Organisation unerlässlich.

Um die Einfachheit sicherzustellen und Geodatabase-Verwaltungsaspekte zu berücksichtigen, besteht die empfohlene bewährte Vorgehensweise darin, entweder eine flache Versionsstruktur zu verwenden oder für die Bearbeitung der Default-Version mehrere Editoren gleichzeitig zu verwenden.

Gleichzeitiges Bearbeiten der veröffentlichten Datenbank

Viele Benutzer können die Datenbank gleichzeitig bearbeiten. Daher besteht die einfachste Möglichkeit, die Bearbeitung durch mehrere Benutzer zu unterstützen, in der direkten Bearbeitung der Default-Version durch viele Bearbeiter.

Wenn die einzelnen Bearbeiter mit der Bearbeitung der Default-Version beginnen, wird in der Editiersitzung automatisch eine nicht benannte, temporäre Version erstellt. Auf diese temporäre Version kann nur der aktuelle Bearbeiter zugreifen. Wenn Bearbeiter ihre Arbeit speichern oder die Editiersitzung beenden, werden die in der temporären Version erfassten Änderungen in die Default-Version zurückgeschrieben.

Wenn die Default-Version von einem anderen Benutzer bearbeitet wurde, seitdem Sie mit dem Bearbeiten begonnen haben, gleicht ArcGIS die Änderungen automatisch ab und schreibt diese zurück, sobald Sie Ihre Änderungen speichern. Sie werden darüber benachrichtigt, dass die Version geändert wurde, und müssen diese erneut speichern, um die von den anderen Bearbeitern vorgenommenen Änderungen zu akzeptieren. Sie können diese Warnmeldung umgehen, indem Sie den Auto-Abgleich im Dialogfeld "Optionen" in ArcMap aktivieren. Unabhängig davon, ob Sie diese Warnung umgehen, müssen Sie bestehende Konflikte im Dialogfeld "Konfliktlösung" lösen, bevor Sie Ihre Änderungen erfolgreich speichern können.

Weitere Informationen zu Einstellungen zum Speichern von Daten

Informationen zum Lösen von Datenkonflikten

Vorteile:

• Diese Strategie unterstützt einfache Datenbankänderungen gut, da die Benutzer zum Bearbeiten der Daten keine neuen Versionen erstellen müssen. Dieses Vorgehen ist empfehlenswert, wenn die Arbeitseinheiten relativ klein sind oder die dauerhafte Speicherung von Alternativentwürfen nicht erforderlich ist.
• Wenn keine Konflikte vorliegen, werden gespeicherte Änderungen direkt in die Default-Version zurückgeschrieben.

Nachteile:

• Die Default-Version wird permanent geändert. Die Gefahr von versehentlichen oder unberechtigten Änderungen ist groß. Datenbankadministratoren müssen somit möglicherweise häufiger Sicherungskopien der Datenbank erstellen.
• Transaktionen mit langer Dauer und die Erstellung alternativer Entwurfsversionen, die viele Editiersitzungen umfassen, werden nicht unterstützt.
• Es kann immer nur ein Abgleichvorgang pro Geodatabase aktiv sein. Bei häufigen Abgleich- und Zurückschreibevorgängen aus verschiedenen Editiersitzungen müssen Bearbeiter, die ihre Änderungen speichern möchten, ggf. auf den Abschluss aktiver Abgleich- und Zurückschreibevorgänge warten. In großen Mehrbenutzer-Geodatabases sollten möglichst Situationen vermieden werden, in denen viele Benutzer Abgleich- und Zurückschreibevorgänge für eine gemeinsame Version vornehmen. Beim Abgleichen und Zurückschreiben wird die Version exklusiv gesperrt. Während diese Sperre besteht, können andere Benutzer ihre Tasks nicht abschließen.

Mehrere Projekte

Wenn Sie mehrere Projekte oder Arbeitsaufträge verwalten, müssen Sie bei der Verwaltung von Workflows strukturierter vorgehen. Eigenständige Arbeitseinheiten können sich über zahlreiche Editiersitzungen und mehrere Tage, Wochen oder Monate erstrecken, ohne dass die Default-Version geändert wird. Beispiele für solche eigenständigen Arbeitseinheiten sind Autobahnausbauten, die Einrichtung neuer Telefon-Services oder auch ein laufendes Wartungsprojekt für eine Gas-Pipeline.

Bei Beginn eines Arbeitsauftrags oder Projekts wird eine Version als Child-Version der Default-Version erstellt. Diese Version kann von einem oder mehreren Bearbeitern bearbeitet werden, bis der Arbeitsauftrag oder das Projekt abgeschlossen ist. Wenn alle Änderungen an einer Version abgeschlossen wurden, gleicht der Bearbeiter oder der ArcSDE-Administrator die Änderungen mit der Default-Version ab und löst möglicherweise entstandene Konflikte. Anschließend werden die Änderungen in die Default-Version zurückgeschrieben, wobei sie in die veröffentlichte Datenbank integriert werden. Nun kann die Child-Version entfernt werden.

Berechtigungen für den Benutzerzugriff auf die Default-Version können eingeschränkt werden, um diesen Workflow zu erzwingen und sicherzustellen, dass die Default-Version nicht geändert wird. ArcSDE-Administratoren können die Berechtigung für die Default-Version auf geschützt festlegen. Damit wird es Benutzern ermöglicht, die Default-Version weiterhin anzuzeigen, doch wird der Zugriff auf schreibgeschützt beschränkt. Bearbeiter, die die Daten ändern möchten, müssen eine neue Version erstellen.

Wenn die Benutzer, die nur über Leseberechtigungen verfügen, Änderungen nach dem Zurückschreiben in die Default-Version nicht sofort anzeigen müssen, können Sie für diese eine geschützte, statische Version der Default-Version erstellen. Diese Version sollte erstellt werden, nachdem die Datenbank komprimiert wurde und die Indizes und Statistiken neu erstellt wurden. Auf diese Weise wird sichergestellt, dass alle Zeilen, die für die Darstellung der schreibgeschützten Version erforderlich sind, in der Basistabelle gespeichert werden und die Datenbank eine optimale Performance aufweist. In einem solchen Szenario werden an den Datenbankversionen der Benutzer, die nur über Leseberechtigungen verfügen, keine Änderungen vorgenommen (FastTrak in der Abbildung unten). Daher müssen keine Abfragen von Versionsunterschieden ausgeführt werden, und die Datenbankstatistiken und Indizes bleiben aktuell und werden nicht fragmentiert. Nachdem alle geplanten Datenbankkomprimierungen ausgeführt wurden, wird diese Version neu erstellt, wodurch Benutzer, die nur über Leseberechtigungen verfügen, auf die Änderungen seit der letzten Datenbankkomprimierung zugreifen können.

Vorteile:

• Einfachheit: Jede Arbeitseinheit ist nach Version logisch von den anderen abgegrenzt.
• Lang andauernde Transaktionen, die viele Editiersitzungen umfassen, sowie die Erstellung alternativer Entwürfe werden unterstützt. Somit können Bearbeiter Vorschläge entwickeln, ohne die Produktionsdatenbank zu beeinflussen.
• Durch das Erstellen einer neuen Version aus der Default-Version wird die Produktionssicht der Datenbank vor unbeabsichtigten Änderungen geschützt. Einzelne Arbeitsprojekte werden bei Abschluss in die Produktionsdatenbank integriert.
• Batch-Abgleich-/Zurückschreibevorgänge werden unterstützt.

Nachteile:

• Wie bei jeder mehrschichtigen Versionskonfiguration gilt, dass sich mit steigender Anzahl von Zeilen in den Delta-Tabellen der Version die potenziellen Auswirkungen auf die Abfrage-Performance der Version erhöhen. Dieser zusätzliche Aufwand kann minimiert werden, indem die Datenbank regelmäßig komprimiert wird und die DBMS-Statistiken aktualisiert werden.

Mehrere Projekte mit Teilprojekten

Komplexe Projekte erfordern eine kompliziertere Struktur der Workflows, als es beim gleichzeitigen Bearbeiten oder bei mehreren Projekten möglich ist. Solche Projekte können in mehrere funktional oder geographisch orientierte Einheiten unterteilt werden, sodass sich eine komplexe Versionshierarchie entwickelt. So kann ein Projekt für den Entwurf und Bau eines neuen Einkaufszentrums beispielsweise unterschiedliche Konstruktionsphasen aufweisen, die in einen Ost- und einen Westabschnitt oder nach Konstruktionsarbeiten aufgeteilt sind, etwa Bau, Einbau der Versorgungsleitungen und Gestaltung der Außenanlagen.

Bei umfangreichen Projekten mit unterschiedlichen Teams und zahlreichen eigenständigen Arbeitseinheiten stellt eine mehrschichtige Versionsstruktur eine Möglichkeit dar, den Workflow effizient anzuordnen. Die Teams, die an unterschiedlichen Aspekten desselben Projekts arbeiten, erstellen jeweils eine eigene Version, um eine private Sicht der eigenen Aktualisierungen zu pflegen. Sobald das Projekt abgeschlossen ist, können die Versionen abgeglichen und in die Default-Version zurückgeschrieben werden. Sie werden so zu einem integralen Bestandteil der veröffentlichten Datenbank.

Vorteile:

• Unterstützt komplexe Projekte.
• Unterstützt Transaktionen langer Dauer, die viele Editiersitzungen umfassen.
• Unterstützt automatisierte Batch-Abgleich- und Zurückschreibevorgänge.

Nachteile:

• Sie müssen Versionen in der richtigen Reihenfolge abgleichen und zurückschreiben, d. h., Sie beginnen mit den Versionen, die von der Default-Version am weitesten entfernt sind, und gehen dann rückwärts. Anders ausgedrückt: Die Versionen dritter Ebene (Child-Versionen von Child-Versionen von Child-Versionen) der Default-Version müssen in ihre Parent-Versionen zurückgeschrieben werden, die ihrerseits Versionen zweiter Ebene (Child-Versionen von Child-Versionen) der Default-Version sind. Diese Versionen zweiter Ebene können dann in die Versionen erster Ebene (Child-Versionen) der Default-Version zurückgeschrieben werden. Zuletzt können die Versionen erster Ebene (Child-Versionen) in die Default-Version zurückgeschrieben werden.

  Nachdem jede Child-Version in die jeweilige Parent-Version zurückgeschrieben wurde, kann die Child-Version gelöscht werden.

• Das Abgleichen und Zurückschreiben kann nur zwischen Versionen auf dem direkten Pfad vorgenommen werden, über Versionspfade hinweg können keine Abgleich- und Zurückschreibevorgänge erfolgen.
• Mit der Verwaltung einer komplexen Versionsstruktur sind einige Performance-Einbußen verbunden: Mit steigender Anzahl von Zeilen in den Delta-Tabellen der Version erhöhen sich die potenziellen Auswirkungen auf die Abfrage-Performance.

In Phasen unterteilte Projekte

Viele Projekte werden in einer vorgeschriebenen und aufeinander abgestimmten Abfolge von Phasen durchgeführt, die vor dem Wechsel zur nächsten Phase baulich, behördlich oder rechtlich genehmigt werden müssen. Zum Beispiel werden im Bereich Versorgungsunternehmen häufig die Phasen "in Bearbeitung", "vorgeschlagen", "angenommen", "im Bau" und "gebaut" verwendet. Dieser besondere Prozess verläuft im Wesentlichen zyklisch: Ein Arbeitsauftrag wird anfänglich einem Ingenieur zugewiesen und in der Zeit, in der das Projekt verschiedene Phasen durchläuft, nach und nach geändert, bevor er vollständig in die Produktionsdatenbank integriert wird.

Bei diesem Vorgehen werden Versionen erstellt, die die einzelnen Phasen des Prozesses darstellen: Anfangsentwurfs- oder Vorschlagsversion, genehmigte Version und Version für die Bauphase. Mit dem Fortschritt des Projekts über verschiedene Etappen wird jede Phase überprüft und genehmigt sowie anschließend mit der nächsten Version überschrieben, bis die letzte Phase erreicht und abgeschlossen ist. Die älteren Versionen können je nach Bedarf zu Zwecken der Verlaufsverfolgung beibehalten oder gelöscht werden.

Sobald das Projekt abgeschlossen ist, kann die gebaute Version mit der Default-Version abgeglichen und direkt in diese zurückgeschrieben werden. Dazu muss kein Abgleich- und Zurückschreibevorgang mit den früheren Versionen in der Lineage vorgenommen werden.

Vorteile:

• Diese Methode ist für Projekte geeignet, die in einer Abfolge von Phasen durchgeführt werden, die jeweils als eigenständige Arbeitseinheit voneinander isoliert werden müssen.
• Wie bei jeder anderen mehrschichtigen Konfiguration ermöglicht es dieser Workflow Bearbeitern, Vorschläge und Alternativentwürfe zu entwickeln, ohne die Produktionsdatenbank zu beeinflussen.
• Änderungen können direkt in die Default-Version zurückgeschrieben werden, wodurch der Aufwand des schrittweisen Zurückschreibens entlang der Versionsstruktur bis zur Default-Version entfällt.

Nachteile:

• Nicht für Batch-Abgleich- und Zurückschreibevorgänge geeignet.

Archivierung

Eine grundlegende Anforderung für viele Projekte besteht in der Beibehaltung verschiedener Datenbank-States in einem Zeitraum. Zu den typischen Abfragen, die Geodatabases häufig unterstützen müssen, zählen die folgenden:

• In welchem Zustand befand sich die Datenbank zu einem bestimmten Zeitpunkt?
• Wie hat sich ein bestimmtes Feature im Laufe der Zeit geändert?
• Wenn ein Feature an einem bestimmten Datum aus der Datenbank entfernt wurde, welche Features sind an dessen Position jetzt vorhanden?

Eine häufige Voraussetzung für die Beibehaltung von historischen Aufzeichnungen besteht in der Verwaltung eines Archivs der Default-Version, da diese meist die veröffentlichte Version der Datenbank darstellt. Änderungen an der Default-Version können entstehen, wenn diese bearbeitet wurde oder wenn Änderungen aus anderen Versionen abgeglichen und in die Default-Version zurückgeschrieben wurden. Geodatabases können für das automatische Erfassen dieser Änderungen eingerichtet werden. Diese Funktion ist in die Geodatabase integriert. Für die Unterstützung der automatisierten Archivierung ist keine zusätzliche Datenmodellierung oder Anwendungsanpassung erforderlich.

Für manche Projekte ist die Archivierung einer anderen als der Default-Version notwendig. Da eine Version den State der Parent-Version zum Erstellungszeitpunkt der Version darstellt, können Sie eine Version mit dem einzigen Zweck erstellen, den Zustand der Parent-Version zu einem bestimmten Zeitpunkt zu erfassen. Beispielsweise kann aus der Entwurfsversion eine neue historische Version erstellt werden. Wenn die Entwurfsversion abgeglichen und in die Parent-Version zurückgeschrieben wird, verbleibt die historische Version als Aufzeichnung des Entwurfs zu einem bestimmten Zeitpunkt in der Datenbank.

Ausführliche Informationen zur Archivierung finden Sie unter Der Archivierungsprozess.

Verteilte Datenverwaltung

Bei manchen Projekten müssen zwei oder mehr räumlich voneinander getrennte Niederlassungen an denselben Daten arbeiten. Jede Niederlassung benötigt jeweils einen lokalen Zugriff auf die Datenbank und erstellt daher eine Kopie der Datenbank. Wenn an einem Ort eine Datenänderung vorgenommen wird, muss die Änderung auch auf die Daten am anderen Ort angewendet werden. Um die Synchronisierung der Datenbankkopien aufrechtzuerhalten, können die Standorte die Änderungen regelmäßig untereinander austauschen. Diese Funktion wird als Geodatabase-Replikation bezeichnet.

Die Replikation ermöglicht es auch, ein Subset der Geodatabase beim Verlassen des Büros mitzunehmen und offline zu bearbeiten. Dies ist eine häufige Anforderung von Wartungsteams im Außendienst. Sobald Sie ins Büro zurückkehren, können Sie die Verbindung mit dem Netzwerk wiederherstellen und die Änderungen mit der Produktionsdatenbank zusammenführen.

Die Replikation ist zudem für Benutzer nützlich, die Daten anderenfalls über ein langsames Netzwerk bearbeiten müssen. In diesem Fall ermöglicht es die Replikation, ein Subset der Daten auf den lokalen Computer zu extrahieren, sodass Sie dieses bearbeiten können, ohne über das Netzwerk kommunizieren zu müssen. Wenn Sie den Bearbeitungsvorgang abgeschlossen haben, können Sie die Änderungen über das Netzwerk übertragen und mit der Produktionsdatenbank zusammenführen. Weitere Informationen finden Sie unter Szenarien mit verteilten Daten.