Newsgroups: comp.object
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!sdl!mntgfx!plogan
From: plogan@apd.mentorg.com (Patrick Logan)
Subject: Queries and navigation in OODBs (was: Re: Availability of class extension (was: value semantic versus...))
In-Reply-To: bobm@server.Berkeley.EDU's message of 31 May 91 17: 56:12 GMT
Message-ID: <1991Jun6.143624.2485@apd.mentorg.com>
Organization: engr
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> <1991May31.175612.16655@objy.com>
Date: Thu, 6 Jun 1991 14:36:24 GMT

In article <1991May31.175612.16655@objy.com> bobm@server.Berkeley.EDU (Bob Muller) writes:
   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:
   |> |> 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"
   |> 
   |> It may be true that associative queries can work with arbitrary
   |> collections, ... 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.
   |> 
   |> Relational databases ... easily reach all objects in
   |> the database from queries starting with only globally known objects
   |> (relations).

Relations and _tables_. The tables are the globally known objects. The
relations relate them. In an OODB there could be a top level
collection of employees. This could be the set of employees mentioned
in the example query Dan Weinreb used above, e.g. "Find all employees
in the top level employee collection for which...".

   |> 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.

This could be true. There could be a top level collection of
departments, each with a collection of employees. Then the query would
have to state which department's employees should be used, e.g. "Find
all employees in all departments for which..." or "Find all employees
in department A for which...". Or there could be both the top level
collection and each department collection. Each employee could still
be stored just once. Essentially, any graph you create in your
run-time structures can be stored in the database. The relational
model has all top level tables (collections) and relationships between
them, there is no opportunity to store nested tables. In _some_
applications, the top level tables would have to be restructured to
represent the more complex graph at run time. This is supposed to be
the advantage of OODBs, they represent the graph more efficiently. If
you are maintaining the furniture inventory in a building, a
relational DB is probably better. If you are designing buildings, an
OODB is probably better.

   |> 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.

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

Ditto, but I did more editing.

   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.

That is, I think, because he failed to think of tables as instances
(objects) in a database. He was comparing tables to classes (types)
and so he was comparing apples to oranges.
-- 
Patrick Logan, Try: plogan@dad.mentor.com, plogan@ws.mentor.com,
plogan@mentorg.com or substitute patrick_logan for plogan and try
that. You can also try going through uunet!(mntgfx, mentorg, mentor.com)!plogan
[Can you tell things are changing around here?]