OPA – Entities Adventures #3 Entity Relationships…

Reference Relationships

In the previous post we laid some groundwork for our Mechanic and Car Entities. Now we are ready to implement a couple of Reference Relationships. You can think of Reference Relationships as any relationship that is not Containment – basically it is any Relationship that you create, that is not created by the Policy Modelling application.

OPA - New Relationship Step One

Create a Relationship between the Mechanic and the Car. The Source is the Mechanic, and the Target is the Car, so begin by selecting the Mechanic and right-clicking the Relationship area on the right. Enter the correct kind of Relationship, and the relevant text as shown in the example below.

OPA - Create Relationship Step Two


In this example we have created a 1-Many relationship and the text we have written reflects that in English. The text of the relationship is often used in Functions with Entities as we will see in a moment.

Relationship Type

We need to pay close attention to the type of Relationship Type, since certain functions do not work with certain Relationship Types. Let us put all of this in to practice now by adding a useful Attribute to the Car for our business logic. Add “the car’s age”  as an Attribute. Make sure that the Attribute is definitely in the correct context – note “Entity” in the top right-hand corner.

OPA - Car Age Attribute

Now we can begin to focus on the rules we can write thanks to this hard work. Let’s begin with the obvious ones. Note in the following example, that the relationship text is the function’s argument – so your text must match exactly. For the purposes of clarity I have added a new Word Document in this Project, but that is not necessary.

OPA - Function InstanceCount


Counting based on a Reference Relationship

Remember to create a number Attribute the mechanic’s workload. Creating the Attribute with the text that includes “the mechanic” ensures that Policy Modelling understands that this is an Attribute that can be applied to each Mechanic.

OPA - Add Mechanic Workload

Compare this new rule with the example we created in the previous post :

The total number of cars in the workshop = the number of all the cars 

The above rule counts cars, but all the cars. The relationship text tells Policy Modelling which relationship is the source of the information. So now, let us Build and Debug without Screens. With Build and Debug we can review and edit the data as well as save it for later use.

OPA - Add Instances of Mechanic and Car

I have added three cars and three mechanics. The only inferred Attributes that have been updated will be the orignal Attriibutes from the previous post, which leverage the Containment Relationshiip. These are populated automatically.

OPA - Global Inferred Attributes

Defining Reference Relationships

The other Attriibutes that we have just added are not yet delivering any values. Why? Because Reference Relationships will simply be “Unknown” until we actively declare which Car is for which Mechanic.

OPA - The Mechanics Cars

OPA - The Mechanics Cars Step Two

In short, these Relationships will need to be specified. If the Relationship data is “Unknown”, so therefore the Attributes that derive their value from Entity Relationship-based Functions, are “Unknown”.

OPA - Final Mechanic Count Cars


When we take a moment to select the different Cars and define their Mechanic (or vice-versa), then we get the result we are expecting. But notice that we only will see results when we have removed all  the uncertainty – in short the three Mechanics need to explicitly be defined as having 0,1,2 or 3 cars. Then the function can reliably provide the information we need.

Zut alors!

Switching to our French version, most of the behavior is identical, however the rules written using the same basic structure are less grammatically acceptable. Take the following Reference Relationship, as before, only in French.

OPA - Voitures Reference Relationship

And then the rule we build refering to it:

OPA - Reference Relationship Instance Count French

Sadly the rule is considerably less grammatically correct than the English version. It might be tempting to change the Reference Relationship text and thus be able to write a more grammatically natural rule:

OPA - Tempting Change OPA - Tempting Change 2

But it probably will just complicate matters. Even in the Debug we can begin to see that “voitures du mécanicien” without the article “Les” will probably have negative impact when we write rules later. Generally, we always should include a definite article “The” or equivalent in our Entity and Attribute so that writing rules will be more natural (there are other reasons).

OPA - French Debug with Highlights

In this case, since the Attribute “La charge de travail du mécanicien” is grammatically acceptable we can decide to make changes to the Decision Report to make it as optimally readable as possible. As we will see in the next post, where we will also add some new features to our Web Determination and experiment with Substitution.




Richard Napier

Author: Richard Napier

After 8 years in case management and ERP software roles, Richard Napier joined Siebel Systems in 1999 and took up the role of managing the nascent Siebel University in Southern Europe. He subsequently was Director of Business Development and Education for InFact Group (now part of Business & Decisions) for 8 years. He now runs Intelligent Advisor IT Consulting OÜ. Owner of intelligent-advisor.com, he also is Co-Founder of the Siebel Hub.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Serving Customers Worldwide
Hide picture