How time flies! Here we are already on part three of our learning journey (part one Containment Relationships and part two Inferred Containment Relationships are here) . Obviously , these previous articles saw lots of content about Containment Relationships (and we haven’t finished with them yet) but this week we are looking into the other “big” relationship concept that causes confusion – Reference Relationships. Yes, that’s right. After the strange terminology of Containment Relationships, here’s another one.

What is a Reference Relationship?

A facetious answer would be “anything that is not a containment relationship”. Not the best definition but it is surely a good start. Here’s a visual example. In the first picture, you have a Containment Relationship. And in the second, a Reference Relationship. Take them on board and then let’s look at the differences.

In the animated capture above, you can see a Containment Relationship like those discussed the first two learning videos (Part 1 and Part 2). Notice how the rule designer cannot change the From and To of an Containment Relationship – since they define a structure that is inherent in the model. The only way to remove the Containment Relationship is to remove the child entity that is contained.

In the example above, things are very different. Firstly, the reference relationship must be actually created by the designer – this is not an inherent structural piece of real-estate that “has to be there”. It is something that is added to reflect a business concept or necessary expression of a concept. In this case, above, there are vehicles and there are people. We want to be able to put people in vehicles. Think of a ride-sharing company that needs to place people in cars depending on information like destination or type of customer – the user needs to be able to select the right candidates for the cars.

We can now go even further and state a basic principle (because Reference Relationships are not unique to Oracle Intelligent Advisor) : with containment relationships, one entity is contained by another, and with reference relationships, one entity points to another. Furthermore, the containment relationship has to be hierarchical, whereas a reference relationship may or may not be. Here’s an example from a completely different industry, proof if proof was needed that none of these terms are unique to Oracle Intelligent Advisor.

With this scenario in our minds, let’s put some detail on this concept:

The text you use to describe the reference relationship will depend entirely on what you are trying to express. No “default text” will be provided, unlike containment relationships.

The From and the To are your choices, to describe whatever it is you are modeling

The type is modifiable in both directions; one person per car, multiple people per car, multiple cars with multiple people or multiple cars with one person. The choice is entirely yours and is basically your “model” that you need to implement.

Although we will be dealing with it in a later part of the learning journey, the reverse text gives you a little bonus in the Debugger (see the video below for more information) and helps you see the reference relationship from both sides of the model. If nothing else at this stage it can help to have something written here to make it more obvious.

So, let’s take a walk-through of all of that with some commentary. Here is the next video in our learning journey!