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] as well as the following data content rule statements:^[5]  range rule statements,^[6] value set rule statements,^[7] uniqueness constraint statements,^[8] (in)equality rule statements,^[9] data consistency rule statements,^[10] temporal data constraint statements,^[11] and data item format rule statements.^[12]  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.

We will now look at a further type of data content rule (the spatial data constraint), as well as various types of data update rules.

Spatial Data Constraints

Systems increasingly cater for spatial (or geographic) data.  A user interface can include such data by such means as interactive maps or by geocoding of address or placename data.

Spatial or geographical constraints at a relatively coarse level include such things as the requirement that a residential or delivery address be in a certain country or state.  For example, US mail order houses generally only deliver to US addresses.  This can be handled simply by requiring that the country component of the delivery address (if one is provided) be restricted to the value "US" or "United States".  This restriction can be expressed in an equality rule statement such as RS119.

An example of a finer-grained spatial constraint is one that governs registered clubs in Australia (providing meals, drinks, entertainment, and various activities).  If you live within 5km of a club, you can only use the facilities there if you become a paid and registered member of that club.  Only a person whose residential address (as printed on their driving licence or other identification) is more than 5km from the club premises can use the facilities as a guest.  This constraint is expressed in rule statement RS120.

While the wording of RS120 makes sense to a human reader, it bears closer examination.  It takes the form of a range rule statement (the predicate starts with the range operator be more than) but the subject is not a numeric data item.  Rule statement RS120 is actually an abbreviated version of RS121 (which could in turn be considered as an abbreviation of RS122!); however, RS120 is by far the easiest to read.

A spatial data constraint prescribes or prohibits 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.

Depending on the system in use, geocoding an address will yield a point or a polygon. Rule statement RS120 can therefore be considered as a constraint on the location of the point or polygon associated with a guest's address, namely one that requires that that point or polygon be within the defined circle.

There may be other constraints on polygon data.  For example, a polygon specified in a dataset may be:

1. obliged to be entirely within some other polygon, as expressed in rule statement RS123:

2. obliged to be a minimum (or maximum) distance inside (or outside) the boundary of a polygon, as expressed in rule statement RS124:

3. prohibited from intersecting or overlapping some other polygon or polygons:  for example, when a real estate parcel is subdivided (such as when previously-rural land is divided into individual blocks of land for housing) the resulting individual parcels must not overlap, as expressed in rule statement RS125:

4. obliged to be adjacent to (share a common boundary with) some other polygon.

Spatial data constraints can also govern line segment data.  For example, a line segment specified in a dataset may be:

1. obliged to be entirely within (or entirely outside) a polygon or solid figure, as expressed in rule statement RS126:

2. obliged to form part of the boundary of a polygon or solid figure, as expressed in rule statement RS127:

Spatial data constraints can also govern sets of spatial objects.  For example, a spatial data constraint may require that a set of polygons specified in a dataset completely spans some other polygon, as in rule statement RS128.

Of course, many of these constraints are actually constraints on the real-world object(s) represented by the spatial data, but generally an organisation is only able to perform tests on the data about those real-world objects rather than the objects themselves.  In particular, with respect to real estate, the information submitted to and registered at a Land Registry has more legal standing as to the extent of Land Parcels than anything in the physical world.

Other spatial data constraints you might encounter include those that:

1. oblige a point to be outside a polygon or solid figure
   
   
2. oblige a point to be a minimum (or maximum) distance inside (or outside) the boundary of a polygon or solid figure
   
   
3. oblige a point to be on a line segment
   
   
4. oblige a point to be a minimum (or maximum) distance from a line segment
   
   
5. prohibit a point from being on a line segment
   
   
6. oblige a line segment to intersect (i.e., cross) another line segment
   
   
7. oblige a line segment to meet another line segment (i.e., one end of the subject line segment must lie on the other line segment)
   
   
8. prohibit a line segment from intersecting or meeting another line segment.

Rule Statement Pattern for Spatial Data Constraints

Due to the wide variety of spatial data constraints, this pattern is not very prescriptive.  It takes much the same form as those for other data content rule statements.

P35.	<spatial data constraint predicate> ::= <spatial operator> {each | the | any} <spatial data item term> <qualifying clause>
P36.	<spatial operator> ::= {be {entirely |} {within | outside} | be on | overlap | be adjacent to | form part of the boundary of | cross | meet | be on | completely span}

Data Update Rules

A data update rule either prohibits update of a data item or places restrictions on the new value of a data item in terms of its existing value.  While data cardinality rules and data content rules may be used to constrain either the content of a persistent data resource such as a database or transient data as in a data entry facility or an electronic message, data update rules only constrain persistent data (although such constraints have implications for data entry, as discussed below).

There are four varieties of data update rule:

1. A data update prohibition rule prohibits update of a particular data item or set of data items, for example:

2. A non-transferable relationship rule specifies that a recorded relationship between two entity instances cannot be transferred to a different entity instance, for example:

3. A state transition constraint limits the changes in a data item to a set of valid transitions, for example, the allowed state transitions for loan applications might be:
   1. submitted ⇒ under review
   2. under review ⇒ approved
   3. under review ⇒ rejected.

Thus a loan cannot transition to "approved" status directly from "submitted" status without passing through "under review" status.  Rule statement RS131 prevents this.

We can assume that all loan application status transitions are recorded.  Where we cannot guarantee that all status transitions are recorded, there may be less scope for such constraints.  For example, an employee may change marital status without advising his or her employer; as a result, a transition of "never married" to "divorced" or "widowed" status is possible in a Human Resources system even if not in the real world.  However there may be some transitions which are impossible even in a system that may not record all transitions, as illustrated in RS132.

4. A monotonic transition constraint requires that a numeric value can either only increase or only decrease, e.g., some employment arrangements prohibit a reduction in a person's hourly pay rate, for example:

Note that data update prohibition rules and non-transferable relationship rules govern system behaviour as much as user behaviour.  A system allowing recording of financial transactions should only display existing transactions in read-only mode; similarly, a purchase order management system should, when displaying an existing purchase order, display the customer number and/or name in read-only mode.

Rule Statement Patterns for Data Update Rules

Each type of data update rule has its own rule statement pattern.

To be continued...
The next article in this series will discuss complex data types and how they can be used to reduce rule statement proliferation.

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 (or different to) 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]  A statement of a rule that constrains one or more temporal data items (dates or times).  

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

# # #