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 earlier articles in this series (see the "Language Archives" sidebar) we have looked at standardised rule statements for various types of operative rules^[4] (data rules,^[5] activity rules,^[6] and party rules,^[7]) and definitional rules.^[8] Each specific 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 the last two articles^[9]we looked at the syntax of data cardinality rule statements^[10] and some data content rule statements^[11] in general.  In this article we will look at the general syntax of other data rule statements:  spatial data constraint statements,^[12] temporal data constraint statements,^[13] and data update rule statements,^[14] as well as the use of rule statements in describing a data model.

Review of spatial data constraint statements

In this series we briefly encountered some spatial data constraint statements, such as:

The anatomy of a spatial data constraint statement

Spatial data constraint statements — like other data rule statements — are operative rule statements,^[15] consisting of the following syntactic components in sequence:

• an initial determiner (Each, The, A, An, or At least one)
• a subject
• the keyword must, possibly followed by not
• a predicate
• possibly a conditional clause following if, unless, or after.

The subject of a spatial data constraint statement

The subject of any spatial constraint rule statement consists of:

• a subject noun phrase, either:
• the term signifying the data item for which the content is constrained (as in RS121 – RS127)
  or
• set of followed by the plural form of the term signifying a set of data items for which the content is constrained (as in RS128 )
  
  
• at least one prepositional phrase, such as
• of each Structure
• erected on each Land Parcel
• resulting from a Real Estate Subdivision.

The predicate of a spatial data constraint statement

The predicate of a spatial data constraint statement consists of:

• a verb phrase signifying a spatial operator, such as be more than, be entirely within, be at least, be on, overlap, be entirely outside, form part of, completely span; other useful verb phrases include be adjacent to, cross, meet
  
  
• if the verb phrase is be more than or be at least, a literal (such as 1m) followed by from or away from
  
  
• a qualified term signifying the object of the verb phrase, such as
• that Land Parcel
• any Boundary of that Land Parcel.

Review of temporal data constraint statements

We have also encountered various types of temporal data constraint statements:

1. Temporal data non-overlap constraint statements,^[16] such as

2. Temporal data completeness constraint statements,^[17] such as

3. Temporal single record constraint statements,^[18] such as

The anatomy of a temporal data constraint statement

Temporal data constraint statements are also operative rule statements, consisting of the following syntactic components in sequence:

• an initial determiner (Each, The, A, An, or At least one)
• a subject
• the keyword must, followed by not in the case of a temporal data non-overlap constraint statement
• a predicate
• possibly a conditional clause following if, unless, or after.

The subject of a temporal data constraint statement

The subject of any temporal constraint rule statement consists of:

• a subject noun phrase:
• effective time period (as in RS94), which must be used in a temporal data non-overlap constraint statement
• day within the lifespan (as in RS95), which must be used in a temporal data completeness constraint statement
  or
• either data item (as in RS97) or the term signifying the time-variant data item (as in RS98), which must be used in a temporal single record constraint statement
  
• specified
  
• at least one prepositional phrase (see below).

The prepositional phrase in the subject of temporal data non-overlap constraint statement consists of:

• in each
• the term signifying the versions of the time-variant entity, such as Insurance Product Version.

The prepositional phrase in the subject of temporal data completeness constraint statement consists of:

• for each
• the term signifying the time-variant data item, such as Insurance Product.

The prepositional phrase in the subject of temporal data single record constraint statement consists of:

• in each
• the term signifying the versions of the time-variant entity, such as Insurance Product Version
• for each
• the term signifying the time-variant data item, such as Insurance Product.

The predicate of a temporal data constraint statement

Predicates of temporal data constraint statements take different forms depending on the type of rule being stated.

The predicate of a temporal data non-overlap constraint statement consists of:

• overlap the
• the subject noun phrase
• specified
• the prepositional phrases in the subject, with any other in place of each
• a final prepositional phrase identifying the time-variant entity, such as for the same Insurance Product.

The predicate of a temporal data completeness constraint statement consists of:

• be within the effective time period specified in exactly one
• a noun phrase signifying the versions of the time-variant entity, such as Insurance Product Version
• for that
• a noun phrase signifying the time-variant entity, such as Insurance Product.

The predicate of a temporal single record constraint statement consists of:

• be different to the
• either:
• same data item (if the subject noun phrase is data item)
  or
• the subject noun phrase (if other than data item)
• specified in the latest of the earlier
• the plural form of the term signifying the versions of the time-variant entity, such as Insurance Product Versions
• for that
• the term signifying the time-variant data item, such as Insurance Product.

Review of data update rule statements

We have also encountered various types of data update rule statements:

1. Data update prohibition rule statements,^[19] such as

2. Non-transferable relationship rule statements,^[20] such as

3. State transition constraint statements,^[21] such as

4. Monotonic transition constraint statements,^[22] such as

The anatomy of a data update rule statement

Data update rule statements are also operative rule statements, consisting of the following syntactic components in sequence:

• an initial determiner (The, A, or An)
• a subject
• either:
• the keyword may in the case of a state transition constraint statement
  or
• the keywords must not for any other type of data update rule statement
• a predicate
• either:
• a mandatory conditional clause following only if in the case of a state transition constraint statement
  or
• an optional conditional clause following if, unless, or after for any other type of data update rule statement.

The subject of a data update rule statement

The subject of any data update rule statement consists of the following syntactic components in sequence:

• a subject noun phrase, either:
• the term signifying the data item for which update is constrained (as in RS130, RS131, and RS133)
  or
• data item in a data update prohibition rule statement (such as RS129) if all data items are non-updateable
• at least one prepositional phrase, such as
• in a Financial Transaction
• of a Loan Application.

The predicate of a data update rule statement

Predicates of data update rule statements take different forms depending on the type of rule being stated.

The predicate of a data update prohibition rule statement is simply:

• be updated.

The predicate of a non-transferable relationship rule statement consists of the following syntactic components in sequence:

• be transferred from one
• the term signifying the object or entity at the opposite end of the relationship from the object or entity signified by the subject noun phrase (e.g., Customer in RS130)
• to another
• again the term signifying the object or entity at the opposite end of the relationship.

The predicate of a state transition constraint statement consists of the following syntactic components in sequence:

• be updated to
• the literal signifying the status to which transitions are constrained (e.g., Approved in RS131).

The predicate of a monotonic transition constraint statement is simply:

• be increased
  or
• be decreased.

Describing a data model with rule statements

I am frequently asked about the nature of the relationship between business rules and data models.  There is a school of thought that asserts that all the business rules that govern a system can be documented in the system data model, or indeed that all rules are so documented as a matter of course.

Depending on the modelling tool it may be possible to document all data rules that govern each entity, attribute, and relationship.  Even if this is possible and taken advantage of, it would cover only data rules, not activity (process) rules or party rules.

Of course any given data model may model one of three things:

1. a subset of the real world that is of interest to the organisation
2. a database that the organisation will use to record information about various real-world concepts
3. transactions posted to that database.

Of course some data models end up including both real-world and data objects (database tables and transactions), often without making clear which are which!

A model of the real world will include both:

1. definitional rules (described in articles 19^[23] and 20^[24]), such as RS291, which cannot be violated, and
2. data rules (described in subsequent articles), such as RS292, which can be violated.

By contrast a model of a database or transaction set will only include data rules, such as RS293.

The fact that the date of birth column may have been declared as mandatory in the database schema does not mean that that constraint cannot be violated (such a declaration in the schema is a means of implementing the rule and may have been omitted).

Note that some organisations prefer noun phrases such as Record of an Employee instead of terms such as Employee Record.  Still others recognise that record is really a keyword in this context, and so prefer to render noun phrases such as this as record of an Employee.  These are all valid alternatives, so long as they are used consistently across the organisation's rule statements.

A model of a database may include any of the types of data rules we have encountered, whereas a model of a transaction set will be unlikely to include either temporal data rules or data update rules.  In theory the rules governing a transaction set can be inferred from the rules governing the database to which those transactions are posted, but the inference logic is complex and subtle.  I shall provide an overview of the relationships between database model rules and transaction model rules in a subsequent article.

To be continued...
In the next article in this series I will look at the general syntax of activity and party rule statements.

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]  A rule that states what must or must not happen in particular circumstances, and which can therefore be contravened, by contrast with a definitional rule.  

[5]  A rule that constrains the data included in a transaction (a form or message) or a persistent data set (e.g., a database record).  

[6]  A rule that constrains the operation of one or more business processes or other activities.  

[7]  A rule that makes a distinction between different parties or the roles they play.  

[8]  A rule that defines a construct created or used by an organisation (or the industry within which it operates), or defines a property of such a construct, and which cannot therefore be contravened, by contrast with an operative rule.  

[9]  Graham Witt, "Writing Natural Language Rule Statements — a Systematic Approach — Part 21:  The syntax of Data Cardinality Rule Statements," Business Rules Journal, Vol. 15, No. 4 (Mar. 2014). URL: http://www.brcommunity.com/a2014/b757.html and
Graham Witt, "Writing Natural Language Rule Statements — a Systematic Approach — Part 22:  The Syntax of Some Data Content Rule Statements," Business Rules Journal, Vol. 15, No. 5 (May 2014), URL:  http://www.BRCommunity.com/a2014/b762.html  

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

[11]  Statements of rules that place 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).  

[12]  Statements of rules that prescribe or prohibit the content of data items representing spatial objects (points, line segments, polygons, other plane figures such as circles, or solid figures in 3-dimensional space), generally by reference to required relationships between those spatial objects and other spatial objects.  

[13]  A statement of a rule that constrains one or more temporal data items (dates or times).  

[14]  A statement of a rule that specifies the required format of a data item.  

[15]  A statement of a rule that specifies what must or must not happen in particular circumstances, and which can therefore be contravened, by contrast with a definitional rule.  

[16]  Statements of rules that require that the time periods specified in a set of records do not overlap.  

[17]  Statements of rules that require that the time periods specified in a set of records are contiguous and between them completely span some other time period.  

[18]  Statements of rules that require that a temporal state of affairs be recorded using a single record rather than multiple records.  

[19]  Statements of rules that prohibit update of a particular data item or set of data items.  

[20]  Statements of rules that specify that a recorded relationship between two entity instances cannot be transferred to a different entity instance.  

[21]  Statements of rules that limit the changes in a data item to a set of valid transitions.  

[22]  Statements of rules that require that a numeric value can either only increase or only decrease.  

[23]  Graham Witt, "Writing Natural Language Rule Statements — a Systematic Approach — Part 19:  Some Definitional Rules in Detail," Business Rules Journal, Vol. 15, No. 2 (Feb. 2014). URL:  http://www.BRCommunity.com/a2014/b745.html  

[24]  Graham Witt, "Writing Natural Language Rule Statements — a Systematic Approach — Part 20:  More Definitional Rules in Detail," Business Rules Journal, Vol. 15, No. 3 (Mar. 2014). URL:  http://www.BRCommunity.com/a2014/b752.html  

# # #