Zeilen und Features werden dem Replikat beim Erstellen basierend auf den in der Anwendung definierten Filtern hinzugefügt. Nach Abschluss dieses Vorgangs werden Beziehungsklassen so verarbeitet, dass sie zusätzliche in Beziehung stehende Objekte enthalten.
Bei der Verarbeitung von Beziehungsklassen werden die einzelnen Datasets ausgewertet, die Teil mindestens einer Beziehungsklasse sind. Beim Auswerten eines Datasets werden alle bereits replizierten Zeilen erfasst und zum Abfragen von in Beziehung stehenden Zeilen in den entsprechenden Datasets verwendet. Alle in Beziehung stehenden Zeilen, die über die Abfragen zurückgegeben werden, werden dem Replikat hinzugefügt. Während dieses Prozesses wird jedes Dataset einmal aufgerufen.
In ArcGIS Pro wird eine Beziehungsklasse immer nur in eine Richtung, nämlich in Vorwärtsrichtung, verarbeitet. Vorwärtsrichtung bedeutet, dass die Quellklasse so ausgewertet wird, dass dem Replikat in Beziehung stehende Zeilen aus der Zielklasse hinzugefügt werden. Die Verarbeitung von Beziehungsklassen kann während der Replikaterstellung deaktiviert werden.
Anhand der folgenden Beispiele wird das Replikationsverhalten in Bezug auf in Beziehung stehende Objekte veranschaulicht. Bei dem in diesen Beispielen verwendeten Datenmodell handelt es sich um eine einfache Ursprung-Ziel-Beziehung zwischen Eigenschaften, Gebäuden und deren in Beziehung stehenden Annotationen.
Beispiel 1
In diesem Beispiel ist der Replikatbereich mit acht Flurstücken und sechs Gebäuden dargestellt. Beim Erstellen des Replikats werden zwei weitere Gebäude hinzugefügt, da diese in Beziehung zu den Flurstücken stehen. Bei der Verarbeitung von Beziehungsklassen wird dem Replikat zudem eine Annotation für die Gebäude und Flurstücke hinzugefügt.
Im obigen Beispiel wurde für ein Replikat die Verwendung des Standardverhaltens festgelegt, bei dem in Beziehung stehende Objekte einbezogen werden. In ArcGIS Pro kann die Replikation angepasst und dieses Verhalten auf globaler Ebene überschrieben werden, wenn das Geoverarbeitungswerkzeug Replikat erstellen verwendet wird. Der Replikationsprozess kann auf globaler Ebene so konfiguriert werden, dass keine in Beziehung stehenden Objekte enthalten sind, die mit für die Replikation vorgesehenen Features verknüpft sind.
Beispiel 2
Anhand dieses Beispiels wird gezeigt, was im Fall einer zirkulären Beziehung geschieht. Das System wendet während der Replikaterstellung eine Logik zur Unterbrechung des Zirkels an und verhindert so die Verarbeitung in einer Endlosschleife. Diese Logik sorgt jedoch dafür, dass die Reihenfolge, in der Beziehungen verarbeitet werden, nicht vorhergesagt werden kann.
Beziehungsklassen, bei denen ein ObjectID-Feld das Primärschlüsselfeld ist
Die Replikation mit Beziehungsklassen, bei der das Feld ObjectID als Primärschlüsselfeld verwendet wird, erfordert während der Synchronisierung zusätzlichen Bearbeitungsaufwand. Dies kann die Performance beeinträchtigen. In einigen Fällen kann dies auch zu unerwartetem Verhalten führen. Im Folgenden werden diese Fälle ausführlicher beschrieben. Nachdem Sie diesen Abschnitt gelesen haben, möchten Sie Ihre Beziehungsklassen möglicherweise so ändern, dass anstelle des ObjectID-Feldes ein anderes Feld als Primärschlüsselfeld verwendet wird. Im Folgenden sind einige gute Alternativen aufgeführt:
- Beziehungsklassen mit einem Primärschlüsselfeld vom Typ "GlobalID" und einem Fremdschlüsselfeld vom Typ "GUID"
- Eigenes Primärschlüsselfeld erstellen und verwenden, das für alle Datenbanken eindeutig ist
Zusätzliche Verarbeitungsschritte während der Synchronisierung, wenn das ObjectID-Feld das Primärschlüsselfeld ist
Die ObjectID-Werte in einer Feature-Class sind in Geodatabases nicht eindeutig. Einer neuen Zeile in einer Replikat-Geodatabase kann dieselbe ObjectID wie einer vollkommen anderen Zeile in der anderen Replikat-Geodatabase zugeordnet werden. Beim Synchronisierungsprozess müssen diese Unterschiede bei der Übertragung von Beziehungen zwischen Replikat-Geodatabases berücksichtigt werden, wenn der Primärschlüssel in der Beziehung eine ObjectID -Spalte ist. Um dies zu erreichen, müssen im Rahmen des Synchronisierungsprozesses Beziehungsklassen erkannt werden, die die ObjectID-Spalte verwenden. Wenn Klassen dieser Art vorhanden sind, werden bei der Synchronisierung zusätzliche Informationen übertragen, die zur Durchführung weiterer Verarbeitungsschritte verwendet werden.
Bei der Verarbeitung werden für jede bearbeitete Beziehung Fremdschlüsselwerte an die jeweiligen ObjectID-Werte in der Ziel-Geodatabase angepasst. Wenn zahlreiche Beziehungen bearbeitet werden, können diese zusätzlichen Verarbeitungsschritte die Performance der Synchronisierung erheblich beeinträchtigen.
Unerwartetes Verhalten, wenn das ObjectID-Feld dem Primärschlüsselfeld entspricht
Im Folgenden werden Fälle beschrieben, in denen ein unerwartetes Verhalten beobachtet werden kann, wenn das ObjectID-Feld als Primärschlüsselfeld verwendet wird:
- Änderungen, bei denen die Ursprungszeile in der Ziel-Replikat-Geodatabase nicht vorhanden ist: Wie bereits beschrieben werden im Rahmen des Synchronisierungsprozesses zusätzliche Verarbeitungsschritte durchgeführt, um Beziehungen beizubehalten, wenn ein ObjectID-Feld in einer Beziehungsklasse als Primärschlüsselfeld verwendet wird. In Fällen, in denen Änderungen die Referenzierung einer Ursprungszeile beinhaltet, die in der relativen Replikat-Geodatabase nicht vorhanden ist, wird eine Beziehung nicht beibehalten. Das führt beim Einfügen dazu, dass der Fremdschlüssel in der Zielzeile auf NULL gesetzt wird. Bei einer Aktualisierung bleibt der Wert des Fremdschlüssels unverändert wie vor der Synchronisierung in der Zielzeile erhalten. Dieses Verhalten tritt bei Check-Out-/Check-In-Replikaten nicht auf.
- In der Abbildung oben ist ein Fall dargestellt, bei dem zwischen Flurstücken und Gebäuden eine einfache Beziehungsklasse vorhanden ist und das ObjectID-Feld der Parcels-Feature-Class der Quell-Primärschlüssel ist. In diesem Beispiel wird nur für die Flurstücke und Gebäude innerhalb einer räumlichen Ausdehnung ein Replikat erstellt. Nach dem Erstellen des Replikats wird jedoch ein Digitalisierungsfehler erkannt, da ein Gebäude gefunden wurde, das im falschen Flurstück digitalisiert wurde. Dieser Fehler wird in der Parent-Replikat-Geodatabase behoben, indem das Gebäude verschoben und die Beziehung so bearbeitet wird, dass sie sich auf das richtige Flurstück bezieht. Anschließend wird das Replikat synchronisiert, sodass die Änderungen auf das Child-Replikat angewendet werden. In diesem Fall wird das Gebäude zwar verschoben, es steht jedoch weiterhin in Beziehung zum falschen Flurstück im Child-Replikat. Die Beziehung wurde im Child-Replikat nicht geändert, weil die richtige Ursprungszeile (Flurstück mit ObjectID 102 im Parent-Replikat) in den Geodatabases mit dem Child-Replikat nicht vorhanden ist. In diesen Fällen werden die Beziehungen nicht geändert.
- Dangle-Fremdschlüssel: Beim Erstellen eines Replikats werden Zeilen anhand der Replikatdefinition aus der Quell-Geodatabase in die Ziel-Geodatabase kopiert. Beim Definieren des Replikats können Sie Zeilen aus der Zieltabelle ohne die in Beziehung stehenden Zeilen in der Quelltabelle einbeziehen. In der Zieltabelle werden für diese nicht in Beziehung stehenden Zeilen dieselben Fremdschlüsselwerte wie in der Quell-Geodatabase verwendet. Dies sind die Dangle-Fremdschlüssel, da die Ursprungszeile, die sie referenzieren, in der Ziel-Geodatabase nicht vorhanden ist.
- In der obigen Abbildung ist ein Beispiel dargestellt, in dem das Vorhandensein von Dangle-Fremdschlüsseln ein unerwartetes Verhalten zur Folge hat. Hier weist die Parent-Replikat-Geodatabase eine einfache Beziehungsklasse zwischen Flurstücken und Gebäuden auf. Die Parcel-Feature-Class ist der Ursprung und verwendet das ObjectID-Feld als Primärschlüssel. Es wird ein Replikat erstellt, das alle Gebäude in der Stadt und Flurstücke für einen Gebäudeblock enthält. Bei der Replikaterstellung werden die entsprechenden Flurstücke und Gebäude aus der Parent-Replikat-Geodatabase in die Geodatabase mit dem Child-Replikat kopiert. Im Child-Replikat verfügen Gebäude, die in Beziehung zu Flurstücken außerhalb des Gebäudeblocks stehen, über Dangle-Fremdschlüssel, da diese Flurstücke nicht Teil des Replikats sind. Das Gebäude mit dem Fremdschlüssel 100 verfügt beispielsweise über einen Dangle-Fremdschlüssel, da das Flurstück mit der ObjectID 100 im Child nicht vorhanden ist. Wenn im Child-Replikat ein neues Flurstück erstellt wird und diesem die ObjectID 100 zugewiesen wird, wird es unabsichtlich zum Gebäude in Beziehung gesetzt.