Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!tellab5!chinet!dhartung
From: dhartung@chinet.chi.il.us (Dan Hartung)
Newsgroups: comp.object,comp.database
Subject: Re: Looking for explanation of OODB problem
Message-ID: <1991Jun10.070451.18516@chinet.chi.il.us>
Date: 10 Jun 91 07:04:51 GMT
References: <1991Jun6.194440.2879@apd.mentorg.com>
Organization: Chinet - Chicago Public Access UNIX
Lines: 64

plogan@apd.mentorg.com (Patrick Logan) writes:
>It is not entirely clear what is being described below. Rather than
>propose my interpretation, I am looking for other opinions and
>experiences.

Well, I have Codd's Relational Model V2 at my desk right now, so I
might as well respond.

>From "UNIX Today!", May 13, 1991, pp. 58, 64...
>
>    [Paraphrasing: Dan Gerson, Xerox PARC, is developing collaborative
>    systems, in particular a document database that will allow
>    multiple users and track versions. He's not sure OODBs are best
>    for his work. He's using a Sybase DBMS and is investigating
>    ObjectStore from Object Design.]
>
>    [Quoting: typing errors are mine.]
[Deletions by dhartung for clarity.] 
>
>    During a transaction in an OODBMS, objects are loaded into memory,
>    either real or virtual. "As soon as you execute a transaction, you
>    can't see the object anymore," he says. "In an RDBMS, the system
>    is giving you some sort of a copy. In an OODBMS, the system is
>    giving you the actual object, so they're only valid in a
>    transaction."
>
>    [End of quote.]

In his new 1990 book on the relational model, Codd devotes a chapter to
rebuttal of "Claimed Alternatives to the Relational Model", including
Entity-Relationship, Binary and Universal Relational, and Object-Oriented
approaches.  He gives succinct reasons why he believes each falls short
of the Relational Model (<-- I capitalize because he is speaking of something
very specific).

There is approximately one page on the object-oriented approaches.  First
he raises questions about the "adaptability to change" of an object-
oriented database manager, and whether o-o is as "high-level" as any
relational language (thus limiting its optimizability).

The paragraph I think is relevant is this:

"Can the OO approach to database management support distribution independence?
In other words, can application programs remain unchanged and correct when
a database is converted from centralized to distributed and later when the
data must be re-distributed?  What support does the OO approach provide for
built-in and user-defined integrity constraints that are not embedded in
the application program?"

I believe his point, however obliquely made, is that OO does not, in his
view, have the flexibility to successfully operate under different
configurations without change, as a relational language would (must).
The paragraph cited above is merely a specific instance of this: by
having a grab-the-object-until-done approach, relational integrity
would be virtually unenforceable.  Ironically, this is very much akin
to the record-locking that is done in so many "relational" databases
(really semi-relational) -- e.g. xbase.  The "EDIT" command is
actually something like an EDIT object in this sense.

-- 
Daniel A. Hartung           |  "What's the difference anyway, between being
dhartung@chinet.chi.il.us   |  safe and being rad, the joke's on us, we've
Birch Grove Software        |  all been had."  -- John Wesley Harding
-----------FoxPro Programmer Looking For Work--------------