Deciding between relationship classes, relates, and joins

This topic applies to ArcGIS for Desktop Standard and ArcGIS for Desktop Advanced only.

NoteNote:

Although relationship classes can be both created and edited in ArcGIS for Desktop Advanced and ArcGIS for Desktop Standard, they are read-only in ArcGIS for Desktop Basic. The feature classes participating in the relationship class will also be read-only in ArcGIS for Desktop Basic.

Relationship classes help ensure referential integrity. For example, the deletion or modification of one feature could delete or alter a related feature. Furthermore, a relationship class is stored in the geodatabase, which makes it accessible to anyone who uses the geodatabase.

On-the-fly relationships, also called relates, are defined as a property of an ArcMap layer. Use them for improved editing performance.

Joins are best suited for labeling and symbology. You define joins through the relational database to make standard SQL queries cross the database as well as a variety of data sources.

Relationship classes

On-the-fly relates

Joins

Typical uses

Ensuring data integrity

Editing with low overhead

Labeling, symbology

Scope

Geodatabase

Cross database or data source

Cross database or data source

Framework

Geodatabase data model

Defined in map layer

Relational database/SQL

User interface for editing

ArcMap

VBA application in ArcMap

SQL queries

User interface for navigating

ArcMap

ArcMap

SQL queries

Composite objects

Yes

No

No

Referential integrity

Yes

No

No

Messaging

Yes

No

No

Attributes

Yes

No

No

Relationship rules

Yes

No

No

Cardinality

One-to-one, one-to-many, many-to-many

One-to-one, one-to-many, many-to-many

One-to-one, many-to-one

Pros

Manages referential integrity and messaging behavior via ArcMap attributes inspector

No editing overhead, can cross workspace and data source type

No editing overhead; can cross workspace and data source type; can be used for SQL queries, labeling, and symbology

Cons

Incurs editing overhead; must be defined only between tables in same geodatabase within the same user schema; still requires joins for SQL query, labeling, and symbology

No referential integrity; no messaging; no support for many-to-many cardinality; still requires joins for SQL query, labeling, and symbology

No referential integrity, no messaging, no support for many-to-many relationships; one-to-many relationships involving feature classes not supported

Relationship classes, relates, and joins

Related Topics

2/10/2012