Using Decision Tables - Take 2!
Published by Rajgo December 20th, 2006 in Business Rules, BRMS, Rule Engine, QuickRules.NET, Business Rule Engine, Business Rules Management System, Decision TablesJames pointed out to a post on Decision Tables in Krzysztof’s blog in his comment, and I wanted to add my two cents.
Decision Tables, along with Flow Rules are the most business user friendly business rules formats available.
Most Business Analysts I have come across are most comfortable with Decision Tables, and Flows (Sequential rules in the form of a Flow Chart). I don’t think anyone really captures their requirements as Decision tables, but many requirements are captured as Excel tables. These are prime candidates for capture as Decision Tables.
Decision tables provide a near zero learning curve for business analysts and managers , and help adoption of business rules technology by increasing participation, or at least improving confidence levels among analysts >> Hey, I can do that !
One of the things that James mentioned in his comment in Krzystof’s blog was interesting
Most BRMSs (e.g. Blaze Advisor and JRules) “compile” tables and trees into production rules though as that is what their engines execute. Not sure this is inherent in the design of decision trees and tables though.
Lastly I think you miss a key point. trees and tables are usually used to represent rules that are exhaustive (all cases covered) and exclusive (only 1 path / row for any case). This means there is no inferencing where more conventional rulesets may include chains of rule reasoning.
I am assuming that this means the following.James, correct me if I got this wrong! The blog post that contains the above comment is old, so things might be different now.
- Decision Tables are compiled into a Rete Network
- Decision Tables return a single match only.
Now, lets see what this means.
- If Decision Tables are compiled into a Rete Network, then this might mean that for large Decision Tables, the network itself will become very large affecting rule engine execution performance
- Why should Decision Tables return only a single match. There can be decision tables that can return multiple matches. For example, Product Recomendations can come from a Decision Table that returns multiple matches.
- If the tables get compiled into a Rete Network(assuming 1 is true), then how would any rule engine be able to guarantee that a top row will match before a lower row, that can also be satisfied for the same data? If this guarantee is not provided, then it means the onus is on the person writing the Decision Table to ensure that there is only one match.
Now, Decision Tables, the way I have seen it implemented in QuickRules, work differently. I have explained it here in this post, DecisionTable Execution Engines - Meeting the Need for Speed.
Well I can only speak for Blaze Advisor and with Blaze Advisor you have a choice - sequential execution, compiled execution or Rete III-based execution - for decision tables the same as you do for any ruleset. For a very large decision table, where a very small percentage of the rules will fire, Rete-based inferencing is actually much faster at finding and executing the right rule than sequential execution. Decision Tables, like any ruleset, can return many hits. So:
1 - if you like
2 - no
I absolutely agree that Decision Tables are a perfect fit for capturing business rules. But what most people don’t realize is that there are many variations of Decision Tables and they’re not all functionally equivalent. Most flavors are good for specific scenarios where you are trying to compare a single (or possibly few variable) to a maze of literal values. How Decision Tables are used by most vendors is effectively as a special tool in the toolkit that should be used when circumstances are right.
Corticon uses a patented extended Decision Table that is capable of modeling any and all rule sets that can expressed using first-order predicate calculus. Any production rule set that can be executed in an inference engine can in fact be modeled in Corticon Decision Tables. In fact, Decision Table (or what we call Rulesheet) is the only rule modeling metaphor we use. Our flavor of Decision Table also lends itself nicely to rule analysis (conflict check, completeness check, conflict resolution, …).
Last but not least, our Decision Table design also lends itself nicely to rule execution. We do not use/need a traditional inference engine. We have a patent pending algorithm called DETI (DEsign-Time Inferencing) that leverages the Decision Table metaphor and the fact that rule conflicts are resolved at rule modeling time to generate the most optimal Decision Service (a deployment unit of a rule set) that can scale well with both increasing number of rules and increasing amounts of input data.
Traditional inference engines are designed to scale well with increasing number of rules but they fall apart with increasing amounts of data. It’s just a matter of how much data can be pumped into an engine before it suddently degrades exponentially. Corticon engine scales linearly with increasing amounts of data because it doesn’t have to take the hit of a runtime in-memory network to perform conflict resolution.
Thank you James and Pedram for participating and letting me know your view points on Decision Tables !
I believe the following statement is wrong and does not apply to modern RETE implementations.
“Traditional inference engines are designed to scale well with increasing number of rules but they fall apart with increasing amounts of data. It’s just a matter of how much data can be pumped into an engine before it suddently degrades exponentially. Corticon engine scales linearly with increasing amounts of data because it doesn’t have to take the hit of a runtime in-memory network to perform conflict resolution”
one of the reasons why older RETE engines had problems with large dataset is due to maintaining the bindings. Any RETE implementation that uses late binding does not suffer from that specific problem. One can take it even further and use do things like turn off alpha memories, by-pass the agenda for stream processing and several other simple enhancements.
I think it’s great that Corticon is trying different things and applying backward chaining rule validation techniques to make authoring easier. My main caution to users is that no matter how nice the writing part is, how does the tool make it easier to maintain and understand a large ruleset? Does it have the ability to analyze the rules and show the relationship to the user? Can it display a subset in a tree format or a flow diagram?
I can think of a dozen cases where one really needs runtime inferencing in a business case and none of them would be feasible in a decision table. Those cases are generally harder so solve and require rule expertise and domain expertise. I would say that largely it doesn’t matter what product or tool a person uses for the difficult cases. What matters more is taking time to analyze the business problem and creating a solution to fit the problem.
It is far to simplistic to say decision tables is easier for business users to use if it all ends up in a huge mess. There are plenty of customers of various BRMS products that ended up with tens of thousands of rules in a decision table and get overwhelmed by the maintenance.
What I see is the primary problem isn’t authoring. It’s maintenance, auditing, reporting, tracking and flexibility.
Peter,
Those are some really good valid concerns. Your statement: “My main caution to users is that no matter how nice the writing part is, how does the tool make it easier to maintain and understand a large ruleset? Does it have the ability to analyze the rules and show the relationship to the user?”, has always really intrigued me.
I work for Acumen Business, and we have addressed this issue by the introduction of an Interactive Rule Map. Sometimes referred to as Rule Spider. This dynamic rulemap shows the direct dependencies of rules to terms and from terms to rules.
There is also a complete Rule Graph generation, however that will quickly loose it’s power when hundreds of rules are defined. The interactive rule map is an advanced browser through the complete rule graph.
We also provide Rule Verification and Rule Validation, but that by itself is not sufficient to assist the Business Rule Author.
You can see this all in action within the Rule Manager that is available on our website.
(http:\\www.acumenbusiness.com)
Marco Ensing