I need some help understanding OODBMS'. I'm well versed in normal
databases and SQL, and I understand object brokers, but I'm at a loss
when it comes to OO databases. Perhaps someone could explain a few
things or point me elsewhere for explanations.

I've programmed in C++, and I understand about storing objects in a
file to achieve persistence. I also understand that relationships
exist between objects. But
1) what is stored in an OODBMS that is useful?
2) and under what circumstances would an SQL-like query be useful?

In a data-only database one uses SQL to retrieve a series of records
so that they can be displayed and perhaps changed, but how one would
do this in an OO environment isn't obvious to me. Can you set
selection criteria for object member data in the same way that you set
selection criteria for "columns" in normal databases? I thought you
couldn't access member data when the object is stored in the OODBMS.

Lou Arnold wrote:
Objects !

Using an object database, you have to worry very little
about persistence when you design your class model.

You simply store objects as they are.


You will need queries to get your objects back:
"Give me all person objects where the first name is "Lou".

to have a starting point.


When you work with objects, query-by-example is a very
natural way for querying, because you always stay within
the OO world.

An example:
Person personTemplate = new Person();
personTemplate.setFirstName("Lou");
database.get(personTemplate);

Different object databases provide different querying
systems. Some offer querying against member fields,
which indeed breaks OO encapsulation to a certain extent.
Some implementations allow you to query against method
results, they even index method results, so queries
execute fast.

Best,
Carl
--
Carl Rosenberger
db4objects Inc.
http://www.db4o.com

Possibly anything including code and data, although mostly data at
present.

When one needs to create, select, update, delete, etc things.

The exact steps will vary depending on the tool being used. The
following pseudo-code for an experimental db creates persons John and
Mary in a non-OO programming environment such as C.

// Create John and Mary
NLI_create ("*person.item ~in = dir")
NLI_create ("*John.cls = person")
NLI_create ("*Mary.cls = person")

// Select all persons
Q = NLI_select("*.cls = person")
while (person = X(Q)){
// Var person can access all related things
print (T_Name_get(person))
}

Thank you, Carl and Neo. This is starting to make sense.
The key comment was: That one can query by the results of a method for
some databases, and by data member (I assume for public members).

It was nice to see that storing and retreiving can be so easy. These
points bring to mind some additional questions:

1) It was mentioned that code (methods) might be stored in the DB; how
would this be of help?

2) Can one say that each class (i.e. object type) has a "table" (in
the RDB sense)? If so, this has rather serious ramifications for
inherited members. It also means that objects stored in the OODB have
a unique ID.

3) Are relationships recorded in the same way as in an RDB - 1:M and
M:M? I assume that program code has to place the IDs in a "table" to
establish the relationships between specific objects. Or would the
OODBMS somehow know to record such relationships automatically. After
all, it seems to know what members of an object that it needs to
store. I also assume that the OODBMS handles referential integrity
matters.

4) Once a query has returned several object "records" as a "set", is
there a cursor to step through the objects, or does one simply get a
list of objects as a collection?

These questions are getting complicated. I'd appreciate some
written/online literature about OODBMS's that would give me answers to
questions such as these.

Many thanks,
Lou.

Following answers with respect to XDb2. Currently it does not store
methods. Making code the same a data would have an effect along the
lines of a person knowing basic Windows GUI and thus being able to
handle any new program to some degree.

With respect to XDb2, there are no tables, there are only things. Some
group of things could be viewed as a list, table, tree, network, cube,
etc. In general, user does not work with an ID, but with
classifications, attributes and relationships that specify a unique
thing or set of things.

XDb2 can model almost any type of relationship imaginable (within
limits of memory, processing time, etc). How the db actually stores the
relationship is mostly irrelevant from a XDb2 user's point of view. Via
it "Natural" Language Interface (similar to SQL), user submits a
statement such as "John.cls = person" to form a relationship.

XDb2 maintains ref integrity between things user has related. XDb2 does
not limit what things user can relate however.

XDb2's API provides a "cursor" to step through things returned by a
query.

Lou Arnold wrote:
The other responders have their own agendas, so I'd like to clear up a few things...

An OODBMS is really little more that an "object persistence" utility. Unlike
relational/normalization, they have no solid foundation for their structure. They use an
ad-hoc organization that is not appropriate for storing usable information. They can't
guarantee that the information is accessible and that the integrity of the information
is protected. Some do provide a primitive type of SQL interface, but it is a mere shadow
of the power of a relational query facility.

--
Lee Fesperman, FFE Software, Inc. (http://www.firstsql.com)
================================================== ============
* The Ultimate DBMS is here!
* FirstSQL/J Object/Relational DBMS (http://www.firstsql.com)

Could explain further? Or better yet, demonstrate with a simple example?

Neo wrote:
Fully explaining the solid foundation and power of the relational model and
normalization is beyond the scope of a usenet posting. If you really want to educate
yourself, get over to Database Debunkings (http://www.dbdebunk.com). You should also
read the books by the denizens of dbdebunk.com -- Date and Pascal. I'd recommend
Pascal's latest book (see the site). However, I will say this...

The relational model guarantees accessibility by requiring that all data be reachable
with 3 pieces of information -- a relation (table) name, a primary key value and an
attribute (column) identifier and by requiring *all* information be represented by
values in tables. It guarantees integrity of information with constraints, transactions,
privileges, security (all declarative) and a normalized data structure. SQL is a
declarative language that describes the results desired instead of how to navigate to
retrieve the data.

I am still wary of quick explanations considering how far off the track you've gone with
normalization.

I'll pass on your request for a simple example to avoid the obtuse procedural code that
you've been flooding the database newsgroups with lately ;^)

--
Lee Fesperman, FFE Software, Inc. (http://www.firstsql.com)
================================================== ============
* The Ultimate DBMS is here!
* FirstSQL/J Object/Relational DBMS (http://www.firstsql.com)

If one is modelling a person named John whose gender is male, it might
look like the following in RM:

T_Name
ID Value
-- -----
1 male
2 John

T_Gender
ID NameID
-- ------
10 1

T_Person
ID NameID GenderID
-- ------ --------
20 2 10

// RM's SQL Script to create above and query John's gender
// would be approximately:
CREATE TABLE T_Name (ID int, Value CHAR(50));
CREATE TABLE T_Gender (ID int, NameID int);
CREATE TABLE T_Person (ID int, NameID int, GenderID int);
INSERT INTO T_Name (ID, Value) values (1, 'male');
INSERT INTO T_Name (ID, Value) values (2, 'John');
INSERT INTO T_Gender (ID, NameID) values (10, 1);
INSERT INTO T_Person (ID, NameID, GenderID) values (20, 2, 10);
SELECT T_Name.Value FROM
((T_Person JOIN T_Gender ON T_Person.GenderID = T_Gender.ID)
JOIN T_Name ON T_Gender.NameID = T_Name.ID)
WHERE T_Person.NameID = (SELECT ID FROM T_Name WHERE Value = 'John'));

// While XDb2's NLI script is:
(CREATE *gender.item ~in = dir)
(CREATE *person.item ~in = dir)
(CREATE *.cls = person & it.name = +John & it.gender = +male)
(SELECT John.name = *)

Actually RM's SQL would be more complicated than shown above if
normalized not just to names but down to symbols as is the db created
by XDb2's script.

Yes I visited them and the best part of the site is where they quote
Neo's definition of normalization