Decisions in Your Tables

So how do I start explaining about decision tables? Well, its an interesting subject..

Introduction

What does wikipedia say ?
"Decision tables are a precise yet compact way to model complicated logic. Decision tables, like if-then-else and switch-case statements, associate conditions with actions to perform. But, unlike the control structures found in traditional programming languages, decision tables can associate many independent conditions with several actions in an elegant way."

Decision tables, for me, seem to make sense in that they model logic into an understandable table-diagram that can be checked easily.


Advantages to Using Decision Tables

The first advantage of decision tables, in my opinion, would be to replace if-then-else statements with something more manageable.

Printer troubleshooter

		Rules
Conditions	Printer does not print	Y	Y	Y	Y	N	N	N	N
	A red light is flashing	Y	Y	N	N	Y	Y	N	N
	Printer is unrecognized	Y	N	Y	N	Y	N	Y	N
Actions	Check the power cable			X
	Check the printer-computer cable	X		X
	Ensure printer software is installed	X		X		X		X
	Check/replace ink	X	X			X	X
	Check for paper jam		X		X

Here you can see an example of a decision table for a printer trouble shooter. Above are the conditions (the if-then-else) and below are the actions to take according to the conditions.
While this table contains quite a few options, you can see that its easy to handle them because it is more visual then if-then-else.

Now, since this is a blog about MySQL, lets pretend for a minute that it would be a good idea to put your decision table in your database. Why? well, because databases hold tables. Think of it as a regular configuration file (like an XML file or an INI file), but you just decided to keep it in your database.
So what have you done exactly? Well, you have seperated your if-then-else statements (your logic) and then convert it into a diagram (which happens to fit nicely into a database table). So basically, you have abstracted your logic from your application code into a manageable place. This is very important.
By abstracting your logic, you can now manage changes in your application.What this means is, in the future, if you need to make a change to your logic, you can simply change your decision table and the logic will be updated in your application. In theory, you can also let non-technical people make changes in these tables also.
So the second advantage for using decision tables is for managing change and the third advantage, again in my opinion is debugging. Just the fact that its more visual and you can see the paths for conditions and actions, helps to debug errors.

Example

An insurance company wants to setup a system that will determine if their already existing customers deserve a discont on their next policy and/or get money back.

For a customer to get a discount on his next policy he/she needs to:

• Already have an existing policy with the insurance company
• Want to renew his/her policy with the insurance company
• Must have paid most of the monthly insurance payements on time. Atleast 75% of the time.
• Customers who have big insurance policies (that are over 10,000 USD) can also get discount, but only if those customers paid on time not less then 50% of the time.
• Customers who are very good can also get some money back. Meaning, they must have paid more then 90% of the payments on time and not made any claims on their insurance policy.
• If a customer has made claims on their policy over 50% of the value of the policy, they will not get a discount or money back.

Here is the code for these conditions:

-If HasPolicy(Person) = True {
--If Wants2Renew(Person) = True {
---If Not(PaidOnTime(Person) = ‘Less50%’) and Not(UsedPolicy(Person) = ‘More50%’) {
----If (PaidOnTime(Person) = ‘More75%’ and BigPolicy = True) {
-----Discount = True;
-----MoneyBack = False;
----} Elseif PaidOnTime(Person) = ‘More90%’ {
-----Discount = True;
-----If UsedPolice(Person) = ‘NotUsed’ {
------MoneyBack = True;
-----} Else {
------MoneyBack = False;
-----}
----} Else {
-----Discount = False;
-----MoneyBack = False;
----}
---} Else {
----Discount = False;
----MoneyBack = False;
---}
--} Else {
---Discount = False;
---MoneyBack = False;
--}
-} Else {
--Discount = False;
--MoneyBack = False;
-}

Here is a condition table for the same example. Minus (-) equals all the options.

Conclusion

As you can see decision tables are much much better then writing code, because its half the size...
.
.
.
HEY! wait a minute! that code is waaay too long, I can do much better than you!

Ok Ok, lets refactor the code:

-If HasPolicy(Person) and Wants2Renew(Person) and ((PaidOnTime(Person) = ‘More75%’ and BigPolicy(Person)) or (PaidOnTime(Person) = ‘More90%’)) and Not(UsedPolicy(Person) = ‘More50%) {
--Discount = True;
--If PaidOnTime(Person) = ‘More90%’ and UsedPolicy(Person) = ‘NotUsed’{
---MoneyBack = True;
--} Else {
---MoneyBack = False;
--}
-}

So here the code if a lot smaller. I do admit that it did take me some time to check the code (and I might have mistakes) and I didn't get the chance to make tests for it. Normally, after writing code, you would test it many many times over to see that it does what its supposed to do.

Conclusion

Decision tables can help you make things clearer when it comes to implementing logic in your application. It also helps debug and manage changes.

For the example above,

The insurance company decided that giving money back will now also be given to people who already have an insurance policy, but may or may not want to renew their policy with the insurance company.

Please change the program for this new requirement.