Internet of Things and Services Blog | Bosch Software Innovations » The Trouble with Tables Part II

Part I Recap

In my first post on decision tables, I described how decision tables and flow rules share the same theoretical basis, and why a decison table can be converted into a flow rule but not the reverse. In this post I will use this reasoning to discuss aspects of the Visual Rules approach to decision tables. I will also cover the table-within a table approach other methods use to model business rules.

Characteristics of a Good Decision Table

In examining at many business rules in Visual Rules, the characteristics of a proper decision table are clear. The business logic that is modeled by the decision table should appear tabular and symmetrical. As the customer case shows, a decision table is easy to understand when the top-down logic has a dendritic quality. In the real world, business logic often is asymmetrical and decided with heterogeneous data sources. That is: data elements for a single logic node might be different at the branches. Placing this kind of logic into a decision table would lead to sparse sets of predicates. There are three more characteristics of a good subject area for a decision table:

• Decision tables should be small in scope, generally under 2 viewable pages. It should be simple to view and edit the decision table.
• The conditional columns of the decision table should be used frequently. Empty or nil values should be rare.
• The conditions should be mostly data values. While Visual Rules supports expressions within condition cells, using many different functions in a condition cell obscures the logic.

Decision Model and Pseudo Relational Models

Some methodologist and software architects have created systems that place tables-within table. They apply the relational model to the decision tables. This has been suggested by first by Jan Vanthienen in the articles listed at the end of this post. For instance in the example, we can break out an internal decision table, customer score based on the order volume. By inspection one can see that the customer score can be separated. The two decision tables are as follows:

Decision Table

Where the customer score is determined by:

Figure 5: The Decision Table from figure one has been ‘normalized’ into these two decision tables.

In the relational data model, entities are connected by relations. The relations are well formed and are based on data values. For instance, we might think of the two decision tables as an entity relation diagram:

Figure 6: The two decision tables as a relational entity.

The suggested existence of the relation between Customer Score the Loyalty and Premium tables asserts that there is a well formed function that can connect these. This is evident when the predicates are pure data types; however, decision tables can contain functions, such as the functions we suggested were needed to map logic that is sparse and multi-valued into logic that is suitable for decision tables. For example the following entry into the Loyalty and Premium table breaks the well-formed nature of the relation:

Figure 7: The function in the Customer Score Predicate breaks the well formed formulae

When the only Tool you have is a Hammer every Problem looks like a Nail

From our experience, not every business rule can be fed into a decision table. The structure of business rule logic can be forced into the decision table through two mechanisms: First, the number of conditions in our asymmetric logic can be reduced with unnecessary vocabulary, functions and mapping. Next, the business rules that do not fit the decision table logic can be declared ‘out-of-bounds’ , or data manipulation or formulae These items would be ‘out-of-bounds’.

• Many formulae and computations
• Algorithms for seeking and selecting

If every fragment of logic in the Rule Flow was replaced with a decision table model, these models would become overly abstract. Since a decision table cannot loop through an array of records, these data must be prepared and fed into these decision tables. Many decision tables would have complex table conditions with expressions. To force the types of logic we encounter into decision table would require a very heavy methodology, one that requires adding a syntax or dictionary of terms. These terms compress the natural flow of the logic into a form that permits the logic to artificially fit a decision table.

Summary

Benefits of tables are:

• They provide a compact, succinct form of visual logic
• Many organizations have existing logic built into the decision tables
• With their limited logic variations, it is possible to perform automated checks on
• Maintaining well designed decision table is simple.

The troubles with tables are:

• Very large decision tables are difficult and complicated to maintain.
• Many business logic problems are asymmetric. Forcing symmetry with mappings and functions obscures the business logic.
• The logical pathways supported by decision tables are limited.
• Business rules that must iterate through records are not supported, or algorithms that must process arrays, and business rules that need services cannot be placed into decision tables

To create a decision table-only approach, all decision must be collapsed into a simplified hierarchy of logic. Yet, we often encounter decision scenario’s that filter records, compute the aggregate of a measure or conditionally jump across decision areas. These challenges are not easily placed into a decision table without a heavy vocabulary-oriented approach. Alternately, complicated computer code can be written to address this.

Therefore, developing a decision model should not be an exercise in data modeling. Visual Rules decision graph approach is more flexible and provides more visual metaphors. The result is a broader definition of decision, one that can meet the needs of a wide range of technical capabilities.

References:

• Integration of the decision table formalism with a relational database environment, Vanthienen, J., Wets, G., 1995 , Information Systems, vol. 20, no. 7 (Nov.), pp. 595 – 616., refsdtpubs\DT&RelDB_InformationSystems.pdf
• On the decomposition of tabular knowledge systems Vanthienen J, Wijsen J, 1996, DTEW Research Report 9604, 11 pp.
• Knowledge factoring using normalization theory Vanthienen J, Snoeck M, 1993, International Symposium on the Management of Industrial and Corporate Knowledge (ISMICK), pp. 97 – 106, DTEW Research Report 9306, 20 pp., refsdtpubs\NORM4WIN.pdf

Article by Tom Debevoise

Since 2008, I have been with Bosch Software Innovations. I am mainly focused on government and 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 @tomdebevoise Google+ LinkedIn