When comparing data relationship options in ArcGIS Pro, they can seem similar, though they each have their benefits, limitations, and reasons you might consider using each one.
If needed, see Data relationship options before comparing and deciding which data relationship option to use.
The following summary highlights reasons you might consider using each of these data relationship options in ArcGIS Pro.
Relationship classes—Relationship classes in ArcGIS Pro are useful for maintaining the referential integrity of related data. Relationship classes enable the navigation of complex relationships between different types of data, simplifying data management and analysis. This means if the primary feature is deleted or modified in the origin table, the corresponding related features in the destination table can be automatically deleted or modified, which helps to maintain the accuracy, consistency, and integrity of the data in your geodatabase. Furthermore, a relationship class is stored, persists as a dataset type in the geodatabase, and can be accessed by all users with geodatabase access.
Relates—Relates are a useful feature in ArcGIS Pro for finding and selecting features in related layers or tables, particularly during editing workflows. They can enhance editing performance by allowing you to access and analyze related attribute data. Relates are defined as a property of a layer in ArcGIS Pro and provide a convenient way to work with related data.
Joins—Joins in ArcGIS Pro are useful because they allow you to combine data from different tables or layers based on a common attribute. Joins allow you to access and display related attribute data, perform spatial analysis using combined attributes, and create more comprehensive maps and visualizations. Joins are particularly beneficial for labeling and symbology purposes, as they help integrate multiple sources of information and provide a more holistic understanding of your data.
Decide which data relationship option to use
The following table provides a detailed comparison of these three nonspatial data relationship options.
Relationship classes | Relates | Joins | |
---|---|---|---|
How to create | |||
Supported data types | Feature class or table | Feature layers, table views, subtype group layers, and raster layers with a raster attribute table | Feature layers, table views, or a raster layer with an attribute table |
Lifespan | Persists | Temporary | Temporary |
Participating data location | Both objects must reside in the same geodatabase. | Any two compatible objects | Any two compatible objects |
Stored In | Geodatabase | Project or layer | Project or layer |
Cardinality |
|
|
|
User interface for editing | ArcGIS Pro | ArcGIS Pro | SQL queries |
User interface for navigating | ArcGIS Pro | ArcGIS Pro | 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 |
Typical uses | Ensuring data integrity | Editing with low overhead | Labeling, symbology |
Benefits | Supports query, editing, referential integrity, attributed relationships, and relationship rules. | Creating relates between multiple tables, allows you to query related tables in different formats. There is no editing overhead, and it can cross workspace and data source type. | Creates a single virtual table from two tables. There is no editing overhead, and it can cross workspace and data source type. Use the additional attribute information in SQL queries, labeling, and symbology. |
Limitations | Incurs editing overhead. It must be defined only between tables in same geodatabase within the same user schema, and it still requires joins for SQL query, labeling, and symbology. | Relates do not modify data; they are a property of the layer. There is no referential integrity and no messaging. It still requires joins for SQL query, labeling, and symbology. | Joins will always reside in the layer, not with the data. There is no referential integrity, no messaging, and no support for many-to-many relationships. One-to-many relationships involving feature classes are not supported. |
Additional notes |
|
|
To learn more about relationship classes, see Geodatabase relationship class types.