Geodatabase-Replikationstypen

Mit der Standard- oder Advanced-Lizenz verfügbar.

Es gibt drei Typen der Geodatabase-Replikation: Check-Out-/Check-In-Replikation, unidirektionale Replikation und bidirektionale Replikation. Die einzelnen Optionen werden nachfolgend beschrieben.

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.

Das Parent-Replikat ist immer eine Enterprise-Geodatabase. Das Child-Replikat kann eine Enterprise-Geodatabase oder eine File-Geodatabase sein.

Wenn Sie die Daten synchronisieren, wird die Registrierung des Check-Out-Replikats aufgehoben (das Replikat wird gelöscht), und Sie können keine weiteren Änderungen synchronisieren. Wenn zusätzliche Änderungen erforderlich sind, müssen Sie ein anderes Check-Out-Replikat erstellen.

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. Unidirektionale Replikate werden nach der Synchronisierung beibehalten, sodass Sie weiterhin Datenänderungen senden können.

• Unidirektionale Parent-zu-Child-Replikation: Die Daten des Parent-Replikats können 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 ist das Quellreplikat (Parent) immer eine Enterprise-Geodatabase. Als Ziel (Child) kann eine Enterprise- oder File-Geodatabase verwendet werden.
• Unidirektionale Child-zu-Parent-Replikation: Die Funktionsweise ist ä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 Enterprise Geodatabase gehostet werden.

Bidirektionale Replikation

Bei der bidirektionalen Replikation können mehrmals Datenänderungen vom Parent-Replikat an das Child-Replikat und 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.

Tipp:

Sie können die Konfliktlösungsmethode konfigurieren und definieren, was als Konflikt gilt, wenn Sie eine Synchronisierung durchführen. Damit steuern Sie, wie Konflikte verarbeitet 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 Quelle (Parent) und Ziel (Child) eine Enterprise-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 File-Geodatabases benötigen, müssen Sie die Check-Out-/Check-In-Replikation oder die unidirektionale Replikation nutzen.
• Bei einer bidirektionalen Replikation können Sie die Replikate mehrmals synchronisieren, ohne die Replikate neu erstellen zu müssen. Bei diesem Replikattyp ist für die Quell- und die Ziel-Geodatabase eine Enterprise-Geodatabase erforderlich.
• 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. Eine Beschreibung dieses Workflows finden Sie unter Szenarien mit verteilten Daten.

  Bei der unidirektionalen Replikation wird eine unidirektionale Synchronisierung erzwungen. Zudem müssen die Daten des Child-Replikats nicht versioniert sein, sofern Sie das einfache Modell für den Replikatzugriffstyp verwenden. Bei einem einfachen Modell sind die Features und ihre Attribute im Replikat enthalten, erweiterte Geodatabase-Funktionen jedoch nicht. Dadurch wird die Interoperabilität der Daten verbessert, da sie nicht den komplexen Geodatabase-Datenstrukturen entsprechen müssen.

• Wenn Sie bisweilen die Daten des Child-Replikats bearbeiten müssen, sollten Sie die bidirektionale Replikation verwenden. 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. Wenn Sie Konflikte manuell lösen möchten, können Sie 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.

In der folgenden Tabelle sind die verschiedenen Geodatabase-Replikationstypen zusammengefasst:

	Child-Replikat wird in einer File-Geodatabase gespeichert	Unterstützt mehrere Synchronisierungen vor dem Aufheben der Registrierung	Kann Aktualisierungen in beide Richtungen synchronisieren
Check-Out/Check-In in eine File-Geodatabase
Check-Out/Check-In in Enterprise-Geodatabase
Unidirektional zu File-Geodatabase (Parent – Child)
Unidirektional zu Enterprise-Geodatabase (Parent – Child)
Unidirektional zu Enterprise-Geodatabase (Child – Parent)
Bidirektional zu Enterprise-Geodatabase