The Database Design Resource Center



Business Rules | NULL values | Atomic values | Flat tables | Objects vs tables.


Database Theory and Practice :
The very Fundamentals for Database Designers

This section of the site deals with database theory and practice : What is the relational data model telling us about how we should organize our information, and how we actually have to DO it in today's different products from database vendors.

This section is probably the most important one of the whole site, so I hope you read it carefully and THINK.

You will find that in many cases, we end up with more of a philosophical than a technical situation, when we deal with the theoretical aspect. Then we have the practical aspect: How do we use the theoretical foundation in order to create high-quality, fast-performing, rock solid relational databases?

This section of the site is meant to give you some advice, and to explain some of the theoretical issues.

I will quote Chris Date: "Theory is practical!" And I agree.

I hope that this section will help you draw the same conclusion...

OK, let's get on with it:

The first article in this section of my site deals with the concept of Business rules: These are basics for understanding the rest.

Then, we discuss the concept of NULLs, or, as many say, NULL values (NULL is precisely the opposite of a value...). The article was published some time ago, and the responses and interest returned, sparked the creation of this section.

(BTW: All these articles have been re-published on several sites on the Net, but only here will you find the (updated!) originals :-)

NULL is a very interesting concept: Allowing users to "enter" unknown "values" into one or more columns in your system.

When E.F. Codd introduced his relational concept back in 1970 (actually, the first paper was created in 1969), he (basically) stated that the relational data model is based on tables (actually: relations) with columns (attributes) that hold values(!). So, initially, the concept of NULLs was non-existent.

Somewhere along the way, the concept of not having to supply a value for a column, was introduced. Of course, it is an easy way out, not having to specify a value for a column, but: What are the consequences?

  • First, let us start with some very basic stuff: You need to know a few fundamental terms, so we'll talk about Business Rules and the different stages of database design.
  • This article discusses the term NULL values. When differing between database theory and practice, this is possibly one of the most difficult issues.
  • How small is small enough? This article discusses what the elementary information elements are in an information system. We work hard in order to to analyze the atomic database values in our systems, but what is an elementary (atomic value) information element, anyway?
  • The flat Earth; This article discusses the misconception of flat relational tables - An idea just as erroneous as the belief 600 years ago about the Earth being flat... A brilliant example on the difference between database theory and practice...
  • This article on database theory and practice discusses what some object oriented database vendors view as the top benefit: The encapsulated (denormalized) object instead of a normalized (fragmented) relational structure.It is Objects vs relational tables. (Great fun!)

This concludes (so far) this section on database theory and practice. For what it's worth, many bloggers and other websites are linking in to these articles, both with negative as well as positive comments. It's OK: All I ask of you is: THINK.

Return to Database Design home


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.