Business Rules: Informal Predicates

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...

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