Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!odi!dlw
From: dlw@odi.com (Dan Weinreb)
Newsgroups: comp.object,comp.database
Subject: Re: Looking for explanation of OODB problem
Message-ID: <1991Jun13.231646.29226@odi.com>
Date: 13 Jun 91 23:16:46 GMT
References: <1991Jun6.194440.2879@apd.mentorg.com> <1991Jun10.070451.18516@chinet.chi.il.us>
Reply-To: dlw@odi.com
Organization: Object Design, Inc.
Lines: 49
In-Reply-To: dhartung@chinet.chi.il.us's message of 10 Jun 91 07:04:51 GMT

In article <1991Jun10.070451.18516@chinet.chi.il.us> dhartung@chinet.chi.il.us (Dan Hartung) writes:

   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?"

What a peculiar question.  I cannot imagine why he thinks that an OO
database should have any more trouble with distribution than a
relational database.  The best speculation I can come up with is that
he is under the impression that object identifiers as stored in
databases encode the physical location of the object, in a way that is
somehow visible to the program, or something like that.  I don't know
why he should make such an assumption.

As for integrity constraints, there's no reason that an OO database
can't have constraints just as any other kind of database can.  It's
hard to discuss this further without going on for pages, since there
are so many kinds of integrity constraint imaginable, and all
different kinds of implementation techniques that can be used to
implement them.

   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.  

What do you mean by "relational integrity" in the context of an OO
database?  What, exactly, do you mean by "grab"?  What constraint on
an OO database would be desirable, but so very hard to enforce
compared to a similar constraints on a relational database?

				      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.

Locking is part of concurrency control; I don't understand why it has
anything to do with data models and data integrity.  (I assume that
Codd uses "integrity" in the same sense that Date uses it, i.e.
protecting a database from errors due to concurrent access, or aborts,
or system crashes, or media failure, is not what is meant by
"integrity".  See Date's "Introduction to Database Systems".)
Concurrency control in OODBs can be done any number of ways, including
exactly the same way that it's done in commercial relational database
systems.