THE DATA ADMINISTRATION NEWSLETTER – TDAN.com
ROBERT S. SEINER – PUBLISHER

In previous articles, we discussed the kinds of business rules that can ("Modeling Business Rules: What Data Models Do") and cannot ("Modeling Business Rules: What Data Models Cannot Do") be displayed on entity / relationship model diagrams. The first article concerned itself with the terms, facts, and derivations that are the heart of a data model. The second described the business constraints that can and cannot be represented on a data model. This article will present the metamodel for constraints, in order to reveal exactly what it is that is not being displayed. Before that, however, we will first correct a significant misunderstanding presented in the first article, and then examine some notations that do describe constraints more effectively than entity / relationship diagrams can. This will give us a clue as to what the metamodel should look like.

Correction

Figure 1 shows Figure 2 from the first article. In it, a business term is shown to be the use of a word or phrase to mean a definition. Since that writing your author has been exposed to recent work by the Business Rules Group, who have been working with the Object Management Group (OMG) to develop a "Business Semantics for Business Rules"^[1]. They have recognized that there is a difference between the universe of discourse (the body of concepts and facts that are what language describes) and the form of expression that is the set of symbols and statements doing the describing.

Accepting these arguments means that the correct drawing should look more like Figure 2. In this, entity class, and attribute are recognized as concepts (a reformulation of "definition" in Figure 1. They are not simply business terms. This make sense, since there are numerous ways that an entity class (for example) could be described. Indeed the entity class called "Entity class" can be described using different symbols, depending on the modeling language used.

Note that different instances of an entity class will have names that are instance names—a specific kind of business term. Note also recognition that a word can in fact be part of more than one phrase. This also is corrected in Figure 2, with the addition of word usage, which is simply the fact that a particular word appears in a particular phrase.

Of course this change to Figure 2 in the original article affects the other drawings as well, but since the subject is entity class, attribute, and so forth, the basic content of the article is not changed.

Constraint Language

And now back to this article:

To describe business rules (specifically constraints) more completely, we need a language for discussing them. Ron Ross has provided us with such a language.^[2] Recognizing that an additional vehicle is needed to describe business rules, he invented a notation to lay over a data model for this purpose.

Figure 3 shows the elements of the notation. Constraints are of two basic types—integrity constraints and conditions. An integrity constraint is something that must be true, or it must be kept true. In the example, the integrity constraint "X" is one of 28 atomic rule types. This one means "existence". That is, "X" means that if there is a party a value must exist for the attribute "Address". A condition is a test that, depending on its outcome, may invoke another constraint or an action. In the example, the condition "X" means that if party has a value for "Address" then another rule will be invoked.

Each symbol has a single line going into it, pointing from the thing being constrained. Mr. Ross refers to this as the anchor of the rule. A symbol may have one or more lines going out from it, pointing to things doing the constraining. These are called correspondents. In the example, the entity class party is the anchor (the thing being constrained) and the attribute "Address" is a correspondent (a constraint).

Figure 4 reproduces one of the problem models from last quarter's article. Recall that in that model, we could not enforce the rule that a test type can only be embodied in a test if

• the sample method used to draw the sample that was subject to the test...
• ... is the same sample method that is the basis for a test requirement for that test type.

The relationship "Each test must be an example of a test type" is constrained. We cannot create an instance of this relationship unless the relationship from test through sample to sample method is consistent with the relationship from test type through test requirment to sample method. This is shown by an "R" ("Restricted") integrity constraint, and the constraining is done by the two relationships:

• from test to sample (and its implied sample method) and
• from test type to test requirement (and its implied sample method).

The Object Role Model (ORM) notation is a variation on entity / relationship modeling that is much more versatile in describing constraints.^[3] Figure 5 shows our model in ORM notation. Here, entity classes are represented by ovals, and relationships are shown as divided boxes, with one space for each role that makes up the relationship. The double-headed arrow over half of each relationship box is what in ORM is called a "uniqueness constraint". This means that, for example, each occurrence of test requirement can have only one occurrence of the role from sample method. (This is ORM's way of saying that each test requirement is from one and only one sample method.) The dot between a relationship line and an entity class means that the relationship is mandatory for that entity class.

The constraint we are after is called a "join-subset constraint", and in Figure 5 this is represented by the lines linking the relationship from test to test type to a line between the test type / test requirement relationship and the test / sample relationship. That is the test / test type relationship is constrained by the contents of the two other relationships. In both cases, this means that the latter relationships ultimately must point to the same sample method.

Figure 6 shows the metamodel of constraints. Note that we have seen part of this last issue, where we showed the metamodel of the inter-role constraint. In that case, the business constraint was to constrain either an entity class or a role., and each business constraint element was constrained by a role. As you can see from this Figure, the complete model is much more extensive than that. A business constraint must be either an integrity business constraint or a condition, and it may be to constrain an entity class, a role, or an attribute. The business constraint may be composed of one or more business constraint elements, each of which refers to something doing the constraining—an attribute, a role, an entity class, or another business constraint.

As mentioned above, a condition will trigger either other business rules (constraints), or an action. Thus, in Figure 7, each condition may be the source of one or more rule triggers, each of which is (the trigger) of either another business constraint or a function.

Figure 8 shows some additional information that can be captured about a constraint. As previously mentioned, Mr. Ross recognizes 28 atomic types of rules, grouped into "Instance Verifiers" (such as "Mandatory", shown above), "Type Verifiers" (such as "Mutually Exclusive"), "Position Verifiers" (such as "Lowest", "Highest", etc.), "Functional Verifiers" (such as "Unique"), "Comparative Verifiers" (such as "Equal to", "Less than", etc.), "Mathematical Evaluators" (such as "Sum", "Subtract", etc.), and "Projection Controllers" (such as "Execute" (a function)). In addition, he's defined another dozen categories of derived rules.

Other authors have categorized rules differently, but in any case, it is reasonable to assert that each business constraint must be an example of a business constraint type.

People and organizations play roles in the definition and enforcement of rules. This is shown in Figure 8 by the fact that a business constraint may be managed via one or more business constraint roles, each of which must be played by one party. Each business constraint role must be an example of one business constraint role type.

Violation of a business constraint may have widely different consequences, depending on the nature of the business constraint. Either entry of the information may be refused, or it may be accepted, with notification of the violation to various parties. Thus, each business constraint may be subject to a particular consequence of violation.

Figure 9 shows that either a business constraint or a business constraint element may be qualified by one or more business constraint arguments. These are the data that control constraints. These are the test requirement occurrences described above. Each argument must be an example of a business constraint argument type.

An example of an argument would be, for example in Figure 10 (reproduced from last quarter's article), that an occurrence of the relationship "Each physical asset may be accounted for in one asset account" must be in place within 14 days. The argument is "14 days".

Arguments are one example of business constraints being controlled by data. Another is to have them expressed in terms of other entity classes and attributes in the model. This will be discussed in the next article.

[1] For information about their current efforts, see John Hall, "Business Semantics of Business Rules", BRCommunity, Volume 5, Issue 5, May, 2004. Available at: http://www.brcommunity.com/b182.php

[2] Ron Ross. The Business Rule Book: Classifying, Defining, and Modeling Rules, Second Edition. Boston: Database Research Group. 1997.

[3] For a complete description of ORM, see Terry Halpin, . Information Modeling and Relational Databases. San Francisco: Morgan Kaufman Publishers. 2001