Replikationstypen
Dieses Thema gilt nur für ArcEditor und ArcInfo.
Es gibt drei Typen der Geodatabase-Replikation: Check-Out-/Check-In-Replikation, unidirektionale Replikation und bidirektionale Replikation.
Für alle Typen müssen als Quelle der Replikaterstellung Daten aus einer ArcSDE-Geodatabase verwendet werden. Alle Typen werden auch in vernetzten oder nicht verbundenen Umgebungen unterstützt. Im vorliegenden Abschnitt werden diese Typen näher erläutert:
Check-Out-/Check-In-Replikation
Bei der Check-Out-/Check-In-Replikation können Sie die Daten des Child-Replikats bearbeiten und die Änderungen mit dem Parent-Replikat synchronisieren.
Nachdem die Daten synchronisiert wurden, können keine weiteren Änderungen synchronisiert werden. Wenn zusätzliche Änderungen erforderlich sind, müssen Sie ein neues Check-Out-Replikat erstellen. Beim Erstellen von Check-Out-Replikaten kann als Ziel eine ArcSDE-, File- oder Personal-Geodatabase verwendet werden.
Die seit ArcGIS 8.3 verfügbare entkoppelte Bearbeitung ist nun Teil der Geodatabase-Replikation. Sie entspricht der Check-Out-/Check-In-Replikation. Die Werkzeuge für die entkoppelte Bearbeitung, die in ArcGIS Desktop verfügbar waren, wurden entfernt und sind nun Teil der verteilten Geodatabases-Umgebung. Die Geoverarbeitungswerkzeuge für die entkoppelte Bearbeitung stehen jedoch weiterhin für Zwecke der Rückwärtskompatibilität zur Verfügung.
Unidirektionale Replikation
Bei der unidirektionalen Replikation können Datenänderungen mehrmals in eine bestimmte Richtung gesendet werden, entweder vom Parent-Replikat an das Child-Replikat oder umgekehrt.
Bei einer unidirektionalen Parent-zu-Child-Replikation können die Daten des Parent-Replikats bearbeitet werden, während die Daten im Child-Replikat schreibgeschützt sind. Wenn Änderungen an den Daten des Child-Replikats in Konflikt mit den während der Synchronisierung übernommenen Änderungen stehen, werden sie überschrieben.
Beim Erstellen eines unidirektionalen Parent-zu-Child-Replikats kann als Ziel eine ArcSDE-, File- oder Personal-Geodatabase verwendet werden.
Die unidirektionale Child-zu-Parent-Replikation funktioniert ähnlich, nur in umgekehrter Richtung. Bei dieser Replikation können die Daten des Child-Replikats bearbeitet werden, während die Daten im Parent-Replikat schreibgeschützt sind. Wenn Änderungen an den Daten des Parent-Replikats in Konflikt mit den während der Synchronisierung übernommenen Änderungen stehen, werden sie überschrieben.
Beim Erstellen eines unidirektionalen Child-zu-Parent-Replikats muss sowohl das Child-Replikat als auch das Parent-Replikat in einer ArcSDE-Geodatabase gehostet werden.
Unidirektionale Replikate werden nach der Synchronisierung beibehalten, sodass Sie weiterhin Datenänderungen senden können.
Bidirektionale Replikation
Bei der bidirektionalen Replikation können mehrmals Datenänderungen vom Parent-Replikat an das Child-Replikat oder vom Child-Replikat an das Parent-Replikat übermittelt werden. Wenn in beiden Replikat-Geodatabases die gleiche Zeile bearbeitet wird, wird dies bei der Synchronisierung der Replikate als Konflikt erkannt. In den Abgleichungsrichtlinien ist festgelegt, wie solche Konflikte gelöst werden.
Bidirektionale Replikate bleiben nach der Synchronisierung erhalten, sodass Sie die Replikate weiterhin bearbeiten und synchronisieren können. Wenn Sie bidirektionale Replikate erstellen, müssen Sie als Ziel eine ArcSDE-Geodatabase auswählen.
Auswählen eines Replikattyps
Beachten Sie bei der Entscheidung für einen Replikattyp folgende Gesichtspunkte:
- Wenn Sie die Funktion zum Erstellen von Replikaten in Personal- oder File-Geodatabases benötigen, müssen Sie eine Check-Out-/Check-In- oder eine unidirektionale Replikation verwenden. Wenn Sie jedoch eine ArcEditor-Lizenz zum Bearbeiten der Daten im Child-Replikat verwenden, sollten Sie als Ziel-Geodatabase möglicherweise eine Personal ArcSDE-Geodatabase verwenden. Durch Verwendung einer Personal ArcSDE-Geodatabase anstelle einer Personal- oder File-Geodatabase können Sie bidirektionale Replikate erstellen. Bei einer bidirektionalen Replikation können Sie die Replikate mehrmals synchronisieren, ohne die Replikate neu erstellen zu müssen.
- Die unidirektionale Replikation ist für Situationen ideal, in denen Sie Änderungen, die auf dem Produktionsserver vorgenommen wurden, auf dem Veröffentlichungsserver veröffentlichen möchten. Bei der unidirektionalen Replikation wird eine unidirektionale Synchronisierung erzwungen. Zudem müssen die Daten des Child-Replikats nicht versioniert sein, sofern ein einfaches Modell verwendet wird. Da die Daten in einem einfachen Modell nicht in komplexen Typen vorliegen und nicht den komplexen Esri-Datenstrukturen entsprechen müssen, sind sie in einem höheren Maße interoperabel.
- Wenn Sie ein unidirektionales Replikationssystem implementieren, in dem Sie bisweilen die Daten des Child-Replikats bearbeiten müssen, sollten Sie die Verwendung der bidirektionalen Replikation erwägen. Da bei einer unidirektionalen Replikation davon ausgegangen wird, dass die Daten im Child-Replikat schreibgeschützt sind, werden bei einer Synchronisierung möglicherweise Änderungen an den Daten im Child-Replikat überschrieben. Die Konflikterkennungslogik bei der bidirektionalen Replikation kennzeichnet diese Unterschiede als Konflikte. Sie können entscheiden, wie die Unterschiede behandelt werden sollen. Eine bidirektionale Replikation ermöglicht den Datenaustausch in beiden Richtungen. Sie kann aber auch in Situationen eingesetzt werden, in denen Sie Änderungen nur in eine Richtung übermitteln.