Szenarien mit traditioneller Versionierung

Im Folgenden 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. Häufig verlaufen 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. Nach Abschluss der Arbeit können Sie die Änderungen in die veröffentlichte Version der Datenbank integrieren. Wenn Sie auf diese Weise mit Versionen arbeiten, können Sie sowohl die einfachsten als auch die komplexesten Workflow-Prozesse umsetzen.

Das Konzept der Versionierung ist bei Szenarien mit Verzweigungsversionen oder Szenarien mit traditionellen Versionen gleich. Die Versionierung bietet Repräsentationen der Daten, ohne Daten zu kopieren, erlaubt die gleichzeitige Bearbeitung und ermöglicht es Benutzern, für längere Zeiträume eine Version zu nutzen. Weitere Details finden Sie im Überblick über die Versionierung.

Traditionelle Versionierung: Bietet die Flexibilität für die Arbeit in Versionen für lange Transaktionen beim direkten Zugriff über die Enterprise-Geodatabase und vereinfacht die Bearbeitung bei der Verwendung von Feature-Services für kürzere Transaktionen.

Es wird ein allgemeiner Überblick über den Workflow der traditionellen Versionierung gezeigt.

Im wahrscheinlichsten Fall wird die veröffentlichte Datenbankkonfiguration durch gleichzeitige Änderung der Default-Version durch mehrere Editoren oder aber mit einer Kombination der anderen Konfigurationen bearbeitet. Grundkenntnisse der Organisations- und Geschäftsanforderungen sowie ein Bewusstsein für die Vorteile und Beschränkungen der einzelnen Szenarien mit traditioneller Versionierung 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 und bewährte Vorgehensweise darin, entweder eine flache Versionsstruktur zu verwenden oder für die Bearbeitung der Default-Version mehrere Bearbeiter gleichzeitig einzurichten.

Bearbeiten der Default-Version

Die Default-Version ist die erste Version, die erstellt wird, wenn Daten als traditionell versioniert registriert werden. Wenn Sie die traditionelle Versionierung verwenden und der Versionszugriff auf öffentlich festgelegt ist, können mehrere Editoren gleichzeitig Daten unter Verwendung der Default-Version bearbeiten und anzeigen. Die einfachste Methode, um das Bearbeiten durch mehrere Benutzer zu unterstützen, besteht darin, mehreren Editoren das direkte Bearbeiten der Default-Version zu gestatten.

Wenn der Versionszugriff auf die Default-Version (orange) auf "Öffentlich" festgelegt ist, können Editoren die Default-Version direkt bearbeiten. Viewer, die eine Verbindung zur Default-Version herstellen, können die an der Default-Version vorgenommenen Aktualisierungen sehen.

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 Editor bearbeitet wurde, seitdem Sie mit dem Bearbeiten begonnen haben, gleicht ArcGIS die Änderungen automatisch ab und schreibt diese zurück, sobald Sie die Ä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. Bestehende Konflikte müssen im Dialogfeld "Konfliktlösung" gelöst werden, bevor Sie Ihre Änderungen erfolgreich speichern können.

Weitere Überlegungen

Berücksichtigen Sie die folgenden Vorteile und Beschränkungen, wenn Sie die Default-Version verwenden oder bearbeiten:

• 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.
• Beschränkungen
  • 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 Editoren, 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. Solange diese Sperre besteht, können andere Benutzer ihre Tasks nicht abschließen.

Weitere Informationen zu Einstellungen zum Speichern von Daten

Informationen zum Lösen von Datenkonflikten

Bearbeiten einer Child-Version

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

Wenn Sie die traditionelle Versionierung verwenden, wird bei Beginn eines Arbeitsauftrags oder Projekts eine Version als Child-Version der Default-Version erstellt.

Wenn der Versionszugriff auf die Default-Version (orange) auf "Öffentlich" festgelegt ist, können Editoren die Default-Version direkt bearbeiten. Sie können aber auch eine Child Version wie Version A (grün) oder Version B (violett) erstellen und bearbeiten. Anschließend können die Editoren ihre Änderungen mit der Default-Version abgleichen (R) und in sie zurückschreiben (P). Viewer, die eine Verbindung zur Default-Version herstellen, können die Aktualisierungen sehen, die an der Default-Version vorgenommen oder in sie zurückgeschrieben wurden.

Diese Version kann von einem oder mehreren Bearbeitern bearbeitet werden, bis der Arbeitsauftrag oder das Projekt abgeschlossen ist. Wenn alle Änderungen an einer Child-Version abgeschlossen wurden, gleicht ein Editor oder der Administrator die Änderungen mit der Default-Version ab und löst mögliche Konflikte. Die Änderungen an der Default-Version werden dann zurückgeschrieben und in die veröffentlichte Datenbank integriert. 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. Administratoren können die Berechtigung für die Default-Version auf geschützt festlegen. Damit wird es Benutzern ermöglicht, die Default-Version weiterhin schreibgeschützt anzuzeigen. Bearbeiter, die die Daten ändern möchten, müssen eine neue Child-Version erstellen.

Wenn der Versionszugriff auf die Default-Version (orange) auf "Geschützt" festgelegt ist, können Editoren nur Änderungen an einer Child-Version wie Version A (grün) oder Version B (violett) vornehmen. Anschließend können die Editoren ihre Änderungen mit der geschützten Default-Version abgleichen (R) und in sie zurückschreiben (P). Viewer, die eine Verbindung zur Default-Version herstellen, können die Aktualisierungen sehen, die an der Default-Version vorgenommen oder in sie zurückgeschrieben wurden.

Wenn Sie die traditionelle Versionierung verwenden, wird der Versionszugriff durch eine Kombination der Berechtigungen der Datenbankbenutzer und der für die Version festgelegten Zugriffsberechtigungsebenen (öffentlich, geschützt oder privat) bestimmt.

Weitere Überlegungen

Berücksichtigen Sie die folgenden Vorteile und Beschränkungen, wenn Sie eine Child-Version verwenden oder bearbeiten:

• 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.
  • Das Abgleichen und Zurückschreiben im Batch wird unterstützt.
• Beschränkungen
  • 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.

Unterstützen von Editoren und Viewern

Wenn Ihre Organisation sowohl eine Gruppe von Editoren als auch Benutzer mit schreibgeschütztem Zugriff auf das System unterstützen muss, verwenden die Editoren den Workflow mit traditioneller Versionierung, der im Szenario "Bearbeiten einer Child-Version" erläutert wird. 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. 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.

Nachdem die Bearbeitungen von den Editoren in die Default-Version (orange) zurückgeschrieben wurden, kann eine geschützte statische oder schreibgeschützte Version von der Default-Version erstellt werden. Bevor diese schreibgeschützte Version B (violett) erstellt wird, sollten alle Bearbeitungen von der Child-Version A (grün) abgeglichen (R) und in die Default-Version zurückgeschrieben (P) werden. Außerdem sollten die Datenbank komprimiert sowie die Indizes und Statistiken neu erstellt werden. Durch diesen Prozess wird sichergestellt, dass die Viewer, die eine Verbindung zu dieser schreibgeschützten Version B herstellen, auf Änderungen zugreifen können, die seit der letzten Datenbankkomprimierung vorgenommen wurden.

Verteiltes Datenmanagement

Es gibt mehrere Möglichkeiten, versionierte Daten in Ihrer Organisation zu verteilen, um verschiedene Workflows zu vereinfachen.

Geodatabase-Replikation

Die Geodatabase-Replikation arbeitet direkt mit Geodatabases oder Geodaten-Services und unterstützt Workflows, um ihre Synchronisierung sicherzustellen. Ebenso wie in ArcGIS Desktop werden auch in ArcGIS Pro Werkzeuge für die Durchführung der Geodatabase-Replikation bereitgestellt. Für die meisten dieser Workflows sind traditionell versionierte Daten erforderlich.

Beispiel: 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 in einer Niederlassung eine Datenänderung vorgenommen wird, muss die Änderung auch auf die Daten in der anderen Niederlassung angewendet werden. Um die Synchronisierung der Datenbankkopien aufrechtzuerhalten, können die Niederlassungen die Änderungen regelmäßig untereinander austauschen. Diese Funktion wird als Geodatabase-Replikation bezeichnet.

Die Replikation ist außerdem nützlich für Editoren, die Daten anderenfalls über ein langsames Netzwerk bearbeiten müssten. In diesem Fall bietet die Replikation die Möglichkeit, eine Teilmenge der Daten auf ein lokales Gerät zu extrahieren, sodass der Editor diese bearbeiten kann, ohne auf das Netzwerk zugreifen zu müssen. Wenn der Bearbeitungsvorgang abgeschlossen ist, können die Änderungen über das Netzwerk übertragen und mit der Produktionsdatenbank zusammengeführt werden. Weitere Informationen finden Sie unter Szenarien mit verteilten Daten.

Feature-Services

Traditionell versionierte Daten können auch als Feature-Services mit aktivierter Synchronisierung veröffentlicht werden. Diese unterstützen Workflows mit mobilen Editoren, die ArcGIS Collector oder ArcGIS Pro verwenden. Die Editoren können eine Kopie der Daten herunterladen, diese lokal bearbeiten und dann die Synchronisierung auf dem Feature-Service aufrufen. Erfahren Sie, wie Sie traditionell versionierte Daten in offline genommenen Feature-Services verwenden, wenn Sie mit traditionell versionierten Daten und mobilen Editoren arbeiten.

Feature-Services können auch in Workflows zur verteilten Kollaboration genutzt werden. Zum Beispiel unterstützt die verteilte Kollaboration (oder einfach Kollaboration) Feature-Services, die Feature-Layer enthalten, die auf traditionell versionierten Daten ausgeführt werden. Dadurch ist es möglich, Feature-Services mit aktivierter Synchronisierung als Kopie freizugeben, wenn die für die Kollaboration freigegebenen Feature-Services separate Kopien der Daten ausführen. Weitere Informationen über Kollaborationsprozesse und -konzepte finden Sie unter Funktionsweise von Kollaborationen.