The Newest Idea in Business Rules: Rules Normalize!

by Ronald G. Ross

This column originally appeared in the March/April 1996 issue of the Data Base Newsletter.

The foundation for formal thinking about integrity in database designs, of course, is normalization from relational theory. Normalization provides sound prescriptions -- very practical ones -- to evaluate whether a database design for persistent data is a good one with respect to integrity (correctness). These prescriptions are represented by the normal forms (1NF, 2NF, 3NF, etc.).

Rules also directly address integrity; that is, which database states are permitted, and which are not, based on business rules. The question naturally arises: Is there a connection between rules and normalization?

The emerging answer is yes. The connection is a fundamental one -- and very exciting! I believe this discovery is among the most significant of the newly emerging field of business rules. (More on that in a moment.)
To understand the connection, consider these two observations about rules.

First, rules are, or at least have, data. This data includes (but is not limited to) the truth value of the rules. Although this is not regular 'business' data, it is data nonetheless.
Second, this data is persistent. It must last longer than individual frames of processing (transactions) so that the rules can be tested across applications.

In other words, rules involve data, and that data persists. This is exactly where normalization takes up for regular business data. The implication is that normalization can be applied directly to rules -- in other words, that rules normalize. (Actually, that is not exactly the right way to say it. Relational experts say that tables normalize. Unfortunately, saying "rules have values that can be considered along with the other values of a table when normalized" does not have quite the same ring to it.)

The profound insight that rules normalize seems obvious once you think about it. How could it be any other way? There are at least two important implications, as follows.

It can be exploited directly in a syntax for modeling rules. In the graphic syntax I have devised, the type in the data model to which a rule normalizes is shown explicitly -- this is a basic organizing principle.
It can provide an indisputable test -- one that is not ad hoc or based on aesthetics -- for deciding when an information system design that addresses rules is a good one. In other words, it tells you explicitly where the rules should go.

If you have followed object orientation (OO) in recent years, especially OO approaches to analysis and design, you may have sensed that something like this has been sorely missed. (This is especially true about the responsibility-driven camp.) It is a source of great confusion -- and, I believe, one very good reason you why you should be considering a business rule approach.

standard citation for this article:

Ronald G. Ross, "The Newest Idea in Business Rules: Rules Normalize!" Data Base Newsletter, Vol. 24, No. 2 (Mar./Apr. 1996), URL: http://www.BRCommunity.com/a1996/a335.html

September 2005
The Fin de Siegle Legacy Mindset
By Ronald G. Ross -- (November/December 1999)

August 2005
Analysis Paralysis Just May Save Your Life
By Ronald G. Ross -- (September/October 1999)

July 2005
If We Had Started Coding Already...
By Ronald G. Ross -- (July/August 1999)

June 2005
Your Core Business Processes Need a Rule Engine
By Ronald G. Ross -- (May/June 1999)

May 2005
Four Things Wrong with the Way We Develop Information Systems
By Ronald G. Ross -- (January/February 1999)

April 2005
Push-Type Data Hub vs. Pull-Type Data Warehouse
By Ronald G. Ross -- (November/December 1998)

March 2005
What Knowledge Management is About (And What it Has To Do With Business Rules)
By Ronald G. Ross -- (September/October 1998)

February 2005
The Next Great Leap Forward ~ About the Changes You See
By Ronald G. Ross -- (May/June 1998)