Home > The Trouble with Tables I
Feb
25 Business Rules 2 comments

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. I highly recommend the work of my longtime friend Jan Vanthienen. He has placed is an excellent summary of the decision table topic here.

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
 Article by Tom Debevoise

Since 2008, I have been with Bosch Software Innovations. I am mainly focused on government and defense projects. I am also interested 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. I am the author of three books, "The Data Warehouse Method," "Business Process Management with a Business Rules Approach" (2006), and "A Microguide to Process Modeling in BPMN" (2008).I have specific business rules experience in the fields of Supply Chain Management, Petroleum, Pharmaceutical Clinical Trials, and Health Care. At various times at Bosch Software Innovations, I manage teams of engineers, and technologist to complete complex systems integrations. When I am not working I like to play classical guitar and ride a mountain bike.
more articles by this author contact
Trackback URL for this entry:
http://blog.bosch-si.com/the-trouble-with-tables-i/trackback/

Leave a comment

  1. from Christof Pitzer   /   February 25th, 2011 at 16:17

    Just one addition referring to Toms last sentence. It´s true that not all Visual Rules (VR) rule branches can be converted into a decision table, however VR still tries. At least since VR 5.0.
    If you right-click on a decision, select “Extract branch as Decision Table”. If it cannot be converted, VR will tell you the elements, that aren´t possible in Decision Tables.
    Thanks for your post, Tom. Live long and prosper!

  2. from Tom Debevoise   /   February 28th, 2011 at 20:45

    Thanks Christof, I stand corrected. I knew that we could go from a decision table to a flow rule, but not the other way around. Also, in practice, have you ever used these features?

    Tom