Writing Natural Language Rule Statements — a Systematic Approach Part 22: The Syntax of Some Data Content Rule Statements

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 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:

RS121. The Location signified by the Address specified in the Identification
    shown by each Guest of a Registered Club
must be more than 5km from the Location of that Registered Club.
RS123. The Base of each Structure erected on each Land Parcel
must be entirely within that Land Parcel.
RS124. The Base of each Structure erected on each Land Parcel
must be at least 1m from any Boundary of that Land Parcel.
RS125. A Land Parcel resulting from a Real Estate Subdivision
must not overlap any other Land Parcel in any Real Estate Subdivision.
RS126. Each Line Segment making up the Route in each Flight Plan
must be entirely outside any Special Use Airspace.
RS127. The Street Frontage of a Land Parcel
must form part of the Boundary of that Land Parcel.
RS128. The set of Local Government Areas in an Australian State
must completely span that Australian State.

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
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.
  1. Temporal data completeness constraint statements,[17] such as
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.
  1. Temporal single record constraint statements,[18] such as
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.
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.

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
RS129. A data item in a Financial Transaction
must not be updated.
  1. Non-transferable relationship rule statements,[20] such as
RS130. A Purchase Order
must not be transferred from one Customer to another Customer.
  1. State transition constraint statements,[21] such as
RS131. The status of a Loan Application
may be updated to Approved
only if the status that is currently recorded for that Loan Application
    is Under Review.
  1. Monotonic transition constraint statements,[22] such as
RS133. The hourly pay rate of an Employee
must not be decreased.

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.
RS291. An Employee has by definition
exactly one date of birth.
RS292. An Employee
must be allocated to
exactly one Department.

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

RS293. An Employee Record
must specify
exactly one date of birth.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

# # #

Standard citation for this article:


citations icon
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. 6, (Jun. 2014)
URL: http://www.brcommunity.com/a2014/b766.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

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.