Writing Natural Language Rule Statements — a Systematic Approach Part 12: Spatial Data Constraints, Data Update Rules

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

RS119. The Country specified in the Delivery Address in each Online Order
    must be United States.

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.

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

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.

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.
RS122. The Location signified by the Address specified in the Identification
        shown by each Guest of a Registered Club
    must be within a Circle that
        has a Radius of 5km and
        is centred on the Location of that Registered Club.

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:
RS123. The Base of each Structure erected on each Land Parcel
    must be entirely within that Land Parcel.
  1. obliged to be a minimum (or maximum) distance inside (or outside) the boundary of a polygon, as expressed in rule statement RS124:
RS124. The Base of each Structure erected on each Land Parcel
    must be at least 1m from any Boundary of that Land Parcel.
  1. 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:
RS125. A Land Parcel resulting from a Real Estate Subdivision
    must not overlap any other Land Parcel in any Real Estate Subdivision.
  1. 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:
RS126. Each Line Segment making up the Route in each Flight Plan
    must be entirely outside any Special Use Airspace.
  1. obliged to form part of the boundary of a polygon or solid figure, as expressed in rule statement RS127:
RS127. The Street Frontage of a Land Parcel
    must form part of the Boundary of that Land Parcel.

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.

RS128. The set of Local Government Areas in an Australian State
    must completely span that Australian State.

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.

P34.  <spatial data constraint statement> ::=
{Each | The | A} {set of |} <spatial data item term>
    {<qualifying clause> |}

must {not |} <spatial data constraint predicate>
{{if | unless} <conditional clause> |}.
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:
RS129. A Data Item in a Financial Transaction
    must not be updated.
  1. A non-transferable relationship rule specifies that a recorded relationship between two entity instances cannot be transferred to a different entity instance, for example:
RS130. A Purchase Order
    must not be transferred from one Customer to another Customer.
  1. 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.

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.

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.

RS132. The Marital Status of an Employee
    may be updated to Never Married
    only if the Marital Status that is currently recorded for that Employee
        is Unknown.
  1. 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:
RS133. The Hourly Pay Rate of an Employee
    must not be decreased.

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.

P37.  <data update prohibition rule statement> ::=
{The | A | An} <attribute term> {(if any) |}
    {{in | for} {the | a} <complex attribute term> {(if any) |} |}
    {in | of} {a | an} <entity term>

must not be updated
{{if | unless} <conditional clause> |}.
P38.  <non-transferable relationship rule statement> ::=
{A | An} <entity term>
must not be transferred from one <entity term> to another <entity term>
{{if | unless} <conditional clause> |}.
P39.  <state transition constraint statement> ::=
The  <attribute term> {(if any) |}
    {{in | for} {the | a} <complex attribute term> {(if any) |} |}
    {in | of} {a | an} <entity term>

may be updated to <literal>
only if <conditional clause>.
P40.  <monotonic transition constraint statement> ::=
The  <attribute term> {(if any) |}
    {{in | for} {the | a} <complex attribute term> {(if any) |} |}
    {in | of} {a | an} <entity term>

must not be {increased | decreased}
{{if | unless} <conditional clause> |}.

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

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

# # #

Standard citation for this article:


citations icon
Graham Witt , "Writing Natural Language Rule Statements — a Systematic Approach Part 12: Spatial Data Constraints, Data Update Rules" Business Rules Journal Vol. 14, No. 6, (Jun. 2013)
URL: http://www.brcommunity.com/a2013/b707.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.