Writing Natural Language Rule Statements — a Systematic Approach Part 9: Temporal Data Constraints

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 five types of data content rule statement,[5] namely range rule statements,[6] value set rule statements,[7] uniqueness constraint statements,[8] (in)equality rule statements,[9] and data consistency rule statements.[10] 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 data content rule statements that govern temporal data (data items that represent time points or time periods).

Temporal Data Constraints

A temporal data constraint constrains one or more temporal data items.  There are various subcategories of temporal constraint.

A simple temporal data constraint requires that a particular date or time fall within a certain temporal range, e.g.,

RS58. The Departure Date
    specified in each Travel Insurance Application
must be later than the Date
    on which that Travel Insurance Application is made.

This rule statement (which we encountered in a previous article in this series) is simply a range rule statement governing a temporal data item and requires no additional pattern.

Other temporal constraints prescribe or prohibit relationships between time periods.  The following rule statements illustrate the most common of these constraints:

  1. There are many situations where the properties of some real-world object vary over time, and it is necessary to retain records of earlier as well as current properties of that object.  For example, the price (or parameters used to calculate the price) of a product varies over time, but since currently active instances of a product may have been sold before the latest price change, it is necessary to retain records of earlier as well as current pricing.  It is important that only one pricing record applies to each date in the life of a product, i.e., that there is no temporal overlap between pricing records.  This requires a temporal data non-overlap constraint:  a requirement that the time periods specified in a set of records do not overlap, e.g.,
RS94. The Effective Time Period
    specified in each Insurance Product Version
must not overlap the Effective Time Period
     specified in any other Insurance Product Version
     for the same Insurance Product.

What would it mean if this constraint were not in force?  A pair of Insurance Product Versions could exist for the same Insurance Product with overlapping time periods.  If this were so, any query about the premium or other properties of that product for any date within the period of overlap would return multiple, possibly conflicting results.

  1. Historical records such as these are also subject to a temporal data completeness constraint:  a requirement that the time periods specified in a set of records (in this case product version records) are contiguous and, between them, completely span some other time period (in this case the lifespan of the product), e.g.,
RS95. Each Day within the Lifespan
    specified for each Insurance Product
must be within the Effective Time Period
     specified in exactly one Insurance Product Version
     for that Insurance Product.

Note that the 'exactly one' determiner implies the corresponding temporal data non-overlap constraint.  If the non-overlap constraint does not apply but the completeness constraint applies, the determiner 'at least one' should be used instead.

What would it mean if this constraint were not in force?  At least part of the lifespan of an Insurance Product would not be covered by any Insurance Product Version.  If this were so, any query about the premium or other properties of that product for any date not covered would return no results.

  1. Historical records such as these are also subject to a temporal data inclusion constraint:  a requirement that the time periods specified in a set of records (in this case, product version records) do not fall outside some other time period (in this case, the lifespan of the product), e.g.,
RS96. Each Day within the Effective Time Period
     specified for each Insurance Product Version
for each Insurance Product
     must be within the Lifespan
     specified for that Insurance Product.

What would it mean if this constraint were not in force?  At least one Insurance Product Version would cover (at least in part) a time period outside the lifespan of the corresponding Insurance Product.  If this were so, it might not affect most (or any) queries, but there is always a risk of inconsistent results being returned.

  1. Historical records such as these are also subject to a less obvious requirement raised by Date, Darwen, & Lorentzos.[11]  This arises from the fact that it is theoretically possible to create two records with two contiguous time periods and all other content identical.  For example, if the premium calculation parameters for Product #123 were updated on 1 January 2010 and 5 April 2011, there should be an Insurance Product Version for Product #123 that covers the period 1 January 2010 to 4 April 2011.  There is, of course, nothing to stop us recording this situation using two otherwise identical Insurance Product Version records covering (respectively) the periods 1 January 2010 to 4 April 2010, and 5 April 2010 to 4 April 2011.  However, to do so causes a variety of problems, e.g., a query as to which products were updated in April 2010 would erroneously include Product #123.  Creation of such multiple records can be prevented by requiring (in this case) that a new version record only be created for a change in at least one parameter, as in RS97.  Date, Darwen, & Lorentzos refer to such multiple records as "circumlocution"; given the fact that these constraints require a temporal state of affairs to be recorded using a single record rather than multiple records, I refer to them as temporal single record constraints.
RS97. At least one Data Item
     specified in each Insurance Product Version
     for each Insurance Product
must be different to the same Data Item
     specified in the latest of the earlier Insurance Product Versions
     for that Insurance Product.

Note that this formulation is appropriate if Insurance Product Version records hold more than one time-variant data item.  If, however, there are separate version records for each time-variant data item,[12] a separate rule statement is required for each such data item, e.g.,

RS98. The Base Premium
     specified in each Insurance Product Base Premium Version
     for each Insurance Product
must be different to the Base Premium
     specified in the latest of the earlier Insurance Product Base Premium Versions
     for that Insurance Product.

What would it mean if this type of constraint were not in force?  As described above there is a risk of inconsistent results being returned.

Patterns for Temporal Data Constraints

Each type of temporal data constraint has its own rule statement pattern.  These involve the following types of terms:

  • <object term>:  the term signifying the real-world objects about which earlier as well as current version data is maintained

  • <object version term>:  the term signifying the versions of that real-world object that are maintained

  • <time period term>:  any term signifying a time period of interest with respect to the real-world object or its versions, e.g., Lifespan, Effective Time Period; note that typically a lifespan or time period are specified using two dates, e.g., Start Date and End Date, or Effective Date and Expiry Date.[13]

  • <time point term>:  the term signifying the "granularity" (precision) with which versions are distinguished:

    • if changes are made so as to come into effect at midnight, we can legitimately refer to the version that is effective on any given date without reference to the time of day, in which case, we can use Day or Date;

    • if, however, changes may occur at any time of day and are effective immediately, we need to specify not only the date but the time of day to establish which version is in effect, and we would use Date and Time or Timestamp.
P28.  <temporal data non-overlap constraint statement> ::=
The <time period term>
     specified {in | for} each <object version term>
must not overlap the <time period term>
     specified {in | for} any other <object version term>
     for the same <object term>.
P29.  <temporal data completeness constraint statement> ::=
Each <time point term> within the <time period term>
     specified for each <object term>
must be within the <time period term>
     specified {in | for} {exactly | at least} one <object version term>
     for that <object term>.
P30.  <temporal data inclusion constraint statement> ::=
Each <time point term> within the <time period term>
     specified for each <object version term>
     for each <object term>
must be within the <time period term>
     specified for that <object term>.
P31.  <temporal single record constraint statement> ::=
{At least one Data Item | The <data item term>}
     specified in each <object version term>
     for each <object term>
must be different to the {same Data Item | <data item term>}
     specified in the latest of the earlier <object version term>
     for that <object term>.

To be continued...
The next article in this series will discuss some other ways in which the time dimension affects rules.

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 statement of 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]  Date, C. J., Darwen, H., & Lorentzos, N. A. (2003). Temporal Data and the Relational Model. San Francisco, CA, USA: Morgan Kaufman.  return to article

[12]  The version data is then in 6NF (6th Normal Form).  return to article

[13]  Expiration Date in North America.  return to article

# # #

Standard citation for this article:


citations icon
Graham Witt, "Writing Natural Language Rule Statements — a Systematic Approach Part 9: Temporal Data Constraints" Business Rules Journal, Vol. 14, No. 3, (Mar. 2013)
URL: http://www.brcommunity.com/a2013/b694.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
 Ronald G. Ross
The BRSolutions Professional Training Suite

BRSolutions Professional Training Suite

All About Concepts, Policies, Rules, Decisions & Requirements
We want to share some insights with you that will positively rock your world. They will absolutely change the way you think and go about your work. We would like to give you high-leverage opportunities to add value to your initiatives, and give you innovative new techniques for developing great business solutions.