How you set the parameter values when you run the Create Relationship Class geoprocessing tool depends on the type of relationship class you need and what rules you may need to apply.
To help you understand what values to use, the following describes the input parameters for the Create Relationship Class geoprocessing tool.
Parameters
The following is an explanation of each parameter on the Create Relationship Class geoprocessing tool:
- Origin Table—The table or feature class that is associated with the destination table.
- Destination Table—The table that is associated with the origin table.
- Output Relationship Class—The name of the relationship class that will be created.
- Relationship Type—Specifies the type of relationship that will be created between the origin and destination tables.
- Simple—The origin and destination tables will have a simple relationship. This is the default.
- Composite—The origin and destination tables will have a composite relationship.
- Forward Path Label—A name to uniquely identify the relationship when navigating from the origin table to the destination table.
- Backward Path Label—A name to uniquely identify the relationship when navigating from the destination table to the origin table.
- Message Direction—Specifies the direction in which messages will be passed between the origin and destination tables. For example, in a relationship between poles and transformers, when a pole is deleted, a message will be sent to its related transformer objects indicating that it was deleted.
- Forward (origin to destination)—Messages will be passed from the origin table to the destination table.
- Backward (destination to origin)—Messages will be passed from the destination table to the origin table.
- Both directions—Messages will be passed from the origin table to the destination table and from the destination table to the origin table.
- None (no messages propagated)—No messages will be passed. This is the default.
- Cardinality—Specifies how many relationships will exist between rows or features in the origin table and rows or features in the destination table.
- One to one (1:1)—Each row or feature in the origin table can be related to zero or one row or feature in the destination table. This is the default.
- One to many (1:M)—Each row or feature in the origin table can be related to one or several rows or features in the destination table.
- Many to many (M:N)—Several rows or features in the origin table can be related to one or several rows or features in the destination table.
- Relationship class is attributed—Specifies whether the relationship class will have attributes. See Understanding attributed relationship classes to learn more about where these attributes are stored and how to create and populate an attributed relationship class.
- Checked—The relationship class will have attributes.
- Unchecked—The relationship class will not have attributes. This is the default.
Origin Primary Key—For one-to-one or one-to-many relationship classes that are not attributed, this is the field in the origin table, often abbreviated as PK, and links to the Origin Foreign Key field in the destination table.
For many-to-many or attributed relationship classes, this is the field in the origin table that links to the Origin Foreign Key field in the intermediate relationship class table.
Origin Foreign Key—For one-to-one or one-to-many relationship classes that are not attributed, this is the field in the destination table, often abbreviated as FK, that links to the Origin Primary Key field in the origin table.
For one-to-many or attributed relationship classes, this is the field in the intermediate relationship class table that links to the Origin Primary Key field in the origin table.
- Destination Primary Key—The field in the destination table that links to the Destination Foreign Key field in the intermediate relationship class table. This value is required for many-to-many or attributed relationship classes but should be left empty for one-to-one or one-to-many relationship classes that are not attributed.
- Destination Foreign Key—The field in the intermediate relationship class table that links to the Destination Primary Key field in the destination table. This value is required for many-to-many or attributed relationship classes but should be left empty for one-to-one or one-to-many relationship classes that are not attributed.
Origin and destination classes
When you create a relationship class, you choose one class to be the origin and another to be the destination. It is important not to confuse the two. With the behavior of cascade deletes in composite relationships, the importance of this may seem obvious.
In simple relationships, getting this correct is critical. This is because when you delete a record in the origin class, the simple relationship class finds the matching records in the destination class and sets the value of their key field to Null. If you choose the wrong class as the origin and delete objects in the origin, you will introduce errors in the foreign key field. The following example illustrates how this can occur:
Case 1: Parcel to Zone (wrong)
This is a common scenario for this error. The Zone table contains the descriptions for the various zoning codes and is conceptually similar to a lookup table. In this case, the Parcel class is the origin, and the Zone table is the destination. The problem is that when you delete a parcel, the value in the key field (Zone) is set to Null for the matching record in the Zone table, and none of the other parcels that have that zoning code have a match in the Zone table.
Case 2: Zone to Parcel (correct)
To correct the problem, set the Zone table as the origin. Deleting a parcel (a destination object) will have no effect on the Zone table, and deleting a Zone code (an origin object) will simply set the value of the Zone field in the matching parcel records to Null, which is as it should be, because they no longer have a matching Zone table record.
Output relationship class name
Each relationship class has a name that displays in the Catalog pane. It is recommended that you name the relationship class so the name describes the participating elements and cardinality of the relationship.
Start with the name of the origin feature class, follow with Has or Have, and end with the name of the destination feature class. For example, AddressHasZones or ParcelsHaveOwners. Pluralize the origin feature class name if it is a many-to-one or many-to-many cardinality, and pluralize the destination feature class name if it is a one-to-many or many-to-many cardinality.
Using this method, you can determine the cardinality of a relationship class from its name. For example, with both feature classes in the plural, ParcelsHaveOwners suggests a many-to-many relationship.
Names must be unique in a geodatabase-you can't have more than one object (table, feature class, relationship class, and so on) with the same name. See Define feature class properties to learn more about feature class and table name rules and limitations.
Forward and backward path labels
Forward and backward labels display on the Attributes and Identify results dialog boxes in ArcGIS Pro and help you navigate between related objects.
A relationship class has two labels:
- A forward label that displays when you navigate from the origin to the destination. In the pole-transformer example, this label could read supports, meaning this pole supports these transformers.
- A backward label that displays when you navigate from the destination to the origin. In the pole-transformer example, this label could read is mounted on, meaning these transformers are mounted on this pole.
Message notification direction
As previously discussed, when you delete an origin object in a composite relationship, related destination objects are automatically deleted.
Whether you're working with simple or composite relationships, there may be other actions that require an update of one feature to trigger an update in its related features. Furthermore, updates can be required in one direction or another, or both.
- When you move or rotate a feature, you want related features to move or rotate along with it.
- When you update a feature, you want an attribute in a related feature to update automatically.
- Updating an origin can require related destination objects to update.
- Updating destination objects can require related origin objects to update.
If your relationship requires this behavior, you can have origin and destination objects send messages to notify one another when they are changed, allowing related objects to update appropriately.
To accomplish this, set the message notification direction when you create the relationship. If updating an origin requires related destination objects to update, set the message notification direction to Forward. If updating the destination requires related origin objects to update, set the message notification to Backward. If you require both of these, set the message notification direction to Both. Once you've created the relationship, you must program behavior into the objects that receive the messages so they can respond.
The only exception is composite relationships when messaging is set to Forward. When you create a composite relationship with forward messaging, moving or rotating an origin object causes related destination features to automatically move or rotate along with it. Provided you set up your relationship correctly, this functionality works as soon as you've created the relationship—no custom programming is required.
For other message notification directions, custom programming is required. Unless you're creating a composite relationship with forward messaging or are intending to program custom behavior, set the message notification to None. Otherwise, messages will needlessly generate each time you perform an edit operation, slowing performance.
When setting the direction for composite relationships, keep in mind that when the origin object in a composite relationship is deleted, all related objects in the destination are automatically deleted. This happens regardless of whether messaging is set to Forward, Backward, Both, or None.
| Direction | Effect on simple relationships | Effect on composite relationships |
|---|---|---|
Forward | No effect unless customized with programming |
|
Backward | No effect unless customized with programming |
|
Both | No effect unless customized with programming |
|
None | Prevents messages from being sent, slightly improving performance |
|
Cardinality
Cardinality describes the maximum number of associations between two different table rows or columns.
A GIS integrates information about various geographic and nongeographic entity objects, many of which can be related. When adding nongeographic data to your feature data, you must consider how the objects are related and if there is a common field.
Relationships are built around the concept of an origin and destination table and how objects in the origin relate to the objects in the destination table. To create a relationship between two tables, you must identify a field common to both with common values, known as a key.
Note:
Common fields are not required to have the same name, but they are required to have the same data type. The values in the common fields are used to link records in the table based on the defined cardinality.
A relationship's cardinality specifies how many objects in the origin table are related to how many objects in the destination table. A relationship class can have one of three cardinalities:
- One to one—One row or feature in the origin class or table can relate to zero or one row or feature in the destination class or table. This setting is the default. For example, a parcel can have only one legal description.
Note:
In ArcGIS, this cardinality also covers many to one. An example of a many-to-one relationship is many parcels relating to the same legal description.
- One to many—One row or feature in the origin class or table can relate to one or more rows or features in the destination class or table. For example, a parcel may have many buildings. In a one-to-many relationship, the one side must be the origin class and the many side must be the destination class.
- Many to many—One origin object can relate to multiple destination objects, and conversely, one destination object can relate to multiple origin objects. For example, a given property may have many owners, and a given owner may own many properties. To learn more, see Understanding attributed relationship classes..
Note:
When evaluating the cardinality of objects between two tables, the terminology one is really zero-to-one, and the terminology many is really zero-to-many. So when you create a one-to-many relationship between parcels and buildings, for example, the relationship permits all of the following:
- A parcel with no buildings
- A building with no parcel
- A parcel with any number of buildings
If a relationship class has been created, you can further refine the cardinalities by adding rules to the relationship class. You can add rules that specify the number of rows or features in the origin class or table that are permitted to relate to a number of rows or features in the destination class.
Note:
Cardinality is defined when a relationship class is created. Once the relationship class is created, the cardinality for the relationship class cannot be modified; therefore, it is important to consider and verify the cardinality of the data prior to creating the relationship class.
Primary and foreign keys
In a relationship class, objects in the origin table match objects in the destination table through the values in their key fields.
In a non-attributed relationship class, the relationship is maintained when values in the Origin Primary Key (PK) field in the origin table directly relate to values in the Origin Foreign Key (FK) field in the destination table. Unlike a true primary key, the values in the primary key field in a relationship are not required to be unique for every object. The foreign key field contains values that match those of the primary key field in the origin table. Again, the key field values do not need to be unique for each row.
For example, parcel 789 matches permits 2 and 3 because all those records have the same parcel ID.
Optionally, in an attributed relationship class, such as when a many-to-many relationship is created, an intermediate table is also automatically created. This intermediate table maps values in the Origin Foreign Key field and the Destination Foreign Key field to the primary keys of the related tables or feature classes. Each row associates one origin object with one destination object. The key fields may have different names but must be of the same field data type, and contain the same kind of information, such as parcel IDs. Fields of all data types, except binary large object (BLOB), date, and raster, may be key fields.
For example, to help determine the owners of parcels in your community, a many-to-many relationship class is created between the Parcel feature class and the Owner stand-alone table. This many-to-many relationship class will create an intermediate or attributed table, ParcelToOwner, that will associate one or more owners with each parcel.
You specify the key fields when you create a relationship class.
When deciding on a primary key field, one option is to use the row ID field, commonly referred to as the ObjectID field. The ObjectID field is automatically added by ArcGIS when you create a feature class or table or register an enterprise geodatabase layer or table. This field guarantees a unique ID for each record. It is maintained by ArcGIS, and you can't modify it.
The ObjectID value of a given object never changes as long as it remains in its original class and, if the object is a feature, you do not split it. If you split a feature, it will maintain the original feature (but will update the geometry) and create a new feature, which will have a new ObjectID assigned to it. As a result, only the feature with the original ObjectID will maintain any relationships that are dependent on the ObjectID value.
Because of this, it may be better to create and use your own primary key field instead of relying on the ObjectID field. The following describes how your own primary key field can help maintain relationships when you perform each of these operations.
- When you import records to another feature class or table, new ObjectID values are assigned, losing any relationships based on the original ObjectID values. If, instead, you base the relationship on another primary key, the ID values in the primary key will not change when records import. This allows you to preserve relations when you import related sets of objects to new classes.
An exception is when you use the Copy/Paste function. Copy/Paste preserves ObjectID values, so if you plan to move objects with this method only, you can use the ObjectID field as the primary key.
- When you split a feature, the original feature is maintained (with updated geometry), and a new feature is created. If you have a relationship based on the original ObjectID, only one of the two features created in the split will maintain the relationship. However, if you used another field as the key, when you split the feature, the ID value of the original feature would be copied to the two new features. As a result, the records in the related table would now be related to both new features—ideal if the relationship class is set up as many-to-many.
If you won't be splitting features and are sure that all objects will remain in their original class, you can use the ObjectID as their IDs. If you can't guarantee this, it's recommended that you set up and use your own ID field instead of relying on the ObjectID field.
- When you merge two features, the new feature retains the ObjectID of one of the original features. If you plan on merging features but not moving features out of their class or splitting them, you can use the ObjectID field as the primary key.