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.

Figure 1: Each row in the table corresponds to a decision to the logic question:

Figure 1: Each row in the table corresponds to a decision to the logic question:
If New Customer=Input 1 and Bad Experience= Input 2 and Order Volume = Input 3
Then Customer Score = Output 1 and Earned Points = Output 2 and Premium Customer = Output 3

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

Decision tables are only one part of the way that Visual Rules represents business logic. The central metaphor for the Visual Rules modeler is the Flow Rule, which is yet another visual depiction of logic. In fact, a decision table and a rule flow are equivalent. They are both a form of a directed graph. A directed graph is a mathematical function that can be represented as a logic diagram or map. They often appear in science and math; however, most management persons are familiar with the decision tree. For instance examine the directed graph that is posted on Professor David Weiss’s lecture pages:
Figure 2: Each node in the diagram directs actions in the diagrams model.

Figure 2: Each node in the diagram directs actions in the diagrams model.

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.”

Were truer words were ever said, especially when we model business logic?
In the decision tree, logic is tested in each node of the branch to decide the branch. Let me be clear: a Visual Rules Flow Rule is not, strictly, a directed graph. There are not enough restrictions in the modeler to create a formal mathematical function; however, the concepts of the directed graph give the Flow Rule its power, flexibility and expressiveness. Moreover, when properly used it can be one of the best methods of describing how business rules or logic works.
Chief among the mathematical ideas of both the Flow Rules and the decision table is that they would be ‘Composable’. Simply put, composable functions, can call each other with predictable results. For example if a decision table of insurance policies is a function, F1, and a table of current benefits is a function, F2, then the you can build a new function F3 by composing the two F3=F1(F2()).As business rules are added to the visual model, the combination of Flow Rules, and decision tables should create consistent results. Again, this is not strictly mathematical— Visual Rules can combine a Flow Rule with a decision table, and there are mechanisms for creating a stable outcome.

Converting the table into a flow rule

In fact, version 5.0 of Visual Rules can convert a decision table can convert a decision table into a Flow Rule. In the figure below our example decision table is converted into a Flow Rule:
Figure 3: Decision Tables can be converted into Flow Rules in version 5.0

Figure 3: Decision Tables can be converted into Flow Rules in version 5.0

Resulting in the Flow Rule below:

Figure 4: FlowRule

Figure 4: FlowRule

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
 

About the author

Tom Debevoise

Tom Debevoise

Tom Debevoise was a regular contributor to our blog until 2013. His interest is in building practices that empower the business analyst or expert to use a framework of software and methods to create their own process, services and managed events. Tom is the the author of several books, “The Data Warehouse Method,” “Business Process Management with a Business Rules Approach” (2006), and “A Microguide to Process Modeling in BPMN”.