Decision tables have been around for a long time. In this edition of Technology Review, Jan Vanthienen of Katholieke Universiteit Leuven shows us their value in repesenting and validating business rules. Although they are not in themselves a technology, decision tables are an important feature of many business rules products -- John Hall.
 
Quality by Design: Using Decision Tables in Business Rules

By Jan Vanthienen
 

Why decision tables?
 

Business rules have become a common approach to understanding, specifying and implementing business systems. When modeling and representing the complex business logic to be dealt with in real business situations, we want to ensure the quality of the set of business rules from the start. Also, because maintaining the business rules, e.g. by end user domain experts, is not a trivial task and often introduces unnoticed anomalies, it is important that this quality is maintained and that the set of rules remains correct, complete, consistent and simple.
 

Decision tables are a powerful technique to represent and validate a set of related business rules in the form of tables (see Ross 2003). Although originally used as a technique to support programming, decision tables have proven a useful aid in modeling complex business situations of various sorts in a simple manner, easy to check by business experts for consistency, completeness and correctness. The focal point of this approach is the use of decision tables as a modeling formalism for expressing (at least part of) the business knowledge in the problem domain at hand.
 

How decision tables represent business rules
 

A decision table is a tabular representation used to describe and analyze situations where the state of a number of evaluation terms (conditions) determines the execution of a set of outcomes (actions). In this representation all distinct situations are shown as columns in a table, such that every possible case is included in one and only one column (completeness and exclusivity). The decision table concept in this definition is deliberately restricted to the so called single-hit table, where columns are mutually exclusive: no condition combination occurs in more than one column. Only this type of table allows easy checking for consistency and completeness.
 

A column however may include multiple single cases and is then called a contracted column. If each column only contains simple states (no contractions or irrelevant conditions), the table is called an expanded decision table, in the other case the table is called a contracted decision table.
 

The tabular representation of the decision situation is characterized by the separation between conditions and actions, on one hand, and between subjects (criteria) and values, on the other hand. A decision table therefore consists of four parts:
 

• The condition subjects (upper left part) are the criteria which are relevant to the decision making process. They represent the items about which information is needed.
• Every condition subject has a relevant set of values (upper right hand side of the table).
• The action subjects describe the results of the decision making process (lower left part of the table).
• The action values are the possible values a given action can take. They are found at the lower right hand side of the table. Every table column (decision column) indicates which actions should (or should not) be executed for a specific combination of condition values

An example is given below:
 

Obtaining quality by avoiding errors
 

It is important that business rule specifications are correct, consistent, complete and non-redundant. Research in the verification & validation (V&V) community has focused on these anomalies in rule based systems. See e.g. Preece & Shinghal (1994) for a common classification.
 

The advantage of the decision table technique is that it allows to avoid the common anomalies in rule systems, such as: redundant rules, conflicting rules, subsumed rules, unnecessary conditions, circular rules, missing rules or combinations, etc. Moreover, the acquisition process is well served through the overview and communication abilities of well-structured decision tables.

a) How decision tables avoid inconsistency
 

Inconsistency occurs when rules with the same premises, but with different conclusions, exist. In a single-hit decision table (the only type we will use), columns are non-overlapping and therefore conflicting columns will not occur. This is one of the major advantages of decision tables: each condition combination occurs only once and refers to exactly one configuration of conclusions. Some common forms of inconsistency:

• Conflict: rules with the same premises (or containing overlapping combinations), but leading to contradictory conclusions.
  • A credit check must be performed for a customer if the order total is more than $1000
  • A credit check must not be performed for a customer if the order total is more than $1000 and a waiver has been authorized

  The single-hit table format avoids such conflicts.

• Invalid attribute values: a rule containing a nonexistent value of an attribute (e.g. because of a typing error). Once the domain of conditions is well defined, invalid values will not occur, as table entries can be generated automatically.
• Cyclical rules: a set of rules where a conclusion occurs somewhere as one of the premises. In a decision table context, conclusions occurring as premises lead to separate tables. The forward character of the decision table structure eliminates the problem of cyclical references.

b) How decision tables avoid redundancy
 

Redundancy usually does not lead to errors in the final system, although it may harm efficiency. The main problem with redundancy, however, is maintenance and the risk of creating inconsistencies when changing the specifications. Some common forms of redundancy:

• Subsumption: rules with the same conclusions but with one of them containing additional premises (and therefore being less general)..
  • A credit check must be performed for a customer if the order total is more than $1000
  • A credit check must be performed for a customer if the order total is more than $1000 and a waiver has not been authorized

  Subsumption cannot occur in the decision table, because columns do not overlap

• Redundant premises: (partly) complementary rules with equal conclusions, which can be combined.
  • A credit check must be performed for a customer if the order total is more than $1000 and a waiver has not been authorized
  • A credit check must be performed for a customer if the order total is more than $1000 and a waiver has been authorized

  In a contracted decision table, two or more complementary rules with equal action configurations are automatically combined, leading to the detection of irrelevant or partly irrelevant conditions. The number of distinct columns is thereby minimized.

• Redundant rules: rules with the same premises and (partly) equal conclusions. Because in the decision table every possible case is included in only one column (exclusivity), redundant rules will not occur.

c) How decision tables avoid incompleteness
 

No current system is able to incorporate all possible knowledge, but within the specific problem area, the following omissions often occur:

• Unused attribute values or combinations: when attribute values (or combinations) never occur as premises, a number of rules may be missing. Detecting the completeness of all combinations of attribute values is not always simple.
  • A credit check must be performed for a customer if the order total is more than $1000
  • A credit check must not be performed for a customer if the order total is less than $500

  What if the order total is $800?

  The nature of the decision table easily allows to check for completeness: the number of simple columns should equal the product of the number of states for every condition. This guaranty of completeness of condition combinations is one of the main advantages of decision tables.

• Unreachable conclusions: conclusions which are never deduced and cannot be asked.

  The format of the decision table easily shows unreachable conclusions.

• Missing knowledge: the absence of some essential elements from the problem situation. Inconsistency often is a symptom of incompleteness because of missing premises.

Detecting these rule shortcomings (either by the designer or automatically), without some form of decision tables, is highly improbable, unless through excessive testing.

Constructing the decision table
 

As a simple example, consider the holidays regulation in Figure 1, used by the Personnel Department of a small company. As the information is available in written form, capturing the business knowledge in decision tables can start from this initial text.
 

We will go through the stages of building the decision table step by step.

a) Defining decision criteria, values and outcomes
 

When we draw up a list of all criteria and outcomes that are mentioned in the text, it is clear that this example only uses the Age and Years of Service of an employee in order to calculate the number of holidays. The following tables list all occurrences of these terms in the text.
 

If we delete the restatements and the complements from the list, and think about the domain of each term (completeness!), we obtain an exhaustive set of mutual disjoint states. This is done by representing the different states of a condition on a numerical scale, as can be seen in Figure 3.
 

Based on these enumerations, we can now fill out the condition subjects, action subjects and condition states of the decision table. The number of columns that will be presented in the empty (expanded) table is the product of the number of states for each condition (4x3). In the empty table, each combination is included in one (completeness) and only one column (consistency and non-redundancy).
 

b) Filling in the table cells
 

Based on the text of the regulations and on the conditions, the condition states and the actions, we can now proceed by translating the text into a more formal specification and filling in the decision table. We analyze each sentence in the regulation, enumerate the appropriate condition combinations (in a more formal logical way) and fill the table accordingly. E.g., the last sentence of the specification:

• Employees with at least 40 years of service and also employees of age 60 or more, receive 3 extra days, on top of the additional days already given.

translates into:

• 3 extra days if Service >=40 or Age >=60

and will mark ‘X’ in columns 3,6, 9-12.
 

After specifying the business logic, and filling it into the appropriate combinations in the decision table, the table looks as depicted in Figure 5.
 

c) Verifying Completeness, Consistency and Correctness
 

Empty columns, unreferenced actions or unreferenced conditions do not occur in this example. All condition combinations are included in one and only one column.
 

When, however, we take a good look at the preliminary decision table, we see that it should be impossible for an employee younger than 18 years to have 25 or more years of service. Of course, we would prefer to discard this impossible situation. This can be done by adding a new rule. Since children are not allowed to work, we can also add a rule that employees younger than 45 can not have 40 years of service in the company. In fact, we could have defined these semantic impossibilities when stating the concepts. The impossible columns will be deleted from (or marked in) the table.
 

When verifying correctness, we verify if the different columns of the decision table correspond with the described specifications, which is OK in this example. If this is not the case, it means that the interpretation of the text is wrong, or in other words one of the specifications does not correspond to the text.
 

Finally, one has to check if the decision table corresponds to the desired reality. For instance, it could be possible that management would prefer to give an extra day after 10 years of service, even if this is not mentioned in the text. This is exactly what has to be checked: (1) does the text fully represent the current situation?, and (2) does it represent the desired business situation?
 

d) Simplifying the Decision Table
 

Once a complete verification and validation of the decision table is finished, the table could be reduced to its minimal format.

• Contraction of the decision table

  Columns (or groups of columns) leading to identical action configurations can be combined. The final contracted decision table is shown in Figure 2.

• Optimizing the condition order
  The order of the conditions might influence the number of columns in the contracted table. In this example, the original condition order is already the optimal one.

Because manual decision table construction can be a cumbersome process, design tools for computer-supported construction, manipulation, validation and optimization of decision tables will be valuable.
 

Experiences with decision tables and tools indicate that the representational and verification & validation advantages of decision tables fit very well with the world of business users.
 

References
 

1. Preece A. & Shinghal R., Foundation and Application of Knowledge Base Verification, Int. Journal of Intelligent Systems, 9, 683-701, 1994.
 

2. Ross, R., Principles of the Business Rule Approach, Addison-Wesley, 372 pp., 2003.
 

3. Vanthienen, J., Dries, E., Illustration of a Decision Table Tool for Specifying and Implementing Knowledge Based Systems, International Journal on Artificial Intelligence Tools, 3(2), 1994, 267-288.

# # #