Re: Lucid statement of the MV vs RM position?

"Pickie" <keith.johnson_at_datacom.co.nz> wrote in message news:1146110247.495974.84970_at_i39g2000cwa.googlegroups.com...
> People can collaborate (and exchange data in a meaningful, formal
> fashion) without a DBMS. In practice, using a DBMS involves much more
> than just providing the database(s). You have to be able to evolve the
> database structure for new circumstances, which means you run into a
> different set of problems. But I understand where you are coming from.
>

Thank you for a rational and lucid exposition of a point of view that's different from my own. This is perhaps the best discussion between a Pickie and a database designer I've seen. I'm going to try to keep the tone high, while exploring the issues as deeply as I know how.

> The original request was for a lucid statement of the MV vs RM
> position. In my reply I tried to describe Pick-MV a bit, because there
> are a few misconceptions about it. The basic position I took with
> respect to the request was that I didn't think it could be compared
> with RM because they are different things.

I have to agree. First off, it's been asserted that Pick didn't have a data model in mind when he developed Pick, and that the MV is an attempt to provide a data model in retrospect. I think of this as largely a side issue. Having built applications in everything from FORTRAN to SQL, I'm going to suggest that, in every case, I had some kind of data model somewhere in my brain, even if it was at the subconscious or subverbal level. The advantages of making the data model conscious and explicit, rather than subverbal and implicit, is food for another discussion.

> Moreover Pick-MV doesn't
> have some of the key things required of a DBMS, so it can't be compared
> with RDBMSs either.

I accept this, because I just don't know enough about Pick to question it. However, some others in the forum have begun talking about products like UniVerse, and descibing them as MV based DBMS products. At that point, a comparison between "the multivalue data model" and "the relational data model" becomes relevant, because we are comparing one DBMS with another. I've found it necessary to learn at least a flyby overview of the way Pick data files are structured as a handle on what the MVDM might be about. There may be better handles.

> You are, however, left with the fact that one can
> build a system which acts as if it was built with a DBMS. People can
> access information, update it, report on it, etc. without getting in
> each others way. Of course, this does depend on the application
> programmer. Similarly you depend on your DBA when you have a DBMS.
> These people need to be skilled, and an undestanding of normalisation,
> etc. is necessary to both.
>

You can certainly build a system without using a DBMS. And I'm the last person to suggest that every application ought to be layered on a DBMS. There is a large class of problems that are better solved without a DBMS than with a DBMS. However, there's also some truth to Spight's law, which reads: sooner or later every application needs a database. And I think it's obvious that if you need a database, you're better off with a good DBMS than without any DBMS.

However, I'm going to take issue with one thing you said: People can acess information and report on it. People can't access information directly, in the scenario you outline. They can access services provided by the application, and report on the data, provided they can feed the data output by the application into a report writer! From 1969 to 2003, I've seen numerous applications where the API is so grotesque that the information inside it is unusable for all practical purposes. These aren't particularly Pick applications, but applications across the board.

This is the problem that databases were invented to solve. If you're a "pro DBMS partisan" as I am, this is what you want a database to provide: standard DBMS services, like backup; a standard data interface, like SQL (with due allowance for its defects); a standard data description format, like the metadata in SQL after about 1992, I think; a reasonably standard, or at least not counterinuitive, way of understanding the semantics of the data; and a reasonably simple and expressive way of connecting the data, as modeled and stored, with the view of the data expressed by subject matter experts.

The above is a high cost wish list. I grant that. In order to get sufficient bang for the buck, you are going to have to get a lot of utility out of the data that you've made this investment in. That's what I think the practice of database development is all about.

> The only theory I have any knowledge at all about in the database world
> is the RM. The major DBMS's (I mean the ones that call themselves
> RDBMSs) are based on SQL which doesn't follow the RM. In fact, given
> that the RM does not have nulls, Codd's rules for a RDBMS don't seem to
> follow the RM either. There are DBMS's that are said to follow the RM
> but I have my doubts if SQL is supported.
>

When I'm being careful (wich is not always), I try to use the initials, RDM, rather than RM. It's important to remember that the RDM is a data model, not just a model. Some people in this forum argue that "NULL" has no counterpart in mathematics, so it shouldn't be part of the model. That misses the point. If you are building a DATA model, you have to address the question: what are you going to do when the data isn't there? as well as the question, how do you prevent missing data? That is why Codd addresses the issue of missing data, rather than evading the issue.

Alternatives to RDM are the hierachical data model, the CODASYL (or network) data model, various object oriented data models, and the mulitvalue data model.

> The truest answer to the request seems to be that the Relational Model
> is a theory that has no practical example and Multi-Value (at least the
> Pick version) is a practical example that has no theory.
>

It depends. As a practitioner, I've been willing to live with SQL as an approximation to an RDM interface. It's one of those eighty-twety things. And, also as a parctitioner, I've been able to build some very practical, and very successful databases, along with applications, that use products like Oracle. Oracle is another one of those eighty-twenty things.

Soooo...... if you are willing to accept the idea that "SQL is approximately relational" (an idea that is nonsense to the laudest voices in this forum) then I'm going to say that there are tens of thousands of practical examples of the usefulness of RDM.

There are also tens of thousands of poorly built databases based on SQL out there. Some of those might be traceable to SQL's flaws. More of them, in my opinion, are traceable to lack of database design skills or lack of data analysis skills.

I'm sorry this response was so long. It hope it was worth reading. Received on Thu Apr 27 2006 - 15:04:45 CEST