Business Rules: Informal PredicatesBusiness 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:
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:
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:
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.
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.
Free eBookSubscribe 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.Read more Testimonials
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."
Theory & Practice
SQL Server DBA
Install SQL Server
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
The name Oracle is a trademark of Oracle Corporation.