Re: In an RDBMS, what does "Data" mean?

From: mAsterdam <>
Date: Mon, 31 May 2004 12:47:10 +0200
Message-ID: <40bb0d26$0$559$>

Alfredo Novoa wrote:

>>>... It was mathematically proven 
>>>that it is better than the graph
>>>based approaches.

> mAsterdam wrote:
>>This is a very strange statement...

> This is a very basic knowledge taught in every
> serious database introductory course.

The statement is made in just about every database course, without demonstrating it - that's exactly what I think is strange about it. If it's proven why not give or at least reference the proof? The way it is put, it is propaganda, not basic knowledge.

>> ... - Better at what?
> Simplicity

This reduces the statement to
"It was mathematically proven that it is simpler than the graph based approaches." and leaves the judgement to the reader/student. An improvement, but it still leaves the questions unanswered: simpler at what? etc.

>> - What exacltly was proven?

> That the Relational Model is superior.
>> - Could you please give a reference?

> Codd, E. F. and C. J. Date. "Interactive Support for Nonprogrammers:
> The Relational and Network Approaches." ... 1974 ...

Part of it was quoted at your second url, see below. I could only find the abstract on-line.

abstract (from <quote>

    The objectives and strategies of the relational and network approaches     are compared. The status of support for non-programming users is     examined. General purpose support for such users entails provision of an     augmented relationally complete retrieval capability without branching,     explicit iteration, or cursors. It is clear how this capability can be     realized with the relational approach—whether with a formal or informal     language interface. It is not at all clear how the network approach can     reach this goal, so long as the principal schema includes owner-coupled     sets “bearing information essentially”. A relational discipline is     suggested as a way out for DBTG users.


Appearantly the information principle is dicussed avant la lettre there. For the people who do not know that cornerstone:

Chris Date in "EDGAR F. CODD 08/23/1923 – 04/18/2003 A TRIBUTE" at : <quote>

     The concept of essentiality, introduced by Ted in this debate, is
     a great aid to clear thinking in discussions regarding the nature
     of data and DBMSs.  In particular, The Information Principle (which
     I heard Ted refer to on occasion as the fundamental principle
     underlying the relational model) relies on it, albeit not very

         The entire information content of a relational database
         is represented in one and only one way: namely, as
         attribute values within tuples within relations.



While this does give some insights in the history of the use of 'data model' and
related terms (for the people here who
showed interest in that topic), it doesn't at all claim to mathematically prove anything.


Here it gets very interesting. From the overview: <quote>

     Of course, the battle between relations and networks is
     ancient history now. (The good guys won.) This fact notwithstanding,
     Codd's paper --  even though it was written over 25 years ago -- is
     still worth reading today as a beautiful example of clear thinking.
     Indeed, it's quite remarkable to see how, on a topic where muddled
     thinking was the norm at the time, Codd was able to do such a good
     job of cutting to the chase and focusing on the real underlying
     issues. Let me elaborate:

         * First of all, Codd realized that to compare the very concrete
           CODASYL specifications and the much more abstract relational
           model would be an apples-and-oranges comparison and would
           involve numerous distracting irrelevancies.

         * Hence, it would be necessary first to define an abstract
           "network model." The comparison could then be done on a
           level playing field, as it were, in a fair and sensible

         * Codd therefore proceeded to define an abstraction of
           the CODASYL specifications that might reasonably be
           regarded as such a model. (And then, of course, he went
           on to compare that abstraction with the relational model.)


Relevancy to the 'mathematical proof' statement under discussion: a fair comparison (a precondition for the claimed mathematical proof) would require specification on the same (or at least similar) levels of abstraction.

I don't know if anybody after this has provided another formalization of the network model, so AFAIK this comparison stands.

But what exactly is compared? Relational model versus network model for interactive support(1) for nonprogrammers. To dissmiss all graph based approaches for all purposes based on it is overstretching it, IMO, jumping to conclusions.

>>I happen to like graph based approaches
>>for the overall picture and to elicit design
>>ideas from non-IT professionals.

> We are talking about very different things. I am not talking about
> drawings, I am talking about the network and hierarchical approaches.

Equating network approaches to graph based approaches, for all purposes? The network approach is Codd's formalization of the CODASYL specification for the purpose of interactive support(1) for nonprogrammers, in the documents you referenced. (Or should I say pointed me to :-)

To determine wether it possible generalise Codd's comparisons to relational approach vs. graph based approach, some more levelling is needed. Generalising the stated purpose is not trivial, either.

>>>I am completely opposed to faith and other forms of irrationalism. The
>>>Relational Model is maths not irrational faith.
>>Rationalism is as irrational(/rational) as any oher faith.

> What a nonsense!

Very faithful ;-)

I suspect we will not be able to agree on this one.

However, maybe we can try to agree on the 'mathematical proof' issue, by clearly
stating what exactly was proven.

Anyway, thank you for the nice read.

(1) : interactive in textmode is implicitly meant - but that's another can of worms. Received on Mon May 31 2004 - 12:47:10 CEST

Original text of this message