Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!nosc!ucsd!sdcc6!calmasd!wlp
From: wlp@calmasd.GE.COM (Walter L. Peterson, Jr.)
Newsgroups: comp.databases
Subject: Re: What is an OODBMS (was Re: Object Oriented DB Articles ?)
Summary: More on OODBMSs
Message-ID: <56@calmasd.GE.COM>
Date: 3 Sep 88 05:52:43 GMT
References: <3560019@wdl1.UUCP> <37@calmasd.GE.COM> <408@cullsj.UUCP> <410@cullsj.UUCP>
Organization: GE-Calma, San Diego R & D,   Object and Data Management Group
Lines: 149

In article <410@cullsj.UUCP>, gupta@cullsj.UUCP (Yogesh Gupta) writes:
> In article <49@calmasd.GE.COM>, wlp@calmasd.GE.COM (Walter L. Peterson, Jr.) writes:
> < [... my stuff about transactions & locking deleted...]
> 
> I think that one of the things that is being noticed by a lot of OODBMS
> developers/researchers is that two-phase locking does not lead to much
> concurrency, especially in the case of OODBMS (I agree that the problem
> also exists in RDBMS).  For example, ObServer (Brown Univ.) supports
> more than just two-phase locking  (I do not know whether ENCORE
> [OODBMS on top of ObServer] utilizes it or allows the user to specify
> the locking protocol).

Locking has always been a problem no matter what data model is being
used, and it dosn't seem to be getting any better with OODBMSs.  One
of the major problems that we face is that many of the commercially
available OODBMS systems are designed to work with CAD systems.  CAD
introduces its own special problems to any locking mechanism, in that
the frequency, granularity and longevity of CAD data accesses are very
different from the typical MIS application.  CAD data accesses tend to
be infrequent, long-term accesses of very large amounts of closely 
related data.  Most OODBMSs that have been produced to support CAD
data have opted for a "check-in-check-out" type of system like a code
management system (like SCCS) uses, rather than rely on a locking 
scheme.  The problem is still there and I think that it will require
some original thinking to solve, not just adapting what has been done
a million times before.

> 
> < [...my stuff about authorization deleted...]
> 
> The reason to bring this up was that so far the authorization mechanisms
> have been based on relations - a user may or may not access data from
> a specific relation, or specific columns within a relation, or where the
> value in some field is a specific value.  I think that for OODBMS, the
> authorization and security would be more based on relationships, that
> is a user may be allowed to look at an object within a class iff it is
> accessed through "relationship X" and not if it is accessed through
> relationship Y.  Thus, the specification and implementation of access
> authorization could be quite different from those that we see today.
>

Oh-oh. I think we have just hit one of those "terminology barriers" as
I call them, that seem to be plaguing object-oriented technology.
From what you say about "columns" I think that you are refering to 
relations as in "tables".  However, there is another usage in some
object-oriented languages that would be ideal for authorization and
security.  This type of "relation" is a semantic construct ( in at least
one OO-language that I know of ) that expresses relationship, associations,
and constraints between objects.  That language is DSM, which has been
developed by GE Corporate R&D and GE-Calma R&D.  It is the language
in which I work and have had some small part in helping to  develope.
Using DSM relations, one could leave the issue of authorization and
security completely up to the applications and not have the database
system ITSELF have to worry about it.  ( For more on DSM see :
Rumbaugh, J.E. "Relations as Semantic Constructs in an
Object-Oriented Language" OOPSLA-87 p. 466   and
Blaha, M.R., W.J. Premerlani and J.E. Rumbaugh "Relational Database
Design Using an Object-Oriented Methodology"  CACM April, 88 V. 31 No. 4 )
( Jim Rumbaugh is the original designer of DSM ).

I did not mean to down-play the importance of authorization. I did,
however mean to show that if we simply map objects onto the basic
architecture of the "traditional" DBMS, we will be accepting a lot of
system overhead that is simply not needed in an OODBMS, where the
semantics of the objects and their relations can do the work.

> 
> < [...my stuff about storage & retrieval of methods deleted...]
> 
> When I said "store Objects" I implied "objects and methods".  I agree with
> your statements that the methods should be retrieved and be executable for
> an OODBMS to be efficient enough to be a viable product.  I also agree that
> it is doable.  However, the problems of sharing, modifications and security
> becomes worse - how does one prevent a user from applying incorrect methods
> to an object?  How does one prevent a user corrupting the methods and then
> applying them on the objects? etc.

Preventing users from applying incorrect methods on an object is relatively
straight forward.  That can easily be handled by the method search
mechanism of the Object-Oriented language that is being used.  If the
method exists for an object class, then it is used, if not then the
object's super class is searched for a method of that name and its
super class and so on until the top of the class hierarchy is reached.
If at that point there is still no method by that name or none with the
proper invocation, then it is up to the language system to gracefully
handle the error.

The ability of a user to corrupt a retrieved method is a bit more
involved, but if there is an adequate authorization scheme in use then
the user class(es) can be restricted to allow only certain users to 
modify existing methods.  This could even be carried a step further by
not allowing the "run-time" access to the 'text' of the methods and
requiring that methods could only be loaded in to the system by some
"super-user" like the DBA. ( By the way we at GE-Calma have coined the
term Object-base Administrator or OBA, since we see the duties as
being a bit more complex due to this very issue of method use.  I made
the unfortunate mistake of producing the 'strawman' document on our need
for an OBA and as a result I was selected to be it. Lucky me. :-) )

> 
> < [...my stuff about data integrity and data dictionaries deleted...]
> 
> I agree that integrity constraints are indispensible in a DBMS.  I also
> think that this is something that would fall out of an OODBMS just because
> one can specify methods that enforce integrity along with the definition of
> the class.  In fact, the OODBMS really is nothing more than a repository :-),
> and the methods of a class define the operations on the objects in that
> class.  So, the collection of the methods IS the active data dictionary.
> 

Using methods to enforce data integrity, or more properly referential
integrity, is part of the solution, but it is not a complete solution.
Method enforcement of integrity constraints would be a bit cumbersome
for some applications, espically if the OODBMS were to be used by
clerical personnel, with little or no training in programming. We
can't always expect that the users of the system will have a large DP
shop at their disposal to write ad hoc methods for them. The users
have to have some sort of database language like SQL ( note: that
means "on the general idea of SQL"; NOT SQL itself !!! ) that will
allow the use of a simple data definition language which has the
necessary syntax and semantics to define the integrity constraints
when the user is defining data objects.  These requirements can, to
some extent, be implemented within the objects being defined, but much
of it will still have to be done by a data dictionary.  In this
context the class hierarchy ( as in Smalltalk ) may be thought of as
being at least part of the data dictionary, if not actually being the
DD itself.

I think it is very important for us ( those involved in OODBMS R&D )
to be think in terms of flexibility.  One of the reasons for the
success of the relational model is its (preceived) greater flexiblity
than the hierarchical or network models.  With object-oriented
systems, I believe that we can attain even greater flexiblity and we
can not allow ourselves to be constrained by accepting the paradigms
of the systems built upon the previous models.


Notice that once again I have studiously avoided talking about the
user interface !


>
> Thanks for your response.  I hope that others get into this also.


-- 
Walt Peterson   GE-Calma San Diego R&D (Object and Data Management Group)
"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