Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!mips!sgi!llustig!objy!server!bobm
From: bobm@server.Berkeley.EDU (Bob Muller)
Newsgroups: comp.object
Subject: Re: Availability of class extension (was: value semantic versus...)
Message-ID: <1991May31.175612.16655@objy.com>
Date: 31 May 91 17:56:12 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> <1991May30.003525.21161@cs.ucla.edu>
Sender: bobm@server (Bob Muller)
Reply-To: bobm@objy.com
Organization: Objectivity, Inc.
Lines: 121

In article <1991May30.003525.21161@cs.ucla.edu>, rowley@bath.cs.ucla.edu (Michael T Rowley) writes:
|> 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

Sorry for including all of the above, but my response won't make much sense
without it.

I'm with Mr. Weinreb for the most part; but Mr. Rowley's approach is not
really in opposition, it just makes some invalid assumptions.

The key to understanding declarative query languages is in understanding
scope.  Mr. Rowley is correct in supposing that there must be globally known
objects such as relations.  You've got to use some kind of global name in
the declaration of what you want.  However, where he errs is in thinking that
the only valid candidate for such names are classes or types.  In fact, an
OODB can make available various kinds of storage extents as global objects, and
this can be orthogonal to the type system.  In a type forest, it can be a separate
type hierarchy (storage hierarchy), the objects of which can be found by either
declarative specification (if they have names, for example) or by navigation.

The second bad assumption made by Mr. Rowley is that if you don't have global
names you must navigate.  This may be true in the old navigational (and relational)
databases, but not in modern OODBs, most of which implement encapsulation and
functional composition in some way.  This kind of nested (or networked) scoping can
allow for both full data independence and for declarative access through constructs
such as Mr. Weinreb suggests.  So "within this set of employees" could be fully
declarative, not navigational, if the query language provides declarative constructs
for specifying the set using storage object declarations in addition to type declarations.
You could say "IN DB 'OBJY'", for example, to look only at employees in the Objectivity
employee database named "OBJY".  This is hardly navigational; what it does is to
allow the query system to do the navigation for you.  Obviously this language could
include the standard logical operators to combine extents in whatever way you wish.

But getting back to the original post (way back, I guess)--I think any DBMS must provide
a way to look at "all the objects of a certain class", regardless of logical storage
location or any other orthogonal attribute.  Clearly this is a useful kind of query.
Just as clearly, an OODBMS must not restrict you to this kind of query, as it may involve
too much overhead for the limited query you really want to do.  Certainly this is true
in engineering and CASE applications.  You also don't want queries to be limited to
"extents of classes", because you may want to mix objects of different types in a
certain extent, querying both at once; this is usually called "clustering", but looks
very different than the clustering in a relational database because of the
orthogonality.

So my general response is that you should talk about the problem declaratively, not
navigationally, both for type-based and for storage-based queries.  Talking about
"reaching" objects from global objects is not the point; you should be able to
describe _any_ set of objects with a fully declarative language that takes advantage
of whatever global or local names are available, and in an OODBMS there are more such 
names than just the global type names.
-- 
The opinions expressed here are mine, not my employer's.

    -- Bob Muller
       Objectivity, Inc.
       bobm@objy.com