Relates vs.

Relationship Classes 
A review of recent course evaluations for our most popular geodatabase
Web course revealed a lot of confusion over the terms "relate" and
"relationship class." Both are covered in the course, and the confusion is
nothing new. In fact, it's been an issue ever since ESRI introduced the
geodatabase. In this post, we'll attempt to clear it up.

The Basics

 A relate (also called a table relate) is a property of a layer in

ArcMap. You create a table relate so that you can query and select features
in one layer and see all the related features in another layer or table. A
table relate exists only in the map document in which it was created or in a
layer file (*.lyr).

 A relationship class is an
object in a geodatabase that stores information about a relationship
between two feature classes, between a feature class and a nonspatial
table, or between two nonspatial tables. Both participants in a relationship
class must be stored in the same geodatabase.

 Cardinality controls how relates and relationship classes are set up.

Cardinality is not a measure of an Arizona football fan's fervor, it is a
description of how records in two different tables are related to one
another. Cardinality may be one-to-one, one-to-many, many-to-one, or
many-to-many.

 Table relates are created between tables that have a one-to-many or

many-to-one cardinality. Relationship classes support all cardinalities.
 When you create a table relate or a relationship class, you specify the
field in each table that the relationship will be based on. The fields must be
the same data type (i.e., text, short integer, long integer, object ID, etc.). 

All clear now? No? OK, let's dig in more. 

The Example

In the Table of Contents in the map above, you see a layer of city fire
stations and a nonspatial table that stores data about the city's fire
department personnel. A table relate has been created between the layer
and the nonspatial table based on a short integer field in each table that
stores a fire station ID number.

What happens when a station is selected on the map?

Below, you see the attribute table for the fire station layer and the fire
personnel table. The option to show only selected features is being used for
both tables. Notice that while only one fire station record is selected (the
Washington station), six records in the fire personnel table are selected.
 This tells you that the Fire Stations layer has a one-to-many cardinality with
the fire personnel table. For each fire station, multiple fire personnel are
associated. In this case, six firefighters are assigned to the Washington
station. Because the tables are related, when you select a station you can
easily find out who works at the station. Table relates are bi-directional,
which means you can also select a record in the fire personnel table and
access the name of the station to which the firefighter is assigned.

You don't even need to select a feature or open the tables; you can quickly
view the information by using the Identify tool. The name of the related
table displays under the feature name on the left side of the Identify
window. Expanding the related table reveals the related records. Clicking a
related record displays the data stored in the related table.

Suppose Brian Butler is transferring to the Adams station. You are going to

edit the FirePersonnel table to reflect this. Here are the steps for
accomplishing this using our example.

 Start an edit session.

 In the Fire Personnel table, select Brian Butler's record.
 In the Number_ field, change the value to 1714 (the ID number for
the Adams station).
 Close the table and save your edits.
 Click the Adams station with the Identify tool.
o Brian Butler now appears in the list of personnel associated
with the Adams station.
 Click the Washington station with the Identify tool.
o Brian Butler's record no longer displays.

Why Use a Relationship Class?

Table relates are very useful for accessing and viewing information about
the real world that is actually stored in two different tables. Relationship
classes offer more powerful capabilities, however.

In addition to selecting records in one table and seeing related records in

the other, with a relationship class you can set rules and properties that
control what happens when data in either table is edited, as well as ensure
that only valid edits are made. You can set up a relationship class so that
editing a record in one table automatically updates related records in the
other table.
 Using the example above, suppose a relationship class is created between
the Fire Stations layer and the fire personnel table. The city has a
requirement that all stations have a minimum of five firefighters and
a maximum of 15 firefighters. A rule has been created for the relationship
class that reflects this requirement. 

At the end of the table relate example, the Washington station had five
assigned firefighters. Now, with the relationship class in place, if a staffer
tries to assign a different station number to one of the Washington station
firefighters, an error message will display and they won't be able to edit the
station number. They will have to assign a new firefighter to the
Washington station before editing the fire station number for the existing
Washington station firefighter.

The relationship class ensures that data edits are valid and supports the fire
department's goal that personnel assignments comply with the city's
requirement.

Remember

 Table relates exist only in a map document or layer file.

 Relationship classes exist as discrete objects in a geodatabase. If one
of the participating tables is deleted from the geodatabase, the relationship
class is deleted as well.
 Both table relates and relationship classes allow users to access and
view information for related features from either table.
 Relationship classes offer a method for ensuring data integrity. They
help make your geodatabase smart.

A lot more could be said about relates and relationship classes, but in the
interest of simplicity we will end the post now. Hopefully, some of the
confusion has been dispelled. For more information, check out theArcGIS
Desktop Help topics on relationships.

Filed under: ArcGIS fundamentals

Thursday, February 26, 2009 2:49 PM - SuzanneB

Comments

# re: Relates vs. Relationship Classes

Friday, March 12, 2010 12:46 PM by jakekrohn

I currently only have access to ArcView. Am I correct in my readings of the

help files that I am out of luck when it comes to defining relationship
classes? I'd like to check out my GeoDB tables for editing in ArcPad, but
when I do, the AXF only contains the feature class. Is this a consequence of
only having ArcView and no relationship classes? Short of upgrading, is
there any way around this?

# re: Relates vs. Relationship Classes

Friday, March 12, 2010 2:50 PM by SuzanneB

Yes, you are correct. With an ArcView license you can view relationship
classes but you need ArcEditor or ArcInfo to edit a feature class that
participates in a relationship class. Talk to your GIS manager or system
admin--it may be possible to use a floating ArcEditor or ArcInfo license if
you need to edit data that has relationships.

# re: Relates vs. Relationship Classes

Wednesday, December 01, 2010 8:38 AM by u1388

You wrote: A relationship class is an object in a geodatabase that stores

information about a relationship between … two nonspatial tables. I succeed
in creating a relationship between two nonspatial table. But how can I
populate the relationship class table with attribute values. I always get the
message: “Error retrieving row for update. Record may have been delete.
Refresh table to get latest view.” All introductions populate relationship
tables by selecting feature. But how does it work for two nonspatial tables??
Thank you for any help or link