Re: So let me get this right: (Was: NFNF vs 1NF ...)

David Cressey wrote:
> "Jan Hidders" <jan.hidders_at_REMOVETHIS.pandora.be> wrote in message
> news:9GJPd.10844$rU2.621604_at_phobos.telenet-ops.be...
>

>>No. No problem there. Codd was a good mathematician and the mathematics
>>in the paper is trivial anyway. Which is not meant as criticism, in some
>>sense this simplicity is actually one of the points of the paper. But
>>when reading it one might get the impression that the proposed method
>>allows you to flatten any nested relation without any problems.

True, but let me bring to my defence that I did say that the math was trivial, not the method. Not that this matters much but I'm the holder of an engineering degree in computer science and I still tend to think that there is somewhere some engineering blood left in me. :-) Actually I don't think there is that much of a gap between engineers and scientists / mathematicians. In my experience good engineers know their math.

> Perhaps you can shed some light on this.
>
> As I read the 1970 paper, Codd is NOT introducing the relational model of
> data. He's specifically referencing some prior work on inference engines (I
> forget the exact term). What is introduced in the 1970 paper is the
> proposal that the RDM be used as the basis for organizing (at some level of
> abstraction) a large scale shared database. That is, to use the power of
> the RDM specifically for formulating queries in a way that would be better
> than what existed at that time.

Well observed IMO. The relational model as Codd proposed it is simply another name for the model theory of first order logic, and he knew that, although he probably wasn't aware of some of Tarski's work which he more or less duplicated. But this doesn't diminish Codds achievement in any way because it took much insight to see that applying this model leads to both practical and theoretical advantages.

> I'm interested in following the development of the RDM and the RDM based
> DBMSes until it reaches the point where I think some other alternative would
> have been worthy of more exploration.
>
> I also have a second reason for citing the use of the RDM in a context other
> than a DBMS. It seems to be that many of the discussions in this forum
> hinge on the desireability of using relational operators to transform data
> into a more relevant or more useful form, and not merely as a way of making
> queries on shared data. In particular, the recent discussion on "tight
> integration" between the application language and the DBMS seems to suggest
> to me that the RDM might be desirable in a programming language, even if
> there were no DBMS for it to exploit.

Indeed interesting questions. One could probably write whole essays on this. For practical reasons I will limit myself to the first question.

What went wrong with the relational model? It has been riding for a very long time on the waves of commercial success and many people, even scientists, have forgotten to critically investigate the claims that are made by it and what are the aspects of the model that give it its nice properties. This has made the claims IMO more broad than justified.

For example, I would claim that the benifit of the RM is mainly at the conceptual level (as in the ANSI/SPARC model) and not at the external level. For data-modelling ER-like models are much more convenient and can be just as formal and exact. For presenting data to users hierarchical structures are often much more intuitive and closer to the original form of the data. But if you want to integrate large amounts of data upon which many different users have different views then the flat relational model is very hard to beat. And if you look at it this way, then it becomes quite clear that adding RVAs is an external level issue, not a conceptual level issue. Long live the good old flat relational model! :-) Note that I'm not saying that RVAs are bad, just that they are good for some purposes (presenting data at the external level and querying, for example) and not good for others. It is all a matter of being more precise about which claims are made about wich aspects of the model.

Related to the previous is the question whether domain values and their associated operations should be allowed to be of arbitrary complexity.  From the beginning it was tacitly assumed that domain operations would be simple and efficient and would not have to be optimzed. But if you allow them to get arbitrary complex then you might need something of the complexity of a relational engine, complete with query optimization et cetera, again at that level. Would that be worth it? Never mind what happens if allow nesting and unnesting and start mixing the operations of the two levels. Does that really weigh against the benefits? Would we really gain something over an approach where at the external level things can be arbitarily complex but at the conceptual level they are all mapped to relations with simple basic domains?

There's much much more that can be said about this, but I still have some work to finish for tomorrow, so I will leave it at that.

Kind regards,

• Jan Hidders