There are different types of relationships. A relationship may involve people (more on that later) or may exist between GIS objects. There are two basic types of relationships between GIS objects; spatial and attribute. This post will outline the different types of attribute relationships and their creation.
Utility poles don’t just contain power-related attachments, they also commonly carry communications medium (telephone, cable, and internet). The pole’s owner will often lease space to other providers, which prevents the occurrence of multiple pole lines. Those providers (Lessee) pay a negotiated fee to the pole’s owner (Lessor). Skye wrote an excellent blog post on this subject.
The use of a relational database helps remove repeated information between records. Specifically to our example above, a relationship between the pole (parent feature class) and a joint use table (child object) is an excellent, efficient means of documentation. There are multiple reasons to do this:
- Determination of fees owed for efficient billing
- Calculation of loading capacity
- Communication for maintenance and damage repair
What are the options in Esri relationship construction?
Figure 1 is a flow chart which may aid in the decision making process of construction of relationships.
Option 1: Origin and Destination Selection
The first decision may seem obvious. It is the selection of participants of the relationship. As discussed in the example above (and will be used throughout), the origin parent feature class is the Pole and the destination child will be a JointUse table.
Option 2: Cardinality
Cardinality describes how the objects in a relationship correspond with each other. Below is a brief description of each:
- 1:1 – One parent object can relate to only one child object. An example of this could be the pole’s owner. Each utility pole may have only one owner.
- 1:M – One parent object can relate to multiple child objects. The example above of multiple telecommunication cable attachments on a pole is a perfect example.
- M:N – Multiple parent objects can relate to multiple child objects. An example of this is OOTB ArcFM Conduit Manager uses this relationship between Conduits and their linear child feature classes. This type of relationship will not be discussed in detail. May be a future 201 post.
In the case of the JointUse table, multiple attachments may be attached to the same pole. In this case, the 1:M relationship will suffice.
Option 3: Simple versus Complex Relationship
Couldn’t be simpler. If the parent object is removed/deleted, can/should the child object exist? If the answer is “NO”, then the relationship must be established with the type of Complex. If the answer is “YES”, then the relationship is Simple. When possible, establishment of complex relationships helps prevent stale/orphaned records in a database. When established as Complex, when the parent object is deleted, the child object(s) are also deleted.
It should also be noted that M:N relationships must be Simple.
Option 4: Primary and Foreign Key Selection
Beyond the selection of the parent and child objects, one must also choose the Primary and Foreign Keys. The Primary Key is usually the ObjectID or GlobalID field on the parent and gets propagated to the child object’s Foreign Key. The Foreign Key must be of the same field type as the Primary Key (Long Integer for ObjectID and Guid for GlobalID).
How do we Construct a Relationship?
Now that we know the details, an Esri relationship is a piece of cake to construct.
- Within ArcCatalog, right-click on the desired location to place the relationship (typically the root level but may be inside a feature dataset), select New, and Relationship Class from the context menus.
- In the first GUI (Figure 2), enter a name for the relationship (Pole_JointUse), select the desired parent (Pole), select a child (JointUse), and click the Next button.
- In the second GUI (Figure 3), we select a Simple or Composite Relationship. Since there can be no secondary pole attachments without the pole itself, we choose Composite Relationship. Click the Next button.
- In the third GUID (Figure 4), I usually choose None for message propagation. It is recommended to shorten the label. If using an enterprise database, the name can be quite long.
- In the fourth GUI (Figure 5), choose the 1:M option and the Next button.
- The Fifth GUI (Figure 6) is for attributes. I rarely add attributes to relationships. Click No and the Next button.
- The sixth GUI (Figure 7) is for the primary (ObjectID) and foreign (StructureObjectID) selection. Enter applicable values, and click the Next button.
- We lastly get a summary GUI (Figure 8). If happy, click the Finish button. That is it. May your relationships always be in your favor.
Four Degrees of Skye Perry
At the 2014 Esri Electric and Gas GIS Conference in Memphis, there were several old friends in attendance where we shared a common employer. I got to thinking about how fluid the GIS sector is. Fact is that the GIS world is a “small” fraternity and everybody seems to at least have name recognition to hundreds of people with a common career. A friend of mine made a similar observation in his blog post.
Somehow I got to thinking about the game Six Degrees of Kevin Bacon. The basic idea of the game is to find the shortest movie list between any actor and Kevin Bacon. It got to thinking about a similar scenario with Skye.
The rules of the game are simple. To have a first degree relationship, one must work (or worked) directly on a specific job with the SSP Innovations and/or Mr. Perry. To have a second degree relationship, one must work on a specific job with someone with a 1st degree relationship. One can’t be just a LinkedIn contact or have met at a conference. And on and on. The reason that I called this post Four Degrees of Skye Perry (and not Six Degrees) is because I suspect if one is in the business long enough, they won’t be below a 4th degree relationship.
Ms. DeAnna Aungst has never formally met Skye, but her Skye Number is 2 because she worked with me at an enginnering firm in Pennsylvania. I have directly worked Skye and SSP for two years, which gives me a Skye Number of 1. Any coworkers of DeAnna now would have a Skye Number of 3 (Unless they have worked with Skye or another employee of SSP).
The game could also be designed as a Versioning State Tree Diagram. Skye is State0 or Default. Anybody with a Skye Number > 1 that aspires to a higher Skye number can always contract with SSP or apply (i.e., reconcile and post).
Let the games begin.
DeAnna Aungst says:
Great Post, Brian! Its a clear demonstration of what a small and tight-knit community the GIS world truly is!
Brian Higgins says:
Thank, D! Appreciate the comment!