Re: Does Codd's view of a relational database differ from that of Date & Darwin? [M.Gittens]

From: David Cressey <david.cressey_at_earthlink.net>
Date: Fri, 10 Jun 2005 00:34:26 GMT
Message-ID: <me5qe.1679$eM6.935_at_newsread3.news.atl.earthlink.net>


"mountain man" <hobbit_at_southern_seaweed.com.op> wrote in message news:SQhne.9308$BR4.3785_at_news-server.bigpond.net.au...

> In this subsequent article, the author makes the assertion
> that Codd's view of a relational database differs from that
> of Date and Darwin.
>
> Here is the relevant quote:
>

>
> ======[quoting M.Gittens]=====================
>
> According to E.F. Codd a relational database is defined as:
>
> "A relational database is a time-varying collection of data,
> all of which can be accessed and updated as if they were
> organized as a collection of tabular time-varying tabular
> (nonhierarchic) relations of assorted degrees defined on a
> given set of simple domains."
>
>

Like some other respondents, I'm not exactly sure how Codd's ideas on relational databases
and the relational data model evolved over time. I'm limiting my comments to the 1970 paper.

It seems clear to me that, at that time, Codd was NOT asserting that the limitation to simple domains was an inherent part of the theory of the relational data model. Rather, he was taking the simple domain rule as a probable workaround to the practical obstacles to the building of the first relational DBMS.

There ARE implementation difficulties in implementing relational variables whose attributes may be referenced on domains that are relations. I'll go into them in a later response, if need be. The brief version is that somebody has to be able to test two relvars for equality, and that's not as easy as it sounds.

What Codd called "normalization" in the 1970 paper, and later, I suppose became what I learned as "First Normal Form", was introduced merely to prove that for every collection of relations there exists a normalized collection that can express the same facts.

That, as I read the 1970 paper, is NOT an inherent limitation on the theory of the relational data model, but rather a practical stopgap with regard to intial implementations. Whether Codd's position subesquently hardened is something I do not know.

> According to the Third manifesto:
>
> "The question as to what data types are supported is orthogonal
> to the question of support of the relational model."
>
>

Even orthogonal sets have an intersection. The intersection here is when the relational engine must fill the role of both the relational engine and of the data type engine. If an allowed data type is "relation", there's no getting around this. Again, the relational engine HAS to be able to determine whetheror not two relational variables are in the same state.

> Let us take time to notice the fundamental difference between the
> two positions presented here. As a result of the position that
> support for the relational model is orthogonal to the supported
> data types, The Third Manifesto proceeded to allow domains to have
> an arbitrarily complex structure and also to support arbitrarily
> complex user defined operators.
>
> Codd on the other hand specifically states that relational
> databases must be based on "simple" domains. Codd also says that
> domain values should not be decomposable further by the DBMS. Which
> is to say: According to Codd, the question as to what data types
> are supported is not orthogonal to the question of support of the
> relational model. Based on this evidence one can but conclude that
> Codd's view of relational database is logically different from The
> Third Manifesto's view of a relational database. Such logical
> differences are big differences.
>
> ======[end quoting M.Gittens]==================
>
>

I would suggest that, if I'm right in the above assertions, we would do well to separate what is asserted about the relational data MODEL on the one hand, and what is asserted about relational DATABASES on the other.

> Any opinions on this POV?

Any reactions? Received on Fri Jun 10 2005 - 02:34:26 CEST

Original text of this message