Verbalizing Business Rules (Part 12)

Terry   Halpin
Terry Halpin Professor of Computer Science, INTI International University (Malaysia) Read Author Bio || Read All Articles by Terry Halpin

Business rules should be validated by business domain experts, and hence specified in a language easily understood by business people.  This is the twelfth in a series of articles on expressing business rules formally in a high-level, textual language.  This article discusses verbalization of ring constraints.

The first article[2] discussed criteria for a business rules language, and verbalization of simple uniqueness and mandatory constraints on binary associations.  Article two[3] examined hyphen-binding, and verbalization of internal uniqueness constraints that span a whole association, or that apply to n-ary associations.  Article three[4] covered verbalization of basic external uniqueness constraints.  Article four[5] considered relational-style verbalization of external uniqueness constraints involving nesting or long join paths, as well as attribute-style verbalization of uniqueness constraints and simple mandatory constraints.

Article five[6] discussed verbalization of mandatory constraints on roles of n -ary associations, and disjunctive mandatory constraints (also known as inclusive-or constraints) over sets of roles.  Article six[7] considered verbalization of value constraints.  Article seven[8] examined verbalization of subset constraints.  Article eight[9] discussed verbalization of equality constraints.  Article nine[10] covered verbalization of exclusion constraints.  Article ten[11] dealt with verbalization of internal frequency constraints on single roles.  Article eleven[12] considered verbalization of multi-role frequency constraints and external frequency constraints.

Compatible Roles and Ring Constraints

Two roles are said to be compatible if and only if they are played either by the same object type, or by different object types that overlap.  Figure 1 shows four cases of compatible roles, using the ORM graphic notation.  For illustration purposes the compatible roles have been shaded in each case.  In case (a) the roles comprise a binary predicate, and each is played by the same object type A.  In case (b) the compatible roles form part of a ternary predicate, and each is played by the same object type A.  In case (c) the roles are played by object types B and C that share a common supertype A .  In the absence of an explicit or implicit exclusion constraint between the subtypes (see next article), the subtypes are assumed to overlap (i.e., they have some instances in common).  In case (d) the compatible roles are played by a subtype C and its supertype A .

Figure 1.   The shaded roles in each case are compatible.

In each case, a path from the object type A through the compatible role pair and back to A may be visualized as a circle or ring.  A ring constraint may apply only to a pair of compatible roles.  In principle, these roles might belong to different predicates, in which case the ring constraint is external.  But in practice, ring constraints almost always apply to roles from the same predicate, and we confine our attention to such internal cases.  An internal ring constraint may apply only to a pair of compatible roles in the same predicate (binary or longer).

To illustrate some ring constraints, consider the report extract shown in Table 1 .  The table is intended to list each country, as well as the countries that share a land border with it.  For example, Australia has no bordering neighbors of this kind, whereas Belgium has four countries that border it.  The full table lists every country in the left-hand column, but to conserve space only an extract is shown here (e.g., the rows for Austria, Czech Republic, Denmark, Italy, Poland, and Switzerland are among those omitted here).

Table 1. Extract of Country Borders.
Country Bordering Neighbors
Australia  
Belgium France, Germany, Luxembourg, The Netherlands
France Belgium, Germany, Italy, Luxembourg, Switzerland
Germany Austria, Belgium, Czech Republic, Denmark, France, Luxembourg, Poland, Switzerland, The Netherlands
Luxembourg Belgium, France, Germany
Portugal Spain
Spain France, Portugal
The Netherlands Belgium, Germany
... ...

An ORM schema for this example, as well as a sample population extract, is shown in Figure 2(a).  A UML class diagram for this case is shown in Figure 2(b).  The binary fact type Country borders Country is many:many, so has a spanning uniqueness constraint.  In addition it has two ring constraints, depicted as 'ir' (irreflexive) and 'sym' (symmetric) following the ring symbol 'o'.  A binary predicate R with compatible roles is said to be irreflexive if and only if no instance of its object type may bear the relationship to itself (i.e., R is irreflexive iff x ~xRx ).  No country may border itself, so we must not include any fact with the same country playing both roles (e.g., 'Belgium borders Belgium' would violate the constraint).

Figure 2.  (a) ORM schema and sample population, and (b) UML class diagram for Table 1.

A binary predicate R with compatible roles is said to be symmetric if and only if for each relationship instance, the inverse relationship also holds, i.e., R is symmetric iff xy (xRy yRx ).  The borders relation is symmetric because if one country borders a second country, then the second country must border the first.  For example, Belgium borders France, so France must border Belgium.  Another symmetric fact type is Person is a sibling of Person.  For symmetric binary associations, the forward and inverse predicate readings are the same, as shown ('borders').  Figure 2 includes an extract of the fact instances.  In the full population, each pair of countries listed on one row appears in the reverse order on another row.

Notice that the irreflexive ring constraint is a negative constraint in that it forbids some facts (of the form xRx ) from being entered.  In contrast, the symmetric ring constraint is a positive constraint: given one fact (of the form xRy ), the constraint requires the existence of another fact (yRx ).  All the other ring constraints we consider are negative in this sense.

Two other positive ring constraints (reflexive and transitive) are commonly discussed in logic and mathematics.  A relation R is reflexive iff x xRx and is transitive iff xyz (xRy & yRz xRz ).  But reflexive and transitive constraints typically do not apply to base fact types in business domains, so we ignore them.

The names and ORM symbols for the other ring constraints that we do consider are:  asymmetric (oas ); antisymmetric (oans ); intransitive (oit ); and acyclic (oac ).  With an asymmetric relation, if a relationship holds then its inverse cannot hold, i.e., xy (xRy ~yRx ).  For example, Person is taller than Person is asymmetric.  With an antisymmetric relation, if a relationship holds between non-identical objects then its inverse cannot hold, i.e., xy [ (x 1 y & xRy ) ~yRx )].  For example, Number is less than or equal to Number is antisymmetric but not asymmetric.

With an intransitive relation, if a first object bears the relationship to a second, and the second bears the relationship to a third, then the first cannot bear the relationship to the third, i.e., xyz (xRy & yRz ~xRz ).  For example, Person is older than Person is intransitive.  With an acyclic relation, no cycles of any length are allowed (so no object can cycle back to itself through one or more applications of the relationship).  For example, Person is older than Person is acyclic.

As the last example shows, some ring constraints imply other ring constraints (e.g., acyclic implies asymmetric).  In such cases, the stronger constraint should be declared and the weaker (implied) constraint should be omitted.  The following ring constraint implications are the most important to remember: asymmetric implies irreflexive; intransitive implies irreflexive; irreflexive and functional implies intransitive; acyclic implies asymmetric; exclusion implies asymmetric.  For further discussion of these implication theorems, see [1, sec. 7.3].

As an aid to memory, Figure 3 shows an Euler diagram that I devised many years ago to visualize the relationships between the basic ring constraints, as well as what constraint combinations make sense.  For example, the set of intransitive (Oit ) relations is a subset of the irreflexive (Oir ) relations, so intransitive implies irreflexive.  Symmetric (Osym ) may be paired with intransitive or irreflexive but no other ring constraint.  Further discussion of this diagram may be found in [1, sec. 7.3].

Figure 3.  Relationships between ring constraints.

Verbalization of Ring Constraints

The irreflexive and symmetric ring constraints in Figure 2 may be respectively verbalized as shown below.  In the symmetric constraint declaration, the object type variables Country1 and Country2 are understood to be universally quantified.  This assumption may be made explicit by prepending "For each Country1, Country2:" to the formulation.

No Country borders itself.  -- irreflexive
If Country1 borders Country2 then Country2 borders Country1.  -- symmetric

If any ring constraint applies to two roles from a ternary or longer association, then an existential quantifier (e.g., 'some', 'a' or 'an') precedes the names of the object types playing the other roles.  For example, the irreflexive constraint on the first two roles of the ternary association in Figure 4 may be verbalized thus:

No Part contains itself in some Quantity. -- irreflexive

The binary containment relation is not just irreflexive, but acyclic.  So we would normally assert an acyclic constraint here and omit the irreflexive constraint because it is implied by acyclicity.

Figure 4.  The sub-relation formed from the first two roles is irreflexive.

If the object type playing the roles subject to the ring constraint is declared personal, then 'itself' may be replaced by 'himself/herself'.  For example, an irreflexive constraint on Person is a parent of Person may be verbalized as "No Person is a parent of himself/herself."  If the object type is declared to be both personal and male, then 'itself' may be replaced by 'himself'.  If the object type is declared to be both personal and female, then 'itself' may be replaced by 'herself'.  For example, if 'Woman' is declared personal and female, example, then an irreflexive constraint on Woman is a parent of Woman may be verbalized as "No Woman is a parent of herself."

As an example of an asymmetric constraint, consider the reporting relationship depicted in Figure 5(a).  In practice, the reporting relationship is typically acyclic, which implies that it is asymmetric.  But for discussion purposes, suppose we merely wish to declare asymmetry for this example.  The asymmetric constraint may be verbalized thus:

If Employee1 reports to Employee2

then it is impossible that Employee2 reports to Employee1.

Figure 5.  The reporting relation is asymmetric.

If we wish to treat this as a deontic constraint (an obligation that might be violated) rather than as an alethic constraint (a necessity that cannot be violated), then we replace 'impossible' by 'forbidden' thus:

If Employee1 reports to Employee2 then it is forbidden that Employee2 reports to Employee1.

As a variation involving subtyping, the ring asymmetric constraint in Figure 5(b) may be verbalized thus:

If an Employee reports to a Manager then it is impossible that that Manager reports to that Employee.

Since the reporting relation is functional (the first role has a simple uniqueness constraint), it is implied to be intransitive.  So an intransitive constraint need not be declared for this case.  The intransitivity implication holds regardless of which role is functional.  For example, the association Person is the father of Person is 1:many, and hence is implied to be intransitive.  If you have trouble seeing this, try it out with a sample population.

As an example of an intransitive ring constraint that is not implied, consider the parenthood association shown in Figure 6.  This association is many:many, so is not functional, and hence intransitivity is not implied.  Because of the regrettable possibility of incest, the intransitive constraint is deontic (indicated here by a different color) rather than alethic.  The intransitive constraint may be verbalized thus:

If Person1 is a parent of Person2 and Person2 is a parent of Person3

then it is forbidden that Person1 is a parent of Person3.

Figure 6.  The parenthood association is acyclic and deontically intransitive.

If we exclude reincarnation from consideration, the parenthood association is acyclic , as indicated in Figure 6.  This acyclic constraint means that nobody can be one of their own descendants (or one of their own ancestors).  The constraint may be verbalized thus:

No Person may cycle back to itself via a chain of one or more instances of the association Person is a parent of Person.

If the object type playing the roles constrained by the acyclic constraint plays other roles in the association, the verbalization must indicate the constrained roles (e.g., by subscripting the relevant object type variables in the association).

Antisymmetric ring constraints are rare in business domains.  As a somewhat contrived example, consider the inclusion relationship depicted in Figure 7.  If we treat 'includes' as reflexive (so that each group includes itself), then this association is antisymmetric, but not asymmetric.  It may then be verbalized as follows:

If Group1 includes Group2 and Group1 is not identical to Group2

then it is impossible that Group2 includes Group1.

Figure 7.  The group inclusion relationship is antisymmetric.

Of course, if we use 'includes' in an irreflexive sense (so that no group includes itself), the inclusion relationship is asymmetric (which implies that it is antisymmetric).  Indeed, it would then also be acyclic (which implies asymmetric).

That completes our coverage of ring constraints.  The next article considers verbalization of subtype constraints.

References

[1] T.A. Halpin.  Information Modeling and Relational Databases.  Morgan Kaufmann, San Francisco, 2001.  return to article

[2]  T.A. Halpin.  "Verbalizing Business Rules (part 1)," Business Rules Journal, Vol. 4, No. 4 (April 2003).  URL: http://www.BRCommunity.com/a2003/b138.html  return to article

[3] T.A. Halpin.  "Verbalizing Business Rules (part 2)," Business Rules Journal, Vol. 4, No. 6 (June 2003).  URL: http://www.BRCommunity.com/a2003/b152.html  return to article

[4] T.A. Halpin.  "Verbalizing Business Rules (part 3)," Business Rules Journal, Vol. 4, No. 8 (August 2003).  URL: http://www.BRCommunity.com/a2003/b163.html  return to article

[5] T.A. Halpin.  "Verbalizing Business Rules (part 4)," Business Rules Journal, Vol. 4, No. 10 (October 2003).  URL: http://www.BRCommunity.com/a2003/b172.html  return to article

[6] T.A. Halpin.  "Verbalizing Business Rules (part 5)," Business Rules Journal, Vol. 5, No. 2 (February 2004).  URL: http://www.BRCommunity.com/a2004/b179.html  return to article

[7] T.A. Halpin.  "Verbalizing Business Rules (part 6)," Business Rules Journal, Vol. 5, No. 4 (April 2004).  URL: http://www.BRCommunity.com/a2004/b183.html  return to article

[8] T.A. Halpin.  "Verbalizing Business Rules (part 7)," Business Rules Journal, Vol. 5, No. 7 (July 2004).  URL: http://www.BRCommunity.com/a2004/b198.html  return to article

[9] T.A. Halpin.  "Verbalizing Business Rules (part 8)," Business Rules Journal, Vol. 5, No. 9 (September 2004).  URL: http://www.BRCommunity.com/a2004/b205.html  return to article

[10] T.A. Halpin.  "Verbalizing Business Rules (part 9)," Business Rules Journal, Vol. 5, No. 12 (December 2004).  URL: http://www.BRCommunity.com/a2004/b215.html  return to article

[11] T.A. Halpin.  "Verbalizing Business Rules (part 10)," Business Rules Journal, Vol. 6, No. 4 (April 2005).  URL: http://www.BRCommunity.com/a2005/b229.html  return to article

[12] T.A. Halpin.  "Verbalizing Business Rules (part 11)," Business Rules Journal, Vol. 6, No. 6 (June 2005).  URL: http://www.BRCommunity.com/a2005/b238.html  return to article

[13] T.A. Halpin, K. Evans, P. Hallock, & B. MacLean.  Database Modeling with Microsoft Visio for Enterprise Architects.  Morgan Kaufmann, San Francisco, 2003.  

[14] Object Management Group.  UML 2.0 Infrastructure.  Object Management Group, 2003.  URL:  http://www.omg.org/uml  

[15] Object Management Group.  UML 2.0 Object Constraint Language.  Object Management Group, 2003.  URL:  http://www.omg.org/uml  

# # #

Standard citation for this article:


citations icon
Terry Halpin, "Verbalizing Business Rules (Part 12)" Business Rules Journal, Vol. 6, No. 10, (Oct. 2005)
URL: http://www.brcommunity.com/a2005/b252.html

About our Contributor:


Terry   Halpin
Terry Halpin Professor of Computer Science, INTI International University (Malaysia)

Dr. Terry Halpin, BSc, DipEd, BA, MLitStud, PhD, is a Professor of Computer Science at INTI International University, Malaysia, and a data modeling consultant. His prior industrial background includes many years of research and development of data modeling technology at Asymetrix Corporation, InfoModelers Inc., Visio Corporation, Microsoft Corporation, and LogicBlox. His previous academic background includes many years teaching computer science at the University of Queensland (Australia) and Neumont University (USA). His current research focuses on conceptual modeling and conceptual query technology. His doctoral thesis formalized Object-Role Modeling (ORM/NIAM), and his publications include over 200 technical papers and seven books, including Information Modeling and Relational Databases, 2nd Edition (2008: Morgan Kaufmann). Dr. Halpin may be reached directly at t.halpin@live.com.

Read All Articles by Terry Halpin
Subscribe to the eBRJ Newsletter
CONTRIBUTOR ARCHIVES
Logical Data Modeling (Part 14)
Logical Data Modeling (Part 13)
Logical Data Modeling (Part 12)
Logical Data Modeling (Part 11)
Logical Data Modeling (Part 10)
In The Spotlight
 John A. Zachman
';
The Issue Is THE ENTERPRISE By John A. Zachman Jan. 2017 | Vol. 18, Iss. 1
 Silvie  Spreeuwenberg

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.