You can make data relationship associations in several ways, including by joining or relating tables temporarily in your map or by creating relationship classes in your geodatabase that maintain more permanent associations.
Click the following links to further explore each of these data relationship options:
See Data relationship comparison to access a table matrix to help you decide which data relationship option to use.
Tip:
To learn more about these data relationship options applied to a real-world scenario, access this guided Learn ArcGIS lesson that provides a more in-depth review of the workflow steps and data needed to create a join, a relate, and improve campsite data quality using a relationship class.
Joins
A join is a temporary table association where the fields and records from the join table are matched and dynamically appended to the fields and records of the input table.
When a join is created, the resulting joined information is stored in the layer's properties and persists temporarily inside the one map it was created in and can be saved with your project. Only users who have access to your project will be able to see the joined information.
Joins are based on a common key field that must exist in both participating tables. The name of this field in both tables can be different, but the field data type and the type of information or the values stored within this field in both tables must be the same.
Supported data types for a join include feature layers, tables, table views, and raster layers with a raster attribute table and can have one of two cardinality options.
- One to one (1:1)
- Many to one (M:1)
Note:
One to many (1:M) or many to many (M:N)—You can create a join under the circumstances where a one-to-many or many-to-many relationship exists, however, depending on the data source, there are differences between how tools and other layer-specific settings work. When joining tables that reside in the same geodatabase, the default option is to keep all records. If you are using nondatabase data, such as shapefiles or dBASE tables, to create the join, only the first matching record is returned.
See Add Join to learn more about using joins with various inputs and possible outcomes.
In the following example, each natural asset (National Parks) is managed by a specific organization. To help maintain data consistency, using a many-to-one join, records from the National Parks layer have been joined with its specific organization to create a more complete picture of park assets and who owns them.
Once the join has been established, a single virtual table is created from the join and input tables. The resulting joined information is stored in the layer's properties and persists temporarily inside the one map it was created in and can be saved with your project. The additional fields in the joined table can be used to symbolize, label, query, or analyze the layer's features and the field properties—such as aliases, visibility, and number formatting—are maintained when a join is added or removed.
To learn more about joins, see Introduction to joins and relates.
Tip:
If you don't have a common field, but you do have common locations, you can perform a spatial join. Spatial joins are different from attribute-driven joins, relates, and relationship classes because they are not dynamic and require you to save the results to a new output layer. A spatial join determines which features to join based on spatial relationships like proximity and containment. To learn more about spatial joins, see Join data by location.
Relates
A relate is a property of a layer in ArcGIS Pro. A relate associates one or more tables to each other through a key field without physically joining the tables.
In a relate, tables remain separate and do not appear physically joined. Still, when a feature or record in one table is selected, the related records associated with the key field in the related table are selected, enabling you to access and analyze this related data.
Relates can be helpful for data analysis, exploration, and visualization tasks. You can easily access additional information about a feature or location by establishing a relate without duplicating data. For example, you can create a relate between a layer of cities and a table of annual rainfall data to view the rainfall data for each city.
Relates can be created for shapefiles and geodatabase feature classes and can have one of three cardinality options between records,
- One to one (1:1)
- One to many (1:M)
Many to many (M:N)
See Add Relate to learn more about adding and using relates.
Relates can only exist within a project or layer file and are only available as long as the project is open. To save a relate for use in another project or create a permanent relate, you can use geoprocessing tools such as Save Layer To File or Create Relationship Class, respectively.
For example, in a park management scenario, relates can be helpful to connect static details such as campsite names and locations with dynamic information such as check-in and check-out times, site conditions, and pet regulations. In the following example, a one-to-many relate has been created between individual campsite and campsite attributes. By creating a relate, you can query a single campsite and access its related multiple attributes describing details for that campsite.
To learn more about relates, see Introduction to joins and relates.
Relationship classes
A relationship class is a dataset type in the geodatabase that stores information about the relationship or association of related records between two feature classes, between a feature class and a nonspatial table, or between two nonspatial tables.
A relationship class is physically stored and persists in the geodatabase and maintains a more permanent data relationship. You can create a relationship class in your geodatabase one time. Anyone who has access to the geodatabase where the relationship class resides, along with access to the datasets participating in the relationship class, will be able to access the relationship class.
Both participants in a relationship class must be stored in the same geodatabase. Similar to a feature class, a relationship class can be created and reside at the root level of a geodatabase or within a feature dataset. A relationship class is defined by a primary key-foreign key relationship between two tables, and can have one of three cardinality options.
- One to one (1:1)
- One to many (1:M)
Many to many (M:N)
Learn more about cardinalities and how they can be used with relationship classes
You can set up a relationship class so that editing a record in one table automatically updates related records in the other table.
In the following example, a one-to-many relationship class has been created between campground facilities and campsites located at each campground. Using this one-to-many relationship makes it possible to select a single campground and access the associated campsites and attributes of each campsite for that campground. 
Once created, a relationship class persists in the geodatabase, and allows for complex relationships and interactions between the participating datasets. With a relationship class, you can set rules and properties that control what happens when data in either table is edited, as well as ensure that only valid edits are made. This relationship class behavior helps to ensure data integrity and makes data management more consistent and efficient.
For example, if a campground in the origin table is deleted, the corresponding campsites located in the related destination table, that are assigned to that campground are also deleted, maintaining the accuracy and reliability of the data. 
Optionally, when creating a relationship class, you can specify whether the relationship class will be attributed. An attributed relationship class can store additional attributes and details about the relationship itself.
To learn more about relationship classes, see Geodatabase relationship class types.