The trouble with tables I
My associates in Bosch Software Innovations might forgive my onomatopoeic reference to the Star Trek Episode. This post has as much algebra as I will ever produce in a blog posting. As such, this posting has a technical nature that appeals to attendees of Star Trek Conventions.
A decision table is both a compact form of logic and a mathematical function or map. In a decision table, logic is modeled with conditions that correspond to an action. For instance in the decision table below, the customers score, loyalty points and premium status (blue) are set by the yellow predicates of new customer, bad experience and order volume.
In both math and the computer science based on this, the statement part, after the if, is a node and the set of predicates is known as the guard. In computer science, a logic engine might use the Quine–McCluskey algorithm to optimize the ordering of the logic. Decision Tables, an ordered grouping of nodes, play an prominent role in business rules methods in general and in the Visual Rules approach.
Decision tables are, certainly, a powerful metaphor for modeling business rules. In certain circumstances, the quality of business rules can be improved by modeling them with decision tables. There are many things to consider when properly modeling business rules with decision tables.
Decision tables and flow rules are equivalent
The article has a very compelling quote that follows this model:
“Graphical models are simplified descriptions of how some portion of the world works. They will usually not include every possible variable or all interactions between variables, but focus on the most relevant variables and strongest interactions.”
Converting the table into a flow rule
Resulting in the Flow Rule below:
Decision table capabilities are a subset of a flow rule
For several fundamental reasons, there is no conversion from the Flow Rule to a decision table. Most importantly, the Flow Rule offers more pathways and logic variations than a decision. For example, by calling other Flow Rules they can jump across logic nodes. In addition to enfolding and calling other decision tables and Flow Rules, Flow Rules can create more complex ‘nodes’. They can loop across lists of records and data, seeking a maximum, for instance, a feature that is not overtly present in decision tables.
There are more complex paths available to the Flow Rule than a decision table. Decision tables evaluate their logic, node, by node one row at a time so a decision table’s logic is not particularly flexible. Exceptions or anomalies can be raised and handled by other Flow Rules.
We have shown, Flow Rules and decision tables are both forms of directed graphs. Any logic that can be expressed in a decision table can be expressed in a Flow Rule; the reverse is not true.
More to come soon:
- Characteristics of a Good Decision Table
- Decision Model and Pseudo Relational Models
- When the only Tool you have is a Hammer every Problem looks like a Nail
- Summary: Benefits of tables/The troubles with tables