Re: Stupid Database Tricks

From: David Cressey <cressey73_at_verizon.net>
Date: Wed, 13 Jun 2007 15:30:09 GMT
Message-ID: <54Ubi.6005$Mo5.5064_at_trndny08>


"Jan Hidders" <hidders_at_gmail.com> wrote in message news:1181739221.341018.321220_at_j4g2000prf.googlegroups.com...
> On 13 jun, 10:41, vldm10 <vld..._at_yahoo.com> wrote:
> > [...] Although, regarding that you are
> > knowledgeable person I would like to know what is in your opinion
> > reinvented (or looks like it) in my "model". You can roughly present
> > it or one by one.
>
> The ideas of :
> 1. Adding a special key to relations that identifies the entities or
> relationships represented by the tuples in the relation.
> 2. Using the presence of this key to split everything as much as
> possible into binary relations.
>
> These are old ideas, and have already been rejected before. I have not
> seen any argumentation by you that explains why this would now have
> become a good idea.
>
> Btw. did you realize that for a relation R(K, A_1, ..., A_n) where {K}
> is a superkey, it always holds that the relation equals the joins of
> R(K, A_1), ..., R(K, A_n)? Any assumptions about mutual independence
> are not necessary. Also note that such a relation is not necessarily
> in 5NF if {A_1, ..., A_n} are mutually independent, or even in 4NF,
> for that matter.

Just as a tangential note, the above provides a simple answer for those who wish to avoid SQL NULLs. If we decompose the relation (relational table) according to the equality outlined above, a "missing value" for any of the attributes A_1 .. A_N can be expressed as a missing row in the decomposed relation. While missing values in a row provoke endless controversy in the discussion of SQL tables, missing rows hardly cause a ripple.

In order to be strict about it, we need one more relation consisting only of the superkey K. That relation can serve as a reference base for the K in all the other relations.

This doesn't add anything to the point you were making, Jan. I just wanted to note it in passing. Received on Wed Jun 13 2007 - 17:30:09 CEST

Original text of this message