Mit der Standard- oder Advanced-Lizenz verfügbar.
Die Geodatabase-Replikation unterstützt zusätzlich zu den Workflows der traditionellen Versionierung zahlreiche weitere Workflows. Im Folgenden finden Sie verschiedene Szenarien, die durch die Geodatabase-Replikation verfügbar gemacht werden.
Replikatstruktur
Die Geodatabase-Replikation kann zum Erstellen von Replikatstrukturen verwendet werden, die Versionsstrukturen ähneln, wodurch Organisationen ihre Daten auf mehrere Geodatabases in einer hierarchischen Struktur verteilen können.
In manchen Organisationen muss z. B. eine einzelne organisationsweit verwendete Geodatabase für mehrere Niederlassungen repliziert werden können. Jede Niederlassung verfügt über ein Replikat, das nur die Daten für die jeweilige Region enthält. Änderungen dieser Daten können an die Hauptniederlassung übertragen werden. Dies ermöglicht der Hauptniederlassung die Durchführung von Analysen, die für das gesamte Geschäftsgebiet auf aktuellen Daten beruhen. Die Verbindungen innerhalb einer Niederlassung sind schnell, zwischen den Niederlassungen jedoch wesentlich langsamer. Die regionalen Niederlassungen können ihre jeweilige Geodatabase auch für lokale Niederlassungen replizieren, und zwar auf die gleiche Weise, auf die auch die Hauptniederlassung ihre Geodatabase für die Regionen repliziert.
Zentraler Knotenpunkt
Eine Replikat-Geodatabase kann als zentraler Knotenpunkt für Leser und Bearbeiter verwendet werden. Damit die Verbindungsgeschwindigkeit bei der Bearbeitung hoch bleibt, können Bearbeiter ein Replikat erstellen, um die Daten aus dem zentralen Knotenpunkt auszuchecken. Dort werden dann die Änderungen vorgenommen, die anschließend durch Synchronisierung mit der Geodatabase wieder eingecheckt werden.
Über den zentralen Knotenpunkt können auch Änderungen zwischen mehreren Child-Replikaten weitergegeben werden. Um Änderungen von einem Replikat in ein anderes zu übertragen, werden die Änderungen zuerst mit dem Parent-Replikat (dem des Knotenpunktes) synchronisiert. Anschließend kann ein zweites Child-Replikat mit dem Parent-Replikat synchronisiert werden, um diese Änderungen abzurufen.
Mobile Benutzer
Mobile Benutzer in einer Organisation, z. B. Wartungsteams, müssen einen Teil der Enterprise-Geodatabase im Außendienst bearbeiten können. Sie müssen oft über längere Zeit völlig losgelöst von der Infrastruktur der Organisation arbeiten. Bei der Vorbereitung eines bestimmten Arbeitsauftrags oder Projekts werden die relevanten Daten repliziert und auf ein tragbares Gerät, z. B. einen Laptop, übertragen. Dieses Gerät wird dann vom Netzwerk getrennt, sodass die Außendienstmitarbeiter unabhängig vom Netzwerk arbeiten können. Die Außendienstmitarbeiter können auch ohne Verbindung zum Netzwerk mit replizierten Daten arbeiten und Änderungen an diesen vornehmen. Wenn wieder eine Verbindung mit dem Netzwerk hergestellt wird, können die Änderungen an den Daten übertragen und mit den Daten in der Enterprise-Geodatabase synchronisiert werden.
Tipp:
Für dieses Szenario wird empfohlen, dass jeder Bearbeiter vor Ort ein eigenes Replikat verwendet. Wenn Synchronisierungen von zahlreichen Bearbeitern gleichzeitig ausgeführt werden, wird empfohlen, dass jeder Bearbeiter über eine eigene Version verfügt und ein Replikat aus dieser Version erstellt. Dadurch wird die Synchronisierung vereinfacht und die Erfassung in Konflikt stehender Daten vermieden.
Subunternehmer
In manchen Organisationen muss die Verwaltung eines Teiles der Geodatabase an Subunternehmer übergeben werden, wobei der Subunternehmer jeden Monat Aktualisierungen senden muss. Die Organisation muss die Änderungen des Subunternehmers integrieren können, ohne die Daten vollständig neu laden zu müssen. Außerdem wird eine einfache Möglichkeit benötigt, ausschließlich die Aktualisierungen für den Monat zu prüfen anstatt Qualitätstests für das gesamte Dataset durchzuführen.
Dies kann dadurch erreicht werden, dass dem Subunternehmer ein Replikat der entsprechenden Daten für Aktualisierungen gesendet wird. Wenn der Subunternehmer die Änderungen an die Organisation zurücksendet, können diese mit den Daten in der Enterprise-Geodatabase synchronisiert werden.
Produktions- und Veröffentlichungs-Geodatabases
Eine Organisation muss eine Gruppe von Editoren sowie Benutzer unterstützen, die nur mit Lesezugriff auf das System zugreifen können. Um die Anforderungen beider Gruppen zu erfüllen, verfügt die Organisation über zwei Enterprise-Geodatabases. Die eine ist eine Produktions-Geodatabase, die von den Editoren direkt bearbeitet wird. Die andere ist ein Replikat dieser Geodatabase und wird von den Lesern genutzt. Leser können auf diese Daten über ArcGIS Enterprise zugreifen.
In diesem Szenario ist das Replikat in der Veröffentlichungs-Geodatabase eine schreibgeschützte Kopie der Produktions-Geodatabase. Die Daten in der Veröffentlichungs-Geodatabase müssen nicht versioniert werden. Die Replikation kann auf das Senden von Daten in eine Richtung beschränkt werden. Änderungen werden in der Produktions-Geodatabase vorgenommen und von dieser an die Veröffentlichungs-Geodatabase übermittelt. Diese Änderungen werden übertragen, mit den Daten in der Veröffentlichungs-Geodatabase synchronisiert und anschließend für die Leser bereitgestellt.
Mehrgruppen-Datenmanagement
In einer Organisation kann das Datenmanagement auf unterschiedliche Gruppen aufgeteilt sein. Eine Gruppe kann beispielsweise für die Verwaltung von physischen Assets verantwortlich sein, während eine andere mit der Verwaltung der Flurstücksdaten für dasselbe Gebiet betraut ist. Ein weiteres Beispiel ist der Fall, bei dem mehrere Teams an vielen voneinander völlig unabhängigen Projekten arbeiten. Die Datasets für die einzelnen Projekte können größtenteils aus unterschiedlichen geographischen Gebieten stammen, doch die Organisation möchte ein zentrales Repository für alle Projekte einrichten.
Die Organisation kann die Daten mithilfe der Geodatabase-Replikation auf verschiedene Gruppen verteilen, wobei die Daten den entsprechenden Projekten zugeordnet werden. Jedes Projektteam erhält ein Replikat der benötigten Daten aus der zentralen Enterprise-Geodatabase. Die Teams können die einzelnen Replikate dann unabhängig voneinander bearbeiten, ggf. an getrennten geographischen Orten, und die Änderungen an die zentrale Enterprise-Geodatabase übertragen. Umgekehrt werden auch sämtliche Änderungen in der zentralen Enterprise-Geodatabase an die entsprechenden Replikate der Projektteams übertragen.
Zentralisierte Daten aus vielen Quellen
Eine andere häufige Vorgehensweise bei der Replikation ist die Verwendung eines zentralen Speicherorts, an dem Daten gesammelt werden. Organisationen, die diesen Ansatz verwenden, verfügen über eine zentrale Geodatabase, in der die Daten anderer Niederlassungen gesammelt werden.
Ein Beispiel dafür ist die Verteilung von Daten zwischen der Hauptniederlassung in einem Land und den Niederlassungen in den einzelnen Bundesländern. Jede Niederlassung in einem Bundesland arbeitet unabhängig, verwaltet ihre eigenen Datasets und sendet in regelmäßigen Abständen Aktualisierungen an die Hauptniederlassung. Die Änderungen aus den einzelnen Bundesländern werden in der Geodatabase der Hauptniederlassung zu einem umfassenden Gesamt-Dataset synchronisiert. Bei dieser Konfiguration der Child-zu-Parent-Replikation kommt der Geodatabase der Hauptniederlassung die Parent-Rolle zu, und die Geodatabases der einzelnen Bundesländer nehmen die Child-Rolle ein.
