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
|