Re: CODASYL-like databases

On Apr 3, 1:23 pm, "Ken North" <videoscribe21st-i..._at_yahoo.com> wrote:
> > In his 1980 paper "DATA MODELS IN DATABASE MANAGEMENT", Codd points
> > out (under HISTORY OF DATA
> > MODEL DEVELOPMENT) that "[h]ierarchical and network systems were
> > developed prior to 1970, but it was not until 1973 that data models
> > for these systems were defined."
>
> Interesting comment that's open to interpretation based on how you
> define a data model.
>
> The network model that emerged from the CODASYL Data Base Task Group was
> derived from GE IDS, much as today's XQuery was derived from Quilt.
> Charles Bachman's IDS was released by GE in 1965. Bachman and Codd were
> both recipients of the ACM Turing Award and they faced off in a famous
> 1970s debate about navigational vs. relational data access.
>
> The CODASYL network model is much like a persistent representation of a
> doubly-linked list. That model for traversing lists was well-known
> before the CODASYL spec of 1971. Linked lists date back to the 1950s.
> They were supported by LISP in the 1960s, and were described in Knuth's
> writings.
>
I think you are mixing the notion of models with implementations.

If "The CODASYL network model is much like a persistent representation of a doubly-linked list", then what does the SET OWNER have to do with it? What I mean is that it is the relationship between one set owner and zero or more set members that forms the basis of the model, not it's implementation as a doubly-linked list with a logical link from each set member to the set owner.

The CODASYL data model is much closer to the notion of recursive lists: A CODASYL set is an ordered list with each list element (set owner) having a sublist (the set members). Composition of these 2- level lists yields 3-level lists and so on.

I haven't looked at the CODASYL stuff in many years, but I've always assumed that the data model was a blueprint for an implementation engine upon which applications and higher-level interfaces would be built. I didn't really think it was intended as an enduser interface. (paul c's earlier comment resonates with this: "They have an unnecessarily complicated data interface, are basically impossible for an end-user to handle without a lot of expert help ...")

By that same reasoning, an SQL engine could support higher-level, enduser interfaces, but that never really has happened. As a consequence, nonprogrammers and programmers have had to struggle with SQL to interact with relational databases, or, rely on SQL experts to build custom interfaces, textual/graphical or APIs.

Here's two (I think) interesting network- vs. relational theoretical questions:
1. Suppose you had a relational DBMS. Could you implement a CODASYL DBMS upon it?
2. Suppose you had a CODASYL DBMS. Could you implement a relational DBMS upon it?

This is an equivalence test. If the answer to both were "yes", it would mean the data models are equivalent. Received on Thu Apr 03 2008 - 22:56:26 CEST