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

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

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.

2. 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.,

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.

3. 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.,

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.

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

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

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.

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  

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

[11]  Date, C. J., Darwen, H., & Lorentzos, N. A. (2003). Temporal Data and the Relational Model. San Francisco, CA, USA: Morgan Kaufman.  

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

[13]  Expiration Date in North America.  

# # #