Create Relationship Classes

The following relationship classes must be created in your geodatabase as part of Conduit Manager's minimum configuration requirements.

When building a relationship, the ArcCatalog relationship wizard wants to know where to find the unique identifier for the parent (that’s the primary key) and where this same identifier is placed in the child (that’s the foreign key). The application is then able to “match” the parent and child because all the children have the parent’s unique identifier. For the primary and foreign keys, Conduit Manager supports using ObjectID or GlobalID except for the Conduit_CrossSectionAnnotation relationship, which does not support GlobalID. This is because feature linked annotation relationships cannot be globalized.

IMPORTANT: As a best practice, you should decide which field type to use for all relationship keys. In other words, all relationships should use ObjectID, or all relationships should use GlobalID (except for Conduit_CrossSectionAnnotation, as noted above). You should not mix and match the field types.

The tables below are for new relationships. If you have existing relationships that you need to convert from ObjectID-based to Global-ID based, see the topic Migrate Existing Relationships to use GlobalID.

Conduit_CrossSectionAnnotation

For the primary and foreign keys, Conduit Manager supports either ObjectID or GlobalID except for the Conduit_CrossSectionAnnotation relationship, which does not support GlobalID. This is because feature linked annotation relationships cannot be globalized.

Origin table	Conduit feature class
Destination table:	Cross Section Annotation feature class
Relationship type:	Composite (when conduit is deleted, associated annotation is deleted)
Notification:	None (no messages propagated) IMPORTANT: The default notification for Composite relationships is Forward. Ensure you change this to None.
Cardinality:	One to Many
Attributes?	No
Primary Key:	ObjectID
Foreign Key:	FeatureID

Conduit_Cable

Create a relationship between each conductor (or cable) class and the conduit feature class. For example:

Conduit_PriUGElectricLineSegment
Conduit_SecUGElectricLineSegment
Conduit_FiberOpticCable

Origin table:	Conduit feature class
Destination table:	Conductor (Cable) feature class
Relationship type:	Simple
Notification:	None (no messages propagated)
Cardinality:	Many to Many
Attributes?	Yes
Add fields:	You must enter these three field names exactly as shown. Field model names are not supported in attributed relationships; thus, the application is looking for these fields exactly as they are displayed. ULS_Position (long integer) - This is required for both electric and non-electric cables that run through the conduit. PhaseDesignation (long integer) - This is required for both electric and non-electric cables that run through the conduit. Even though non-electric cables (such as fiber optic cables) do not track “phase,” The autoupdater “ArcFM UFM Duct to Conductor Relationship” depends on this field existing in the relationship. Cables (long integer) - This is required only for electric cables that run through the conduit. It allows you to represent situations where multiple cables carry the same phase within the same duct for redundancy (fail over) purposes.
Origin (Conduit) Primary Key:	ObjectID or GlobalID
Destination (Conductor or Cable) Primary Key:	ObjectID or GlobalID
Origin (Conduit) Foreign Key:	Conduit_ObjectID or Conduit_GlobalID This becomes the field name visible in the relationship table. Thus, we recommend adding a descriptor (for example, Conduit_ as seen above) so you know which ID is from the origin. The descriptor is up to you, but ensure it is recognizable for all GIS administrators.
Destination (Conductor or Cable) Foreign Key:	Cable_ObjectID or Cable_GlobalID This becomes the field name visible in the relationship table. Thus, we recommend adding a descriptor (for example, Cable_ as seen above) so you know which ID is from the destination. The descriptor is up to you, but ensure it is recognizable for all GIS administrators.

IMPORTANT: Currently the ULS_Position and PhaseDesignation fields must be named exactly as shown here. Field Model Name support is not available for attributed relationships. Failure to enter this as documented will result in errors.

Conduit_UGStructure

Create a relationship between each underground structure feature class and the conduit feature class.

Origin table:	Conduit feature class
Destination table:	Underground Structure feature class
Relationship type:	Simple
Notification:	None (no messages propagated)
Cardinality:	Many to Many
Attributes?	No
Origin (Conduit) Primary Key:	ObjectID or GlobalID
Destination (UGStructure) Primary Key:	ObjectID or GlobalID
Origin (Conduit) Foreign Key:	Conduit_ObjectID or Conduit_GlobalID This becomes the field name visible in the relationship table. Thus, we recommend adding a descriptor (for example, Conduit_ as seen above) so you know which ID is from the origin. The descriptor is up to you, but ensure it is recognizable for all GIS administrators.
Destination (UGStructure) Foreign Key:	UGStructure_ObjectID or UGStructure_GlobalID This becomes the field name visible in the relationship table. Thus, we recommend adding a descriptor (for example, UGStructure_ as seen above) so you know which ID is from the destination. The descriptor is up to you, but ensure it is recognizable for all GIS administrators.