About editing relationships in ArcMap

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

About relationships

Relationship classes allow you to maintain associations between objects in your geodatabase. These relationships can be simple and passive, or they can be composite. Composite relationships imply parent-child relationships, or composition, and therefore have behavior, which is triggered through changes to objects on one side of the relationship to objects on the other side. Feature-linked annotation in the geodatabase uses composite relationships.

Relationships in a relationship class can be stored using primary and foreign keys in the object classes on either side of the relationship class. Alternatively, in the case of many-to-many (M–N) and attributed relationship classes, the relationships are rows stored in a separate table.

You can use the Attributes window or the table to find all objects related to any selected object. Once you have navigated to the related object, you can edit its attributes. You can also use the editing tools in ArcMap to break the relationship between any two objects or create new relationships between objects. When you edit objects and relationships in this way, all referential integrity is maintained.

Adding and deleting relationships

You can use the Attributes window to create and delete relationships between two objects. If the relationship is managed by primary and foreign keys (nonattributed 1–1 or 1–M relationships), the foreign key in the destination object is populated with the value of the primary key from the origin object. If a relationship between two objects is deleted, the value for the foreign key in the destination object is replaced with a null. The foreign key in the destination object must have fields that can be nulled.

If the relationship class is M–N or attributed, the relationships are stored on a separate table in the database. When a new relationship is created between two objects in this type of relationship class, a new row is added to that table. This new row is populated with the values from the primary keys in the origin and destination objects. If a relationship between two objects is deleted, the row corresponding to that relationship is deleted from the relationship table.

Editing objects in a simple relationship class

When an object that participates in relationships with other objects is deleted from the geodatabase, all its relationships are also deleted. If the object that is deleted is the origin object, the foreign key in all of the related destination objects is set to null. If the object deleted is a destination object, the origin object is not affected.

If the relationships are maintained as rows in a relationship table (M–N relationships or attributed relationships), then when either an origin or destination object and its relationships are deleted, the rows corresponding to those relationships are deleted from the relationship table.

Note:

Since simple relationship classes set the foreign key to Null when an origin feature is deleted, orphaned objects can exist in the relationship's destination class. This is allowed because simple relationship classes are designed to related objects that can exist independently of each other. In order to identify orphaned destination objects in a simple relationship class, relationship rules must be setup to prevent orphaned destination objects. Once the rules are set up the Validate Features tool will identify any orphaned destination objects.

To learn more about relationship rules see: Creating_relationship_rules

Creating new related objects

In ArcMap, you can select an object, then use the Attributes dialog box to create a new nonspatial object in a related class. When this new object is created, all its attributes are populated with their appropriate default values, and a relationship is established back to the object from which it was created. You can only create nonspatial objects in this way; you cannot create new features.

If the relationships are maintained using primary and foreign keys, the foreign key in the destination object is populated with the primary key of the origin object, regardless of whether the origin or destination object is created using the Attributes dialog box. If the relationships are maintained as rows in a relationship table (M–N relationships, attributed relationships), a new row is added to the relationship class's table.

The following set of tables shows that when you use the Attributes window to create new related objects, a relationship is created back to the object from which it was created. If the relationships are maintained using primary and foreign keys, the foreign key in the destination object is populated with the primary key of the origin object.

Editing objects in a composite relationship class

Composite relationships have some specialized behavior. When editing the objects that participate in a composite relationship, this behavior carries over to the editing process. Edits made to the origin object in a composite relationship often directly affect its related destination objects. This behavior is partially dependent on relationship class messaging.

By default, composite relationship classes have forward messaging—that is, when the origin object in a composite relationship is edited, it sends messages to its related destination objects. The related objects will respond to that messaging in a standard way: If the destination objects are nonspatial objects, they will not change. However, if the destination objects are features, when the origin object is moved, the destination objects will also move the same distance. If the origin object is rotated, the destination objects will be rotated by the same angle. Editing individual vertices of a feature's geometry is considered an update, not a move of the feature's geometry. In that case, the related object is not moved.

In the example, the blue selected pole is the origin object and the green transformer is the destination object.

Like simple relationships, composite relationships also maintain referential integrity when objects are deleted, but they do this in a different way. When the origin object in a composite relationship is deleted, all of the objects related to it through that composite relationship are also deleted. This cascade deletion will happen whether messaging is set to forward, back, both, or none.

The set of tables below demonstrates that when an origin object in a composite relationship is deleted, all destination objects related to it through a composite relationship are also deleted.

When a destination object is deleted, the relationship between it and the origin object is deleted; the origin object itself is not deleted or modified.

Note:

Although destination objects are deleted when the related origin object is deleted in a composite relationship, orphaned destination objects can still exist in the destination class. This is because the geodatabase model does not prevent you from inserting new features into an object class if it is the destination in a composite relationship. If you create a destination object but didn't associate it with an origin object, the Validate Features tool will warn you of the error.

With feature-linked annotation, the link between each piece of annotation and the feature that it annotates is modeled as a composite relationship. The parent (or origin) in the relationship is the regular feature, and the child (or destination) is the associated annotation.

If you have many-to-many relationships that are modeled using a Join table, you can use the Table To Relationship Class geoprocessing tool to convert the table that links values between two other tables into an attributed relationship class.

You can add your attributed relationship class to ArcMap as a table. Once it's in ArcMap, you can open the table and edit it like other tables. However you cannot edit the Foreign Key fields or add new rows unless you use the attribute editor.

Splitting features that participate in relationships

Splitting a single geodatabase feature into two separate features will maintain the original feature (but will update the geometry) and create one new feature. When a feature is split, the larger part will maintain the ObjectID of the original feature and the smaller part will be the new feature. In the case where the feature is split 50-50, the side of the feature with the start point of the line will remain as the original feature (original ObjectID) and the second half will become the new feature. This has implications when the feature being split has relationships with other objects in the database.

With simple relationships, when an origin feature is split, the relationships between the original feature and its related destination objects are deleted. When the new features are created from the split operation, both features will have the same primary key value and, therefore, are both related to the associated destination objects or features.

In the case of a composite relationship, the behavior is different. When the origin feature in a composite relationship is split, it does not delete the objects related to it through the composite relationship class because the original feature is still present. It is only the geometry of the original feature that is altered in the split operation.

When splitting a destination feature in either a simple or composite relationship, the relationship between the original feature and the related origin objects is not deleted. New relationships are created between the origin objects and the new feature that was a result of the split.

The behavior of splitting objects with relationships described here is the default behavior. You can override this behavior at the class level by writing a class extension that implements the IFeatureClassEdit interface. The IFeatureClassEdit interface has a property called CustomSplitPolicyForRelationship that allows you to specify how relationships are handled when features are split.