TDAN: The Data Administration Newsletter, Since 1997

THE DATA ADMINISTRATION NEWSLETTER – TDAN.com
ROBERT S. SEINER – PUBLISHER

Subscribe to TDAN

   > home
 Printer-friendly
 E-mail to friend

Business Rules – February 2009
Are Integrity Constraints Business Rules? Not!

by Ronald G. Ross
Published: February 1, 2009
Data 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? This column examines these and related questions.

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.

  • 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.
  • 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. 
  • A customer record may include at most only one phone number. This case is fundamentally different. There’s generally no such rule in real life or business – someone has made a 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 may have at most only 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 may have at most only 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!

Go to Current Issue | Go to Issue Archive


Recent articles by Ronald G. Ross

Ronald G. Ross -

Ronald G. Ross serves as Executive Editor of www.BRCommunity.com and its flagship publication, Business Rules Journal.  He is a sought-after speaker at conferences world-wide. His gives popular public seminars through AttainingEdge (www.AttainingEdge.com) and in Europe though IRM-UK (www.IRMUK.co.uk).

Mr. Ross is recognized internationally as the “father of business rules.” He has served as Co-Chair of the annual Business Rules Forum Conference (www.businessrulesforum.com) since 1997. He was a charter member of the Business Rules Group in the 1980s, and an editor of the two landmark BRG papers, “The Business Motivation Model: Business Governance in a Volatile World” and the “Business Rules Manifesto”. He is active in OMG standards development, with core involvement in SBVR.

Mr. Ross is Co-Founder of Business Rule Solutions, LLC (www.BRSolutions.com). At BRS, Mr. Ross co-develops ProteusR, its landmark business requirements methodology, including the popular RuleSpeakR. Mr. Ross is the author of eight professional books. His newest are: Business Rule Concepts (2005), a 2nd edition of his popular, easy-to-read 1998 handbook, and Principles of the Business Rule Approach, Addison-Wesley (2003).