Database professionals are prone to equating 'integrity constraint' with 'business rule'.  Are they the same?  Probing deeper, it's generally accepted that any integrity constraint can be violated -- indeed, the reason you define them is to prevent that very thing from happening.  Can all business rules be violated?  Is violating an integrity constraint the same as violating a business rule?

To make sense of these questions, consider the following sample rules.

1. A barred driver must not have possession of a rental car. 
   
   This is an operative (behavioral) rule.  It can be violated in real life for a variety of reasons -- e.g., theft.  In the real world, unfortunately you can't always prevent that from happening.  This sample is a true business rule -- it is relevant to the business without any mention of a system.
   
   
2. A car rental always has a rental customer. 
   
   This is a structural (definitional) business rule.  The sense of this rule is that something simply isn't a car rental without a rental customer -- by definition.  You can't really violate a rule that establishes whether something is or is not something by definition.  That's just the way it is.  Nonetheless, this sample is also a true business rule -- it is again relevant to the business without any mention of a system.
   
   
3. A customer record may include at most one phone number.  
   
   This case is fundamentally different.  There's generally no such rule in real life or business -- someone has made a (database) design decision in the form of a rule.  A system can prevent violations in the data, but certainly not in real life.  This is a system rule, not a business rule.

So which of the samples above are integrity constraints?  Obviously the third is.  With some translation work, perhaps the first and second could become ones too.  But they would need to become more data-ish first.  And that's the key difference.  Business rules always have to do with the conduct and decisions of people; integrity constraints and system rules always have to do with the integrity of data.  That's a big difference!

Also note that in contrast to integrity constraints, not all business rules can be violated.  The reason is that some business rules (e.g., the second above) have to do with the way people understand concepts and make decisions.  You can misapply such rules, but you really can't violate them per se.

To emphasize these points, let's examine two more sample rules.

• A rental can have at most two drivers.
  
  This operative rule forbids the customer to put the third driver behind the wheel.  In the real world, it obviously can be violated.  There is simply no way to prevent it.
  
  
• A rental can have at most two recorded drivers.
  
  This is a system rule.  If the rental record has only two slots, it is not possible to record a third driver.  Violations can be prevented -- because they are data violations, not people violations.  This integrity constraint is a data-recording (i.e., system) rule.

The business rules approach makes a clear distinction between these two cases.  It prescribes looking first at rules from a business point of view, then at the rules from a data-recording point of view (whether by computer, pencil-and-paper, abacus, etc.).  If you can't get the former right, you'll never get the latter right.  By the way, getting the former right doesn't guarantee you will get the latter right -- it just gives you the best possible chance.

In my experience, failing to appreciate the distinctions between business rules and system rules or integrity constraints is a root cause of many IT 'requirements' problems.  A customer record may include only one phone number.  The system may record only two driver names in the record of a car rental.  Integrity constraints probably, but not business rules!

# # #