Relates and Relationship Classes Explained
Updated February 7, 2022
The difference between relates (often called table relates) and relationship classes is a source of much confusion, especially for new ArcGIS users. Though they sound similar, the terms refer to different things. Both have benefits and there are reasons to use each one. Here are the main things to know.
- A relate exists in a map or layer file.
- A relationship class is an object in a geodatabase.
- Relates can be created and edited with an ArcGIS Pro or ArcGIS Desktop Basic, Standard, or Advanced license.
- Relationship classes can be created and edited with an ArcGIS Pro or ArcGIS Desktop Standard or Advanced license. They are read-only with a Basic license.
All clear now? No? Let's continue then.
Deconstructing the Terminology
Relates are great because they allow you to select features in a layer, then easily see related features in a different layer or related records in a nonspatial table. Relationship classes are great because they enable "smart behavior." You can set up rules for how the participating feature classes or tables behave when something happens. For example, with a relationship class in place, if a feature is deleted, then its associated record in the other feature class or table can be automatically deleted as well.
Both relates and relationship classes rely on cardinality, which describes how records in two different tables are related to one another—cardinality can be one-to-one, one-to-many, many-to-one, or many-to-many.
- One-to-one: Every feature has exactly one related record in the other table.
- One-to-many: Features in one table may have more than one related record in the other table.
- Many-to-one: Multiple features in one table have one related record in the other table.
- Many-to-many: Multiple features in one table have multiple records in the other table.
Relates support one-to-many and many-to-one cardinalities, while relationship classes support all cardinalities. Feature classes and tables that participate in a relate or a relationship class must have a field of the same data type (text, short integer, long integer, object ID, etc.). That field will be the "connection point" (AKA key field) between the two.
The Relate Example
The map below contains a layer of fire stations and a nonspatial table that stores data about the city's fire department personnel. A relate was created between the layer and the nonspatial table, which have a one-to-many cardinality (every fire station has multiple personnel). The relate is based on a short integer field in both tables that stores a fire station ID number. The fields have different names, but that doesn't matter at all.
Thanks to the relate, it's easy to find out which personnel are assigned to any given fire station. Just use the Identify tool and click a fire station on the map. In the Identify window, the related table name displays below the fire station feature name. Expanding the table shows the records associated with that station (the Washington station in this example, which has six assigned personnel).
Suppose Brian Butler is transferred to the Adams station. His record in the FirePersonnel table is edited to replace the Washington station number (2) with the Adams station number (202). When the edit is saved, the data shown in the Identify window will reflect his new assignment. Washington now has only five assigned personnel...
...while the Adams station personnel list now includes Brian.
The Relationship Class Example
Table relates are super-useful to quickly view feature data stored in separate tables (for efficient data management purposes). Relationship classes give you the ability to do more than easily view data, however. With a relationship class, you can set rules and properties that control what happens when data in either table is edited. You can also ensure that only valid edits are made.
Using the example above, suppose a relationship class named StationsPersonnel has been created between the Fire Stations feature class and Fire Personnel table. Also suppose the city requires that all stations have a minimum of five assigned firefighters and a maximum of 15 assigned firefighters. A rule has been created in the relationship class to enforce this requirement.
With Brian Butler's transfer to the Adams station, Washington is left with five assigned firefighters. Jean Fiorini, however, has requested a transfer, and her request was approved. A GIS technician responsible for maintaining the fire department's GIS data updates Jean's record in the personnel table with the new station number. She gets a message warning her that the edit has broken a rule.
- Note: Depending on which version of ArcGIS you are using and how the relationship class was configured, edits that conflict with a relationship class rule may not be accepted.
The database knows that without Jean, Washington will have fewer than five assigned personnel. To comply with the relationship class rule, the technician should first add a firefighter to the Washington station, then edit Jean's record to reflect her new station assignment.
A relationship class is intended to ensure that all data edits are valid and that an organization's GIS database accurately reflects and supports real-world needs. Suppose the person who approved Jean's transfer didn't realize that Washington would be left with only four firefighters. The relationship class rule surfaced that piece of key information, and we will assume the GIS technician communicates the issue to prevent loss of property or lives down the line due to insufficient staffing.
Want to learn more about relates and relationship classes? Check out these help topics:
For detailed training and hands-on practice with relates, relationship classes, and other geodatabase capabilities that enforce data integrity, take our Managing Geospatial Data in ArcGIS class.