About this series of articles

While my first series of articles on writing natural language rule statements^[1] explored a wide variety of issues in a rather organic and hence random manner, this series takes a more holistic and systematic approach and draws on insights gained while writing my recently-published book on the same topic.^[2]  Rule statements recommended in these articles are intended to comply with the Object Management Group's Semantics of Business Vocabulary and Business Rules (SBVR) version 1.0.^[3]

The story so far

In previous articles in this series (see the "Language Archives" sidebar) we have looked at a variety of data cardinality rule statements,^[4] and four types of data content rule statement,^[5] namely range rule statements,^[6] value set rule statements,^[7] uniqueness constraint statements,^[8] and equality rule statements.^[9]  Each type of rule statement has a common formulation which we have discussed in both a relatively informal way and by way of rule statement patterns.  In this article we will look at some further types of data content rule statement.

Inequality Rules

There are situations in which the content of a data item must be different to that of some other data item, as illustrated by rule statement RS86.

This has the same formulation as an equality rule except that the predicate starts with "be different to" rather than "be the same as".  As with uniqueness constraints, you may prefer "different to" or (in American English) "different than".  And, where the governed data item is a simple numeric value (but not a date), "be unequal to" may be used.

We could create a separate rule statement pattern for inequality rules (and a separate pattern for inequality predicates) but, since these are so similar to equality rules and equality predicates respectively, we could alternatively modify those patterns to accommodate inequality rule statements and predicates.  I have chosen the second approach; here are the revised patterns.

P20.	<(in)equality predicate> ::= <(in)equality operator> {<literal> | {<offset> |} the <data item term> <qualifying clause>}
P21.	<(in)equality operator> ::= be {the same as | equal to | different to | unequal to}

Complemented Predicates in Data Content Rules

Substituting different to in place of the same as (or unequal to in place of equal to) creates the complement of the predicate; for example:

• be unequal to 1 is the complement of be equal to 1;
  
  
• be different to the Origin City specified in that Flight Booking Request is the complement of be the same as the Origin City specified in that Flight Booking Request.

Range predicates also have complements; for example:

• be less than $500 is the complement of be more than $500;
  
  
• be earlier than the Date on which that Travel Insurance Application is made is the complement of be later than the Date on which that Travel Insurance Application is made.

These are already allowed for in patterns for range predicates.  However, value set rules, as formulated so far, accommodate only the requirement for the value of a data item to be one of the members of a particular set of values.  There are situations where the requirement is that the value of a data item not be one a particular set of values, as in rule statement RS87.  This states a rule that some Rewards Programmes use to prevent passengers using the rewards points to fly on popular travel days (when a full complement of fare-paying passengers can be relied on).

To accommodate this statement form, we need to modify the value set predicate pattern.

Uniqueness constraint predicates also have logical complements.  However, while the requirement of a uniqueness constraint is that a set of data items in a transaction all be different, the complementary requirement (that a set of data items in a transaction all be the same) is quite a different requirement.  Consider RS88, a restriction imposed by some online flight booking systems (a requirement usually achieved in practice by including only a single Travel Class field in the on-screen form).

This is a rule requiring consistency between data items, which we will discuss later in this article.

Data Consistency Rules

Consider the following two rule statements, the first of which we encountered in a previous article:

These rule statements are clearly equivalent so do we need them both?  An important principle of rule statement syntax is that the subject of a data rule statement should signify the data item to be tested by the stated rule.  This makes it is easy for rule implementers to identify which rules need to be executed whenever some event affecting data occurs.  For example, if content is entered into the Return Date field in a Travel Insurance Application form or existing content in that field is changed, that content should be tested against every rule with a statement containing Return Date specified in each Travel Insurance Application in the subject.  Typically a user will enter a date in a blank Departure Date field then another date in a similarly blank Return Date field, which means that:

1. the rule stated in RS89 is not executed when a date is entered in the Departure Date field since it cannot be executed until there is also a date in the Return Date field;
   
   
2. the rule stated in RS61 is executed when a date is entered in the Return Date field (since there is also a date in the Departure Date field).

However, the user may then go back and change the date in the Departure Date field.  This should cause the rule stated in RS89 to be executed.  If RS89 were not also included in the rule book, the intention would presumably be that the rule stated in RS61 be executed in this situation.  This would violate the principle stated above — that the subject of a data rule statement (in this case Return Date) should signify the data item to be tested by the stated rule (in this case Departure Date).

A solution to this dilemma is to introduce RS90, a data consistency rule^[10] to ensure consistency between the content in the Departure Date and Return Date fields.  The rule stated here will be executed whenever the combination of Departure Date and Return Date is changed, i.e., whenever either Departure Date or Return Date is changed.

This rule statement governs a combination of data items in a transaction, but there is another situation in which multiple data items in a transaction need to be consistent, namely when there are multiple data items of the same name that need to be consistent either with each other or with some other set of data items.  We've already seen one such rule statement, in the form of RS88.  Let's look at two more examples.

In the case of rule statement RS91, a Real Property Transfer Instrument can specify the transfer of multiple shares but the total of shares transferred cannot exceed the total value of the property.  The constraint is therefore on the sum of the set of Share Fractions.  This is only one of various set functions, others being maximum, minimum, average, and number (count); the set function number is used in dependent cardinality rule statements, introduced in Part 3 of this series.^[11]  The value of a set function may be constrained by a range predicate (as in RS91) or an (in)equality predicate, as in RS93.

As for rule statement RS92, it requires that a governed set of data items be the same as some other set.  Other rules might require that the governed set be different to some other set or be a subset or superset of some other set.  If the requirement is that the governed set of data items be a subset of some other set, this is more simply expressed by a rule that requires that each member of the governed set also be a member of the other set (by way of a value set rule statement).  If the requirement is that the governed set be a superset of some other set, include is a more business-friendly verb phrase than be a superset of.

It can be seen that there are four rule statement patterns involved here:

• P24, for statements of rules governing combinations of data items, such as RS90,
  
  
• P25, for statements of rules governing set functions on sets of data items, such as RS91,
  
  
• P26, for statements of rules relating multiple sets of data items, such as RS92,
  
  
• P27, for statements of rules requiring a set of data items to all be equal, such as RS88.

To be continued...
The next article in this series will discuss rules governing temporal data.

References

[1]  The first of which is:  Graham Witt, "A Practical Method of Developing Natural Language Rule Statements (Part 1)," Business Rules Journal, Vol. 10, No. 2 (Feb. 2009), URL:  http://www.BRCommunity.com/a2009/b461.html  

[2]  Graham Witt, Writing Effective Business Rules.  Morgan Kaufmann (2012).  

[3]  Semantics of Business Vocabulary and Business Rules (SBVR), v1.0.  Object Management Group (Jan. 2008).  Available at http://www.omg.org/spec/SBVR/1.0/
     The font and colour conventions used in these rule statements reflect those in the SBVR, namely underlined teal for terms, italic blue for verb phrases, orange for keywords, and double-underlined green for names and other literals.  Note that, for clarity, these conventions are not used for rule statements that exhibit one or more non-recommended characteristics.   

[4]  Statements of rules that require the presence or absence of a data item and/or place a restriction on the maximum or minimum number of occurrences of a data item.  

[5]  A statement of a rule that places a restriction on the values contained in a data item or set of data items (rather than whether or not they must be present and how many there may or must be).  

[6]  A statement of a rule that requires that the content of a data item be a value within a particular range.  

[7]  A statement of a rule that requires that the content of a data item be (or not be) one of a particular set of values (either a fixed set or a set that may change over time), or that the content of a combination of data items match or not match a corresponding combination in a set of records.  

[8]  A statement of any of the following:

1. an integrity constraint by which a DBMS ensures that a particular column (or combination of columns) in a table has different values in every row,
   
   
2. in ORM (Object Role Modelling), a constraint in which each instance of a particular object type may participate in no more than one instance of a particular fact type,
   
   
3. a rule that requires that the content of a data item (or combination of data items) be different to that of the corresponding data item(s) in the same or other records or transactions.  

[9]  A statement of a rule that requires that the content of a data item be the same as that of some other data item (or some specific value).  

[10]  A rule that requires the content of multiple data items to be consistent with each other, other than as provided for by a value set rule, range rule, or equality rule.  

[11]  Graham Witt, "Writing Natural Language Rule Statements — a Systematic Approach:  Part 3 — Other Data Cardinality Rules," Business Rules Journal, Vol. 13, No. 9 (September 2012), URL: http://www.BRCommunity.com/a2012/b669.html  

# # #