DTRules

This article is a simple introduction to the concept of a Decision Table, as it is used by DTRules. The article discusses the concepts of Balanced and Unbalanced decision tables at a conceptual level. You may also be interested in the article Balanced Vs. Unbalanced Decision Tables.

Decision Tables are a way of organizing conditional logic into a tabular form. Conditional logic in this context refers to a set of tests, and a set of actions to take as a result of these tests. This is often called ‘Business Logic’ when the conditions and actions are restricted to business operations.

Conditional logic can actually be organized into tables in quite a large number of ways, and any of these tabular forms may be referred to as Decision Tables. Still, perhaps the most common form organizes the conditional logic into for quadrants:

• Conditions — List of conditions or tests
• Actions — List of actions to be performed
• Condition Table — Indicates for each column what result from each condition is necessary for this column to execute
• Action Table — For each column, provides an ‘X’ for each action that should execute should that column execute.

Simple Balanced Decision Tables

Balanced Decision Tables require that all paths through the logic be represented in the table, and that the first condition must have a ‘Y’ or a ‘N’ in every column used. This is hard to visualize with out a problem, so let’s use a very simple example.

Consider two integers A and B. Define a decision table that prints a message in the event of any of three conditions: A == 0, or A > 5, or if A == B. Obviously this problem can be programmed in most languages fairly easily, as the following pseudo code demonstrates:

   if (A == 0 ) {
       print "A == 0"
   } else if ( B > 5 ) {
       print "B > 5"
   }
   if (A == C) {
       print "A == B"
   }

Note that we have recognized that the two conditionals involving A are mutually exclusive, and we have recognized that in our pseudo code above. We will continue to do so in our example decision tables.

Using Decision Tables, we can create the following Balanced Decision Table:

 

We call this a Balanced Decision Table because it describes every combination of conditions possible using either a ‘Y’, a ‘N’, or a blank. Again, the Blank is interpreted as “Don’t Care” and succeeds regardless of the value of the condition. Thus in the example above, Column 1 will execute if the first condition (A == 0) is true, and the third condition (A == B) is true, independent of the results of the second condition (B > 5).

Unbalanced Decision Tables

Unbalanced Decision Tables are also supported by DTRules. Unbalanced Decision Tables describe the business logic on a column by column basis, but because they are not balanced, one of two rules must be used to balance the tables.

• FIRST — A FIRST Table will execute the first column whose conditions are met, and only the first column whose conditions are met.
• ALL — An ALL Table will execute every column whose conditions are met. All actions are executed in the order specified in the Decision Table, and actions are executed only once (even if their execution is indicated in multiple columns whose conditions are met).

When using Unbalanced Decision Tables, it is important to choose the type of table that best represents the logic implemented. When priorities naturally exist in the conditional logic, a FIRST table is best. When the conditions that specify particular actions are relatively independent, then an ALL table is best.

FIRST Tables

If we recode the example above as a First Table, we can see some simplification of the table:

Notice the differences between the FIRST table and the balanced table above. We don’t have to specify column 6 because nothing happens in that case. We don’t have to specify ‘N’ for the first action in columns 3-5 because that condition has nothing to do with the actions taking place in columns 3-5. Before it was needed by the rules of balanced tables, that require the first condition to have no blank or “don’t care” entries.

The FIRST table is simpler than the balanced table. However, the third condition is completely independent of the first two conditions. This makes this problem a good candidate for an ALL table.

 ALL Tables

All Tables execute all the columns whose conditions are met. These tables are used when there are independent Condition/Action relationships that none the less need to go into the same decision table. In our example, we wish to print “A==B” regardless of the value of A. This Condition/Action relationship is independent of the first two conditions (which both test the variable A, and which cannot both be true at once).

The following ALL table implements our example:

The ALL table is by far the simplest for this example. A glance at the table tells the user exactly what conditions are required to print “A is 0” or “A == B”. Working out the balancing of these conditions is left to the compiler. However, DTRules does provide the balanced decision tables for review by the user for all unbalanced decision tables. It can be useful to consider how conditions interact.

Conclusion

Decision Tables provide a easy way to examine the relationship of tests to the actions that result. Unbalanced Decision tables reduce the complexity and clutter even further, and greatly enhance a table’s ability to represent the logic behind the table.