Relationship properties

When you create a relationship class, you must define its properties. The properties tell ArcGIS exactly how the tables should relate to each other. Some relationship properties have already been described, such as cardinality and origin and destination tables. The others are described below.

User-defined properties for a relationship class are summarized in the New Relationship Class wizard. Once a relationship class has been created, you cannot modify its properties.

Labels

Relationship classes have forward and backward path labels that describe the relationship when you're navigating from one table to another in ArcMap. The forward path label displays when you're navigating from the origin table to the destination table. The backward path label displays when you're navigating from the destination to the origin table.

In this example, a relationship class has been created between two feature classes: Poles and Transformers. Transformers is the destination feature class. The backward path label displays in ArcMap for easy navigation to the origin table, Poles.

Relationship types and messaging

There are two types of relationships: simple and composite.

Simple relationships exist between two tables whose objects can exist independently of one another. When related objects change, no messages are sent between the tables. For example, if you delete a parcel record in the origin table, the related owner record in the destination table remains. Only the value in the foreign key field is deleted, thus removing the owner's relationship with that parcel. Simple relationships can have any type of cardinality.

In composite relationships, destination objects cannot exist without an origin object. For example, electric transformers are mounted on a utility pole and, therefore, transformer features cannot exist without a pole feature. By default, composite relationship classes have forward messaging. This means that if the origin object is deleted, rotated, or moved, related objects in the destination table are deleted, rotated, or moved with the origin object. Composite relationships can have one-to-one or one-to-many cardinality.

You can set up other types of messaging between related tables, but only if you have added custom behavior through programming.

Attributes

Relationship classes can have attributes describing the relationship. For example, in a relationship between parcels and owners, an attribute of the relationship may be the percentage of ownership.

Relationship classes, relates, and joins

The decision of whether to use a geodatabase relationship class or an ArcMap join or relate depends on what type of relationship is required as well as your ArcGIS license. If you have an ArcEditor or ArcInfo license, you can create and edit relationship classes.

Relationship classes are usually created to establish enduring relationships between objects, and to take advantage of the additional functionality. In multiuser geodatabases, relationship classes support versioning to allow multiple users to edit the objects participating in a relationship at the same time. The disadvantage of using relationship classes is that they have a higher editing overhead—they require more computer processing than joins and relates.

	Relationship Class	Relate	Join
Typical Uses	Modeling and editing related objects	Querying, selecting	Querying, labeling, symbolizing
Referential Integrity	Yes	No	No
Messaging	Yes	No	No
Attributes	Yes	No	No
Relationship Rules	Yes	No	No
Cardinality	All	All	One-to-one, many-to-one