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:

1 Comments:

At 3/28/2006 9:52 AM, Blogger KK said...

James,

Yes, I meant rules being graphically represented in the engine. Sorry about that.

"Most BRMSs "compile" tables and trees..."

James, yes, that is exactly what I meant when I said that "either structure is compiled into similar executable rule statements". You are right however; I can't make a global assumption about how a particular vendor has chosen to implement the execution of trees and tables.

Last, while tables and trees are typically well defined, they do not tend to start out as such. Quite often rule writers will return to the BAs asking for further definition and typically the BAs will be able to provide that information. Having empty action cells isn’t necessarily considered an invalid outcome however and so it does happen. In the case however where the complete outcome space cannot be defined, there it might be better to convert the table into individual rule statements.

As to BAs defining requirements in the form of tables and tress...we do frequently see requirements represented as tables with our clients. Often these tables will be sourced from existing manuals or legacy database table driven decisioning systems. Trees are not as common, I agree.

 

Post a Comment

<< Home