Coverage relationships and relationship classes

License:

Though you can only view relationship classes in ArcGIS for Desktop Basic, they can be both created and edited in ArcGIS for Desktop Advanced and ArcGIS for Desktop Standard.

Features in a coverage often have associations with features in other coverages or attributes in separate tables that are stored in relationship classes. You can create a simple or composite relationship class between any two tables and feature classes in the same folder that share a common attribute. Related feature classes may exist in the same coverage or in different coverages. A relationship is similar to an ArcInfo relate.

With a relationship, you can define which column in a feature class's attribute table and which column in another table share the same values. Once created, the relationship allows you to establish a temporary connection between a coverage's features and descriptive attributes in a table. A relationship class allows you to query, label, and symbolize the features in the coverage using attributes in the associated table.

The relationship classes in which a coverage feature class or an INFO table participates are listed on the Relationships tab on the Properties dialog box. Click a specific relationship in the list and click Properties to learn more about it. For example, you can determine all the coverages and tables to which an INFO table is related. An item's relationships are also recorded in its metadata. With the FGDC Esri style sheet, you'll find the item's relationships listed at the bottom of the Attributes tab in the metadata.

You can define a relationship in ArcCatalog, or you can use the Join Info Tables tool; however, you need an Advanced license to use this geoprocessing tool.

Properties of a relationship

One property of a relationship is its cardinality, which describes how many features in the coverage are related to how many records in the other attribute table. If the associated table contains measurements taken at a point in the coverage, the relationship will be one-to-many: one point to many measurements. In general, relationships can have one-to-one (1–1), one-to-many (1–M), many-to-one (M–1), and many-to-many (M–M) cardinalities.

In the example above, the point feature class in the coverage is the origin of the relationship, and the table containing the measurements is the destination. The columns used to connect these data sources are key attributes. The point feature class, or origin, has an attribute containing a code for each station; this is the primary key for the relationship. The measurements table has an attribute indicating the station at which the measurements were taken; this is an embedded foreign key.

Relationships have path labels that describe the nature of the association:

• The forward path label describes the relationship when navigated from the origin to the destination; for example, station points have measurements.
• The backward path label describes the same relationship when navigated from the destination to the origin; in this example, measurements are taken at stations.

Types of relationships

There are two types of relationships: simple and composite. Simple relationships describe associations between data sources that exist independently of each other. A coverage and table are independent of each other if, when you delete the origin coverage, the destination table continues to exist. In the previous example, if you started taking measurements at a new point upstream and deleted the old point from the coverage, you would still keep the measurements taken from the old station for historical purposes. The relationship, therefore, is a simple one.

Composite relationships describe associations in which the lifetime of one object controls the lifetime of its related objects. An example is the association between highways and points for placing a highway shield marker. The primary key in the line feature class in the highways coverage has a unique code for each line. The foreign key in the point feature class in the shields coverage contains the code for the line it is associated with. Shield points can't exist without a highway.

Simple relationships can have one-to-one, one-to-many, or many-to-many cardinalities. A many-to-one relationship is by definition a one-to-one relationship. Composite relationships always have a one-to-many cardinality. When you create a one-to-many relationship, whether simple or composite, the "one" side of the relationship must be the origin and the "many" side must be the destination.

One object can participate in many relationships. For example, in addition to the composite relationship between highways and shield points, the highway line feature class might have a simple relationship to an INFO table. In this case, each highway line has a code indicating the type of surface used and the related table contains a description of each surface code, so many highways share the same surface description. To describe this second association, you would create a simple one-to-one relationship.

Although all the above examples have included coverages, it is important to note that you can create a relationship class to define an association between two INFO tables.

Coverage relationship classes

Layers may define joins and relates between geographic and tabular data that are stored in different formats or in different ArcInfo workspaces. Joins and relates provide similar functionality to simple relationship classes, except that they must be defined for each individual layer.

Learn more about joining tables and relating tables

You can create a coverage relationship class to model the relationships between objects in an ArcInfo workspace in a permanent and realistic fashion. Once created, the information can be reused in many layers. ArcMap will detect when a relationship class exists and allows you to easily access related attributes.

Coverage relationship classes are essentially the same as the relationship classes you can create in a geodatabase. For specific information regarding relationship classes in geodatabases, see Benefits of relationship classes.