Eigenschaften von Beziehungsklassen

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

Eine Beziehungsklasse enthält eine Reihe von Eigenschaften, die bestimmen, wie sich Objekte am Ursprung auf Objekte am Ziel beziehen. Diese Eigenschaften werden beim Erstellen der Beziehungsklasse festgelegt.

• Typ: Einfach oder abhängig
• Ursprungs- und Zielklassen
• Primär- und Fremdschlüssel
• Beziehungsart: Handelt es sich um eine Eins-zu-eins-, Eins-zu-viele- oder Viele-zu-viele-Beziehung?
• Richtung, in der Nachrichten übermittelt werden sollen; nur zutreffend, wenn benutzerdefiniertes kaskadierendes Aktualisierungs- oder Löschverhalten implementiert werden soll
• Sollen Attribute für die einzelnen Beziehungen gespeichert werden?
• Name
• Vorwärts- und Rückwärtsbeschriftungen, die beim Navigieren durch in Beziehung stehende Datensätze in ArcMap angezeigt werden

Nach dem Erstellen der Beziehung können Sie Regeln festlegen, um die Beziehungsart zu optimieren.

Einfache Beziehungen im Vergleich zu abhängigen Beziehungen

Beim Erstellen einer Beziehungsklasse geben Sie an, ob diese einfach oder abhängig ist.

In einer einfachen Beziehung können die in Beziehung stehenden Objekte unabhängig voneinander existieren. Beispiel: In einem Eisenbahnnetz gibt es Bahnübergänge, an denen eine oder mehrere verbundene Signalanlagen angebracht sind. Der Bahnübergang kann jedoch auch ohne eine Signalanlage existieren und Signalanlagen existieren im Eisenbahnnetz auch dort, wo es keine Bahnübergänge gibt.

Wenn Sie das Ursprungsobjekt in einer einfachen Beziehung löschen, wird der Wert des Fremdschlüsselfeldes für das entsprechende Zielobjekt auf NULL gesetzt. Dies soll die referenzielle Integrität zwischen Features sicherstellen. Wenn das Ursprungs-Feature gelöscht wird, wird diese Zeile nicht mehr durch den Fremdschlüsselwert mit einem Feature im Ursprung verknüpft; daher ist der Fremdschlüsselwert nicht mehr erforderlich und wird auf NULL gesetzt. Der einzige Zweck des Fremdschlüssels besteht darin, eine Beziehung zwischen dem Zielobjekt und dem zugehörigen Ursprungsobjekt herzustellen. Wenn kein Ursprungs-Feature mit dem passenden Primärschlüsselwert vorliegt, besteht kein Grund zur Beibehaltung des Fremdschlüsselwertes. Wenn Sie in Zukunft dasselbe Ziel-Feature mit einem neuen oder anderen Feature verknüpfen möchten, kann das Feld mit dem Fremdschlüsselwert von NULL auf den neuen Fremdschlüsselwert aktualisiert werden.

Das Löschen eines Zielobjekts hat keine Auswirkungen auf den Primärschlüsselwert im zugehörigen Ursprungsobjekt.

Einfache Beziehungen können die Beziehungsarten Eins-zu-eins (1:1), Eins-zu-viele (1:M), Viele-zu-eins (M:1) und Viele-zu-viele (N:M) aufweisen.

Ebenso wie einfache Beziehungen behalten auch abhängige Beziehungen ihre referenzielle Integrität, wenn Objekte gelöscht werden, aber auf eine andere Weise. In einer abhängigen Beziehung können die Zielobjekte nicht unabhängig von den Ursprungsobjekten existieren. Wenn der Ursprung gelöscht wird, werden die in Beziehung stehenden Zielobjekte daher in einem so genannten kaskadierenden Löschvorgang ebenfalls gelöscht.

Eine abhängige Beziehung kann auch zur räumlichen Verwaltung von Features beitragen. Durch das Verschieben oder Drehen eines Ursprungs-Features werden die Ziel-Features ebenfalls verschoben bzw. gedreht, wenn für die Nachrichtenübermittlung "Vorwärts" festgelegt wurde.

Abhängige Beziehungen sind beim Erstellen immer Eins-zu-viele-Beziehungen. Sie können aber mit Hilfe von Beziehungsregeln auf Eins-zu-eins beschränkt werden.

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 in den Schlüsselfeldern 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:

Fall 1: Flurstück zu Zone (falsch)

Dies ist ein häufig auftretendes Fehlerszenario. 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.

Primär- und Fremdschlüssel

In einer Beziehungsklasse sind die Objekte im Ursprung über die Werte in ihren Schlüsselfeldern Objekten im Ziel zugeordnet. Im folgenden Beispiel ist Flurstück 789 den Genehmigungen 2 und 3 zugeordnet, da diese Datensätze dieselbe Flurstücks-ID aufweisen.

Das Schlüsselfeld in der Quellklasse einer Beziehung wird als Primärschlüssel bezeichnet. Der Primärschlüssel wird häufig als PK (von der englischen Bezeichnung "Primary Key") abgekürzt. 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 Schlüsselfeld in der Zielklasse wird als Fremdschlüssel bezeichnet. Der Fremdschlüssel wird häufig als FK (von der englischen Bezeichnung "Foreign Key") abgekürzt. Es enthält Werte, die denen des Primärschlüsselfeldes in der Quellklasse entsprechen. Auch für diese gilt, dass die Schlüsselfeldwerte nicht für jede Zeile eindeutig sein müssen.

Die Schlüsselfelder können unterschiedliche Namen aufweisen, müssen jedoch über denselben 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. 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, empfiehlt es sich, 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.

Beziehungsart

Die Beziehungsart einer Beziehung gibt die Anzahl der Objekte in der Quellklasse an, die zu einer Anzahl von Objekten in der Zielklasse in Beziehung stehen können. Eine Beziehung kann eine von drei Beziehungsarten aufweisen:

Eins-zu-eins: Ein Quellobjekt kann nur mit einem Zielobjekt in Beziehung stehen. Ein Flurstück kann beispielsweise nur eine Beschreibung aus dem Bestandsverzeichnis des Grundbuchs aufweisen. 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: Ein Quellobjekt kann mit mehreren Zielobjekten in Beziehung stehen. 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.

Die Begriffe "Eins" und "Viele" können irreführend sein. "Eins" bedeutet 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

Beziehungsregeln

Wenn Sie eine Beziehungsklasse erstellen, erstellen Sie diese mit der Beziehungsart "Eins-zu-eins", "Eins-zu-viele" oder "Viele-zu-viele".

Beziehungen müssen häufig restriktiver definiert werden. In einer Beziehung zwischen Flurstücken und Gebäuden könnte es beispielsweise erforderlich sein, dass jedes Gebäude einem Flurstück zugeordnet ist oder dass ein Flurstück höchstens eine bestimme Anzahl an Gebäuden enthalten kann. Dadurch wird verhindert, dass Benutzer vergessen, einem Gebäude ein Flurstück zuzuweisen, oder dass Benutzer einem Flurstück zu viele Gebäude zuordnen.

Wenn Subtypes vorhanden sind, können Sie die Anzahl und die Typen von Objekten im Ursprung beschränken, die zu einem bestimmten Objekttyp im Ziel in Beziehung stehen können. Beispiel: Für Stahlmasten können Transformatoren der Klasse A verwendet werden, während für Holzmasten Transformatoren der Klasse B zulässig sind. Darüber hinaus ist es möglicherweise erforderlich, den zulässigen Bereich der Beziehungsart für die einzelnen gültigen Subtype-Paare festzulegen. Beispiel: Auf Stahlmasten können null bis drei Transformatoren der Klasse A, auf Holzmasten null bis zwei Transformatoren der Klasse B montiert werden.

Um die Beziehungsregeln für Ihre Beziehungsklasse anzuzeigen, klicken Sie im Bereich Katalog mit der rechten Maustaste auf die Beziehungsklasse, um das Dialogfeld Eigenschaften von Beziehungsklassen zu öffnen und die Registerkarte Regeln auszuwählen.

Dadurch wird eine Liste aller möglichen Regeln angezeigt, die für eine Beziehungsklasse vorhanden sein können. Die Spalte Aktiviert gibt an, welche Regeln aktuell aktiv sind.

Sie können Beziehungsklassenregeln in der Anzeige sortieren, indem Sie Ursprungs- dann Ziel-Subtype oder Ziel- dann Ursprungs-Subtype im Dropdown-Menü Sortieren nach auswählen.

Um eine Regel aus der Beziehungsklasse zu entfernen, deaktivieren Sie das Kontrollkästchen Aktiviert für die Zeile, die die zu entfernende Regel darstellt, und klicken Sie auf OK.

So erstellen Sie eine neue Regel für die Beziehungsklasse:

1. Aktivieren Sie das Kontrollkästchen Aktiviert für die Zeile, die die Regel darstellt, die Sie der Beziehungsklasse hinzufügen möchten.
2. Legen Sie für den Ursprung und das Ziel die entsprechenden Beziehungsarten Min und Max für die Regel fest, indem Sie ganzzahlige Werte in die relevanten Zellen eingeben.
3. Wiederholen Sie die Schritte 1 und 2 für jede hinzuzufügende Regel.
4. Klicken Sie auf OK.

Wenn einer Beziehungsklasse eine Beziehungsregel hinzugefügt wurde, wird diese Regel die einzig gültige Beziehung, die vorhanden sein kann. Damit andere Beziehungskombinationen und Beziehungsarten zulässig sind, müssen Sie zusätzliche Beziehungsregeln hinzufügen.

Im folgenden Beispiel kann eine Sondermülldeponie ("HazMat Landfill") zu einem bis zwei tiefen ("Deep") oder zwei bis sieben flachen ("Shallow") Beobachtungsbrunnen ("MonitorWell") in Beziehung gesetzt werden. Wenn jedoch eine geordnete Mülldeponie ("Sanitary Landfill") in Beziehung zu einem tiefen Beobachtungsbrunnen gesetzt wird und zwischen diesen beiden Subtypes keine Regel erstellt wurde, wird die Beziehung vom Befehl "Features überprüfen" als ungültig betrachtet.

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 erforderlich ist, dass die Aktualisierung eines Ursprungsobjekts eine Aktualisierung der in Beziehung stehenden Zielobjekte nach sich zieht, legen Sie die Richtung der Nachrichtenübermittlung auf "Vorwärts" fest. Wenn bei einer 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, wenn 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
Beides	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
Kein	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

Viele-zu-viele-Beziehungen

In Eins-zu-eins-Beziehungen und Eins-zu-viele-Beziehungen stehen Werte im Primärschlüssel der Quellklasse in direkter Beziehung zu Werten im Fremdschlüssel der Zielklasse.

In Viele-zu-viele-Beziehungen muss hingegen eine Zwischentabelle zum Zuordnen der Beziehungen verwendet werden. Daher wird beim Erstellen einer Viele-zu-viele-Beziehung automatisch eine Zwischentabelle erstellt. Mit der Zwischentabelle werden Primärschlüsselwerte aus dem Ursprung Fremdschlüsselwerten aus dem Ziel zugeordnet. In jeder Zeile wird ein Ursprungsobjekt einem Zielobjekt zugeordnet.

Beim Erstellen einer Zwischentabelle werden nur die Felder automatisch erstellt. ArcGIS erkennt nicht, welche Ursprungsobjekte welchen Zielobjekten zugeordnet sind. Deshalb müssen Sie die Zeilen in der Tabelle manuell erstellen. Das Ausfüllen dieser Tabelle ist der zeitaufwändigste Vorgang beim Einrichten der Beziehung.

Attribute einer Beziehung

Die Zwischentabelle einer Viele-zu-viele-Beziehung kann optional auch einen zweiten Zweck erfüllen – das Speichern von Attributen der Beziehung selbst. In einer Flurstücksdatenbank kann beispielsweise eine Beziehungsklasse zwischen Flurstücken und Besitzern vorliegen, in der Besitzer Flurstücke besitzen und Flurstücke mehreren Besitzern gehören. Ein Attribut der einzelnen Beziehungen kann z. B. der Besitzanteil der einzelnen Besitzer sein. Wenn Sie Attribute dieser Art speichern müssen, können Sie diese beim Erstellen der Beziehung oder zu einem späteren Zeitpunkt der Zwischentabelle hinzufügen.

Auch beim Einrichten einer Eins-zu-eins-Beziehung oder einer Eins-zu-viele-Beziehung kann es erforderlich sein, Attribute der Beziehung selbst zu speichern. Dies ist zwar nicht ganz so nützlich, aber ebenso möglich. Wenn dies der Fall ist, müssen Sie dies beim Erstellen der Beziehung angeben, so dass automatisch eine Zwischentabelle erstellt wird. Wie bei Viele-zu-viele-Beziehungen werden in der Zwischentabelle Primärschlüsselwerte aus dem Ursprung Fremdschlüsselwerten aus dem Ziel zugeordnet. Hierdurch können Sie eine beliebige Anzahl von Attributen für die einzelnen Beziehungen speichern.

Wenn Sie der Karte die Beziehungsklasse hinzufügen, wird sie als Tabelle angezeigt, die Sie öffnen und bearbeiten können. ArcGIS stellt die Zwischentabelle nicht für andere Vorgänge bereit. Sie können beispielsweise die betreffenden Eigenschaften nicht im Bereich Katalog anzeigen und Felder in der Ansicht "Felder" hinzuzufügen oder löschen. Die Verwendung von Standardwerten oder Domänen wird nicht unterstützt.

Name

Jede Beziehungsklasse weist einen Namen auf, der im Bereich Katalog angezeigt wird. Wenn Sie die Datenbankstruktur verständlich gestalten möchten, weisen Sie der Beziehungsklasse einen Namen zu, mit dem die Beziehung beschrieben wird.

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.

Vorwärts- und Rückwärtsbeschriftungen

Vorwärts- und Rückwärtsbeschriftungen werden in den Dialogfeldern "Attribute" und "Identifizieren" im Bereich "Karte" angezeigt und erleichtern die Navigation zwischen zugehörigen Objekten.

Eine Beziehungsklasse weist zwei Beschriftungen auf:

• Eine Vorwärtsbeschriftung, die angezeigt wird, wenn Sie vom Ursprung zum Ziel navigieren. 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.