Re: Something new for the New Year (2008).

From: Rob <rmpsfdbs_at_gmail.com>
Date: Thu, 17 Jan 2008 10:23:15 -0800 (PST)
Message-ID: <5628c350-172b-4fde-b1cc-91bc46e9b588_at_u10g2000prn.googlegroups.com>


On Jan 15, 7:03 pm, Gene Wirchenko <ge..._at_ocis.net> wrote:
> Rob <rmpsf..._at_gmail.com> wrote:
>
> [snip]
>
> >You are 100% correct. I totally agree, the model I proposed would not
> >stand up. I said essentially the same thing in
>
> >http://groups.google.com/group/comp.databases.theory/browse_frm/threa...
>
> >(and was called to task for saying that 'there is no "clean,
> >efficient way to store this information" in the relational
> >model that satisfies all constraints').
>
> No wonder. For example, the deficiency of an SQL DBMS does not
> speak against the RM.
>
> Sincerely,
> Gene Wirchenko
>
Again, I agree 100%. The SQL paradigm is a horror, and the implementations of SQL DBMSs encourage practices that are not just bad, they are dangerous. Personally, I believe that the SQL paradigm is the single biggest obstacle to wider use of relational databases.

I believe that from your perspective, an SQL DBMS is a necessary evil: The only available engine that allows you to map your RM model abstractions to operational relational DBs. Not dissimilarly, I see an SQL DBMS as a component. However, because the A-L representation can replace both the PKFK and JT representations, it makes it possible to derive a simpler, relationship-oriented data model at the same level of abstraction as SQL. My objective is a graphical data model defined at a higher level of abstraction that makes relationship joins transparent and therefore usable by less-trained knowledge workers. This will be described in the "next installment" of my website.

I refer you to Codd's 1980 paper, "DATA MODELS IN DATABASE MANAGEMENT" in which he wrote:

<quote>
A data model may be used in any of the following: 1) as a tool for specifying the kinds of data and data organization that are permissable in a specific database; 2) as a basis for developing a general design methodology for databases;
3) as a basis for coping with evolution of databases so as to have minimal logical impact on existing applications programs and terminal activities;
4) as a basis for the development of families of very high level languages for query and data manipulation; 5) as a focus for DBMS architecture;
6) as a vehicle for research into the behavioral properties of alternative organizations of data.
</quote>

I see this work on A-L as relating directly to items 4-6.

I thank you for your insightful comments. I think it's time we wrapped up this thread and moved on.

See "Data Models and Levels of Abstraction".

Rob Received on Thu Jan 17 2008 - 19:23:15 CET

Original text of this message