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 en Relationship Classes Uitgelegd

SuzanneBoden

Bijgewerkt op 7 februari 2022

Het verschil tussen relates (vaak table relates genoemd) en relationship classes is een bron van veel verwarring, vooral voor nieuwe ArcGIS-gebruikers. Hoewel ze vergelijkbaar klinken, verwijzen de termen naar verschillende dingen. Beide hebben voordelen en er zijn redenen om elk van hen te gebruiken. Hier zijn de belangrijkste zaken om te weten.

Een relate bestaat in een kaart- of laagbestand.
Een relationship class is een object in een geodatabase.
Relates kunnen worden gemaakt en bewerkt met een ArcGIS Pro of ArcGIS Desktop Basic, Standard, of Advanced-licentie.
Relationship classes kunnen worden gemaakt en bewerkt met een ArcGIS Pro of ArcGIS Desktop Standard of Advanced-licentie. Ze zijn alleen-lezen met een Basic-licentie.

Alles duidelijk nu? Nee? Laten we dan verder gaan.

De terminologie ontleden

Relates zijn geweldig omdat ze je in staat stellen om functies in een laag te selecteren en vervolgens gemakkelijk gerelateerde functies in een andere laag of gerelateerde records in een niet-ruimtelijke tabel te zien. Relationship classes zijn geweldig omdat ze "slim gedrag" mogelijk maken. Je kunt regels instellen voor hoe de deelnemende feature classes of tabellen zich gedragen wanneer er iets gebeurt. Bijvoorbeeld, met een relationship class ingesteld, als een feature wordt verwijderd, kan het bijbehorende record in de andere feature class of tabel ook automatisch worden verwijderd.

Zowel relates als relationship classes vertrouwen op cardinality, wat beschrijft hoe records in twee verschillende tabellen aan elkaar gerelateerd zijn — cardinality kan één-op-één, één-op-veel, veel-op-één, of veel-op-veel zijn.

Eén-op-één: Elke feature heeft precies één gerelateerd record in de andere tabel.
Eén-op-veel: Features in de ene tabel kunnen meer dan één gerelateerd record in de andere tabel hebben.
Veel-op-één: Meerdere features in de ene tabel hebben één gerelateerd record in de andere tabel.
Veel-op-veel: Meerdere features in de ene tabel hebben meerdere records in de andere tabel.

Relates ondersteunen één-op-veel en veel-op-één cardinaliteiten, terwijl relationship classes alle cardinaliteiten ondersteunen. Feature classes en tabellen die deelnemen aan een relate of een relationship class moeten een veld van hetzelfde gegevenstype hebben (tekst, korte integer, lange integer, object ID, enz.). Dat veld zal het "verbindingspunt" (ook wel key field genoemd) tussen de twee zijn.

Het Relate Voorbeeld

De onderstaande kaart bevat een laag met brandweerkazernes en een niet-ruimtelijke tabel die gegevens opslaat over het personeel van de brandweer van de stad. Er is een relate gemaakt tussen de laag en de niet-ruimtelijke tabel, die een één-op-veel cardinaliteit hebben (elke brandweerkazerne heeft meerdere personeelsleden). De relate is gebaseerd op een korte integer veld in beide tabellen dat een brandweerkazerne-ID nummer opslaat. De velden hebben verschillende namen, maar dat maakt helemaal niet uit.

ArcMap kaart van brandweerkazernes

Dankzij de relate is het gemakkelijk om te achterhalen welk personeel aan welke brandweerkazerne is toegewezen. Gebruik gewoon het Identify-gereedschap en klik op een brandweerkazerne op de kaart. In het Identify-venster wordt onder de naam van het brandweerkazerne-object de naam van de gerelateerde tabel weergegeven. Het uitvouwen van de tabel toont de records die aan die kazerne zijn gekoppeld (in dit voorbeeld het Washington-kazerne, dat zes toegewezen personeelsleden heeft).

ArcMap Identify venster toont Washington kazerne personeel

Stel dat Brian Butler wordt overgeplaatst naar het Adams-kazerne. Zijn record in de FirePersonnel-tabel wordt bewerkt om het Washington-kazerne nummer (2) te vervangen door het Adams-kazerne nummer (202). Wanneer de bewerking wordt opgeslagen, zullen de gegevens die in het Identify-venster worden getoond zijn nieuwe toewijzing weerspiegelen. Washington heeft nu slechts vijf toegewezen personeelsleden...

ArcMap Identify venster toont data voor Washington kazerne

...terwijl de personeelslijst van het Adams-kazerne nu Brian bevat.

ArcMap Identify venster toont Adams kazerne data

Het Relationship Class Voorbeeld

Tabel relates zijn superhandig om snel featuregegevens te bekijken die in aparte tabellen zijn opgeslagen (voor efficiënte gegevensbeheerdoeleinden). Relationship classes geven je echter de mogelijkheid om meer te doen dan alleen gemakkelijk gegevens bekijken. Met een relationship class kun je regels en eigenschappen instellen die bepalen wat er gebeurt wanneer gegevens in een van beide tabellen worden bewerkt. Je kunt ook ervoor zorgen dat alleen geldige bewerkingen worden uitgevoerd.

Gebruikmakend van het bovenstaande voorbeeld, stel dat er een relationship class genaamd StationsPersonnel is gemaakt tussen de Fire Stations feature class en Fire Personnel-tabel. Stel ook dat de stad vereist dat alle kazernes minimaal vijf toegewezen brandweerlieden en maximaal 15 toegewezen brandweerlieden hebben. Er is een regel gemaakt in de relationship class om aan deze eis te voldoen.

ArcMap Catalog venster toont een relationship class object

Met Brian Butlers overplaatsing naar het Adams-kazerne blijft Washington over met vijf toegewezen brandweerlieden. Jean Fiorini heeft echter om overplaatsing gevraagd en haar verzoek is goedgekeurd. Een GIS-technicus die verantwoordelijk is voor het onderhouden van de GIS-gegevens van de brandweer werkt Jeans record bij in de personeelslijst met het nieuwe kazerne nummer. Ze krijgt een bericht dat waarschuwt dat deze bewerking een regel heeft geschonden.

Opmerking: Afhankelijk van welke versie van ArcGIS je gebruikt en hoe de relationship class is geconfigureerd, kunnen bewerkingen die conflicteren met een regel van de relationship class mogelijk niet worden geaccepteerd.

De database weet dat zonder Jean Washington minder dan vijf toegewezen personeelsleden zal hebben. Om aan de regel van de relationship class te voldoen, moet de technicus eerst een brandweerman toevoegen aan het Washington-kazerne en daarna Jeans record aanpassen om haar nieuwe kazerne-toewijzing weer te geven.

Een relationship class is bedoeld om ervoor te zorgen dat alle gegevensbewerkingen geldig zijn en dat de GIS-database van een organisatie nauwkeurig weerspiegelt en ondersteunt wat er in de echte wereld nodig is. Stel dat degene die Jeans overplaatsing goedkeurde niet besefte dat Washington dan nog maar vier brandweerlieden zou hebben. De regel van de relationship class bracht die belangrijke informatie aan het licht, en we gaan ervan uit dat de GIS-technicus dit probleem communiceert om verlies van eigendom of levens later door onvoldoende bezetting te voorkomen.

Wil je meer leren over relates en relationship classes? Kijk dan eens naar deze helponderwerpen:

Voor gedetailleerde training en praktische oefening met relates, relationship classes en andere geodatabase-mogelijkheden die gegevensintegriteit afdwingen, volg onze Managing Geospatial Data in ArcGIS-cursus.

Vind meer berichten getagd met

ArcGIS Step by Step

ArcGIS Desktop

Reacties

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?

Doe mee aan het gesprek

Aangemelde leden kunnen berichten plaatsen, updates volgen en meer. Nieuw hier? Registreer een gratis account.

Snelle links

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