A data model can show two and a half of the four kinds of business rules: terms, facts, and the result of derivations. It can show a limited number of the fourth kind: constraints. But
fundamentally, it cannot show that a row must be or may not be updated under specific circumstances. A data model can, however, portray the data parameters that control business rules. Moreover,
when the subject of a model is rules (as in a regulatory agency), there are very specific steps that can be taken to represent those rules in a data model. This presentation is about the data in
data-driven business rules.
This is the first of three articles that will discuss the relationship between entity / relationship models (ERD) and business rules. This article will describe the kinds of business rules and will
take up those that can (for the most part) be represented in an ERD. This includes terms, facts, and derived attributes. The second article will describe the fourth kind of rule (constraints) and
the difficulties in representing these. The third article will discuss the phenomenon of using data to configure and shape rules.
To highlight what of a business rule a data model can and cannot represent, these articles will present a model of the structure of rules themselves (a “metamodel). This is derived from
previous TDAN.com articles A Repository Model — Business Rules (Structural Assertions and Derivations and A Repository Model — Business Rules (Action Assertions, and provides a way of describing what we can and cannot describe.
These articles will reflect the author’s bias towards Richard Barker’s entity modeling notation, but where appropriate it will describe things that can be done with different
techniques, such as UML and Object Role Modeling.
What is a business rule?
According to the Business Rules Group,[1] business rules are each one of the following kinds:
- Term — The application of a single definition to a word or phrase
- Fact — The attribution of something to describe a thing: a role it plays, or some other descriptor.
- Derivation — An attribute that is derived from other attributes or system variables.
- Constraint — A condition that determines what values an attribute or relationship can or must have.
The Group further organized rules, saying that Term, Fact, and Derivation were examples of “structural assertions”, and Constraint is also called an “action assertion”.
Terms and facts are the primary constituents of data models, along with the results of derivations (derived attributes). The definitions of terms and the logic behind derivations are documented
behind the scenes, typically in the repository of the CASE tool used to draw the model. Only some constraints can be shown, however. The remainder must be displayed or described using a different
technique. This article will discuss the terms, facts, and derivations that can be shown. The next article will talk about the constraints that can and cannot be shown.
Term
Note that the word “term” here has a specialized meaning which was not reflected in the original Business Rules Group work, but which does follow logically from it: A
term is the application of a single definition to a word or phrase. Note that this definition of “term” removes certain issues from the conversation. Yes, words (and
phrases) can have many meanings, and many of those depend on the business context. Similarly, there are often multiple meanings for the same word. So, to simplify the discussion here, we will
constrain the word “term” to mean one word (or phrase) representing one meaning. The same word or phrase meaning several things constitutes several terms.
The kinds of terms we will encounter here include:
- Entity Class* – a thing of significance to the enterprise, about which information is to be held.
- Attribute – a descriptor of an entity class.
- Other Business Term – a term which describes some aspect of life that is not to be addressed formally.
Figure 1 shows how terms are represented in a typical entity/relationship model. Shown are examples of both entity class and attribute names.
To fully understand the meaning of “term”, however, it is necessary to look at the metamodel, which is a model of the structure of business rules themselves. This is shown in Figure 2. In this
model, business term is the intersection between word or phrase and definition. That is, each business term must be to mean one definition and it must be the use of either a word or a
phrase.
This structure neatly handles the fact that there may be more than one definition for a word or phrase, and that the same definition may point to many words and phrases.
As previously discussed, a business term is either an entity class (name), an attribute, or an other business term.
Note that both each business term must be ultimately the responsibility of one party (either a person or an organization). This is a business rule being imposed by the data quality
project, in which someone is held accountable for the language used, not only by systems, but by the organization as a whole.
Fact
A fact is the attribution of something to describe a thing: a role it plays, or some other descriptor. Three kinds of facts can be shown on a data model:
- Relationships (roles) – A has a business relationship with (plays a role with) B.
- Attributes – A is an attribute of B.
- Super-types / sub-types – An occurrence of A is also an occurrence of B.
Figure 3 shows examples of facts.
Figure4 shows the metamodel that describes the nature of a role. A relationship between two entity classes consists of two roles—one going each direction. The model shows that each entity
class may be connected via one or more roles. Each of these, in turn, must be connected to exactly one other role. This second role is then connected to another entity class.
These role-pairs are shown on entity/relationship diagrams as relationship lines, with text identifying each role.
Figure 5 shows the metamodel of the remaining two kinds of facts—attributes and sub-types.
The fact that each attribute must be about a single entity class is shown by the relationship between attribute and entity class. Note that, with this diagram, attributes are beginning to
be shown on the model, as they were on the original example above.
The fact that one entity class may be a sub-type of another entity is shown by the “pig’s ear” shown at the bottom of entity class. Such facts can also be shown on a data model, as
evidenced by the fact that attribute and entity class are themselves sub-types of business term in this drawing.
Derivation A derivation is an attribute that is derived from other attributes or system variables. In Figure 6, derived attributes are, by convention, shown in parentheses.
For example, the attribute “(Extended value)” in line item is computed by multiplying “Quantity” in line item by the “Unit price” of product type. “Unit price” in product type is available
to line item, because each line item must be for one and only one product type.
Similarly, “(Total value)” in order, is the sum of “(Extended value)” in all line items that are part of order. That is, each order may be composed of one or more line items, so it is
possible to sum the values in those related line items to arrive at a value for order.
The syntax for these calculations can be formalized:
Note that derived attributes can be shown on the data model, but the derivation formula cannot. In UML, it is possible to add a note to the diagram to include the formula, and in ORM it is possible
to show the formula in the diagrams legend, but neither of these is really part of the diagram structure.
Figure 7 shows the metamodel of the derivation logic. Note that this representation presumes the formulas are rendered in Reverse Polish Notation. The examples above, then, would be:
Thus, in the model, each attribute may be computed via one or more derivations (formulae), each of which must then be composed of one or more derivation elements. Each derivation element,
in turn, may be either the use of an attribute, a “Constant”, or the use of a system variable. Each derivation element specifies the “Operator” to be used in manipulating the
element, and, optionally, a “Role operator” to apply if a role is used.
[In the next issue, we will take up the last kind of business rule, constraints. Some can be represented on the ERD, while others cannot, although UML and Object Role
Modeling extend what can be represented to some degree.]
[1] The Business Rule Group. “Defining Business Rules—What are they Really?”
http://www.businessrulesgroup.org/first_paper/br01c0.htm
* Originally, data models were in terms of “entity types”, where an entity type was the definition of a class of things of significance to a business.
At that time, an “entity” was an occurrence of such a class. But the language has degenerated since then, so that in common usage, “entity” now means the class. Then
object-orientation arrived on the scene with its “objects” and “classes”. When used for a business model, these mean exactly the same as the original “entity”
and “entity type”. In an attempt to bring these two worlds together, your author will henceforth refer to a class of business things of significance as an “entity class”,
and an individual object or entity as simply an “occurrence of an entity class”.
