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 [1]):

Example

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.[1]

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.

Table structures can also be obtained by normalization (also called factoring).  Factoring allows us to split decision tables into distinct tables according to the principles of normalization.^[2] [3]

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.^[4]  But more about that in another column.

References

[1]  CODASYL, "A Modern Appraisal of Decision Tables," Report of the Decision Table Task Group, ACM, New York (1982), pp. 230–232.  

[2]  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  

[3]  J. Vanthienen and J. Wijsen, "On the Decomposition of Tabular Knowledge Systems," New Review of Applied Expert Systems, (1996), pp. 77–89.  

[4]  J. Vanthienen, C. Mues, A. Aerts, "An illustration of verification and validation in the modeling phase of KBS development," Data & Knowledge Engineering, Vol. 27, No. 3 (1998), pp. 337–352.  

# # #