Xref: utzoo comp.object:1006 comp.databases:5065
Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!aplcen!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!usc!elroy.jpl.nasa.gov!ucla-cs!bath.cs.ucla.edu!rowley
From: rowley@bath.cs.ucla.edu (Michael T Rowley)
Newsgroups: comp.object,comp.databases
Subject: Re: Object Data Models and Manipulation Languages
Keywords: object-oriented data model query language
Message-ID: <32406@shemp.CS.UCLA.EDU>
Date: 1 Mar 90 02:50:25 GMT
References: <1990Feb28.095810.15619@newcastle.ac.uk>
Sender: news@CS.UCLA.EDU
Reply-To: rowley@cs.ucla.edu
Distribution: comp
Organization: UCLA Computer Science
Lines: 48


In article <1990Feb28.095810.15619@newcastle.ac.uk>,
B.J.King@newcastle.ac.uk (Brian King) writes:
> 
> 3. is there a clear distinction between an object-oriented and semantic
>    data model?

Most discussion comparing the two techniques I have seen is in
describing how object-oriented modeling (OOM) is different from
semantic data modeling (SDM).  One very general difference is that
SDM's do not usually incorporate behavioral specification, whereas
OOM's do.

Another common distinction that I see is that in OOM's, user defined
types are indistinguishable from system defined types.  There is also
an implicit claim that any built-in semantic modelling capability of
an SDM system, can be built on top of an OO system.

So an OODBMS can come with a large library of classes for describing
many different semantic relationships, but the user can build more if
needed.

It is questionable, though, whether the claim mentioned above is true.
Most SDM systems have powerful mechanisms for the specification and
maintenence of arbitrarily complex constraints.  These constraints can
involve multiple object types, making it difficult to find an object
type in which to encapsulate the maintenence of the constraints.

As an example, the most basic constraint is that of referential
integrety.  Because DBMS's are used to model real world objects, and
these objects sometimes change or disappear, it must be possible
to change or delete objects.  The constraint that any pointer must
point to a valid object or to Null is difficult to maintain in an
OODBMS.  (One solution to this approach is to leave a "tombstone"
behind when an object is deleted, and to treat a tombstone as a Null).

More complicated constraints specify things like - if a Vertex is
deleted from a Rectangle, it two adjacent edges shoul be deleted, a
new (diagonal) edge should be created, and the Rectangle should be
changed to be of object type Triangle.  (This change then may trigger
other things which relate to an object loosing it's "recangleness" and
gaining "triangleness").  Believe me, there are systems that do this
(at least in R&D).

The solution, I think, is to allow encapsulation in more places than
just object type definition.

-Mike Rowley