Re: relational databases vs. not-so relational databases

From: Jan Hidders <hidders_at_uia.ua.ac.be>
Date: Tue, 22 Jan 2002 19:22:16 +0100
Message-ID: <3c4dadb1$1_at_news.uia.ac.be>


"Mike Preece" <michael_at_preece.net> wrote in message news:1b0b566c.0201220727.7a6f9368_at_posting.google.com...
> Although this posting has nothing at all to do with Lotus Notes, I
> thought it might be of interest to provide the following link anyway.

Having nothing to do with Lotus Notes is a plus in comp.databases.theory. :-)

> I'd be interested to know what you folks think of the whitepaper.
>
> http://www-3.ibm.com/software/data/u2/pubs/whitepapers/nested_rdbms.pdf

It makes the common mistake that most people make that claim that the relational model should be replaced with an OO data model, or an OR data model, or XML, or whatever; they forget what the ANSI/SPARC architecture was all about. There were and still are very good reasons to distinguish between the external level (the user views), the conceptual level (the conceptual schema) and the physical level.(the physical schema). All the arguments in the whitepaper only show that sometimes the nested relational model is appropriate for the *external level*. But that is simply besides the point, because what makes a database a relational database is the data model that is used at the *conceptual level*. Now if we go over the arguments again and check if they are appropriate for the conceptual level you will see that they all break down:

> * The database schema is simpler, with fewer tables to define and
maintain.

This is only true at the external level. At the conceptual level different views of different types of users have to be integrated, and the views may require the data to be nested in different ways. So the nested data model will probably make the work of the DBA (or whoever has to maintain the conceptual data model) more complicated. Moreover, the nested data model for the user view can be quite straightforwardly mapped to a relational data model.

> * The database schema more directly mirrors the relationships inherent in
the data stored, thereby making the schema easier to define and easier for others understand.

Again, this is only true at the external level for one user view, but what is an inherent relationship for one user may be an explicit one for the other.

> * Many time-consuming and compute-intensive joins are eliminated.

That depends on how the conceptual layer is mapped to the physical layer. The whole point of having these two layers is *data independence* and that means that you do not want your conceptual layer to be strongly biased towards some physical storage format. It is that which gives the DBA the freedom to change this format (because of changing needs or new applications) without having to change the applications that use the data.

> * Redundant data for storing relationship relations are eliminated to save
storage space.

Again, this depends upon how the conceptual layer is mapped to the physical layer. There is no reason why two flat relations with a one-to-many relationship cannot be mapped to one nested physical "table".

> * Accessing data is simpler and more straightforward. The required SQL
statements are simpler and more direct.

And also this is only true at the external level for one user view. If the data happens to be nested in a different way then you would like to see, then your SQL will become more difficult than before. And like the nested relations can be mapped to flat relation, so the nested SQL can also be quite straightforwardly and automatically mapped to standard SQL.

So you see that the arguments, in as far as they are applicable at all, at best only show that for some user views the nested relational model would be a nice thing to have. But that is rather different from the claim that the nested relational model is the best choice for the conceptual layer. Perhaps the authors would do best to try and find their old copy of Date's "Introduction" and read the first chapter again. It might contain some interesting "new" insights for them. :-)

Kind regards,

  • Jan Hidders
Received on Tue Jan 22 2002 - 19:22:16 CET

Original text of this message