Wednesday, March 22, 2006

Decision Tables and Trees

Rules can be graphically represented in multiple ways for usability purposes. Two structures are primarily used: decision trees and decision tables. Rule engines do not really care about the rule representation since either structure is compiled into similar executable rule statements.

This is the first of two posts that will hopefully give some helpful tips about when to use and when not to use decision tables and/or trees.

Decision Tables
The decision table is a very familiar decisioning structure. Price lists, bus , and train schedules are often represented as a table and function very similarly to a decision table. For example, given your current location (input parameter 1) and where you want to go ( input parameter 2), the table will tell you when the train will arrive (your outcome). At a most basic level, two different parameters are represented along the axis of the table in columns and rows. The intersections of the two axes constitute the decision point for the given combination of parameter values.

A decision table simplifies the structuring and representation of repetitive rules where only the value of the same parameters differs in determining the outcome. Decision tables are also context free. Unlike decision trees, no prior path must be completed for the table to arrive at a decision. Only input values for the necessary parameters along the axes are required.

Here are some pointers when to use and when not to use decision tables:

  • Decision tables are best used for a consistent, but limited, set of parameters , where, potentially , there are a large number of possible values for those parameters.
  • A table with many different parameters quickly becomes complex which diminishes its usefulness as a simplification concept.
  • Business analysts often use decision tables to represent a particular set of requirements, so replicating that structure in the rule engine reuses a familiar concept.
  • Decision tables can quickly highlight where an outcome or decision is missing.
  • Each decision table should only make one particular type of determination .
Also, not all parameters have valid decision outcomes in all cases. A decision table with a very sparse decision matrix may indicate that:

  • The business may need to better define the rules that drive the matrix.
  • The table may attempt to use too many parameters in one decision step and the table should be split into several decision tables connected by a rule flow.
  • A table structure may not be the best structure to represent a particular set of rules and the rules should be converted into individual rule statements.
Here are some additional helpful links about decision tables: