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 Desktop Basic, Standard, or Advanced license.
- Relationship classes can be created and edited with an 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 many-to-one 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 tries to update Jean's record in the personnel table with the new station number. But she gets a message that the edit cannot be made.
The database knows that without Jean, Washington will have fewer than four assigned personnel. To comply with the relationship class rule, the technician must first add a firefighter to the Washington station, then edit Jean's record to reflect her new station assignment.
In this example, the relationship class ensures that data edits are valid and that the city's GIS database 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 perhaps prevented loss of property or lives down the line due to insufficient staffing. You never know.
Want to learn more about relates and relationship classes? Check out these help topics: