Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!ucsd!sdcc6!calmasd!wlp
From: wlp@calmasd.GE.COM (Walter L. Peterson, Jr.)
Newsgroups: comp.databases
Subject: What is an OODBMS (was Re: Object Oriented DB Articles ?)
Summary: Yes, and more...
Message-ID: <49@calmasd.GE.COM>
Date: 1 Sep 88 06:45:17 GMT
References: <3560019@wdl1.UUCP> <37@calmasd.GE.COM> <408@cullsj.UUCP>
Organization: GE-Calma, San Diego R & D,   Object and Data Management Group
Lines: 80

In article <408@cullsj.UUCP>, gupta@cullsj.UUCP (Yogesh Gupta) writes:
>[...] 
> What do people think of when they think of an OODBMS?  Is it an Object
> Oriented System with the ability to have persistent objects?  Shared
> Objects?  Transactions?  Recoverability?  Authorization and Security?
> What is the interface to it? Is an OODBMS a complete environment, or
> not? ...
> 
> I believe that the question of the interface is very important because
> it defines the behaviour of the system.
> 
> OOPSLA 88 should be interesting...
> 


Persistent objects within an Object-Oriented System are, of course,
part of the answer.  It is very nice to be able to enter an
application, work for a while and then exit the program without
having to explicitly write storage methods on all of your objects.
This can be done by embedding a save/restore mechanism within the 
language itself.  While this capability is very nice to have, it is
not what comes to mind when one hears the term "Database".

The other elements that you mention are closer to the common preception 
of what a database is.  Data sharing is critical; without that most
of the power and indeed the reason for having a database go away.  The
need for transaction support is, I believe, also critical.  You have
to be able to establish logical units of work and then commit or rollback
those transactions, just as in an RDBMS.  The concept of transactions 
also provides a basis for data sharing, since it is usually the framework
arround which locking occurs.

Recovery is important in both the storage of persistent objects and in
an OODBMS.  Murphy is, after all, an optimist.  If things can go wrong
they will and any storage system has to be able to recover as gracefully
and as fully as possible from system crashes, power outages and accidentally
hitting CTRL-C.  If it does not or can not do this, then the system
will never be more than a laboratory curiosity ( which is all that many
ODBMSs are ).

From the point of view of a definition of what an OODBMS is or should
be, the problems of authorization and security are secondary; from the
standpoint of producing a commercially viable product they are not,
however.  Any commercial product will have to address these as closely
if not more so, as the current most successful RDBMSs do.

The problem of the interface is FAR too broad ( to say nothing of
divisive ) to go into in this posting ( I hope to have more to say on
this soon - before OOPSLA, if possible ).

This collection of issues only scratches the surface of the OODBMS question.
It leaves out one of the main issues that I feel is not being properly
addressed; that is "what about the methods?"  An object without methods 
isn't much of an object. How should an OODBMS handle the storage and 
retrieval of the methods on an object? How could the methods be brought 
into a running application, in a runnable form, when the application
retrieves the objects from the DB?  Is this possible ? ( I believe it is ).
Is it desirable? ( I also believe that it is ).

Another issue that is frequently not addressed by even the more commercially
successful RDBMSs is that of data integrity.  Even integrity issues as
simple as primary key - foreign key consistency are simply not addressed.
Most, if not all, data integrity checks can be made by a properly
designed ACTIVE data dictionary. I emphasized the word ACTIVE, since
far too many people, who should know better, still think that a data
dictionary is just a system documentation tool and not the actual
heart of the DBMS.  I know from first hand experience that an active
data dictionary can solve many of the problems that are encountered in
producing a commercial DMBS and that given the power of object oriented 
programming such a data dictionary is really quite easy to design and
implement.

Well, I've stirred the pot long enough; lets see what responses this 
brings.

(P.S. - Yes. OOPSLA '88 should be fun !)-- 
Walt Peterson   GE-Calma San Diego R&D
"The opinions expressed here are my own and do not necessarily reflect those
GE, GE-Calma nor anyone else.
...{ucbvax|decvax}!sdcsvax!calmasd!wlp        wlp@calmasd.GE.COM