The Database Design Resource Center


Business Rules: Informal Predicates

Business rules, also referred to as informal predicates, are the total collection of restrictions on, and meaning of, the data in your database model.

It is important to understand the difference between the conceptual and the logical database model. It is also extremely important to understand the difference between a data model and a database model. When you know the difference, you will be laughing at many points said at different forums on the Net ;-)

It is quite simply unbelievable to notice how many so-called "professionals" are not able to see the clear difference. Please study, read, and understand, in order not to become one of them...

For clarity, I will give a brief (certainly not complete) overview of those differences:

A data model is a general model for how information should be organized. The relational model is such a data model, and in my view the only one that I know of that can be put to practical use. Some people claim that there is an XML data model, an Object data model, an Object/Relational(!) model, and so on:

For those, I recommend you to read a little about Flat relational tables, an article in the Database theory and practice section. That should put matters straight...

Tell you what: If you think I am wrong here, let me know via my Bad contact page. If you think I am right, let me know via that same Good contact page. Warning: You may end up in my Testimonials page. :-)

A database model is a model of your particular database in question. It is constructed by following directions given by the actual, general, data model (relational, I hope :-).

Your database model will most likely be developed in stages: The first stage we call

the conceptual model.

The conceptual model can, for simplicity, be seen as consisting of an E-R model with its entities and attributes, and business rules governing those entities and attributes.

So let me give you a few examples of typical business rules:

  • All attributes of type "Transaction amount" must have a value larger than 0.01
  • All employees must have an age between 18 and 60 years
  • No employees may have illegal Social Security Numbers
  • A transaction can not be posted on a non-existent account no<
  • All credits above 1.000 USD must be approved by the manager of the employee wanting to grant credit to a customer

In short, all limitations and relationships between the complete set of information elements in your database model.

Do look up many terms in database design in my database glossary

Business rules are defined on four levels:

  • Domain
  • Attributes
  • Entities
  • Inter-entity

In the first list, example 1 is a typical domain level rule, 2 is typically an attribute rule, 3 is a rule for the entity of Employees, while 4 and 5 are inter-entity rules (involving more than one entity).

Remember one very important thing here: At this stage, we are building the conceptual model. We are talking natural language: here: That's why we refer to business rules as informal predicates: At this point, we should not care too much about how we will achieve this in our applications.

I know, I know: It is very easy to start on that route: This is where most projects screw up. First of all, we must document the business as correctly as possible. Only then can we move towards the logical database model.

Again, please note the difference between a data model and a database model: Most people get this wrong. Journalists get it wrong. "Experts" get it wrong. You won't, right?

The transformation of business rules, also known as informal predicates, into formal predicates, is done when we transform the conceptual database model into a logical database model. If you f.i. are familiar with Oracle Designer, this will be the Server Model.

The logical database model is the source for further refinement of your database structure. An important part of that transformation, is to be able to transform all your business rules (informal predicates; natural language) into formal predicates, defined in a declarative language (DDL). Typically, the formal predicates will become database constraints.

Here is a set of articles on Oracle database constraints. These articles pretty much describe the possibilities and limitations you are faced with when you try to transform your business rules into database constraints.

From the finished logical database model, we can generate all the necessary DDL scritpts (CREATE TABLE, INDEX, etc.) that will ultimately implement the physical database model on the system's hard disk(s).

To sum it up:

A data model is the foundation for analyzing and defining a:

Conceptual database model, which is transformed into a

Logical database model, which in turn is used to generate the

Physical database model.

Informal predicates, or business rules, spelled out in natural language, must be transformed into Formal predicates, which in turn are defined as constraints in your database.

Return to Database Theory and Practice


Exclusive interviews with:
Steven Feuerstein, PLSQL expert
Donald Burleson, Top IT consultant


Free eBook

Subscribe to my newsletter and get my ebook on Entity Relationship Modeling Principles as a free gift:


What visitors say...

"I just stumbled accross your site looking for some normalization theory and I have to say it is fantastic.

I have been in the database field for 10+ years and I have never before come across such a useful site. Thank you for taking the time to put this site together."

Mike, USA

Read more Testimonials


Database Normalization eBook:


Database Normalization eBook



Copyright © www.databasedesign-resource.com / Alf A. Pedersen
All rights reserved.
All information contained on this website is for informational purposes only.
Disclaimer: www.databasedesign-resource.com does not warrant any company, product, service or any content contained herein.

Return to top

Copyright acknowledgement note:

The name Oracle is a trademark of Oracle Corporation.
The names MS Access/MS SQL Server are trademarks of Microsoft Corporation.
Any other names used on this website may be trademarks of their respective owners, which I fully respect.