Published in TDAN.com January 2002
Previously in this newsletter, I have presented ideas about what a metadata repository might actually look like to support analysis [1], relational design [2], and object-oriented design [3]. This
article and the one to follow 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.
The exceptions to this are assertions that an occurrence of an entity must be associated with at least one occurrence of another entity, or that an occurrence may not be associated with more than a
specified number of occurrences of the other entity. Some notations allow you to say that an occurrence of an entity must be (or may be) associated with either an occurrence of one entity or an
occurrence of another entity but not both. Object role modeling is a special kind of modeling that allows for expression of a few more kinds of rules, but even it does not go all the way when it
comes to describing business rules.
Ronald Ross has developed a notation specifically for representing business rules, laying specialized symbols on top of a data model to show how constraints interact with the data model structure,
but it has proven too formidable for most people to use.
The advantage of looking at business rules from a metadata perspective is that we can look at the nature of many kinds of rules even if there are no CASE Tools to portray them. 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 [4]. 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.
This means that the Business Rules Group paper defined a business rule as a statement that defines or constrains data about an enterprise, not its actions.
In a later paper [5], the Business Rules Group discussed business rules in the context of the Business Owners’ views of system – Row Two of the Zachman Framework. This is about the
business rules that constrain business behavior itself.
The article here follows the first paper: It is concerned with the business rules about data and the constraints on what must or may not be done to them. The categories identified are:
-
Terms (and the 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. [6] -
Facts, linking terms together. The nature or operating structure of an organization can be described in terms of the facts which relate the enterprise’s terms to
each other. To say that a customer can place an order, for example, is a fact, and therefore 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. -
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 constraints were called action assertions. For the most
part, structural assertions can be represented in entity / relationship (or object) models, while action assertions cannot.
This paper is about terms, facts, and derivations. Next issue, I’ll take on constraints (action assertions).
Terms and Definitions
The first kind of business rule is the term and its associated definition.
Figure 1 shows an entity to represent BUSINESS TERM. This is any word used to describe some aspect of an enterprise’s operations or environment. In our data modeling world, we try to capture
terms that refer to things (including abstract things) of significance to the enterprise – specifically those things about which it wished to capture and hold information. These are
identified as entity types (or classes for those of the object-oriented persuasion) to be shown in our entity/relationship (or object) diagrams.
Other business terms of interest include the attributes that describe ENTITY TYPES or CLASSES. The language of the business, after all, consists not only of concepts but also the concepts that
describe those concepts.
Data modeling is a disciplined approach to describing business, but real language is much more fluid and diverse than will ever be captured in any models. There are clearly other business terms out
there that do not show up as entity types or attributes. These are the industry-specific (or company-specific) words that describe technical aspects of processes and other aspects of the
enterprise.
Note that terms do not exist in isolation. They only are terms if people use them. This means that at the very least, we must say who is responsible for each business term used. That is, a PARTY
– either a PERSON or an ORGANIZATION – must be the responsible for each business term.
If you don’t want to get specific, the defining organization can be the enterprise as a whole. Be aware, however, that the integrity of the data in any system built from this model will
depend on the assignment of someone to be responsible for the quality (accuracy, timeliness, etc.) of the contents of each table – that is, the occurrences of each ENTITY TYPE.
Some of those other business terms are nothing other than synonyms for the “official” terms we have sanctified as entity type or attribute names. Figure 1 shows that a synonym is the
use of an other business term for either an entity type or an attribute. As with the underlying business term, a synonym must be the responsibility of a party.
Facts
The second kind of business rule is the fact. Here we’ll discuss four different kinds of facts:
- Relationships
- Sub-types and super-types
- Attributes
- Unique identifiers
Relationships
One kind of fact that can be represented in an entity/relationship or object model is the relationship (also known as an association). That is, a
relationship is the fact that one term is related to another. Factual sentences in natural language are nothing other than the linking of terms together.
Figure 2 shows the meta model of relationship. A relationship is actually composed of two relationship directions, or roles. If A is related to B in some way, then B is also related to A in a
complementary way. These are two ROLES in a relationship. Thus, each entity type or class may be connected via one or more roleS, where each role, in turn must be connected to one and only one
other role (going the other way). This second ROLE must then be connected to a second ENTITY TYPE or CLASS.
For example, since entity TYPE / class and ROLE are themselves two entity types in the model at hand, we can see the relationship between them as two roles. In one direction, each entity type or
class may be connected via one or more ROLES. and going the other direction each ROLE must be connected to one and only one entity type or class. The roles are connected via and connected to.
Sub-types and Super-types
Also shown in Figure 2 is the fact that an entity type or class may be a super-type of 2 or more entity types or classes. (An alternative way of expressing the same fact is that an entity type or
class may be the sub-type of one and only one other entity type or class). That is, occurrences of an ENTITY TYPE or CLASS may constitute a sub-set of the occurrences of another ENTITY TYPE or
CLASS. To be an occurrence of a sub-type is to be an occurrence of the super-type.
For example, in Figure 3, note that an order must be either a purchase order or a sales order. To say this is to express at least two facts, and optionally, two more. In all modeling notations,
this assertion says that an order may be a purchase order, and that an order may be a sales order. In addition, some modeling approaches say that this assertion also asserts that an order may not
be both a purchase order and a sales order, and that an order must be one or the other. (Figure 3 also shows that a PARTY must be either a PERSON or an ORGANIZATION).
Among other things, this means that both SALES ORDER and PURCHASE ORDER inherit the attributes “Order number” and “Total value” from ORDER. They also inherit the
relationship to LINE ITEM.
Indeed, in the meta model back in Figure 2, attribute, entity type / class, and other business entity are all sub-types of business term, and this is an expression of all four facts. This also
means that these sub-types inherit the attributes “Name” and “Definition” from business term, as well as any relationships that might attach to BUSINESS TERM.
In object oriented terms, ORDER in Figure 3 is considered to be a generalization of PURCHASE ORDER and SALES ORDER. In the same model PARTY is a generalization of PERSON and ORGANIZATION.
Attributes
Figure 4 shows another kind of fact that can be shown in a data model – an attribute. That is, in the Figure, we can see that each entity type / class may be
described by one or more attributes.
In the sample model shown in Figure 3, person is described by the attribute “given name”. This is a fact. So is the assertion that a person is described by the attribute
“surname”. Indeed on the meta model in Figure 4, attributes are now also displayed, so we can see that the entity type business term is described by the attributes “Name”
and “Definition”. Similarly, the entity type attribute is described by the attributes “Type”, “Max length”, “Avg length”, and so forth.
ROLE and ATTRIBUTE are predicates of ENTITY TYPE / CLASS. That is, occurrences of these describe occurrences of ENTITY TYPE / CLASS.
Unique Identiifiers
Another kind of fact is the way one identifies a single occurrence of an entity, among all that exist. This is done through the value of one or more attributeS and one or more ROLES. The
combination of attributes and roles that can be used to uniquely identify an occurrence of an entity type is the unique identifier of that entity type. Unique identifier
is shown in Figure 5.
Each unique identifier of an entity type / class must be composed of one or more unique identifier elements, each of which must be the use of either an attribute or a role.
For example, in Figure 3, above, occurrences of PURCHASE ORDER are uniquely identified by The attribute “Purchase order number”. One role shows that each LINE ITEM must be part of one
and only one PURCHASE ORDER. The unique identifier of an occurrence of LINE ITEM, then, is a combination of “Line number” and the part of relationship to PURCHASE ORDER. That is, to
uniquely identify a LINE ITEM, you must know both the “Line number” and the PURCHASE ORDER it is related to.
Derivations
The third major category of business rule is the derivation. A derivation is a statement of knowledge that is derived from other knowledge in the business. Specifically, a
derivation is the evaluation of an attribute.
As shown in Figure 6, a derivation must be to calculate an attribute. It is composed of one or more derivation elements, each of which may be the use of either another attribute, a system variable,
or a “Constant”.
For example, attribute “A” may be derived from attributes “B”, “C” and “D” according to the formula “A = B + C * D + 15. This would be
represented as the following derivation elements:
In three cases, the derivation element is the use of other attributes. In one case, it uses an attribute of derivation element “Constant”. The calculation of the formula is done using
Reverse Polish Notation, where each variable has an “operator” assigned to it. So first “A” is added (to nothing) resulting in “A”. Then “B” is
added, resulting in “A + B”. Then “C” is multiplied by the result to this point, resulting in turn in “(A + B) * C”. Finally “15” is added to come up
with the final result.
Note that calculations can be across relationships between entity types. For example, in Figure 3, above, the “Price” of a product may be inferred across the relationship between line
item and product (Each line item must be for one and only one product, after all), so that it is available in line item. The “Value” of a line item then might be expressed something
like “Quantity” * “Standard price infer through(for PRODUCT). Similarly, the “Total cost” of a purchase order might be the sum of “Cost”
in all the line items the purchase order is composed of. This case might be expressed as “Cost” sum through(composed of LINE ITEM).
This all is recognized in Figure 6 by the relationship that asserts that each derivation element may be via one and only one role / relationship direction.
Derived attributes can be shown in an entity/relationship diagram, but of course the derivation logic itself must be documented separately. Interestingly enough, on an object model, all attributes
are considered derived, even when the derivation is simply “retrieve this from persistent memory”.
CONCLUSION
The models shown in this article were all shown in the article “A Repository Model – The Analysis Process”, published previously. The difference is that this article connected
those concepts with business rules. Next issue will discuss something new: action assertions. These include domains, as well as cardinality and optionality constraints,
plus all other constraints that may be encountered.
[1] David C. Hay, http://www.tdan.com/i013fe04.htm – A Repository Model – The Analysis Model, The Data Administration Newsletter, Issue
13.
[2] David C. Hay, http://www.tdan.com/i014ht01.htm – A Repository Model – The Relational Design Model, The Data Administration
Newsletter, Issue 14.
[3] David C. Hay, http://www.tdan.com/i015ht01.htm – A Repository Model – The Object Oriented Design Model, The Data Administration
Newsletter, Issue 15.
[4] David C. Hay and Keri Anderson-Healy, http://www.businessrulesgroup.org, Business Rules: What Are They Really?, Business Rules Group.
1995.
[5] Keri Anderson-Healy and Ronald G. Ross, http://businessrulesgroup.org, Organizing Business Plans: The Standard Model for Business Rule
Motivation. Business Rules Group. 2000.
[6] These definitions are from Business Rules, What Are They Really?, page 6.
