Relate features

You relate a feature in one table to a feature in another table for a variety of reasons, such as to allow your users to view information in one table for features in another. For example, you might want a user to be able to view fire hydrant inspection reports from a reports table and general fire hydrant information from a hydrants table for the same set of fire hydrants.

When you relate features, you're editing them because the relate operation changes the attribute of the destination feature. The relate operation associates the two tables by setting up a keyField attribute in the destination feature based on the corresponding origin feature. The keyField value is the origin table feature's primary key or global ID. In this hydrant example, relating a hydrant and an inspection report adds the keyField value of the hydrant feature in the hydrants table (origin table) to the corresponding (hydrant) field in the report feature in the reports table (destination table).

The tables of the two features you want to relate must be in a table relationship with each other (must be related tables). Table relationships are created using ArcGIS Desktop.

The pattern for editing a feature to relate it to another is the same as for editing a "regular" feature, as described in Edit features, whether the feature is the origin feature in a table relationship or the destination feature. When tables participate in a table relationship like this, you can perform additional editing-oriented operations not described in Edit features but described on this page:

Relate two features

You use the relate method to relate a feature in one table to a feature in a different table as long as the two participating tables have a valid relationship between them. The relate method sets up the foreign key (KeyField) value on the destination feature and can be called on either the origin or destination feature.

Relating features is akin to changing the attributes of feature; it's synchronous and done in memory. A feature once related must be added or updated to the table using addFeatureAsync(feature) or updateFeatureAsync(feature) for changes to be committed.

It's important to know the cardinality of the table relationship when you relate features.

Consider an example of buildings and mailboxes. If a building can have only one mailbox, and a mailbox can be associated with only one building, then the resulting cardinality is 1:1. The following code creates a new building feature and relates it to a mailbox.

//Buildings and mailboxes - 1:1 relationship
//Identify and get a mailboxFeature       
mailboxTable = mailboxFeature.featureTable as! AGSServiceFeatureTable

let relatedTables = mailboxTable.relatedTables()
buildingTable = relatedTables?[0] as! AGSServiceFeatureTable

//Create a new feature buildingFeature in buildingTable        
let buildingFeature = buildingTable.createFeature() as! AGSArcGISFeature

//Relate buildingFeature to the mailboxFeature
buildingFeature.relate(to: mailboxFeature)

//Add buildingFeature to buildingTable        
buildingTable.add(buildingFeature, completion: { (error) in

    //Check for errors, then applyEdits or sync, and so on          

Unrelate features

You may want to unrelate two already related features. For example, when a feature has a constraint violation, such as an invalid cardinality, you may want to undo the last relate operation that caused the violation. Unrelating features resets the key field of the destination feature. Like the relate method, unrelate is also synchronous and is done in memory. Therefore addFeatureAsync(feature) or updateFeatureAsync(feature) must be called for changes to be committed to the table.

In the buildings and mailboxes example where there is a cardinality violation because a building is related to a second mailbox, the following code unrelates the features, thereby removing the constraint violation.

//Buildings and mailboxes - Simple 1:1 relationship        
//Feature buildingFeature in buildingTable is already related to feature mailboxFeature in mailboxTable
//Check for constraint violation            

if relationshipConstraintViolation == .cardinality
    print("Cardinality Violated"

//Unrelate buildingFeature and differentMailboxFeature that caused the constraint violation

//There are no more constraint violations; you can confirm this by calling the validation method

//Update feature 
buildingTable.update(buildingFeature, completion: { (updateError) in

         //This would succeed

Validate the relationship constraints of a feature

You can check if a given feature violates any relationship constraints (for example, when a hydrant inspection report, is being added by a user), such as cardinality violations. In 1:1 relationships, if an origin feature is already related to a destination feature, no other destination feature can be related to it. In 1:n relationships, a destination feature can be related to only one origin feature (while the other way around is permitted). For more info on cardinality and types of relationships, see Relationship class properties in the ArcGIS Desktop help.

Considering the buildings and mailboxes example above with a relationship cardinality of 1:1, if a building were to be related to a second mailbox, it would be a cardinality violation. The following code checks for constraint violation for a given building.

//Buildings and Mailboxes - Simple 1:1 relationship        
//Feature 'buildingFeature' in 'buildingTable' is already related to feature 'mailboxFeature' in 'mailboxTable'

buildingFeature.relate(to: differentMailboxFeature) //Causes constraint violation

buildingTable.validateRelationshipConstraints(for: buildingFeature) { 
                (relationshipConstraintViolation: AGSRelationshipConstraintViolationType, error: Error?) in

     //Check for constraint violation       
     if relationshipConstraintViolation == .cardinality
         print("Cardinality Violated"

     //Update feature            
     buildingTable.update(buildingFeature, completion: { (updateError) in

          //This would succeed

Note that an update operation on a feature succeeds even if a relationship constraint has been violated by the edit. This is consistent handling with ArcGIS Server and ArcGIS Desktop, which do not enforce cardinality violations. ArcGIS Desktop provides a Validate Feature tool, which allows you to recover from violations in a back office operation after applying edits or syncing, if you choose to do so. See Validating features and relationships in ArcMap for more information. However, if you wish to check for violations in your app and recover from them, you can use the validate method.

Another type of constraint violation captured by the validatie method occurs in a composite relationship when an orphan feature is added to the destination table without relating it to an origin feature. You can recover from this violation by relating the orphaned destination feature to a valid origin feature.


Performance tip: If the related features are not local to the device, the validate method makes network calls to query for them. As a result, it can negatively impact performance when used on a number of features. This hit to performance is why edit operations such as add, update, and delete do not proactively check for relationship constraint violations.

Additional information

Getting related tables for a layer or table on the map returns only those tables on the map. Similarly related queries require both origin and destination table/layer to be present on the map. For tables not on the map, you can query them using regular query operations but cannot use related queries. You can also view what relationships the tables participate in.

All the tables participating in a relationship must be present in the data source. ArcGIS Runtime supports related tables in the following data sources:

  • ArcGIS feature service
  • ArcGIS map service
  • Geodatabase downloaded from a feature service
  • Geodatabase in a mobile map package

Two participating tables can have one of the following cardinalities: one-to-one, one-to-many, or many-to-many.

When defining relationships, one table must be origin and the other destination. A table can participate in more than one relationship. A table can play a destination role in one relationship and origin in another, resulting in nested relationships.

Simple and composite workflow-based relationships are supported:

  • In a simple relationship, features in the destination table are independent to features in the origin table. For example, a transformer and an electric pole may be related but they can also exist their own. Deleting an origin feature resets the keyField of the relationship to NULL in the destination feature.
  • In a composite relationship, each feature in the destination table is expected to be related to an origin feature. In other words, any orphan destination features are considered a violation of the relationship. For example, a building and its mailbox must be related. While the building (origin) can exist on its own, a mailbox (destination) must be related to a building. When an origin feature is deleted, the destination feature should also be deleted. This is known as a cascade delete.

Related topics