6.3 Attribute Joins, Relates, and Relationship Classes

Attribute Joins, Relates, and Relationship Classes in ArcGIS Pro 3.x

In real-world GIS applications, spatial data is rarely self-contained within a single feature class. Often, you must associate spatial features (like polygon boundaries) with external tabular data (like census demographics or tax assessment records).

ArcGIS Pro 3.x provides three primary mechanisms for associating disparate tables: Joins, Relates, and Relationship Classes. Choosing the correct method is a frequent test subject on the EAPA_2025 exam, and the decision hinges entirely on two factors: Cardinality (the numerical relationship between the records) and Persistence (where and how the connection is saved).

Understanding Cardinality

Before executing any table association, you must identify the cardinality. Cardinality describes how records in the target table (origin) relate to records in the join table (destination):

• One-to-One (1:1): Each parcel polygon corresponds to exactly one zoning code in the zoning table.
• Many-to-One (M:1): Many parcel polygons can share the exact same zoning code.
• One-to-Many (1:M): One parcel polygon can be owned by multiple people (a list of owners in a standalone table).
• Many-to-Many (M:N): Many parcels can be owned by many combinations of owners.

1. Attribute Joins

An Attribute Join appends the fields of one table to those of another through a common attribute field, known as the key.

Key Characteristics of Joins:

• Supported Cardinality: Joins are designed exclusively for 1:1 or M:1 relationships.
• Tabular Behavior: The fields from the join table are virtually appended to the target table. When you open the attribute table of the target layer, it appears as a single, wide table.
• Analytical Power: Because the fields are appended, you can symbolize, label, and query the spatial layer using the newly joined fields. For example, you can join a CSV of population data to a state polygon layer and instantly symbolize the states by population density.
• Persistence: Joins are dynamic and temporary. They are saved within the specific map document or layer file (.lyrx), but they are not saved in the underlying geodatabase. If you send the feature class to a colleague without exporting it, the join will be lost.

The Danger of 1:M Joins

Exam Tip: What happens if you attempt an Attribute Join on a 1:M relationship? ArcGIS Pro will not produce a hard error. Instead, it will match the target record to the first matching record it finds in the join table and completely ignore the rest. This silently creates inaccurate, incomplete data. Therefore, standard Attribute Joins must never be used for 1:M data.

Making Joins Permanent

To make an attribute join permanent, you must physically write the joined data to disk. You do this by right-clicking the layer and selecting Data > Export Features. This creates a brand-new feature class in your geodatabase containing the combined schema.

2. Relates

A Relate defines a relationship between two tables, but unlike a join, it does not physically or virtually append the fields together.

Key Characteristics of Relates:

• Supported Cardinality: Relates are the standard solution for 1:M or M:N relationships.
• Tabular Behavior: The target table and the related table remain physically separate in the interface. However, when you select a record in the target table, you can click the 'Related Data' button to automatically select and view the associated records in the related table.
• Interface Integration: Related data is fully integrated into ArcGIS Pro Pop-ups. Clicking a parcel will show the parcel attributes, followed by a list of all related owners.
• Limitations: Because fields are not appended to the target table, you cannot symbolize or label the target spatial layer based on fields from the related table. If you relate a table of building inspections (1:M) to a building footprint, you cannot color the building based on the date of the most recent inspection using just a Relate.
• Persistence: Like joins, relates are temporary and saved only in the project or layer file.

3. Relationship Classes

A Relationship Class is a powerful, permanent object stored within an Enterprise, File, or Mobile geodatabase. It manages the associations between two feature classes or tables at the database level, rather than at the map level.

Key Characteristics of Relationship Classes:

• Persistence: Unlike Joins and Relates, Relationship Classes are stored permanently in the geodatabase schema. Anyone who accesses the geodatabase automatically benefits from the relationship.
• Cardinality: Supports all cardinalities natively (1:1, 1:M, M:N).
• Directionality: A Relationship Class is strictly defined by an Origin class (containing the Primary Key) and a Destination class (containing the Foreign Key).
• Referential Integrity: The primary reason to use a Relationship Class is to enforce data integrity rules during editing workflows.

Simple vs. Composite Relationship Classes

Understanding the distinction between simple and composite relationship classes is a guaranteed exam topic.

• Simple Relationship Class: The origin and destination features exist independently. They are linked, but deleting one does not affect the existence of the other. Example: A relationship between bus stops (origin) and bus routes (destination). If you delete a bus stop, the route still exists.

• Composite Relationship Class: The destination's existence depends entirely on the origin. This represents a "part-to-whole" relationship. Deleting the origin feature automatically deletes the related destination features. This behavior is known as a Cascading Delete. Example: A relationship between a utility pole (origin) and the transformers mounted on it (destination). If the utility pole is demolished, the transformers must mathematically be removed from the database as well.

Advanced Editing Behaviors

Relationship Classes allow for advanced editing. For example, if you move a parcel boundary (origin), you can configure the relationship class to automatically move related address point features (destination) so they remain geometrically synchronized.

Comprehensive Method Comparison Matrix