Mit der Standard- oder Advanced-Lizenz verfügbar.
Während der Replikaterstellung werden dem Replikat anhand der in der Anwendung definierten Filter Zeilen und Features hinzugefügt. Wenn dieser Vorgang abgeschlossen ist, werden Beziehungsklassen verarbeitet, um zusätzliche in Beziehung stehende Objekte zu berücksichtigen.
Bei der Verarbeitung von Beziehungsklassen wird jedes Dataset ausgewertet, das an mindestens einer Beziehungsklasse beteiligt ist. Beim Auswerten eines Datasets werden alle Zeilen, die bereits repliziert wurden, gesammelt und zum Abfragen von in Beziehung stehenden Zeilen in den in Beziehung stehenden Datasets verwendet. Alle von den Abfragen zurückgegebenen in Beziehung stehenden Zeilen werden dem Replikat hinzugefügt. Während dieses Vorgangs wird jedes Dataset einmal verarbeitet.
Jede Beziehungsklasse wird nur in einer Richtung verarbeitet. In der Standardeinstellung erfolgt die Verarbeitung in Vorwärtsrichtung. Bei der Erstellung kann jedoch festgelegt werden, dass die Verarbeitung in Rückwärtsrichtung erfolgt. In Vorwärtsrichtung wird die Quellklasse ausgewertet, um dem Replikat in Beziehung stehende Zeilen aus der Zielklasse hinzuzufügen. In Rückwärtsrichtung wird die Zielklasse ausgewertet, um dem Replikat in Beziehung stehende Zeilen aus der Quellklasse hinzuzufügen. Außerdem ist es bei der Replikaterstellung möglich, die Verarbeitung für eine bestimmte Beziehungsklasse zu deaktivieren.
Da jedes Dataset einmal ausgewertet und jede Beziehungsklasse in höchstens einer Richtung verarbeitet wird, ist die Reihenfolge wichtig, in der die Datasets ausgewertet werden. Gemäß der Logik des Systems erfolgt die Verarbeitung der Datasets in der Reihenfolge, in der die meisten in Beziehung stehenden Objekte hinzugefügt werden. Sie können die Verarbeitungsreihenfolge der Datasets beeinflussen, indem Sie die Verarbeitungsrichtung ändern oder die Verarbeitung für bestimmte Beziehungsklassen deaktivieren.
In den folgenden Beispielen wird das Replikationsverhalten in Bezug auf in Beziehung stehende Objekte veranschaulicht. Das in diesen Beispielen verwendete Datenmodell ist eine einfache Quelle-Ziel-Beziehung zwischen Grundstücken, Gebäuden und den zugehörigen Annotations.
Beispiel 1
In diesem Beispiel wird der Replikatbereich gezeigt, der sich über acht Flurstücke und sechs Gebäude erstreckt. Beim Erstellen des Replikats werden zwei weitere Gebäude hinzugefügt, da sie in Beziehung zu den Flurstücken stehen. Bei der Verarbeitung der Beziehungsklassen werden dem Replikat außerdem Annotations für Gebäude und Flurstücke hinzugefügt.
Beispiel 2
In diesem Beispiel wird das Replizieren von Beziehungen durch Vorwärtsverarbeitung veranschaulicht. Durch das Auswählen der beiden Gebäude im Parent-Replikat für die Replikation und das Verwenden der standardmäßigen Vorwärtsverarbeitung für in Beziehung stehende Datensätze wird die Annotation, die in Beziehung zu diesen Gebäuden steht, ebenfalls in das Child-Replikat repliziert.
Im nächsten Diagramm wird ein Fall dargestellt, in dem Sie dieselben beiden Gebäude auswählen, sich jedoch für die Rückwärtsverarbeitung für die Beziehungsklasse "prop_build" entscheiden. Hier werden zusätzlich zu den Annotations der in Beziehung stehenden Gebäude die Flurstücke, die in Beziehung zu diesen Gebäuden stehen, sowie die Annotations der Flurstücke berücksichtigt.
Beispiel 3
In den vorausgegangenen Beispielen wurde ein Replikat mit dem Standardverhalten (Berücksichtigen der in Beziehung stehenden Objekte) erstellt. Dieses Verhalten kann auf der globalen oder der lokalen Ebene außer Kraft gesetzt werden, um den Replikationsprozess anzupassen. Auf der globalen Ebene kann der Replikationsprozess so konfiguriert werden, dass keine in Beziehung stehenden Objekte berücksichtigt werden, die den für die Replikation identifizierten Features zugeordnet sind.
Im vorliegenden Beispiel werden die Gebäude und Grundstücke im Replikatbereich ausgewählt. Da jedoch die Option zum Ausschließen von in Beziehung stehenden Datensätzen ausgewählt wurde, werden die zu den Gebäuden und Flurstücken gehörenden Annotations nicht repliziert.
Beispiel 4
In diesem Beispiel weist der Replikatbereich zwar vier Grundstücke (17691, 17692, 17698, 17697) auf, die über in Beziehung stehende Gebäude verfügen, die Gebäude wurden jedoch ausdrücklich aus der Replikation ausgeschlossen. Da für die anderen Feature-Classes noch das globale Standardverhalten in Kraft ist, gemäß dem in Beziehung stehende Objekte immer berücksichtigt werden, werden die Grundstück-Annotations wieder in das Replikat eingebunden.
Beispiel 5
In diesem Beispiel wird erläutert, welches Verhalten im Falle einer zirkulären Beziehung auftritt. Um die Verarbeitung in einer Endlosschleife zu verhindern, wird der Kreis während der Replikaterstellung vom System durch die Anwendung einer speziellen Logik unterbrochen. Diese Logik ist jedoch so beschaffen, dass die Reihenfolge der Verarbeitung von Beziehungen nicht vorhergesagt werden kann.
Um ein prognostizierbares Ergebnis für zirkuläre Beziehungen zu erhalten, können Sie festlegen, dass eine der Beziehungen nicht verarbeitet werden soll, oder Sie können die Rückwärtsverarbeitung für eine der Beziehungsklassen auswählen. Im folgenden Diagramm ist beispielsweise der Fall veranschaulicht, dass für R3 die Rückwärtsverarbeitung festgelegt ist. Nun ist die Verarbeitungsreihenfolge vorhersagbar T1 - T2 - T3. Hier weist T3 in Beziehung stehende Datensätze auf, die aus T1 und T2 hinzugefügt wurden. T1 und T2 werden jedoch keine Datensätze aus T3 hinzugefügt.
Beziehungsklassen, bei denen ein ObjectID-Feld das Primärschlüsselfeld ist
Eine Replizierung mit Beziehungsklassen, für die ein ObjectID-Feld als Primärschlüsselfeld verwendet wird, erfordert während der Synchronisierung zusätzlichen Verarbeitungsaufwand. Dies kann die Performance beeinträchtigen. In einigen Fällen kann dies auch zu unerwartetem Verhalten führen. Dies wird unten ausführlicher beschrieben. Es kann sein, dass Sie sich nach dem Lesen dieses Abschnitts entscheiden, die Beziehungsklassen so zu ändern, dass diese andere Primärschlüsselfelder als das ObjectID-Feld verwenden. Beispiele für gute Alternativen sind:
- Beziehungsklassen mit einem Primärschlüsselfeld vom Typ "GlobalID" und einem Fremdschlüsselfeld vom Typ "GUID"
- Ein eigenes Primärschlüsselfeld, das für alle Datenbanken eindeutig ist
Zusätzliche Verarbeitung während der Synchronisierung, wenn das ObjectID-Feld das Primärschlüsselfeld ist
Die ObjectID-Werte in einer Feature-Class oder Tabelle sind über die Geodatabases hinweg nicht eindeutig. Einer neuen Zeile in einer Replikat-Geodatabase kann beispielsweise die gleiche ObjectID wie einer vollkommen anderen Zeile in der anderen Replikat-Geodatabase zugeordnet werden. Beim Übertragen von Beziehungen über Replikat-Geodatabases hinweg muss die Synchronisierung diese Unterschiede berücksichtigen, wenn der Primärschlüssel der Beziehung eine ObjectID-Spalte ist. Um dies zu ermöglichen, erkennt die Synchronisierung die Beziehungsklassen, die eine ObjectID-Spalte verwenden. Falls Klassen dieser Art vorhanden sind, überträgt die Synchronisierung zusätzliche Informationen, die dann für die zusätzliche Verarbeitung verwendet werden. Die Verarbeitung umfasst auch das Anpassen der Fremdschlüsselwerte, um für jede bearbeitete Beziehung in der Ziel-Geodatabase den richtigen ObjectID-Wert sicherzustellen. Wenn eine große Anzahl von Beziehungen bearbeitet wird, kann diese zusätzliche Verarbeitung ggf. eine beträchtliche Auswirkung auf die Synchronisierungs-Performance bedeuten.
Unerwartetes Verhalten, wenn das ObjectID-Feld das Primärschlüsselfeld ist
Im Folgenden werden Fälle beschrieben, in denen unerwartetes Verhalten auftreten kann:
Bearbeitungen, bei denen die Quellzeile in der Ziel-Replikat-Geodatabase nicht vorhanden ist – Wie oben beschrieben, führt die Synchronisierung eine zusätzliche Verarbeitung aus, um Beziehungen beizubehalten, wenn ein ObjectID-Feld in einer Beziehungsklasse das Primärschlüsselfeld ist. Eine Beziehung wird jedoch nicht beibehalten, wenn die Bearbeitung die Referenzierung einer Quellzeile umfasst, die in der relativen Replikat-Geodatabase nicht vorhanden ist. Bei einer Einfügung führt dies dazu, dass der Fremdschlüssel in der Zielzeile auf Null festgelegt wird. Bei einer Aktualisierung wird der Fremdschlüsselwert auf der Einstellung belassen, die vor der Synchronisierung in der Zielzeile vorhanden war. Beachten Sie, dass dieses Verhalten bei Check-Out-Replikaten nicht auftritt.
Das Diagramm oben zeigt einen Fall, in dem zwischen Flurstücken und Gebäuden eine einfache Beziehungsklasse vorhanden ist, bei der das ObjectID-Feld der Parcels-Feature-Class als Quell-Primärschlüssel fungiert. In diesem Beispiel wird ein Replikat nur für die Flurstücke und Gebäude innerhalb eines räumlichen Bereichs erstellt. Nach der Erstellung des Replikats wird jedoch ein Digitalisierungsfehler erkannt, weil ein Gebäude im falschen Flurstück digitalisiert wurde. Dies wird in der Geodatabase mit dem Parent-Replikat korrigiert, indem das Gebäude verschoben und die Beziehung so bearbeitet wird, dass sie mit dem richtigen Flurstück verbunden ist. Anschließend wird das Replikat synchronisiert, um die Änderungen für das Child-Replikat zu übernehmen. In diesem Fall wird das Gebäude verschoben, aber es bezieht sich immer noch auf das falsche Flurstück im Child-Replikat. Die Beziehung wurde nicht im Child-Replikat geändert, da die richtige Quellzeile (Flurstück mit ObjectID 102 im übergeordneten Element) in den Geodatabases mit dem Child-Replikat nicht vorhanden ist. In diesen Fällen werden Beziehungen nicht geändert.
Dangle-Fremdschlüssel –
Beim Erstellen eines Replikats werden Zeilen basierend auf der Replikatdefinition aus der Quell-Geodatabase in die Ziel-Geodatabase kopiert. Wenn Sie das Replikat definieren, können Sie Zeilen aus der Zieltabelle ohne die in Beziehung stehenden Zeilen in der Quelltabelle einschließen. Die Fremdschlüsselwerte in der Zieltabelle entsprechen für diese nicht in Beziehung stehenden Zeilen den Werten in der Quell-Geodatabase. Diese sind Dangle-Fremdschlüssel, da die Quellzeile, auf die sie verweisen, in der Ziel-Geodatabase nicht vorhanden ist.
Das Diagramm oben beschreibt ein Beispiel, bei dem sich aus dem Vorhandensein von Dangle-Fremdschlüsseln ein unerwartetes Verhalten ergeben kann. Hier verfügt die Geodatabase mit dem Parent-Replikat über eine einfache Beziehungsklasse zwischen Flurstücken und Gebäuden. Die Parcel-Feature-Class ist die Quelle und verwendet das ObjectID-Feld als Primärschlüssel. Es wird ein Replikat erstellt, das alle Gebäude des Ortes und die Flurstücke für einen Gebäudeblock enthält. Der Vorgang der Replikaterstellung kopiert die entsprechenden Flurstücke und Gebäude aus der Geodatabase mit dem Parent-Replikat in die Geodatabase mit dem Child-Replikat. Im Child-Replikat verfügen Gebäude mit Beziehungen zu Flurstücken außerhalb des Gebäudeblocks über Dangle-Fremdschlüssel, da diese Flurstücke nicht Teil des Replikats sind. Das Gebäude mit dem Fremdschlüssel 100 weist z. B. einen Dangle-Fremdschlüssel auf, da das Flurstück mit ObjectID 100 im untergeordneten Element nicht vorhanden ist. Wenn im Child-Replikat ein neues Flurstück erstellt wird und ihm die ObjectID 100 zugewiesen wird, steht dieses ungewollt mit dem Gebäude in Beziehung.