Re: foundations of relational theory? - some references for the truly starving

From: Costin Cozianu <c_cozianu_at_hotmail.com>
Date: Tue, 21 Oct 2003 10:59:53 -0700
Message-ID: <bn3s96$s8db8$1_at_ID-152540.news.uni-berlin.de>


Mark Brown wrote:
> "Costin Cozianu" <c_cozianu_at_hotmail.com> wrote in message
> news:bn3nbs$seug1$1_at_ID-152540.news.uni-berlin.de...
>

>>>It's late and I no idea whether these are known to anyone or everyone,
>>>but I remember this, commissioned by Unidata, now an IBM db: maybe it's
>>>of use?
>>>
>>>http://www-3.ibm.com/software/data/u2/pubs/whitepapers/nested_rdbms.pdf
>>
>>That's a marketing hogwash containing blatant inaccuracies and downright
>>idiotic claims:
>>
>>"
>>  2) Normalization of the tables requires the order number and the
>>customer number attributes be stored twice for each order
>>
>>  3) Producing a report to show the data as in (Figure 1) requires thatb
>>the three tables be joined. Joined are highly compute intensive

>
> operations.
>
>>"

>
>
> Well, maybe I AM "ignorant AND stupid",

Well, maybe you are ignorant and stupid, but not because you don't know the technical details -- all of us are limited, but because you go on making claims about a domain you haven't studied enough.

> but I went looking for definitions
> of 1st, 2nd and 3rd Normal Form and I didn't find anything to contradict the
> above statements.

If you did your reading job properly you'd have found that there's no information at all related to the physical layout of data on disk, and how joins are computed.

> Maybe you can explain to me:
>
> 1) How to define relationships without some sort of tag field to point
> back to the main table. "Where tbl1.id = tbl2.tbl1ID" (2 above).

That's right.

> Seems like
> SOMETHING has to be stored twice.

The fact that a logical relation exist does not mean that the information has to be stored twice, and in physically remote locations. The layout is called in Oracle DBMS a CLUSTER: you create a cluster that groups records from related tables together based on say, tbl1.id, so the physical layout will be what you are probably familiar with from Pick.

> What would be the relationship between an
> order header and an order detail, if not order number? Between the order
> header and the customer master? And wouldn't those relationships require
> some data to support them?
>

The relational model does not mandate how data is physically stored, it only mandates how it is logically structured and how it is logically accessed.

> 2) How to do joins without making multiple jumps into the database?

Simple: you pick them exactly as they are in the physically clustered database pages. You can think that the information is stored as precomputed joins (minus the redundancy).

  The
> columns of data may be stored on different machines. But of course,
> theorists aren't concerned with the trivia of reality. Seems to me kike
> saying "All people can fly, theoretically. As long as you ignore the
> reality of gravity."
>

It's not only theoretical but also practical, and used in production databases.

> I'd always heard that a Science major says "Why does it work? (theory)", an
> Engineering major says, "How does it work? (practice)" and a Liberal Arts
> major says, "Would you like fries with that? (reality)" Maybe it applies to
> databases too.
>

Oh, boy. What a crap.

> Mark Brown
>
>

Costin Received on Tue Oct 21 2003 - 19:59:53 CEST

Original text of this message