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.

# # #