Re: What is an OODBMS?

From: H. S. Lahman (h.lahman_at_verizon.net)
Date: 01/07/05 

Date: Fri, 07 Jan 2005 22:24:28 GMT

Responding to Frebe...

>>Thus the static Find method for a single object is as close as one gets
>>to a DB query. One way to look at this is that the specific instance
>>relationships that are saved in the OODB already reflect any queries one
>>might execute to load data on a piecemeal basis.
>
>
> Lets say we have a collection of employees in our application. An
> employee have the attributes name, city and date_of_birth. In one use
> case we want to find all employees from a given city. How would we do
> with an OODB? Create a (persistent) map with the city as the key and a
> set of employees from that city, as value? Lets say we want to find
> every employee that are younger than a given age. Do we have to create
> a sorted map to be able to do this search? What if we want to combine
> these two criterias? Will we loop every one from the given city and
> checking the age?

The relationships in an OOA/D model only describe the static structure
of the relationships and that is all that is stored in the OODB. More
important, they describe only what is important to the problem in hand.
  Relationship instantiation and navigation for specific objects and
collaborations is provided in the dynamic models where methods are
described.

If one wants to select from a collection based upon non-identity data,
then one will have to have explicit selection logic for that. For
example, one might customize the collection class during OOP to have a
selectBasedOnCity (cityID) method that returns a temporary
<sub->collection. In essence that represents relationship navigation,
which is the heart of OO collaboration. But that would be done after
the objects and their relationships have been loaded into memory from
the <memory-mapped> OODB.

So the OO program will already have the explicit selection logic built
into it. Thus is doesn't query the DB; the solution logic selects from
the collections it already has. Note that this is an example of one of
the key differences between the RDB view and OO applications. The RDB
view is geared to ad hoc data retrieval (i.e., there is no assumption of
what data will be selected of why) while the OO view is tailored to very
specific problems (i.e., the problem solution defines /exactly/ what
data will be selected). So if there is no reason in the problem
solution to extract a set of Employees for a particular City, then there
will simply be no way to do it in the solution logic.

OTOH, if the relationship between Employee and City is very important to
the problem in hand, it is quite likely that it will be mapped
explicitly in the original OOA/D model as:

            * 1
[Employee] ----------------- [City]

In that case there will be an explicit collection whose relationships
will be in the OODB and will be loaded. (Corollary: there will be no
explicit selection logic in the relationship navigation because
collection from the City side is based on identity rather than
non-identity attributes.)

>
> Isn't the database you describe VERY close the network databases?

The memory-mapped OODBs are more like a literal map of a program's
memory. That may or may not be network-like. I think the other model
of OODB where join infrastructure is built in would be a better analogy
of a network. Infrastructure support for many and arbitrary
relationships is analogous to token/star sorts of network configurations
where participants come and go.

*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
blog (under constr): http://pathfinderpeople.blogs.com/hslahman
(888)-OOA-PATH