Summary of Recommendations

Fiber Manager relationship configurations are somewhat sophisticated and have some tricky nuances to consider. These topics provide you with several summary recommendations in addition to an in-depth analysis of what those recommendations mean. We strongly suggest that you read through all topics to fully understand why and how we arrived at these recommendations.

First, let’s start with the “easy” settings that apply globally. Then, let’s examine the choices that are contextual given the two sides of the relationship:

Global Settings for all Relationships, The “Easy” Stuff

When you are creating a new relationship, the relationship wizard asks you a few questions along the way. Many of these have straightforward answers for all types of relationships:

• Name of the Relationship Class: The name does not matter to Fiber Manager , but we recommend a consistent approach to make the administrators’ lives easier. Again, the application doesn’t care about the names, but you do. Toward that end, we recommend the following:

  • Start with the prefix “F_.” ArcCatalog alphabetizes the objects and relationships, and adding this prefix simply keeps the Fiber Manager classes together.

  • After the prefix, start with the Origin (aka Parent) name, followed by an underscore, and then followed by the Destination (aka Child) name. In other words, the relationship between patch location and rack would be named F_PatchLocation_Rack, and the relationship between buffer tube and fiber strand would be F_BufferTube_Fiber.

  • Upper and lower case has no bearing on the functionality, so we recommended simply making it readable for you and other administrators.

• Origin and Destination:

  • For Parent/Child relationships, the origin is the parent and the destination is the child.

  • For splitters, the origin is the input, and the destination is the output.

  • For sibling relationships like frontport and backport, it technically does not matter the order. However, for consistency we recommend the origin is the front side, and the destination is the back side.

• Labeling: The wizard asks what you would like to use as a label while “traversing from origin to destination” or vice versa. First, it is important to know what it is talking about and where you would actually see these labels. It is very straightforward. When looking at a row in a parent table using the ArcMap Attribute table, you can request to see the related children. And, when looking at a row in a child table, you can request to see the parent. For example, below a patch panel card is selected, and when viewing the related tables we see three possible choices:

  

  The word “F_BACKSIDEPORT,” “F_FRONTSIDEPORT,” and “F_PATCHPANEL” are the labels. That’s all there is to it. It simply helps you know where the table is about to go when it traverses from parent to child or child to parent.

  In short, we recommend using the name of the object or feature class, which is the default presented to you when building the relationship.

• Message Direction: For all relationships, use None (no messages propagated). For the sake of curiosity, ArcMap is able to send message between related tables when edits are performed. However, Fiber Manager uses model names and autoupdaters to accomplish the same thing, and setting messages to None offers the best performance while working in ArcMap.

• Cardinality: Fiber Manager relationships are either one-to-one or one-to-many. Simply step back and think if the parent is able to have multiple children. For example:

  • Can a cable contain multiple buffer tubes? Yes, so one-to-many is appropriate.

  • Can a rack hold multiple panels? Yes, so one-to-many is appropriate.

  • Can a front port have multiple back ports? No, so one-to-one is appropriate.

  • Can a input port have multiple output ports in a splitter? Yes, so one-to-many is appropriate.

• Attributes on a Relationship Class: For all relationships, choose No. Fiber Manager does not currently leverage any attributed relationships.

• Primary Key and Foreign Key: The 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 all Primary Keys, choose GlobalID. This is the GUID created for the parent when the feature or object is sketched or created.

  • For Foreign Keys:

    • If it is a parent/child relationship, choose FiberParent.

    • If it is a sibling relationship, choose ImpliedConnectionSourceGuid

  • Almost all relationships have the FiberParent as the Foreign key. This field contains the GUID of the parent used to match parent to child. However, for sibling relationships such as frontport_backport and commonport_splitport, they use the ImpliedConnectionSourceGuid. This is because in sibling relationships, both have the same parent GUID already occupying the FiberParent field. Thus, the additional field of ImpliedConnectionSourceGuid is required to understand the sibling connection.

Contextual Settings that Vary Depending on the Relationship, The “Tricky” Stuff

• Relationships can be simple or composite, and composite has a performance advantage over simple. Since each child is allowed only one composite relationship, use composite for its most common parent relationship. For all others, use simple.

• A simple relationship does not automatically delete child records when you delete the parent. Additionally, fiber connections are not automatically deleted in a normal ArcMap delete procedure. Therefore, autoupdaters and model names are required to facilitate the delete process:

  • All fiber features and objects should get the ArcFM Fiber Object Deleted Autoupdater assigned.

  • All fiber features should get the field model name FiberParent assigned to the FIBERPARENT field.

  • All fiber features should get the field model name FiberParentClassModelName assigned to the FIBERPARENTCLASSMODELNAME field.

• To ensure that the aforementioned field model names work, all relationships that involve a parent and child should get the autoupdater ArcFM Update Fiber Parent Field assigned at the relationship level. Sibling relationships do not need this autoupdater.

• For the field THISFIBERCLASSMODELNAME, use an attribute default to populate this field with the appropriate model name for all fiber features or object tables.

• For the field CHILDFIBERCLASSMODELNAME, assigning a value or leaving it null depends on the following:

  • If the parent only has one kind of child, use an attribute default to populate this field with the appropriate model name.

  • If the parent has more than one kind of child, do not populate an attribute default; instead, leave it null and assign the class model name FiberMultiContainer to the parent.

Again, these recommendations make more sense with a bit of context. It is best if you review the remaining topics about relationships, especially if this is your first time configuring Fiber Manager .