Relates vs. Relationship Classes
Updated February 7, 2022
It seems like there's always been confusion around the terms "relate" and "relationship class." In this post, we'll attempt to clear it up. The example screenshots are from ArcMap but the concepts apply to ArcGIS Pro as well.
The Basics
- A relate (also called a table relate) is a property of a layer in ArcGIS Pro or ArcMap. You create a table relate so that you can query and select features in one layer and see all the related features in another layer or table. A table relate exists only in a map or layer file (.lyr).
- A relationship class is an object in a geodatabase that stores information about a relationship between two feature classes, between a feature class and a nonspatial table, or between two nonspatial tables. Both participants in a relationship class must be stored in the same geodatabase.
- Cardinality controls how relates and relationship classes are set up. Cardinality is not a measure of a St. Louis baseball fan's fervor, it is a description of how records in two different tables are related to one another. Cardinality may be one-to-one, one-to-many, many-to-one, or many-to-many.
- Table relates are created between tables that have a one-to-many or many-to-one cardinality. Relationship classes support all cardinalities.
- When you create a table relate or a relationship class, you specify the field in each table that the relationship will be based on. The fields must be the same data type (i.e., text, short integer, long integer, object ID, etc.).
- Relates can be created and edited with a Basic, Standard, or Advanced license.
- Relationship classes can be created and edited with a Standard or Advanced license. They are read-only with a Basic license.
All clear now? No? OK, let's dig in more.
The Example
In the Table of Contents in the map above, you see a layer of city fire stations and a nonspatial table that stores data about the city's fire department personnel. A table relate has been created between the layer and the nonspatial table based on a short integer field in each table that stores a fire station ID number.
What happens when a station is selected on the map?
Below, you see the attribute table for the fire station layer and the fire personnel table. The option to show only selected features is being used for both tables. Notice that while only one fire station record is selected (the Washington station), six records in the fire personnel table are selected.
This tells you that the Fire Stations layer has a one-to-many cardinality with the fire personnel table. For each fire station, multiple fire personnel are associated. In this case, six firefighters are assigned to the Washington station. Because the tables are related, when you select a station you can easily find out who works at the station. Table relates are bi-directional, which means you can also select a record in the fire personnel table and access the name of the station to which the firefighter is assigned.
You don't even need to select a feature or open the tables; you can quickly view the information by using the Identify tool. The name of the related table displays under the feature name on the left side of the Identify window. Expanding the related table reveals the related records. Clicking a related record displays the data stored in the related table.
Suppose Brian Butler is transferring to the Adams station. You are going to edit the FirePersonnel table to reflect this. Here are the steps for accomplishing this using our example.
- Start an edit session.
- In the Fire Personnel table, select Brian Butler's record.
- In the Number_ field, change the value to 1714 (the ID number for the Adams station).
- Close the table and save your edits.
- Click the Adams station with the Identify tool.
- Brian Butler now appears in the list of personnel associated with the Adams station.
- Click the Washington station with the Identify tool.
- Brian Butler's record no longer displays.
Why Use a Relationship Class?
Table relates are useful for quickly accessing and viewing information about the real world that is actually stored in two different tables. Relationship classes offer more powerful capabilities, however.
In addition to selecting records in one table and seeing related records in the other, with a relationship class you can set rules and properties that control what happens when data in either table is edited, as well as ensure that only valid edits are made. You can set up a relationship class so that editing a record in one table automatically updates related records in the other table.
Using the example above, suppose a relationship class is created between the Fire Stations layer and the fire personnel table. The city has a requirement that all stations have a minimum of five firefighters and a maximum of 15 firefighters. A rule has been created for the relationship class that reflects this requirement.
At the end of the table relate example, the Washington station had five assigned firefighters. Now, with the relationship class in place, if a staffer tries to assign a different station number to one of the Washington station firefighters, an error message will display and they will understand that a rule exists that requires all stations to have at least five firefighters assigned. Before editing an existing firefighter's station number, they will have to assign a new firefighter to the Washington station. After that is done, they can change the station number for the existing Washington station firefighter to reflect a transfer.
The relationship class ensures that data edits are valid and supports the fire department's goal that personnel assignments comply with the city's requirement.
Remember
- Table relates exist only in a map or layer file.
- Relationship classes exist as discrete objects in a geodatabase. If one of the participating tables is deleted from the geodatabase, the relationship class is deleted as well.
- Both table relates and relationship classes allow users to access and view information for related features from either table.
- Relationship classes are often used to ensure data integrity. They help make your geodatabase smart.
A lot more could be said about relates and relationship classes, but in the interest of simplicity we will end the post now. Hopefully, some of the confusion has been dispelled. For more information on this topic, check out this help topic.