Relationships

DHFC leverages GIS relationships to maintain data integrity, inform tracing, perform queries, and other functions. It is a beneficial way to relate feature classes with a physical presence on the map with object tables that do not. For example, an RFCoupler is a point feature class with a geographic location, and it has multiple RFCoupler Ports that are records in an object table. These two have a relationship so the application knows which ports belong to which coupler, and there are subsequent relationships to track what is connected to each port.

• Similar to the feature classes and object tables, relationships also follow the design and as-built geodatabase architecture, and there is a relationship for both states. For example, there is an RFCoupler_RFCouplerPort relationship, and an RFCoupler_RFCouplerPort_D relationship.

• The name of the relationship itself is not referenced by the application and is at your discretion. However, for ease and consistency, Schneider Electric recommends a naming convention of origin_destination, as seen in RFCoupler_RFCouplerPort, for all relationships.

• The relationship can be located in the root geodatabase, or it can be located within a dataset as long as either the origin or destination resides in the same dataset.

• Every relationship has an equivalent tag in the schema.xml. See the topic <Relationship> and <ManyRelationship> Tags for more information.

• Attributed relationships create a separate table to store attributes. Refer to the Add Attribute Fields to Relationship Tables topic for more information.

• Refer to Esri’s Create Relationship Class article for steps to create relationships in ArcGIS Pro.