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.
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.
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.
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.
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.
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.
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.
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.
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.
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”.
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.
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.
And then the rule we build refering to it:
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:
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).
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.