Re: What is an OODBMS?

From: AndyW (foo__at_bar_no_email.com)
Date: 01/06/05 

Date: Thu, 06 Jan 2005 12:29:07 +1200

On 4 Jan 2005 21:20:45 -0800, "frebe" <fredrik_bertilsson@passagen.se>
wrote:

>In the OO world, there has been talking about OO databases for about 15
>years now. But to me it is still not clear what a OO database actually
>is?
>
>Sometimes people talk about OO databases as "a database that can do
>everything a relational database can, plus extra OO things". Sometimes
>they seem not to support the relational model and seem to be very close
>to the network model. Sometimes hierarchial databases (like XML
>databases) are referred as "OO databases".
>
>My question is: Which are the most popular OODBMS and what are their
>main features in comparison to relational databases? Does they have a
>query language and in that case, how does it work?
>
>Sometimes I read that OO databases have a "seamless" integration with
>the programming language. Does this mean that the separation of
>database access logic into a persistence layer is not more necessary,
>or?
>
>Fredrik Bertilsson
>http://butler.sourceforge.net

If you think of an RDBMS as a database in its raw form then an OODB is
a database in its complex form. Although it really is unfair to
compare the two as if you are familiar with any RDBMS stuff you have
to do a serious amount of lateral thinking in order to work with an
OODB - something that very very few people can do. In general if you
get negative feedback about OODBMSs it will be from RDBMS folks.

In an OODB you dont have database access logic, there is no need for
it - and thats a mechanism provided by OO itself, rather than a
database.

An OODB stores the instance of an object along with all the code
needed to work with that instance. The location of the object is
irrelevant to its usage - wether its on disk, in memory or on a
machine in a different country is not important.

Objects have what is called an Object ID or OID for short. Think of
it like a name tag for the object and it must be unique - just like an
object is in the real world. Just like your coffee cup is unique.
Also objects may have many OIDs - just like your cup can have many
names.

Objects are complex entities and can be made up of smaller simpler or
complex objects themselves. When you deal with a complex object you
also automatically deal with its individual parts thru the power of
polymorphism and encapsulation. This is why OODBs are very good when
used for diagramatic parts catalogs and telephone exchanges (phone
call info is very complex containing many dynamic sub parts).

Referencing an object automatically creates an instance if none exists
and most OODBs will load the persistant form into transient space
automatically, likewise they will persist automatically (hence no
access code). Persisntance and transience mean slightly different
things in OODBs as they do in normal programming, it also happens to
be mostly irrelevant to the application program.

What OODBs are not good at is relational collections of data - simply
put, they work with objects not attributes. So things like names,
addresses, telephone numbers and charges are not suitable pieces of
data for an OODB. The data you would find would be bob, lufthansa,
toyota car, firestone wheels etc.

To put it another way, attributes of an object are in general an
irrelevance. To give an example when charging someone for a phone
call, you might in an RDBMS read the charge, and add it to the
customers account balance then update the result. These would require
discrete actions of some kind with specific data. In an OODB you
would post a general message to the ether and the appropriate object
would identify itself and perform its own processing (irrelevant to
the application space). (newbie OO people often try and iterate over
collections which is a bit silly at the end of the day).

Thats one of the main problems of understanding OODBs - the fact that
data is often irrelevant to the application space.

To answer your last question, PSE-Pro (and ObjectStore) are good
examples of seemless integration. In C++ you access the object by use
of a pointer. In PSE-Pro if the pointer is invalid a memory fault is
generated causing the database to load the data that needs to be
accessed, the pointer is then retried and the data is accessed.

I'm told that Objectstore has the ability to sit over the top of a
relational database and run it side by side with its own OODB. Thus
you get the best of both worlds by being able to work on both object
and relational data (although i've never tried this out). Many RDBMSs
have also adopted OODB techniques and have some basic ability to try
and mirror the functionality often in a more complex way. Examples of
adopted features are triggers, stored procedures and binary objects.

OODBs often have a query language and there is a standard for it
[OQL]. Often you may need to work with a collection of objects or
related objects. The OODB has a database schema just like a
relational one does (actually the schema in an OODB is polymorphic so
you tend to have a few dozen of them mapping on to the object space).

If you cant get hold of a copy of PSE-Pro (it used to be a free
download), then take a look at the CORBA IDL language - its designed
to work with OODBs (although most wouldnt know that) and is a really
good teaching aid for working with distributed objects. PSE-Pro comes
with a basic case tool for doing class diagrams and creating object
schema. There was a java version as well as the c++ version, but I
havnt used it.

XML is a markup language for defining data, its in no way related to
an OODB - not even close. Simply because to have an object you need
identity, action and state at all times and XML only describes the
state and identity and doesnt do that at all times.

In general i've found that maybe 10% of IT people can fully grasp the
concept of OODBs (although maybe 90% would make the claim they do -
its doesnt pan out in practice), and I would say that the more
relational db knowledge you have the harder the concepts of OODBs
become - the two are almost opposite each other.

Pure OODBs requires that you work in the pure OO world and this is
pretty much not done (Object purists are very few and far between), so
most OODBs are hetrogenus and amalgamate many non OO features of
programming languages in order to make them easier to work with.
These are probably the most common kind and most of them were pretty
awful at best, which is what probably put most people off using them.

Andy

Relevant Pages

  • Re: What is an OODBMS?
    ... But to me it is still not clear what a OO database actually ... There are two OODB models. ... memory; these OODBs usually use virtual memory as a cache for the ... not a lot of difference between this sort of OODB and an RDB; ...
    (comp.object)
  • Re: What is an OODBMS?
    ... > If you think of an RDBMS as a database in its raw form then an OODB is ... > a database in its complex form. ... > OODB - something that very very few people can do. ...
    (comp.object)
  • Re: Database type independence
    ... > independent of the database type (RDB, OODB, LDAP, etc). ... There are many tricksters in this business. ...
    (comp.object)
  • Re: Object/Relational Mapping is the Vietnam of Computer Sci
    ... Just take any ORM layer and the fact that you can directly and easily map a SQLDB to an object model is all the proof I need that a RDBMS *can* indeed be expressed as an object graph and that an OODB can therefore be relational. ... Much of the point of an OODB is to capture a given object hierarchy, which is essentially a constrained Entity-Relationship model - the most obvious constraint being the relaxation of normalisation conditions. ... Personally I want each item of data to occur once - and only once - in my database, as that way I can ensure that a single change is reflected universally and performed efficiently. ... Fine, do that in your software if it makes sense, but don't do it with your data model: it's the underpinning of not only your application, but of every other application that needs access to the same data-space, so generalising the model at a later date will be the most expensive change you can make. ...
    (comp.lang.ruby)
  • Re: Three Kinds of Logical Trees
    ... that includes all code that uses the dbms api would have all such units ... a variable of type int, with an int value and invoke a method ... ... >> database would have all the data and functions it needs to address ... I have no plans to design a language, but I'm happy to learn anyway ...
    (comp.databases.theory)