Relationship Keys

Feeder Manager builds the list of Feeders by starting with the records in the Circuit Source object and determining the attributes of the feeders. It then traverses all defined relationships to associated features to establish starting points for tracing the network.

If only one feature class will be related to the CircuitSource class, then add to the CircuitSource object class a foreign key field to hold ObjectID values from the origin feature class (ObjectID is always the primary key field for a feature class).

In this example, the Tagged Values for the relationship between the DynamicProtectiveDevice and the CircuitSource would designate the OriginForeignKey as DynamicProtectiveDevObjectID. The OriginPrimaryKey would be the ObjectID of the DynamicProtectiveDevice.

If you have defined subtypes for these feature classes, you can specify the relationship rules between them to include minimum and maximum cardinality for the source and destination. In this case, you would define the relationship between the subtypes representing the Circuit Breaker and those for the Circuit Source as a 0..1-to-0..1. This would allow any of the three subtypes for CircuitSource to have up to one DynamicProtectiveDevice associated with it.

To relate more than one feature class to the CircuitSource object class, then you have two choices. You may add to the CircuitSource class a separate foreign key field for each related feature class to hold the feature class ObjectID. This choice entails leaving N-1 of the foreign key fields unused for each CircuitSource object, where N is the number of related feature classes, since each CircuitSource object is allowed to relate to at most one feature. Alternatively you may add to each related feature class a single foreign key field to hold a CircuitSource ObjectID. This choice leaves an unused foreign key field only for those features that have no related CircuitSource object.