Modeling Decision Table Structures
Decision tables provide a good overview of a set of business rules, but most real decision cases will not be represented in one single decision table. That is because decisions may involve sub-decisions and lower-level decisions. If we try to fit all this in one table, the table would be too large, too complex, or too difficult to maintain. In the decision table mechanism, this is called a table hierarchy (or 'table structure').
Consider the following example (taken from ):
|Order Processing Policy
First we check whether the credit limit has not been exceeded. If this is not the case, the stock will be checked. If the product is in stock, the order will be executed, else we put the order on the waiting list. If the credit limit has been exceeded, the same measures will apply if the customer is important. If this is not the case, the order will be refused.
Whether a customer is important depends primarily on the age of the account. If the customer did register less than a year ago, the turnover over the last 6 months has to be at least $10,000 to qualify as an important customer. For all other clients, the critical turnover point has been set to $5,000.
Three critical points have to be taken into account while executing the order:
1. Discount: The discount rates are 10%, 5%, and 2%. 10% is for clients with an order quantity of at least 15 pieces or who are situated within a range of less than 50 miles of the company and order at least 10 pieces; a discount of 5% is allowed to those customers that order at least 10, but less than 15 pieces and whose distance to the company is more than 50 miles (but less than 100); finally, the discount rate comes to 2% for customers that live at least 100 miles from the company, and order at least 10 but less than 15 pieces.
2. Means of Transport: We deliver by rail if the order comes from a customer that has ordered at least 15 pieces. In all other cases, road transport is used.
3. Bill Type: The normal bill type is A. Exceptionally, a type B bill has to be made up. This is the case when a customer's order quantity is at least 15 pieces.
Without going into all details, the order policy contains a number of business rules about order handling, customer type, and order execution details, for example:
- Execute Order if Stock.Quantity is Ok and (Customer.CreditLimit is Ok or Customer.Type is Good).
- Refuse Order if Customer.CreditLimit is Not Ok and Customer.Type is Not Good.
- WaitList Order if Stock.Quantity is Not Ok and (Customer.CreditLimit is Ok or Customer.Type is Good).
- Customer.Type is Good if Account.Turnover>=10 or (Account.Age>=1 and Account.Turnover>=5).
- Discount, Transport and Bill Type rules.
Modeling the structure
When examining the business rules and the order processing policy, it is clear that there are three parts, leading to three related tables:
- The general order policy decision,
- The customer type decision,
- Detailed decisions about discount, transport, and bill type.
This can be seen when we draw up the list of conditions and conclusions from the policy specification. Customer.Type is a condition in the first rules and a conclusion in a later rule, so this is an intermediate decision.
On the other hand, rules about discount, transport, and bill type are only applicable when the decision has been taken to execute an order. They contain more-detailed, low-level decisions about order execution.
So, the three parts are related as can be seen in the stub of the main Order Policy decision table (Figure 1). The stub is the list of conditions and conclusions and contains Customer.Type (the result of another table) as a condition, and Execute Order (the link to another table) as a conclusion. Both are indicated in italics.
Figure 1. Order Policy Stub (conditions).
The Customer.Type decision table uses the conditions Account.Age and Account.Turnover to decide about Customer.Type. The Execute Order table, which is only relevant when the order is executed, uses conditions Order.Quantity and Order.Distance to make the final detailed decisions about Discount, Transport, and Bill Type.
The table structure is represented in Figure 2.
Figure 2. Decision table structure.
The detailed decision tables
We can now fill in the details of each of the decision tables, based on the business rules of the example. The Order Policy Table decides about order acceptance and links to the Customer.Type table and the Execute Order table (Figure 3).
Figure 3. The decision table and subtables.
(For illustrative purposes both horizontal and vertical orientation of the table are used.)
The nature of table structures
As shown in the example, there can be two types of subtables: condition subtables and action subtables. A condition subtable is a table that derives a conclusion about a condition, which is used in another table (inferencing). An action subtable is a table that gives more details about a high-level conclusion (refinement). The table stucture indicates these links and the nature of the reference. See, for example, the Codasyl standard report for some good examples.
Why would we use decision table structures? There are numerous reasons to work with subtables: overview, ease of use, incremental development, modularity of rule sets, maintainability, .... In some cases, subtables are recommended (reuse, normalisation); in other cases, separate tables are even necessary (e.g., for intermediate actions or intermediate conclusions).
And, like in most hierarchies, modeling can proceed in two directions: top-down or bottom-up. Top-down means that we start from the top-level decisions and work down to intermediate decisions and lower-level decisions.
A final word about verification
Good decision tables are easy to verify and validate, basically because typical problems of redundancy, incompleteness, and inconsistencies are avoided by design. A single decision table offers a nice and maintainable overview of a set of related business rules. But be careful if modeling structures become complex; you may want/have to include the same condition fact type as a condition in more than one table. In that case, verification between tables (intertabular verification) will offer a solution. But more about that in another column.
 J. Vanthienen, "Rules as Data: Decision Tables and Relational Databases," Business Rules Journal, Vol. 11, No. 1 (Jan. 2010), URL: http://www.BRCommunity.com/a2010/b516.html
# # #
About our Contributor:
All About Concepts, Policies, Rules, Decisions & Requirements
We want to share some insights with you that will positively rock your world. They will absolutely change the way you think and go about your work. We would like to give you high-leverage opportunities to add value to your initiatives, and give you innovative new techniques for developing great business solutions.