Review tips, tools, and geodatabase capabilities in ArcGIS Pro when using related data from a relationship class.
Copy data in a relationship class
You can copy any feature dataset, feature class, or table from a geodatabase to a destination geodatabase using Copy 
and Paste 
. For every feature dataset, feature class, and table you copy and paste, the result is a new feature dataset, feature class, and table in the destination geodatabase with all the features or records from the source data.
When you copy and paste, you copy any dependent data as well. Suppose you copy a feature class or table participating in a relationship class. In that case, the relationship class and all other feature classes or tables in the relationship class are also copied. The same is true for a feature class with feature-linked annotation; the feature-linked annotation is copied too. When you copy a feature class with attribute rules, all attribute rules and any additional feature classes or sequences referenced in the attribute rules are copied. For a feature class that has a domain, subtype, or index, the domain, subtype, or index is also copied.
Caution:
The Feature Class To Geodatabase geoprocessing tool copies only simple feature classes. For example, if feature classes are contained within feature datasets to be exported, only the feature classes are copied. The feature dataset and any advanced elements—such as topologies, relationship classes, or attachments—will not be copied to the output geodatabase.
Learn more about copying feature datasets, feature classes, and tables to a geodatabase
Editing data in a relationship class
A relationship class can be set up so that when you modify an object, related objects update automatically. This can involve physically moving related features, deleting related objects, or updating an attribute. For example, you could set up a relationship such that whenever you move a utility pole, attached transformers and other equipment move with it. By setting rules, a relationship class can restrict the type of relations that are valid. For example, a pole may support a maximum of three transformers. A steel pole may support class A transformers but not class B transformers. Relationship classes actively maintain the referential integrity between related classes, even if one of them has not been added to the ArcGIS Pro session. When an object that participates in simple relationships with other objects is deleted from the geodatabase, all its relationships are also deleted. If the deleted object is the origin object, the foreign key in all related destination objects is null. The origin object is unaffected if the deleted object is a destination object.
Suppose the relationships are maintained as rows in an intermediate table (many-to-many relationships or attributed relationships). When an origin or destination object and its relationships are deleted, the rows corresponding to those relationships are deleted from the intermediate table.
In the Attributes pane 
, you can create and remove relationships
between selected features and add new relationships between
selected features and nonspatial records in a table. The associated
features must participate in the same relationship
class.
See Edit feature relationships to learn more about editing data in a relationship class.
By providing automatic updates to related objects, a relationship class can save you from performing additional edit operations.
See Versioning data in a relationship class to learn more about editing and managing relationship classes and its related data when stored in an enterprise geodatabase.
Editor tracking and relationship classes
Editor tracking provides a setting on feature classes and tables that automatically records information about any inserts and updates made to the class. It maintains a record of the editor who created or modified the data and a timestamp of when the edit occurred. Editor tracking applies to operations on existing datasets only and does not apply to operations that create datasets.
Not all relationship class types support editor tracking. When a relationship class is created with many-to-many (M:N) cardinality or with attributes, an intermediate table is created. Editor tracking
can only be enabled on these table-based attributed relationship classes. 
Set a relationship class split policy
When a line or polygon feature class is created, a split model is automatically defined on the feature class by default. The split model determines how the feature's geometry and attributes within the table will be divided when a feature is split during editing.
In addition to defining the split model on a feature class, you can also define the split policy on a relationship class. The relationship class split policy determines how related records within the destination table are treated when a feature in the origin feature class is split during editing.
Depending on the relationship class type, simple or composite, different split policy behaviors can be defined, including Default (simple), Default (composite), and Duplicate related objects.
See Set up a relationship class split policy for more details on how to set and use this relationship class property.
Working with relationship attributes
ArcGIS Pro contains tools that help you build and maintain a relationship.
- If you have objects in the origin and destination, but they are not yet related, you can manually establish relations one at a time in ArcGIS Pro. To do this, select one or more objects in the destination, select one or more objects in the origin, open the Attributes dialog box, and relate them. You can do this if at least one side of the relationship contains features.
- You can select an object and create a related object in a related class, if it is a new record in a table and not a feature.
- You can remove an object from a relationship with the Attributes dialog box.
- Once you've finished editing a composite relationship or a relationship with rules, you can use validation or constraint attribute rules to check your work and enforce the referential integrity of your data.
Attribute indexes on attributed relationship classes
Attribute indexes can speed up joins and quickly locate records that match an attribute query on tables, feature classes, shapefiles, or attributed relationship classes.
For most attribute queries, looking up a record with an index is faster than starting at the first record and searching through the entire table. Once you have data in a table, feature class, shapefile, or attributed relationship class, you can create attribute indexes for the fields you frequently query.
Attribute rules on data in a relationship class
Attribute rules can be used to read and edit related records for datasets that participate in relationship classes in a geodatabase.
Rules can be applied to feature classes and tables participating in relationship classes, including attachments and feature-linked annotation. Attribute rules can also intercept edit events from updates made to the origin and destination classes in a relationship; that includes adding, removing, or deleting a related record. For example, an immediate calculation attribute rule can update an attribute field when a feature is added to a related feature class.
When working with relationship classes, you can read related records using Arcade functions that take input features and return the associated related records. Related records from relationship classes can also be edited using calculation rules based on the dictionary return.
Arcade functions and script expressions can be used in calculation attribute rules to access related data in a relationship class. Read related records for a relationship class using the Arcade functions FeatureSetByName, FeatureSetByRelationShipName, and FeatureSetByRelationshipClass. You can also add a new related record for a relationship class on an update edit. 
Caution:
When a many-to-many or attributed relationship class is created, a new intermediate table is created. This intermediate table is not recognized as an object class in the geodatabase. As a result, geodatabase behaviors such as attribute rules, domains, subtypes, contingent values, and default values cannot be applied to or used with this intermediate table.
Validation or constraint attribute rules can be created and applied to enforce relationship class rules.
Learn more about attribute rules and relationship classes and validating relationship class rules.
Privileges and relationship classes
To allow other database users to view or modify the contents of any data in a database or enterprise geodatabase, you must grant them the privileges to do so.
When privileges are granted to a feature class or table that participates in a relationship class, privileges must be granted to both the origin and destination classes. If the origin and destination feature classes are in the same feature dataset, they have the same set of privileges since privileges are granted at the feature dataset level. However, when the origin or destination class is not in the same feature dataset, you must ensure the proper privileges are granted to both the origin and destination classes. If the relationship class is either attributed or has many-to-many cardinality, privileges are automatically propagated to the intermediate table when you assign privileges to the origin class.
Learn more about granting and revoking privileges on datasets in an enterprise geodatabase
Versioning data in a relationship class
Relationship classes are stored and persist in the geodatabase and help facilitate editing. A relationship class in an enterprise geodatabase is supported with the following editing workflow options:
- Branch versioning
- Traditional versioning
- Traditional versioning (move edits to base)
- Nonversioned editing
When relationship classes and related data are stored in an enterprise geodatabase, edits to the data can be managed with versions. In an enterprise geodatabase with multiple editors, versions allow multiple users to work with and edit the same features or records in a relationship at the same time without applying locks or duplicating data. Versions give each editor their own unique, isolated view of the data.
Branch versioning and relationship class tips
You cannot register a dataset as branch versioned if the dataset participates in a relationship class and the primary key of the relationship is the ObjectID field.
Tip:
Use the Migrate Relationship Class geoprocessing tool to migrate an object ID-based relationship class to a global ID-based relationship class.
In branch versioning, conflicts can be discovered during the reconcile process when the named version is reconciled with the default version. For example, a conflict will occur when a topologically related feature or relationship class is modified in both the current named version and the default version.
Tip:
Review the named and default versions' editing conflicts using the Conflicts view. 
In branch versioning, when you resolve conflicts, you are deciding which representation of the features and attributes you want to keep. Deleting a feature from an origin relationship class may trigger a message to delete a feature from the destination relationship class. Therefore, be aware of the ramifications of replacing conflicts involving source feature classes participating in relationship classes.
Learn more about resolving conflicts with relationship classes using branch versioning
Traditional versioning and relationship class tips
Traditional versioning provides the flexibility to work within versions for long transactions when accessed directly from the enterprise geodatabase and a simplified editing experience when using feature services to accommodate shorter transactions.
Traditional versioning with the option to move edits to base is an optional form of traditional versioning. It allows editors and applications direct access to the base data while allowing other editors to work in their isolated versions. Many of the same benefits of traditional versioning are included with this option. However, you can only edit simple features such as points, lines, polygons, annotation, and relationship classes. You cannot edit a feature class in a topology, network dataset, or utility network.
In traditional versioning, conflicts can be discovered during the reconcile operation when you save edits to a version and the same feature has been updated in that version in a different edit session (or updated in one edit session and deleted in the other).
Tip:
In traditional versioning, if your workflow is such that one user edits and another user reconciles, you must make sure the user who reconciles has full permissions to all the feature classes and tables that have been modified in the version; otherwise, the user cannot reconcile. As mentioned in the above section on granting privileges, the user reconciling must have full permissions to both the origin and destination classes that participate in any relationship class that has been modified, including simple or composite relationships. In this workflow, the user reconciling must also have sufficient version permissions. The reconciling user must be able to modify the version to reconcile, meaning it must be public, and must be able to view the target version, meaning the user must own the version, or it must be public or protected.
In traditional versioning, when you resolve conflicts, you are deciding which representation of the features and attributes you want to keep. Deleting a feature from an origin relationship class may trigger a message to delete a feature from the destination relationship class. Therefore, be aware of the ramifications of replacing conflicts involving feature classes participating in relationship classes. For example, in your electric utilities feature dataset, if you delete a utility pole that is related to one or many transformers, the related transformers are also deleted.
Learn more about resolving conflicts with relationship classes using traditional versioning
Use geodatabase replication with relationship classes
Geodatabase replication allows you to replicate some or all datasets in an enterprise geodatabase. It allows you to define which features or rows to replicate using filters and relationship classes. During replica creation, rows and features are added to a replica based on the filters defined in the application. Then, relationship classes are used to append additional features and rows.
The following example illustrates the replication behavior concerning related objects. The data model used in this example is a simple origin-destination relationship between properties, buildings, and their related annotation.
See Prepare data for replication for more information.
Synchronization maintains relationships. For two-way and one-way replication, the same filters and relationship class rules used in replica creation are applied during synchronization. All edits in each replica dataset applied since the last synchronization are evaluated when determining the changes to send. If an edit satisfies the replica's filters, it is synchronized.
For example, some features in an origin class, such as buildings, were selected for replication. The buildings are related through a simple relationship class to attribute records in a table excluded from the replication. During editing on the child replica, a building was deleted. On synchronization, to void the relationship with the feature that was deleted, the corresponding entry in the foreign key field in the related destination class, the table, is set to NULL.
Learn more and see additional examples of synchronizing with filters and related data
Share datasets containing a relationship class
Feature services allow queries on related data but only if the relationship is defined through a geodatabase relationship class and both the origin and destination tables are in the map before you publish.
To allow queries on related data in a feature service or hosted feature layer, define a relationship class between the feature class and related table or feature class. The related data accessed through a relationship class will be included in the feature service you publish. To support queries that return related objects, you must include the table and layer in the relationship class in the published map. The feature service ignores the relationship if the map does not contain the origin or destination layer or table.
Note:
For attributed relationship classes, include the relationship class table in the map.
Learn more about preparing data to publish a feature service, feature service creation, and working with related data via services (video).