Writing Natural Language Rule Statements — a Systematic Approach Part 8: Inequality Rules, Complemented Predicates, Data Consistency Rules

Graham   Witt
Graham Witt Consultant / Author Read Author Bio || Read All Articles by Graham Witt
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.

RS86.  The Destination City specified in each Flight Booking Request
must
be different to the Origin City specified in that Flight Booking Request.

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.

P19.  <(in)equality rule statement> ::=
{Each | The} {<data item term> {(if any) |} |
combination of <item combination list>}
            specified
            {for {the | each} <complex data item term> {(if any) |} |}
            {in | on} each <transaction term>
            {<qualifying clause> |}
must <(in)equality predicate>
{{if | unless} <conditional clause>|}.
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).

RS87.  Each Date specified in each Reward Flight Booking
must
be other than one of the Blackout Dates specified in the Rewards Programme.

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

P18.  <value set predicate> ::=
be {other than |} {<value list> |
{one of the {<data item term> | combinations of <item combination list>}}
<qualifying clause>}

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).

RS88.  The Travel Class specified for each Flight
        in
each Flight Booking Confirmation
must
be the same as the Travel Class specified for each other Flight
        in
that Flight Booking Confirmation.

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:

RS61.  The Return Date specified in each Travel Insurance Application
must be later than the Departure Date specified in that Travel Insurance Application.
RS89.  The Departure Date specified in each Travel Insurance Application
must be earlier than the Return Date specified in that Travel Insurance Application.

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.

RS90.  The combination of Departure Date and Return Date
        specified in
each Travel Insurance Application
must be such that the Return Date is later than the Departure Date.

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.

RS91.  The sum of the Share Fractions of the Shares Transferred
        specified in
each Real Property Transfer Instrument
must
be no more than 1.
RS92.  The set of Passengers specified for each Flight
        in
each Flight Booking Confirmation
must
be the same as the set of Passengers specified for each other Flight
        in
that Flight Booking Confirmation.

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.

RS93.  The sum of the Share Fractions of the Shares Held
        specified in
each Land Title
must
be equal to 1.

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.
P24.  <data combination consistency rule statement> ::=
The combination of <item combination list>
            specified
            {for {the | each} <complex data item term> {(if any) |} |}
            {in | on} each <transaction term>
            {<qualifying clause> |}

must be such that <conditional clause>
{{if | unless} <conditional clause> |}.
P25.  <set function rule statement> ::=
The <set function> of <data item term>
            specified {for {the | each} <complex data item term> {(if any) |} |}
            {in | on} each <transaction term>

must {<range predicate> | <(in)equality predicate>}
{{if | unless} <conditional clause> |}.
P26.  <set consistency rule statement> ::=
{Each | The} set of <data item term>
            specified {for {the | each} <complex data item term> {(if any) |} |}
            {in | on} each <transaction term>

must {be the same as | be different to | include} the set of <term>
            {<qualifying clause> |}

{{if | unless} <conditional clause> |}.
P27.  <set equality rule statement> ::=
{Each | The} <data item term>
            specified {for {the | each} <complex data item term> {(if any) |} |}
            {in | on} each <transaction term>

must be the same as
            {each other | the} <data item term>
            specified {for {the | each other} <complex data item term> |}
            {in | on} that <transaction term>

{{if | unless} <conditional clause> |}.

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  return to article

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

[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.   return to article

[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.  return to article

[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).  return to article

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

[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.  return to article

[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.  return to article

[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).  return to article

[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.  return to article

[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  return to article

# # #

Standard citation for this article:


citations icon
Graham Witt , "Writing Natural Language Rule Statements — a Systematic Approach Part 8: Inequality Rules, Complemented Predicates, Data Consistency Rules" Business Rules Journal Vol. 14, No. 2, (Feb. 2013)
URL: http://www.brcommunity.com/a2013/b690.html

About our Contributor:


Graham   Witt
Graham Witt Consultant / Author

Graham Witt has over 30 years of experience in assisting organisations to acquire relevant and effective IT solutions. NSW clients include the Department of Lands, Sydney Water, and WorkCover while Victorian clients include the Departments of Sustainability & Environment, Education & Early Childhood Development, and Human Services. Graham previously headed the information management and business rules practice in Ajilon's Sydney (Australia) office.

Graham has developed specialist expertise in business requirements, architectures, information management, user interface design, data modelling, relational database design, data quality, business rules, and the use of metadata repositories & CASE tools. He has also provided data modelling, database design, and business rules training to various clients including NAB, Telstra, British Columbia Government, and ASIC and in the form of public courses run by Simsion Bowles and Associates (Australia) and DebTech (USA).

He is the co-author, with Graeme Simsion, of the widely-used textbook "Data Modeling Essentials" and is the author of the newly published book, "Writing Effective Business Rules" (published by Elsevier). Graham has presented at conferences in Australia, the US, the UK, and France. Contact him at gwitt@pacific.net.au.

Read All Articles by Graham Witt
Subscribe to the eBRJ Newsletter
In The Spotlight
 Silvie  Spreeuwenberg
 John A. Zachman
';
The Issue Is THE ENTERPRISE By John A. Zachman Jan. 2017 | Vol. 18, Iss. 1

Online Interactive Training Series

In response to a great many requests, Business Rule Solutions now offers at-a-distance learning options. No travel, no backlogs, no hassles. Same great instructors, but with schedules, content and pricing designed to meet the special needs of busy professionals.