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.
-
Like the feature classes and object tables, relationships also follow the in-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 up to you. 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 The <Relationship> and <ManyRelationship> Tags for more information.
-
Attributed relationships create a separate table to store attributes. Subsequent topics note whether or not to choose attributed and which fields to add in the relationship table.
-
For more about relationship classes, read the ArcGIS Resource topic Relationships and ArcGIS.
Comprehensive, step-by-step instructions are provided in the first relationship topic RFCoupler_RFCouplerPort. Subsequent topics only include the relevant properties to choose while building the relationship..