Parameter des Werkzeugs "Beziehungsklasse erstellen"

Wie die Parameterwerte für die Ausführung des Geoverarbeitungswerkzeugs Beziehungsklasse erstellen festgelegt werden, richtet sich nach dem benötigen Beziehungsklassentyp und den Regeln, die möglicherweise angewendet werden müssen.

Um Ihnen ein besseres Verständnis der Werte und ihrer Verwendung zu vermitteln, werden im Folgenden die Eingabeparameter des Geoverarbeitungswerkzeugs Beziehungsklasse erstellen beschrieben.

Parameter

Im Folgenden werden die einzelnen Parameter des Geoverarbeitungswerkzeugs Beziehungsklasse erstellen erläutert:

• Quelltabelle: Die Tabelle oder Feature-Class, die mit der Zieltabelle verknüpft ist.
• Zieltabelle: Die Tabelle, die mit der Quelltabelle verknüpft ist.
• Ausgabe-Beziehungsklasse: Der Name der Beziehungsklasse, die erstellt wird.
• Beziehungstyp: Gibt den Typ der Beziehung an, die zwischen der Quell- und Zieltabelle erstellt wird.
  • Einfach: Zwischen Quell- und Zieltabelle besteht eine einfache Beziehung. Dies ist die Standardeinstellung.
  • Abhängig: Zwischen Quell- und Zieltabelle besteht eine abhängige Beziehung.
• Vorwärts-Pfadbeschriftung: Ein Name, der die Beziehung beim Navigieren von der Quelltabelle zur Zieltabelle eindeutig kennzeichnet.
• Rückwärts-Pfadbeschriftung: Ein Name, der die Beziehung beim Navigieren von der Zieltabelle zur Quelltabelle eindeutig kennzeichnet.
• Meldungsrichtung: Gibt die Richtung an, in die Meldungen zwischen Quell- und Zieltabelle weitergeleitet werden. Beispiel: In einer Beziehung zwischen Masten und Transformatoren wird von einem Mast, sobald er gelöscht wird, eine Meldung an die mit ihm in Beziehung stehenden Transformatorobjekte gesendet, um sie darüber zu informieren.
  • Vorwärts (Ursprung zu Ziel): Meldungen werden von der Quelltabelle zur Zieltabelle weitergeleitet.
  • Rückwärts (Ziel zu Ursprung): Meldungen werden von der Zieltabelle zur Quelltabelle weitergeleitet.
  • Beide Richtungen: Meldungen werden von der Quelltabelle zur Zieltabelle und von der Zieltabelle zur Quelltabelle weitergeleitet.
  • Keine (es werden keine Meldungen übermittelt): Es werden keine Meldungen weitergeleitet. Dies ist die Standardeinstellung.
• Beziehungsart: Legt fest, wie viele Beziehungen zwischen Zeilen oder Features in der Quelltabelle und Zeilen und Features in der Zieltabelle bestehen.
  • Eins-zu-eins (1:1): Jede Zeile bzw. jedes Feature in der Quelltabelle kann in einer Beziehung zu null oder einer Zeile oder null oder einem Feature in der Zieltabelle stehen. Dies ist die Standardeinstellung.
  • Eins-zu-viele (1:M): Jede Zeile bzw. jedes Feature in der Quelltabelle kann in einer Beziehung zu einer oder mehreren Zeilen oder einem oder mehreren Features in der Zieltabelle stehen.
  • Viele-zu-viele (M:N): Mehrere Zeilen bzw. Features in der Quelltabelle können in einer Beziehung zu einer oder mehreren Zeilen bzw. einem oder mehreren Features in der Zieltabelle stehen.
• Beziehungsklasse ist attribuiert: Legt fest, ob die Beziehung über Attribute verfügt. Weitere Informationen darüber, wo diese Attribute gespeichert werden und wie eine attribuierte Beziehungsklasse erstellt und gefüllt wird, finden Sie unter Grundlagen zu attribuierten Beziehungsklassen.
  • Aktiviert: Die Beziehungsklasse enthält Attribute.
  • Deaktiviert: Die Beziehungsklasse enthält keine Attribute. Dies ist die Standardeinstellung.

• Quell-Primärschlüssel: Bei nicht attribuierten Eins-zu-eins- oder Eins-zu-viele-Beziehungsklassen ist dies das Feld in der Quelltabelle, das häufig mit PK (von der englischen Bezeichnung "Primary Key") abgekürzt wird und mit dem Feld "Quell-Fremdschlüssel" in der Zieltabelle verknüpft ist.

  Bei Viele-zu-viele- oder attribuierten Beziehungsklassen ist dies das Feld in der Quelltabelle, das mit dem Feld "Quell-Fremdschlüssel" in der Beziehungsklassentabelle (Zwischentabelle) verknüpft ist.

• Quell-Fremdschlüssel: Bei nicht attribuierten Eins-zu-eins- oder Eins-zu-viele-Beziehungsklassen ist dies das Feld in der Zieltabelle, das häufig mit FK (von der englischen Bezeichnung "Foreign Key") abgekürzt wird und mit dem Feld "Quell-Primärschlüssel" in der Zieltabelle verknüpft ist.

  Bei Eins-zu-viele- oder attribuierten Beziehungsklassen ist dies das Feld in der Beziehungsklassentabelle (Zwischentabelle), das mit dem Feld "Quell-Primärschlüssel" in der Quelltabelle verknüpft ist.

• Ziel-Primärschlüssel: Das Feld in der Zieltabelle, das die Tabelle mit dem Feld "Ziel-Fremdschlüssel" der Beziehungsklassentabelle verbindet. Dieser Wert muss für Viele-zu-viele- oder attribuierte Beziehungsklassen angegeben werden, jedoch für nicht attribuierte Eins-zu-eins- oder Eins-zu-viele-Beziehungsklassen leer sein.
• Ziel-Fremdschlüssel: Das Feld in der Beziehungsklassentabelle (Zwischentabelle), das die Tabelle mit dem Feld "Ziel-Primärschlüssel" der Zieltabelle verbindet. Dieser Wert muss für Viele-zu-viele- oder attribuierte Beziehungsklassen angegeben werden, jedoch für nicht attribuierte Eins-zu-eins- oder Eins-zu-viele-Beziehungsklassen leer sein.

Ursprungs- und Zielklassen

Beim Erstellen einer Beziehungsklasse wählen Sie eine Klasse als Ursprung und eine andere als Ziel aus. Diese beiden dürfen nicht miteinander verwechselt werden. Im Hinblick auf die kaskadierenden Löschvorgänge in abhängigen Beziehungen ist die Bedeutung dieser Aussage offensichtlich.

In einfachen Beziehungen ist es unerlässlich, die jeweils richtige Klasse als Ursprung und als Ziel zu wählen. Der Grund hierfür ist, dass die Werte im Schlüsselfeld der entsprechenden Datensätze in der Zielklasse der einfachen Beziehungsklasse beim Löschen eines Datensatzes in der Quellklasse auf NULL festgelegt werden. Wenn Sie die falsche Klasse als Ursprung festlegen und Objekte in der Quellklasse löschen, führt dies zu Fehlern im Fremdschlüsselfeld. Dies wird im folgenden Beispiel veranschaulicht:

Bei der Auswahl des Ziels und des Ursprungs dürfen diese nicht miteinander verwechselt werden.

Fall 1: Flurstück zu Zone (falsch)

Dies ist ein häufig auftretendes Szenario für diesen Fehler. Die Tabelle der Zonen enthält die Beschreibungen für die verschiedenen Zoning-Codes und entspricht konzeptionell einer Lookup-Tabelle. In diesem Fall ist die Klasse der Flurstücke der Ursprung und die Tabelle der Zonen das Ziel. Das Problem besteht darin, dass beim Löschen eines Flurstücks der Wert im Schlüsselfeld ("Zone") für den entsprechenden Datensatz in der Tabelle der Zonen auf NULL festgelegt wird. Dies führt dazu, dass in der Tabelle der Zonen keine Entsprechung mehr für die anderen Flurstücke mit diesem Zoning-Code gefunden werden kann.

Fall 2: Zone zu Flurstück (richtig)

Um das Problem zu beheben, legen Sie die Tabelle der Zonen als Ursprung fest. Das Löschen eines Flurstücks (eines Zielobjekts) hat keine Auswirkungen auf die Tabelle der Zonen und durch das Löschen eines Zonencodes (eines Ursprungsobjekts) wird lediglich der Wert des Feldes "Zone" in den entsprechenden Flurstückdatensätzen wie erwünscht auf NULL festgelegt, da in der Tabelle der Zonen kein entsprechender Datensatz mehr verfügbar ist.

Name der Ausgabe-Beziehungsklasse

Jede Beziehungsklasse weist einen Namen auf, der im Bereich Katalog angezeigt wird. Es wird empfohlen, die Beziehungsklasse so zu benennen, dass der Name die beteiligten Elemente und die Beziehungsart beschreibt.

Beginnen Sie mit dem Namen der Ursprungs-Feature-Class gefolgt von "Has" oder "Have" und schließen Sie den Namen der Ziel-Feature-Class an. Beispiele sind "AddressHasZones" oder "ParcelsHaveOwners". Setzen Sie den Namen der Ursprungs-Feature-Class in den Plural, wenn es sich um die Beziehungsart "Viele-zu-eins" oder "Viele-zu-viele" handelt, und setzen Sie den Namen der Ziel-Feature-Class in den Plural, wenn es sich um die Beziehungsart "Eins-zu-viele" oder "Viele-zu-viele" handelt.

Dadurch können Sie die Beziehungsart der Beziehungsklasse anhand ihres Namens bestimmen. Beispiel: Da bei "ParcelsHaveOwners" die Namen beider Feature-Classes im Plural stehen, weist dies auf eine Viele-zu-viele-Beziehung hin.

Namen müssen in einer Geodatabase eindeutig sein. Mehrere Objekte (Tabelle, Feature-Class, Beziehungsklasse usw.) mit demselben Namen sind nicht zulässig. Weitere Informationen zu den Regeln und Beschränkungen für die Namen von Feature-Classes und Tabellen finden Sie unter Festlegen der Eigenschaften von Feature-Classes.

Vorwärts- und Rückwärts-Pfadbeschriftungen

Vorwärts- und Rückwärtsbeschriftungen werden in ArcGIS Pro in den Dialogfeldern Attribute und Abfrageergebnisse angezeigt. Diese erleichtern Ihnen das Navigieren durch in Beziehung stehende Objekte.

Eine Beziehungsklasse weist zwei Beschriftungen auf:

• Eine Vorwärtsbeschriftung, die beim Navigieren vom Ursprung zum Ziel angezeigt wird. Im Beispiel der Masten und Transformatoren könnte diese Beschriftung zulässig lauten, was bedeutet, dass diese Transformatoren für den betreffenden Mast zulässig sind.
• Eine Rückwärtsbeschriftung, die angezeigt wird, wenn Sie vom Ziel zum Ursprung navigieren. Im Beispiel der Masten und Transformatoren könnte diese Beschriftung angebracht an lauten, was bedeutet, dass diese Transformatoren am betreffenden Mast angebracht sind.

Richtung der Nachrichtenübermittlung

Wie bereits erläutert, werden beim Löschen eines Ursprungsobjekts in einer abhängigen Beziehung die in Beziehung stehenden Zielobjekte automatisch ebenfalls gelöscht.

Unabhängig davon, ob Sie mit einfachen oder abhängigen Beziehungen arbeiten, kann es weitere Vorgänge geben, bei denen eine Aktualisierung eines Features die Aktualisierung der in Beziehung stehenden Features auslösen soll. Dabei können zudem Aktualisierungen in einer und/oder der anderen Richtung erforderlich sein.

• Wenn Sie ein Feature verschieben oder drehen, sollen die in Beziehung stehenden Features ebenfalls verschoben bzw. gedreht werden.
• Beim Aktualisieren eines Features soll ein Attribut in einem in Beziehung stehenden Feature automatisch aktualisiert werden.
• Das Aktualisieren eines Ursprungs kann eine Aktualisierung der in Beziehung stehenden Zielobjekte erfordern.
• Das Aktualisieren von Zielobjekten kann eine Aktualisierung der in Beziehung stehenden Ursprungsobjekte erfordern.

Wenn die vorhandene Beziehung dieses Verhalten erfordert, können Sie festlegen, dass sich Ursprungs- bzw. Zielobjekte gegenseitig Nachrichten senden, um einander bei Änderungen zu benachrichtigen, wodurch eine entsprechende Aktualisierung der in Beziehung stehenden Objekte ermöglicht wird.

Legen Sie hierfür die Richtung für die Nachrichtenübermittlung beim Erstellen der Beziehung fest. Wenn bei der Aktualisierung eines Ursprungsobjekts die in Beziehung stehenden Zielobjekte aktualisiert werden müssen, legen Sie die Richtung der Nachrichtenübermittlung auf Vorwärts fest. Wenn bei der Aktualisierung eines Zielobjekts die in Beziehung stehenden Ursprungsobjekte aktualisiert werden müssen, legen Sie die Richtung der Nachrichtenübermittlung auf Rückwärts fest. Wenn die Nachrichtenübermittlung in beiden Richtungen nötig ist, legen Sie die Richtung der Nachrichtenübermittlung auf Beide fest. Nach dem Erstellen der Beziehung müssen Sie das Verhalten für die Objekte, die die Nachrichten empfangen, durch Programmieren festlegen, so dass diese entsprechend reagieren können.

Die einzige Ausnahme sind abhängige Beziehungen, für die die Richtung der Nachrichtenübermittlung auf Vorwärts festgelegt ist. Wenn Sie eine abhängige Beziehung mit einer Nachrichtenübermittlung erstellen, die auf "Vorwärts" festgelegt ist, bewirkt das Verschieben oder Drehen eines Ursprungsobjekts, dass die in Beziehung stehenden Ziel-Features automatisch auch verschoben bzw. gedreht werden. Sofern Sie die Beziehung ordnungsgemäß eingerichtet haben, funktioniert dies unmittelbar nach dem Erstellen der Beziehung und es ist kein gesonderter Programmcode erforderlich.

Bei anderen Richtungen für die Nachrichtenübermittlungen müssen die Objekte hingegen mit benutzerdefiniertem Programmcode versehen werden. Wenn Sie weder eine abhängige Beziehung mit einer Nachrichtenübermittlung vom Typ "Vorwärts" erstellen noch benutzerdefiniertes Verhalten festlegen möchten, legen Sie die Nachrichtenübermittlung auf Keine fest. Andernfalls werden bei jedem Bearbeitungsvorgang unnötige Nachrichten erzeugt. Dies wirkt sich negativ auf die Performance aus.

Beachten Sie beim Festlegen der Richtung für abhängige Beziehungen, dass beim Löschen des Ursprungsobjekts in einer abhängigen Beziehung alle in Beziehung stehenden Objekte im Ziel automatisch ebenfalls gelöscht werden. Dies geschieht unabhängig davon, ob die Richtung der Nachrichtenübermittlung auf Vorwärts, Rückwärts, Beide oder Keine festgelegt ist.

Richtungen für die Nachrichtenübermittlung

Richtung	Auswirkung auf einfache Beziehungen	Auswirkung auf abhängige Beziehungen
Vorwärts	Keine Auswirkung, sofern nicht durch Programmierung angepasst	Löschen des Ursprungs führt zu Löschen des Ziels Verschieben oder Drehen des Ursprungs führt zu Verschieben oder Drehen des Ziels Keine weitere Auswirkung, es sei denn, benutzerdefiniertes Verhalten ist programmiert
Rückwärts	Keine Auswirkung, sofern nicht durch Programmierung angepasst	Löschen des Ursprungs führt zu Löschen des Ziels Keine weitere Auswirkung, es sei denn, benutzerdefiniertes Verhalten ist programmiert
Beide	Keine Auswirkung, sofern nicht durch Programmierung angepasst	Löschen des Ursprungs führt zu Löschen des Ziels Verschieben oder Drehen des Ursprungs führt zu Verschieben oder Drehen des Ziels Keine weitere Auswirkung, es sei denn, benutzerdefiniertes Verhalten ist programmiert
Keine	Verhindert Übermittlung von Nachrichten, Performance wird leicht verbessert	Löschen des Ursprungs führt zu Löschen des Ziels Verhindert Übermittlung von anderen Nachrichten, Performance wird leicht verbessert

Beziehungsart

Die Beziehungsart beschreibt die maximale Anzahl von Zuordnungen zwischen zwei verschiedenen Tabellenzeilen oder -spalten.

In einem GIS werden Informationen über verschiedene geographische und nichtgeographische Objekte integriert, von denen viele miteinander in Beziehung stehen können. Wenn Sie Ihren Feature-Daten nichtgeographische Daten hinzufügen, ist es wichtig zu berücksichtigen, wie die Objekte miteinander verbunden sind und ob es ein gemeinsames Feld gibt.

Beziehungen basieren auf einer Quell- und einer Zieltabelle und der Beziehung zwischen den Objekten in der Quell- und der Zieltabelle. Um eine Beziehung zwischen zwei Tabellen zu erstellen, muss ein gemeinsames Feld mit gemeinsamen Werten identifiziert werden, den sogenannten Schlüssel.

Hinweis:

Gemeinsame Felder müssen nicht denselben Namen haben, jedoch denselben Datentyp. Mithilfe der Werte in den gemeinsamen Feldern werden Datensätze in der Tabelle basierend auf der definierten Beziehungsart verknüpft.

Die Beziehungsart gibt an, wie viele Objekte in der Quelltabelle mit wie vielen Objekten in der Zieltabelle in Beziehung gesetzt werden. Eine Beziehungsklasse kann eine von drei Beziehungsarten aufweisen:

• Eins-zu-eins: Eine Zeile bzw. ein Feature in der Quellklasse oder -tabelle kann mit 0 oder einer Zeile bzw. einem Feature in der Zielklasse oder -tabelle in Beziehung gesetzt werden. Diese Einstellung ist die Standardeinstellung. Ein Flurstück kann beispielsweise nur eine Beschreibung aus dem Bestandsverzeichnis des Grundbuchs aufweisen.

  Hinweis:

  In ArcGIS schließt diese Beziehungsart auch den Typ "Viele-zu-eins" ein. Ein Beispiel für eine Viele-zu-eins-Beziehung sind viele Flurstücke mit einem Bezug zur selben Beschreibung aus dem Bestandsverzeichnis des Grundbuchs.

• Eins-zu-viele: Eine Zeile bzw. ein Feature in der Quellklasse oder -tabelle kann mit einer oder mehreren Zeile bzw. einem oder mehreren Feature in der Zielklasse oder -tabelle in Beziehung gesetzt werden. Ein Flurstück kann beispielsweise viele Gebäude aufweisen. In einer Eins-zu-viele-Beziehung muss die Eins-Seite die Quellklasse sein und die Viele-Seite die Zielklasse sein.
• Viele-zu-viele: Ein Ursprungsobjekt kann in Beziehung zu vielen Zielobjekten stehen, und umgekehrt kann ein Zielobjekt in Beziehung zu vielen Ursprungsobjekten stehen. Ein bestimmtes Grundstück kann beispielsweise viele Besitzer aufweisen und einem bestimmtem Besitzer können viele Grundstücke gehören. Weitere Informationen finden Sie unter Grundlagen zu attribuierten Beziehungsklassen.

Hinweis:

Beim Auswerten der Beziehungsart von Objekten zwischen zwei Tabellen bedeutet "Eins" tatsächlich "Null-zu-eins", und "Viele" bedeutet tatsächlich "Null-zu-viele". Wenn Sie also beispielsweise eine Eins-zu-viele-Beziehung zwischen Flurstücken und Gebäuden erstellen, lässt die Beziehung Folgendes zu:

• Ein Flurstück ohne Gebäude
• Ein Gebäude ohne Flurstück
• Ein Flurstück mit einer beliebigen Anzahl von Gebäuden

Wenn eine Beziehungsklasse erstellt wurde, können Sie die Beziehungsarten weiter verfeinern, indem Sie der Beziehungsklasse Regeln hinzufügen. Sie können Regeln hinzufügen, um die Anzahl der Zeilen oder Features in der Quellklasse oder -tabelle festzulegen, die mit einer bestimmten Anzahl von Zeilen oder Features in der Zielklasse in Beziehung stehen dürfen.

Hinweis:

Die Beziehungsart wird beim Erstellen einer Beziehungsklasse definiert. Nach dem Erstellen der Beziehungsklasse kann deren Beziehungsart nicht mehr geändert werden; daher ist es wichtig, die Beziehungsart der Daten vor dem Erstellen der Beziehungsklasse zu bestimmen und zu überprüfen.

Primär- und Fremdschlüssel

In einer Beziehungsklasse sind die Objekte in der Quelltabelle über die Werte in ihren Schlüsselfeldern Objekten in der Zieltabelle zugeordnet.

In einer nichtattribuierten Beziehungsklasse wird die Beziehung beibehalten, wenn sich die Werte im Feld "Quell-Primärschlüssel" (PK) in der Quelltabelle direkt auf die Werte im Feld "Quell-Fremdschlüssel" (FK) in der Zieltabelle beziehen. Im Unterschied zu einem "echten" Primärschlüssel müssen die Werte im Primärschlüsselfeld einer Beziehung für die einzelnen Objekte nicht eindeutig sein. Das Fremdschlüsselfeld enthält Werte, die mit denen des Primärschlüsselfeldes in der Quelltabelle übereinstimmen. Auch für diese gilt, dass die Schlüsselfeldwerte nicht für jede Zeile eindeutig sein müssen.

Beispiel: Flurstück 789 ist den Genehmigungen 2 und 3 zugeordnet, da diese Datensätze dieselbe Flurstücks-ID aufweisen.

Optional wird in einer attribuierten Beziehungsklasse, wie z. B. beim Erstellen einer Viele-zu-viele-Beziehung, auch automatisch eine Zwischentabelle erstellt. Mit dieser Zwischentabelle werden die Werte in den Feldern "Quell-Fremdschlüssel" und "Ziel-Fremdschlüssel" den Primärschlüsseln der zugehörigen Tabellen oder Feature-Classes zugeordnet. In jeder Zeile wird ein Ursprungsobjekt einem Zielobjekt zugeordnet. Die Schlüsselfelder können unterschiedliche Namen aufweisen, müssen jedoch über dasselbe Feld "Datentyp" verfügen und dieselbe Art von Informationen enthalten, beispielsweise Flurstücks-IDs. Mit Ausnahme von BLOB- (Binary Lage Object), Datums- und Raster-Feldern können alle Datentypen für Schlüsselfelder verwendet werden.

Um beispielsweise die Besitzer von Flurstücken in Ihrer Community zu ermitteln, wird eine Viele-zu-viele-Beziehungsklasse zwischen der Parcel-Feature-Class und der Standalone-Tabelle "Owner" erstellt. Diese Viele-zu-viele-Beziehungsklasse erstellt die Zwischentabelle oder attribuierte Tabelle "ParcelToOwner", die jedes Flurstück mit einem oder mehreren Besitzern verknüpft.

Die Schlüsselfelder werden beim Erstellen einer Beziehungsklasse festgelegt.

Wenn Sie ein Primärschlüsselfeld festlegen, können Sie dazu das Zeilen-ID-Feld verwenden, das häufig als ObjectID-Feld bezeichnet wird. Das ObjectID-Feld wird von ArcGIS beim Erstellen einer Feature-Class oder Tabelle bzw. beim Registrieren eines Enterprise-Geodatabase-Layers oder einer Enterprise-Geodatabase-Tabelle automatisch hinzugefügt. Mit diesem Feld wird sichergestellt, dass für jeden Datensatz eine eindeutige ID vorhanden ist. Es wird von ArcGIS verwaltet und kann nicht geändert werden.

Der ObjectID-Wert eines bestimmten Objekts ändert sich nicht, solange es in der ursprünglichen Klasse verbleibt und, sofern es sich beim Objekt um ein Feature handelt, nicht geteilt wird. Beim Teilen eines Features wird das Ursprungs-Feature beibehalten (die Geometrie wird aktualisiert), und es wird ein neues Feature mit einer neuen ObjectID erstellt. Als Ergebnis hält nur das Feature mit der ursprünglichen ObjectID Beziehungen aufrecht, die vom ObjectID-Wert abhängig sind.

Daher empfiehlt es sich, ein eigenes Primärschlüsselfeld zu erstellen und zu verwenden, anstatt sich auf das ObjectID-Feld zu verlassen. Im Folgenden wird beschrieben, wie Sie bei den oben genannten Vorgängen Beziehungen unter Verwendung eines eigenen Primärschlüsselfeldes beibehalten können.

• Beim Importieren von Datensätzen in eine andere Feature-Class oder Tabelle werden neue ObjectID-Werte zugewiesen, wobei alle Beziehungen verloren gehen, die auf den ursprünglichen ObjectID-Werten basieren. Wenn Sie der Beziehung stattdessen einen anderen Primärschlüssel zugrunde legen, werden die ID-Werte im Primärschlüssel beim Importieren von Datensätzen nicht geändert. Auf diese Weise können Beziehungen beibehalten werden, wenn in Beziehung stehende Gruppen von Objekten in neue Klassen importiert werden.

  Eine Ausnahme stellt jedoch die Funktion zum Kopieren und Einfügen dar. Durch Kopieren und Einfügen bleiben ObjectID-Werte erhalten. Wenn Sie Objekte also nur mit diesem Verfahren verschieben möchten, können Sie das ObjectID-Feld als Primärschlüssel verwenden.

• Beim Teilen eines Features wird das Ursprungs-Feature beibehalten (mit aktualisierter Geometrie), und ein neues Feature erstellt. Wenn eine Beziehung basierend auf der ursprünglichen ObjectID vorhanden ist, kann nur eines der beiden in der Teilung erstellten Features die Beziehung aufrechterhalten. Wenn Sie jedoch ein anderes Feld als Schlüsselfeld verwendet haben, wird der ID-Wert des ursprünglichen Features beim Teilen des Features in die beiden neuen Features kopiert. Daher werden die Datensätze in der in Beziehung stehenden Tabelle nun auf die beiden neuen Features bezogen. Dies ist ideal, wenn die Beziehungsklasse vom Typ "Viele-zu-viele" ist.

  Wenn keine Features geteilt werden und Sie sicher sind, dass alle Objekte in der ursprünglichen Klasse verbleiben, können Sie die ObjectID für deren IDs verwenden. Wenn Sie dies jedoch nicht sicherstellen können, wird empfohlen, ein eigenes ID-Feld einzurichten und zu verwenden, anstatt sich auf das ObjectID-Feld zu verlassen.

• Beim Zusammenführen von zwei Features wird die ObjectID eines der ursprünglichen Features in das neue Feature übernommen. Wenn Sie Features zusammenführen, jedoch keine Features aus ihrer Klasse verschieben oder teilen möchten, können Sie das ObjectID-Feld als Primärschlüssel verwenden.