Versionierungsszenarios

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.

Arbeitsabläufe 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 Arbeitsablaufs 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.

Gleichzeitige Bearbeitung der Default-Version

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 "Konflikt-Lö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:

Nachteile:

Mehrere Projekte

Wenn Sie mehrere Projekte oder Arbeitsaufträge verwalten, müssen Sie bei der Verwaltung von Arbeitsabläufen 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.

Verwalten mehrerer Projekte

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 Arbeitsablauf 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.

Verwalten mehrerer Projekte, wobei eine Version schnelle Abfragen und die schnelle Berichterstellung unterstützt

Vorteile:

Nachteile:

Mehrere Projekte mit Teilprojekten

Komplexe Projekte erfordern eine kompliziertere Struktur der Arbeitsabläufe, 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.

Mehrere Projekte mit Teilprojekten

Bei umfangreichen Projekten mit unterschiedlichen Teams und zahlreichen eigenständigen Arbeitseinheiten stellt eine mehrschichtige Versionsstruktur eine Möglichkeit dar, den Arbeitslauf 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:

Nachteile:

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.

In Phasen unterteilte Projekte

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

Vorteile:

Nachteile:

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:

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.

Erstellen von Versionen für Archivierungszwecke

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.

Räumlich getrennte Niederlassungen können ihre Kopien der Geodatabase synchronisieren.

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 Szenarios mit verteilten Daten.

Verwandte Themen


7/10/2012