Szenarien mit verteilten Daten

Dieses Thema gilt nur für ArcEditor und ArcInfo.

Die Geodatabase-Replikation unterstützt zahlreiche Workflows zusätzlich zu denen, die bereits durch die Versionierung verfügbar gemacht werden. Im Folgenden finden Sie verschiedene Szenarien, die durch die Geodatabase-Replikation verfügbar gemacht werden.

Weitere Informationen zu den folgenden Szenarien finden Sie auch im Whitepaper An Overview of Distributing Data with Geodatabases.

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, eine Analyse von Daten auszuführen, die vollständig auf dem neuesten Stand sind. 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 hoch bleibt, können Bearbeiter ein Replikat erstellen, um Daten aus dem zentralen Knotenpunkt auszuchecken, Änderungen vorzunehmen und anschließend die Änderungen durch Synchronisierung mit der Geodatabase wieder einzuchecken.

Ü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 ArcSDE-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 zurückübertragen und mit den Daten in der ArcSDE-Geodatabase synchronisiert werden.

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 erzielt werden, indem 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 ArcSDE-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 ArcSDE-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 ArcIMS oder ArcGIS Server 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 der Versorgungsnetze verantwortlich sein, während eine andere mit der Verwaltung der Flurstückdaten 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 erforderlichen Daten aus der zentralen ArcSDE-Geodatabase. Die Teams können die einzelnen Replikate dann unabhängig voneinander bearbeiten, ggf. an getrennten geographischen Orten, und die Änderungen an die zentrale ArcSDE-Geodatabase übertragen. Umgekehrt werden auch sämtliche Änderungen in der zentralen ArcSDE-Geodatabase an die entsprechenden Replikate der Projektteams übertragen.

Zentralisieren von 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 Niederlassungen in Bundesländern und der Hauptniederlassung eines Landes. Jede Niederlassung in einem Bundesland arbeitet unabhängig, verwaltet seine 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.

Weitere Informationen finden Sie im Artikel Using Compress on ArcSDE Geodatabases with Replicas.