Simplifying and Optimizing Tabular Decision Models
Decision tables and table structures provide a good overview of a set of business rules. Relations between tables model the relations between the final decision and lower-level (intermediate) decisions, while the tables model related business rules with common conditions and outcomes.
Experience shows that, although decision table models usually already provide a good representation of the decision logic, there may still be multiple ways to simplify and optimize the model. Throughout decennia of decision table usage, the following best practices have been observed:
1. Table Simplifications
Assuming that all relevant conditions, condition values, and outcomes for condition combinations are known, the table can still be represented in different ways: expanded or contracted. Expanded means that every single combination of condition values is shown, while a contracted table 'contracts' one or more rules (columns) into combined rules (columns) using the notation "-" (irrelevant). Note that this does not, and should not, alter the decision logic. It is just a matter of visual representation (and a matter of taste, tool, or timing).
Figure 1. An expanded decision table.
Figure 2. A contracted decision table.
In Figure 2, the first two rows from Figure 1 are combined into one. As you could imagine, the expanded view might be more useful when modeling is not yet complete. Once the business logic is considered correct, consistent, and complete, the contracted view is interesting because of its higher content per ink ratio, meaning it is more concise. Conciseness can be interesting for human viewers.
The contracted table also has the advantage that the 10% discount for web orders is only written once, so if the percentage changes, there is no risk of inconsistency.
A big note: Contraction is not about faster execution. We are still just modeling.
Another big note: Not every tabular representation is a good decision table.
There is a common misunderstanding that anything that looks like a table of rules is a decision table. As already indicated in the earlier CODASYL report on decision tables a good decision table is a complete table with mutually exclusive columns, meaning that each possible combination of conditions can be found in exactly one (one and only one) row (or column). If the rows are not exclusive, at least one combination of conditions is present in more than one row, which may look like a harmless redundancy but it opens the door to (future) inconsistencies.
The contracted decision table therefore should still contain mutually-exclusive columns only. That is a matter of contraction discipline (or tool). Even recent tools or methods sometimes show a decision table as in Figure 3.
Figure 3. A bad decision table.
Figure 3 is a bad decision table. It might originate from a rule stating that "A 10% discount is given for Web or US orders." The table looks compact, but it is considered bad practice because the combination Web – US is present in both row 1 and row 2. What if the discount for a Web order for a US customer changes? This is not a disadvantage of decision tables, it is simply a bad decision table because of the overlapping columns.
The same objection holds against tables that require traversing the rows in a certain order (because of overlapping columns). Good decision tables (i.e., with exclusive columns) do not require this.
Condition Order Optimization
The order of the conditions is not important, i.e., it does not change the (declarative) business logic. If it were, there would be some hidden semantics or procedural thinking in the decision table. But, again for human viewers, reordering the conditions might lead to a different contraction, and therefore to a more compact table. This is especially the case if some conditions can have more than two values. Figure 4 shows a reordered version of Figure 2.
Figure 4. A reordered decision table.
In this case, the table is not more compact, but it shows a different view on the business logic.
Note: We are still in the modeling phase so the testing order of conditions is not relevant here. That is an execution-time issue.
Dealing with execution time is not a decision table modeling issue. Of course, execution time might be important later, and there exist several algorithms to transform decision tables into general execution trees, taking into account condition test times and condition combination frequencies. It is interesting to note that an execution tree does not necessarily test conditions in the same order in every branch of the tree and therefore can be made more execution-efficient than a tree where conditions are always examined in the same order (like in a decision table). But that should not be a decision table modeling concern.
As indicated in an earlier article, there is a striking similarity between decision table modeling and database modeling. A number of interesting consequences (functional dependencies, primary key, normalization forms, factoring) can already be found in  and . Normalization rules for decision tables require that actions are fully dependent on all the conditions (2nd normal form) and that actions are non-transitively dependent on the conditions (3rd normal form). If the result of the decision table is only dependent on a subset of the conditions, the other conditions are of course redundant, as can be seen in Figure 5. Figure 6 removes this redundancy.
Figure 5. A decision table containing a redundant condition (TypeOfOrder).
Figure 6. The normalized decision table.
2. Model Simplifications
Because the normalization rules for decision tables require that actions are fully dependent on all the conditions (2nd normal form), these rules can be used to factor (split or join) decision tables. This is the area of decision table structure modeling and was described in an earlier article.
 Vanthienen J., "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
 Vanthienen J., Snoeck M., "Knowledge Factoring Using Normalization Theory," International Symposium on the Management of Industrial and Corporate Knowledge (ISMICK'93), Compiègne (FR), pp. 97-106, October 27-28, 1993.
 Vanthienen J., "Modeling Decision Table Structures," Business Rules Journal, Vol. 11, No. 11 (Nov. 2010), URL: http://www.BRCommunity.com/a2010/b565.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.