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:

View the original article here

Decision Trees

This second and last article in this series discusses decision trees, what are they, when to use them and when not to use them. Decision trees help systems reach a predictive decision that relies on navigating a path of historic knowledge to reach the end conclusion. An analyst or rules writer lays out the decision path with branching conditions leading to different outcomes. Decision tress during execution very closely resemble structured programming. The serially arranged branching statements can be compared to nesting if…then…else statements in traditional code.

In contrast to decision tables, decision trees have the advantage of being able to contain an inconsistent set of parameters without necessarily making the tree more complex. For example, each branching point does not need to concern the same parameters. Trees become more complex when each parameter potentially has a large number of different values. This is the inverse of decision tables. Each possible parameter value becomes a node at a branching point in the tree. Trees are generally complex and unruly to represent and even more so when the number of branches and levels grow.

We do NOT recommend using decision trees as an implementation for rules unless there are very good reasons to bypass inferencing and force the execution of one rule before another. We do not recommend decision trees for the following reasons:

Decision trees are very brittle when rules change and require significant maintenance.Decision trees quickly become complex and difficult to manage.Rule engines utilize inferencing to determine the execution order of rules. Decision trees hardcode the execution order of rules which circumvents the entire inferencing capability of rule engines and make rule maintenance equate to the maintenance of hard coded and nested if…then…else statements.The entire decision making process is triggered by making a choice about one parameter (the root element). With inferencing, the rule engine can start anywhere and work its way towards the same answer from any angle as it executes rules.Ordering the execution of a small number of rules within a ruleset is better done through rule execution prioritization using weights rather than trees. Even so, this should rarely be necessary.

Trees can be made more user friendly and manageable by writing a high level rule flow around the execution of rule sets and decision tables.

We DO however recommend using decision trees during the rule analysis process for the following reasons:

Decision trees will help analysts identify groupings of rules, which generally trigger together, which will assist with the identification of rule sets.Identical smaller branching structures at different places within a larger tree expose ruleset reuse opportunities within a ruleflow.Analysis using decision trees may expose business processes currently hidden within a larger chain of rules.

View the original article here