nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Relates und Relationship Classes erklärt

SuzanneBoden

Aktualisiert am 7. Februar 2022

Der Unterschied zwischen relates (oft als table relates bezeichnet) und relationship classes ist eine Quelle großer Verwirrung, insbesondere für neue ArcGIS-Benutzer. Obwohl sie ähnlich klingen, beziehen sich die Begriffe auf unterschiedliche Dinge. Beide haben Vorteile und es gibt Gründe, jeweils das eine oder andere zu verwenden. Hier sind die wichtigsten Dinge, die man wissen sollte.

Ein relate existiert in einer Karte oder Layer-Datei.
Eine relationship class ist ein Objekt in einer Geodatabase.
Relates können mit einer ArcGIS Pro- oder ArcGIS Desktop-Basic, Standard oder Advanced-Lizenz erstellt und bearbeitet werden.
Relationship classes können mit einer ArcGIS Pro- oder ArcGIS Desktop-Standard- oder Advanced-Lizenz erstellt und bearbeitet werden. Mit einer Basic-Lizenz sind sie nur lesbar.

Alles klar jetzt? Nein? Dann machen wir weiter.

Die Terminologie aufschlüsseln

Relates sind großartig, weil sie es ermöglichen, Features in einem Layer auszuwählen und dann einfach verwandte Features in einem anderen Layer oder verwandte Datensätze in einer nicht-räumlichen Tabelle zu sehen. Relationship classes sind großartig, weil sie "intelligentes Verhalten" ermöglichen. Sie können Regeln dafür festlegen, wie sich die beteiligten Feature-Classes oder Tabellen verhalten, wenn etwas passiert. Zum Beispiel kann bei Vorhandensein einer relationship class beim Löschen eines Features auch der zugehörige Datensatz in der anderen Feature-Class oder Tabelle automatisch gelöscht werden.

Sowohl relates als auch relationship classes basieren auf cardinality, die beschreibt, wie Datensätze in zwei verschiedenen Tabellen miteinander verbunden sind – Cardinality kann eins-zu-eins, eins-zu-viele, viele-zu-eins oder viele-zu-viele sein.

Eins-zu-eins: Jedes Feature hat genau einen zugehörigen Datensatz in der anderen Tabelle.
Eins-zu-viele: Features in einer Tabelle können mehr als einen zugehörigen Datensatz in der anderen Tabelle haben.
Viele-zu-eins: Mehrere Features in einer Tabelle haben einen zugehörigen Datensatz in der anderen Tabelle.
Viele-zu-viele: Mehrere Features in einer Tabelle haben mehrere Datensätze in der anderen Tabelle.

Relates unterstützen eins-zu-viele und viele-zu-eins Cardinalities, während relationship classes alle Cardinalities unterstützen. Feature-Classes und Tabellen, die an einem relate oder einer relationship class teilnehmen, müssen ein Feld desselben Datentyps (Text, Short Integer, Long Integer, Object ID usw.) besitzen. Dieses Feld ist der "Verbindungspunkt" (auch Schlüssel-Feld genannt) zwischen den beiden.

Das Relate-Beispiel

Die untenstehende Karte enthält einen Layer mit Feuerwachen und eine nicht-räumliche Tabelle, die Daten über das Personal der städtischen Feuerwehr speichert. Ein relate wurde zwischen dem Layer und der nicht-räumlichen Tabelle erstellt, welche eine eins-zu-viele Cardinality haben (jede Feuerwache hat mehrere Mitarbeiter). Das relate basiert auf einem Short Integer-Feld in beiden Tabellen, das eine Feuerwachen-ID speichert. Die Felder haben unterschiedliche Namen, aber das spielt keine Rolle.

ArcMap-Karte der Feuerwachen

Dank des relates ist es einfach herauszufinden, welches Personal welcher Feuerwache zugeordnet ist. Verwenden Sie einfach das Identify-Werkzeug und klicken Sie auf eine Feuerwache auf der Karte. Im Identify-Fenster wird unter dem Namen des Feuerwachen-Features der Name der zugehörigen Tabelle angezeigt. Durch Erweitern der Tabelle werden die mit dieser Wache verbundenen Datensätze angezeigt (im Beispiel die Washington-Wache mit sechs zugeordneten Mitarbeitern).

ArcMap Identify-Fenster zeigt Personal der Washington-Wache

Nehmen wir an, Brian Butler wird zur Adams-Wache versetzt. Sein Datensatz in der FirePersonnel-Tabelle wird bearbeitet, um die Washington-Wachenummer (2) durch die Adams-Wachenummer (202) zu ersetzen. Wenn die Bearbeitung gespeichert wird, spiegelt das Identify-Fenster seine neue Zuordnung wider. Washington hat nun nur noch fünf zugeordnete Mitarbeiter...

ArcMap Identify-Fenster zeigt Daten für Washington-Wache

...während die Personal-Liste der Adams-Wache nun Brian einschließt.

ArcMap Identify-Fenster zeigt Daten der Adams-Wache

Das Relationship Class-Beispiel

Tabelle relates sind super nützlich, um Feature-Daten schnell anzusehen, die in separaten Tabellen gespeichert sind (für effizientes Datenmanagement). Relationship classes geben Ihnen jedoch die Möglichkeit, mehr als nur Daten einfach anzusehen. Mit einer relationship class können Sie Regeln und Eigenschaften festlegen, die steuern, was passiert, wenn Daten in einer der beiden Tabellen bearbeitet werden. Sie können auch sicherstellen, dass nur gültige Bearbeitungen vorgenommen werden.

Anhand des obigen Beispiels nehmen wir an, es wurde eine relationship class namens StationsPersonnel zwischen der Feature-Class Fire Stations und der Fire Personnel-Tabelle erstellt. Außerdem verlangt die Stadt, dass alle Wachen mindestens fünf und höchstens 15 zugeordnete Feuerwehrleute haben. Eine Regel wurde in der relationship class erstellt, um diese Anforderung durchzusetzen.

ArcMap-Katalogfenster zeigt ein relationship class Objekt

Mit Brian Butlers Versetzung zur Adams-Wache bleiben für Washington fünf zugeordnete Feuerwehrleute übrig. Jean Fiorini hat jedoch eine Versetzung beantragt und ihr Antrag wurde genehmigt. Ein GIS-Techniker, der für die Pflege der GIS-Daten der Feuerwehr verantwortlich ist, aktualisiert Jeans Datensatz in der Personaltabelle mit der neuen Wachenummer. Sie erhält eine Meldung mit dem Hinweis, dass die Bearbeitung gegen eine Regel verstößt.

Hinweis: Je nach verwendeter ArcGIS-Version und Konfiguration der relationship class können Bearbeitungen, die gegen eine Regel verstoßen, möglicherweise nicht akzeptiert werden.

Datenbank weiß ohne Jean hätte Washington weniger als fünf zugeordnete Mitarbeiter. Um die Regel einzuhalten, sollte der Techniker zuerst einen Feuerwehrmann zur Washington-Wache hinzufügen und dann Jeans Datensatz bearbeiten, um ihre neue Wachen-Zuordnung widerzuspiegeln.

Eine relationship class soll sicherstellen, dass alle Datenbearbeitungen gültig sind und dass die GIS-Datenbank einer Organisation realweltliche Anforderungen genau widerspiegelt und unterstützt. Angenommen, die Person, die Jeans Versetzung genehmigt hat, wusste nicht, dass Washington danach nur noch vier Feuerwehrleute hätte. Die Regel aus der relationship class hat diese wichtige Information aufgezeigt; wir gehen davon aus, dass der GIS-Techniker das Problem kommuniziert, um späteren Verlust von Eigentum oder Leben aufgrund unzureichender Personalstärke zu verhindern.

Möchten Sie mehr über relates und relationship classes erfahren? Sehen Sie sich diese Hilfethemen an:

Für detailliertes Training und praktische Übungen mit relates, relationship classes und anderen Geodatabase-Funktionen zur Sicherstellung von Datenintegrität besuchen Sie unseren Managing Geospatial Data in ArcGIS-Kurs.

Finde mehr Beiträge mit dem Tag

ArcGIS Step by Step

ArcGIS Desktop

Kommentare

SuzanneBoden

Hi Caitlin, how you organize your data really depends on the types of data you're using and what you need to do with the data. Setting up table relates is an easy and convenient way to access nonspatial data associated with a layer in a map. The tradeoff is that relates are saved only in that map...however, for spatial layers, you can use the Save Layer to File tool to make the relates available in other maps/projects that include that layer. You can learn about that tool here: https://pro.arcgis.com/en/pro-app/latest/tool-reference/data-management/save-to-layer-file.htm.

CaitlinWilloughby

Hi Suzanne - great article! I am looking to have a spatial feature class with several (~6-8?) related tables in the geodatabase. The goal in setting up my data this way is to tie all the tables back to the spatial feature class without having to include all of the attributes of each table into one dataset. The data would be too large and get too unwieldly in that sense. There are no 'smart behaviors' or rules I need between the data, but more just a way to organize all the data and relate it back to the feature class.

I'm wondering if this is a good way to go about handling this big data 'relating' issue I have? Another question: does the spatial data need to be 'related' back to each table every time it's added to a new project?

Thanks! Caitlin

salwansabbar

Thanks Suzanne

SuzanneBoden

Also, regarding your question about table joins: they also remain in the map until removed. If you want the data to be permanently "joined," you can export the joined table to a new nonspatial table or new feature class.

SuzanneBoden

Hi, yes, you are correct. The post didn't explicitly cover many-to-many cardinality as that's a more complex topic, but it's supported in relates and relationship classes. Relates are "temporary" in the sense that they exist in a map, not as an item in a geodatabase. They remain available in the map until the map owner removes them.

salwansabbar

Hi Suzanne,

I have two questions. First, you mentioned that Relates support only one-to-many and many-to-one cardinalities. But the ArcGIS Desktop help center mentioned that relates support one-to-many and many-to-many?

Second, I concluded that the relate is temporal and not permanent, while the relationship is permanent. Also, the table join is permanent, is that right.

thank you

SuzanneBoden

Hi Vince, table joins are typically used to symbolize features in one layer using attributes from another layer or nonspatial table. Relates are great for finding and selecting features in a related layer or table, often as part of an editing workflow. Relationship classes are for when you want to do more than find and select related records, you want to enable "smart behaviors" that automate editing workflows and ensure data integrity over time.

VincentMcClarty

Hi Suzanne,

Just another question you might be able to answer about relates and relationship classes. Can you only use relates when you want to symbolise on a field in a related layer or table in ArcGIS Pro/ArcMap?

I can't see a way to do this with relationship classes, but it would be good to know if I'm missing something.

Thanks

Vince

SuzanneBoden

Hi again, Michael, to avoid the issue you mention, the recommendation is to *not* use the ObjectID field as the primary or foreign key when setting up a relationship class. I think this is the same recommendation you saw in another thread.

SuzanneBoden

Hi Michael, I don't have the answer but will have one of my colleagues reply. In the meantime, this help topic may be useful: Replication and related data—ArcGIS Help | ArcGIS Desktop.

MichaelThornton

Suzanne, I want to use a realtional Class GDB object to relate multiple tables to my feature layer. My concern is that if someone deletes a polygon and redraws it on a sde two-way replication connection, that new objectIDs will be created for the feature layer and thereby breaking my connections between the non-spatial tables and my feature layer. Do you know if esri has a way of handling this?

SuzanneBoden

Hi Andrew, great question! Cardinality depends on which way you're looking at the data (from which table). One fire station has many personnel (1-M), and many personnel are associated with one fire station (M-1). You're correct that in this example, the screenshots show a 1-M cardinality. I'll update the post. Thanks for asking the question.

AndrewBarker3

Hi Suzanne,

Isn’t this fire station and personnel example a one to many relationship? One spatial feature of fire station can have many aspatial records (personnel)?

In the post you mention this is a many to one...I’m confused how it could be. Care to share?

SuzanneBoden

Hi Liam, the choice depends on the specific need. Relates are great when people just need to quickly access and view attributes stored in a separate table from the map layer (for example), and you can create them for shapefiles as well as geodatabase feature classes. Relationship classes are the more robust solution, as they support smart behavior and more cardinalities than relates. But they do require storing data in a geodatabase and a Standard or Advanced license.

LiamHarrington-Missin

Thanks for this useful article. What I am slightly confused by is when to use one or the other. Relate feels like a "light" version of Relationship with only your licence level being the restriction. If given the choice it feels like Relationship should be the default if you can and avoid Relate as it provides a more robust solution.

Is there a situation where that is not the case, when Relate should be chosen over Relationship?

Nehmen Sie an der Diskussion teil

Angemeldete Mitglieder können Beiträge verfassen, Updates folgen und mehr. Neu hier? Registrieren Sie ein kostenloses Konto.

Schnellzugriffe

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.