Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!ucla-cs!bath.cs.ucla.edu!rowley
From: rowley@bath.cs.ucla.edu (Michael T Rowley)
Newsgroups: comp.object
Subject: Re: Availability of class extension (was: value semantic versus...)
Message-ID: <1991May30.003525.21161@cs.ucla.edu>
Date: 30 May 91 00:35:25 GMT
References: <1991May14.093053.3017@jyu.fi> <3683@sequent.cs.qmw.ac.uk> <4851@osc.COM> <1991May22.053938.20827@jyu.fi> <4863@osc.COM> <1991May28.232832.28284@cs.ucla.edu> <1991May29.134314.6850@odi.com>
Sender: usenet@cs.ucla.edu (Mr. News Himself)
Reply-To: rowley@cs.ucla.edu
Organization: UCLA Computer Science
Lines: 67
Nntp-Posting-Host: bath.cs.ucla.edu

In article <1991May29.134314.6850@odi.com>, dlw@odi.com (Dan Weinreb) writes:
|> In article <1991May28.232832.28284@cs.ucla.edu> rowley@bath.cs.ucla.edu (Michael T Rowley) writes:
|> 
|>    However, if there is to be a associative querry language, it must be
|>    possible for the user to say "give me all objects which meet these
|>    conditions".  
|> 
|> No, that's not true.  If you have an OODB that does not keep extents,
|> you can still have an associative query language.  Each query simply
|> needs to be handed a "collection" object.  So a typical query might be
|> "find all of the employees within this set of employees for which the
|> salary is greater than 42", just like the standard mathematical
|> notation {x element-of X | x.emp > 100} (for "element-of" read a
|> little epsilon).  The queries can be as complicated as you like; more
|> than one collection can be involved; and automatic optimization can be
|> performed.
|> 
|> So an OODB can have associative queries even if it does not
|> automatically maintain extents.  These are two separate, orthagonal
|> issues.

It may be true that associative queries can work with of arbitrary
collections, in which case the term "associative query language" may
not be the best descriptor of the features I'm trying to describe.
Maybe a better description would be that the query language is
declarative, rather than imperative.  It is desirable to be able to
specify a query by stating the conditions which the result objects
must meet --- without specifying a navigational strategy for
retrieving the objects.

All queries must start with some known object.  This may be a globally
known object (relation or class) or it may be the result of a previous
query.  In network databases not very much could be retrieved by a
single query using only global objects, so the user would have to make
multiple queries, each building off the previously retrieved data.
In order to facilitate this, the query language looked very much like
an imperative programming language, complete with "cursors" to keep
track of past results.

Relational databases, on the other hand, easily reach all objects in
the database from queries starting with only globally known objects
(relations).  As a result, it is easy for these databases to provide a
declarative query language.

In the example you wrote above:

  "find all of the employees within this set of employees
   for which the salary is greater than 42"

the important words are "within this set of employees".  The
interesting set of employees may only be reachable through a multi-step
navigation through the network.  In which case, the user would be
reduced to writing imperative programs to retrieve his data.  I think
the user community will balk at this.

Hence, I think all objects in an OODB should be easily reachable from
globally known objects.  The most obvious candidates for such objects
in an OODB would be collections representing the extents of the
classes.

Another, less desirable solution would be to provide a single
collection representing every object in the database.  The problem
with this is that it would be hard to write the conditions for the
result objects, since the questions that can be asked of objects
depend on their types.

Michael Rowley