Published in TDAN.com April 2002
Previously in this newsletter I presented ideas about what a metadata repository might actually look like to support analysis, relational design, and object-oriented design. This article and the
one that preceded it look at many of the same elements, but from a different point of view – the perspective of business rules.
Business rules are constraints on a business. While a data (or object) model describes the structure of a business – what the business can do – for the most part, it cannot describe
what it must do, or what it cannot do. Indeed, there are few notations available for representing business rules in all their subtlety.
The advantage of looking at business rules from a metadata perspective is that we can look at the nature of any kind of rules we want, even if there are no CASE Tools that describe the rules
themselves. We can explore what is needed to describe business rules without having to limit ourselves to current notations or technology.
The Business Rules Group (formerly the GUIDE Project on Business Rules) published a paper in 1995 describing the categories of business rules that apply to data structure. [1] This specifically
took the “Row Three” perspective of the Zachman Architecture for Information Systems – that is, the perspective of the information system designer or architect.
In this context, the Business Rules Group defined a business rule as a statement that defines or constrains data about an enterprise.
The categories identified are:
-
Terms, and definitions of those terms. The very definition of a term is itself a business rule which describes how people think and talk about things. Thus, defining a
term is establishing a category of business rule. [2] -
Facts, linking terms together. The nature or operating structure of an organization can be described in terms of the facts which relate terms to each other. To say that
a customer can place an order is a business rule. Facts can be documented as natural language sentences or as relationships, attributes, and generalization structures in a graphical model. -
Derivations – These are business rules (including laws of nature) that define how knowledge in one form may be transformed into other knowledge, possibly in a
different form. -
Business Rule Constraints – Every enterprise constrains behavior in some way, and this is closely related to constraints on what data may or may not be updated. To
prevent a record from being made is, in many cases, to prevent an action from taking place.
In the Business Rules Group paper, Terms and Facts were called structural assertions, and business rule constraints were called action
assertions. For the most part, structural assertions can be represented in entity / relationship (or object) models, while action assertions cannot.
The paper in the last issue of TDAN.com – www.tdan.com/i019ht01.htm – described structural assertions and derivations. This article is concerned with
action assertions.
An action assertion is a statement that concerns some dynamic aspect of the business. It specifies constraints on the results that actions can produce. The constraints are described
non-procedurally, in terms of the data and other atomic business rules. Where the structural assertions describe possibilities, action assertions impose constraints — ’must’ (or,
‘should’), or ‘must not’ (or ‘should not’).
Cardinality and Optionality
Figure 1 shows the model as derived in the last article. In it, Role and attribute are predicates for entity type / class. That is, occurrences of these describe
occurrences of entity type / class.
Note that attributes of these predicates represent additional facts. One attribute of both ROLE and ATTRIBUTE is “Cardinality indicator”. Cardinality is an
action assertion that asserts the maximum number of occurrences of a predicate that can be associated with an entity TYPE or class. This provides the ability to assert a business rule: Each
occurrence of an entity type / class may be related to no more occurrences of a predicate than what is indicated by that predicate’s “Cardinality indicator”.
Relational theory constrains us to say that for an occurrence of an entity type or class there can be only one occurrence of an attribute value. In that environment, every attribute’s
“Cardinality indicator” must be “1”. Object orientation, however, does not recognize that constraint, so the indicator might be “more than one” in some cases.
Also, object role modeling [3] permits description of the situation where an attribute is not unique for an entity type.
A ROLE, on the other hand, usually may have one of two kinds of cardinality: “one and only one”, or “one or more”. (In UML, you have the ability to make this more complex,
as in “1, 5, 7, or 12”, but that would be an extension of this model.)
Figure 1 is of course itself an example of a data model, and it contains the following ROLES: “Each entity type or class may be described by one or more attributes”; and
“each attribute must be about one and only one entity type or class”. The “Cardinality indicator” for the role “described by” is “one or
more”, and the “Cardinality indicator” for “about” is “one and only one”. This represents an upper limit of “more than one” or an
upper limit of “1”.
Previously, we observed that these predicates may be optional or mandatory. That is, for a given occurrence of an ENTITY TYPE / CLASS, must you have an occurrence of that predicate? Nearly all data
modeling and object modeling techniques require you to assert categorically that a predicate is mandatory or optional. In the notation used for this model, for example, this is asserted for
attributes by the symbol before each one. If it is an asterisk (*) a value is required for this attribute for every occurrence of the entity type. If it is a circle (o), then values are not
required. For relationships (roles) it is shown by a dashed (“may be”) or solid (“must be”) line.
In this meta-model, the “Default optionality indicator” tells whether (under ordinary circumstances) a value is required for the attribute or role in all cases.
The problem is that real life doesn’t work that way. It is often the case that when an occurrence of an ENTITY TYPE or CLASS is being created, a predicate is not required, but at some point
during the occurrence’s life, it will become mandatory. Unfortunately, the modeling notations currently available don’t permit expressing this. The closest to it is Clive
Finkelstein’s version of Information Engineering that permits a combination of symbols that means “initially may be but eventually must be” – but even this doesn’t
portray the rule in all its subtlety.
What we are trying to express is shown in the meta model that is Figure 2. Here we recognize that an occurrence of entity type / class may be in one or more entity type states. An OPTIONALITY
INDICATOR for that predicate which is based on a particular ENTITY TYPE STATE then shows the optionality of an ATTRIBUTE or ROLE. An OPTIONALITY INDICATOR must be either for a ROLE or for an
ATTRIBUTE.
For example, imagine the entity oil well. This is a hole in the ground from which petroleum products are extracted. One of its attributes is “API Identifier”, which is the code assigned
to it by the American Petroleum Institute. When the oil well is in the entity type state “Proposed”, “API Identifier” is optional. But before it can assume the entity type
state “Operational”, a value must be given to the attribute.
John Carlis and Joseph Maguire recently published a book on data modeling [4] in which they assert that for this very reason it is inappropriate to show optionality at all in a data model. Because
the rules around this concept are more complex than can be reasonably be represented graphically, they assert that these rules should simply be included among the other rules that are documented
separately.
Other Constraints
Another kind of action assertion is the domain. For the most part this cannot be represented in an entity/relationship or object model, although it can be shown in an
object role model.[5]
In Figure 3, attribute is shown to be of three kinds: discrete attribute, continuous attribute, and OTHER ATTRIBUTE. A discrete attribute is one that can only take a one of a specified set of
values. Indeed, the model shows that each discrete attribute may be constrained by one or more valid attribute values, like “red” “blue” and “green”, or
“1”, “4”, and “16”. That is, a set of valid attribute values is of a particular discrete attribute and represents the values it can take.
A continuous attribute is an attribute that can accept any real number as a value. This may be constrained by a “Maximum value” and a “Minimum value”. When the maximum and
minimum values are specified, no value can be accepted for the attribute that is not inside those values (inclusive).
Note that we have added an OTHER ATTRIBUTE, which could be a string, or a date.
Either kind of attribute is also constrained by formatting characteristics, such as data “Type”, “Maximum length”, and so forth.
Note that here, constraints are described directly for attributes. An alternative way to do this is to define a domain as a set of constraints that can be applied to more than one attribute. In the
Figure, a domain is shown as either a value set, a NUMERIC DOMAIN, or an other domain. Like a discrete attribute, a value set may be composed of one or more valid
attribute values. The difference is that when a discrete attribute is constrained by a set of valid attribute values, the constraint only applies to that attribute. If the constraint is defined as
a value set, which is a kind of domain, then, it can be applied to many attributes. Similarly, like a continuous attribute, a numeric domain may have a “Maximum value” or a
“Minimum value” as attributes. Again, by attaching this constraint to a domain, you can now re-use it for many attributes.
It is reasonable, if you see that a constraint really only applies to one attribute, to specify it for that attribute alone. It often happens, however, that other attributes are discovered
later that have the same constraint. For this reason, it is good practice to always specify constraints through domains, not directly. Some organizations make this a mandatory corporate
policy.
Action Assertions
While above we have been discussing specific examples of action assertions, Figure 4 shows a generalization of this idea. The action assertion here is a business rule constraint, to
constrain either an entity type / class, a role, or an attribute. For example, a validation constraint might constrain the values that can be given to an attribute. Another kind of constraint
might specify when an entity TYPE / CLASS might be updated. And so forth.
Each business rule constraint must be an example of a business rule constraint type. Ronald Ross has identified some 31 business rule types in seven categories, [6] but of course you can
define any set of types that you wish.
Each business rule constraint may be composed of one or more business rule constraint elements. A business rule constraint element identifies something doing the constraining, such as an
attribute, an entity type / class, a role, or another business rule constraint.
A BUSINESS RULE CONSTRAINT must be either a CONDITION or an INTEGRITY CONSTRAINT. A CONDITION may be true or false, and thus controls the firing of other business rules. An INTEGRITY CONSTRAINT is
something that by definition must be true about an ENTITY TYPE / CLASS, ROLE, or ATTRIBUTE,.
A business rule constraint may itself be constrained by one or more business rule constraint arguments. These are parameters that control the operation of the constraint. For example, we previously
described a “Minimum Value” for a continuous attribute. Rather than representing it explicitly like that, we could define a business rule constraint as being qualified by the
business rule argument that is an example of the business rule argument type “Minimum value”. If the business rule constraint is concerned with time, the business rule
constraint argument could be the time interval involved.
A business rule constraint may be managed via one or more business rule constraint roles, where each of these is played by one party. (A party is a person or organization of
interest to the enterprise.)
A business rule constraint must be subject to one consequence of violation, where a consequence of violation may be anything from the display of a warning message to complete rejection of
the value.
Conclusion
As we have seen here, business rules put a whole new spin on the process of understanding what is going on in a business. Modeling the meta data of business rules allows us to see just what the
nature of that spin is.
[1] Business Rules Group. Business Rules: What Are They Really? 1995. Available at www.businessrulesgroup.org
[2] These definitions are from Business Rules, What Are They Really?, page 6.
[3] Terry Halpin. Information Modeling and Relational Databases. San Francisco: Morgan Kaufman Publishers. 2001.
[4] John Carlis, and Joseph Maguire. Mastering Data Modeling. Boston: Addison-Wesley. 2001.
[5] Terry Halpin. Op. Cit.
[6] Ross, Ronald G. The Business Rule Book: Classifying, Defining, and Modeling Rules, Second Edition. Boston: Database Research Group. 1997.
