Use a relationship class split policy

When a relationship class is created, by default, a split policy is automatically defined for it. The relationship class split policy determines how records in the related destination table are treated when a feature in the origin feature class is split during the editing process.

Depending on the type of relationship class created, simple or composite, there are different split policy options that can be defined:

In addition to defining a split policy for a relationship class, you can also define the split model for a line or polygon feature class. The feature class split model determines how the geometry and attributes are divided when a feature in the feature class is split during the editing process. Update/Insert is the default feature class split model, in which after a split, the largest portion of the original feature is updated and a new feature is inserted for the split part. However, if you have specific modeling requirements, the split model pattern can be changed to Delete/Insert/Insert, in which the original feature is deleted and two new features are inserted.

See Split model for details on how to set and use this feature class property.

The following sections take a closer look at each of the split policy options along with an example of the results from using feature class split models with each of the relationship class split policies.

Default (simple)

The default split policy for simple relationship classes is to preserve the relationships on the largest resulting feature after a split. In a relationship class, if the origin feature class uses the default feature class split model, Update/Insert, simple and composite relationship classes share the same behavior for how the related records are associated after a split is complete. In other words, the relationship class on the larger object is preserved after a split.

Relationship class split policy using default for simple relationship class types

Default (composite)

The default split policy for a composite relationship class depends on the feature class split model set for the origin feature class. If the feature class split model is set to Update/Insert, the relationship will be preserved on the largest resulting feature after a split. If the feature class split model is set to Delete/Insert/Insert, when a feature is split in the origin feature class, the original feature is deleted along with the split parts and their relationship with each other.

Relationship class split policy using default for composite relationship class types

Duplicate related objects

The Duplicate related objects option generates copies of the related objects and assigns them to both resulting parts. When Duplicate related objects is set as the split policy for the relationship class and a feature in the origin feature class is split during the editing process, the records that were originally related to this feature remain related to the largest portion. A new related record is created for each new part, duplicating the same user-set values as the original related record.

Relationship class split policy using duplicate related objects

Set the relationship class split policy

You can define the split policy for related features in a relationship class using one of the following two methods:

  • Relationship Class Properties—From the General tab on the Relationship Class Properties dialog box, scroll down to Split Policy. Clicking in the cell beside Split Policy enables a drop down. Choosing a split policy from the list populates the Set Relationship Class Split Policy geoprocessing tool and runs it in the background.

    Relationship Class split policy drop down options

  • Set Relationship Class Split Policy tool—Use the Set Relationship Class Split Policy geoprocessing tool to change the split policy for a relationship class.

    Set Relationship Class Split Policy geoprocessing tool

Requirements

When preparing to use the Set Relationship Class Split Policy geoprocessing tool, consider the following:

  • If the input relationship class is from an enterprise geodatabase, you must be the data owner to execute this tool.
  • Relationship classes in which the origin feature class uses the Delete/Insert/Insert split model are not supported in versions earlier than ArcGIS Pro 2.6 or ArcGIS Enterprise 10.8.1.
  • Relationship classes with a split policy set to Duplicate related objects are not supported in versions earlier than ArcGIS Pro 2.6 or ArcGIS Enterprise 10.8.1.

Note:
The Set Relationship Class Split Policy and Set Feature Class Split Model geoprocessing tools do not execute on a feature service workspace. Define these behaviors on your data before publishing.

The following are additional requirements based on these relationship class split policy behaviors:

  • Default (simple)
    • If the input relationship class is a simple relationship class type, the Default (simple) and Duplicate related objects options are available.
    • Simple relationships can have one-to-one (1:1), one-to-many (1:M), or many-to-many (M:N) cardinality.
  • Default (composite)
    • If the input relationship class is a composite relationship class type, the Default (composite) and Duplicate related objects options are available.
    • Composite relationships are always one-to-many (1:M) when you create them but can be constrained to one-to-one (1:1) with relationship rules.
  • Duplicate related objects
    • The cardinality for the relationship class is either one-to-one (1:1) or one-to-many (1:M).
      Note:
      This split policy is not available for relationship classes in which the cardinality is many-to-many.
    • The origin class must be a polyline or polygon feature class.
    • The primary key for the origin feature class must be set to the GlobalID field.
    • The origin class cannot have a class extension with a custom relationship split policy.
    • The destination class is an object class, such as a table, and cannot be a feature class.
    • The destination class is not the origin class of another one-to-one (1:1) or one-to-many (1:M) relationship class in which the origin primary key is set to a field other than GlobalID.
    • The destination class is not the destination class of another one-to-one (1:1) relationship class.

Tip:
Using copy and paste or the XML export option maintains the split policy set for a relationship class.

Review the relationship class properties

Follow these steps to review the split policy defined for the relationship class on the Relationship Class Properties dialog box:

  1. Start ArcGIS Pro.
  2. In the Catalog pane, in the Databases folder, click the geodatabase connection to expand it.
  3. Right-click the relationship class and click Properties.
    Relationship class properties
  4. On the General tab, the split policy for the relationship class is at the bottom of the Relationship Class Properties dialog box.