Re: What makes an OODBMS different from an RDBMS?

Sajai Paul wrote:
> OK, I know this is a basic question.
> But can anyone enlighten me?

Hi Sajai,

lets talk about relational databases first.

A relational database organizes data in tables: rows and columns. Typically one column contains a unique value to identify the row. This is said to be the "primary key". Other columns may contain values of primary keys of other rows, "relations" or "foreign keys".

A simple example:

table books
  column book_pkey INTEGER
  column name VARCHAR(50)
  column author INTEGER

table authors
  column author_pkey
  column firstname VARCHAR(50)
  column lastname VARCHAR(50)

Let's use the most common database language, SQL, to do some processing. Just by reading along, you can probably guess, what is happening:

CREATE TABLE books (
  book_pkey INTEGER,
  name VARCHAR(50),
  author INTEGER);

CREATE TABLE authors (
  author_pkey INTEGER,
  firstname VARCHAR(50),
  lastname VARCHAR(50));

INSERT INTO books
  VALUES (1, 'Relational Theories', 101);

INSERT INTO books
  VALUES (2, 'Object Practices', 102);

INSERT INTO authors
  VALUES (101, "Tom", "Theoretician");

INSERT INTO authors
  VALUES (102, "Pat", "Practitioner");

Now we have two tables, each filled with two rows. We can take a look with SQL:

SELECT * FROM books;

book_pkey | name                 | author
1           Relational Theories    101
2           Object Practices       102

SELECT * FROM authors;
author_pkey | firstname | lastname

101           Tom         Theoretician
102           Pat         Practitioner

The power of relational databases:
(1) Queries
let you retrieve data by *relating* rows to eachother. Even if your data model is badly designed, very old, or needs to suit many different usecases, you can find comparatively elegant queries to extract data. A very simple example for the above:

SELECT * FROM books, authors
  WHERE author = author_pkey;

gives you back the following:

book_pkey|name               |author|author_pkey|firstname|lastname
1         Relational Theories 101    101         Tom       Theoretician
2         Object Practices    102    102         Pat       Practitioner

(2) Mass Updates
If you work with relational databases, you can think in sets. Set update commands are very powerful, since they let you change many table rows with just one command. A simple example for the above:

UPDATE books
  SET book_pkey = book_pkey + 1000;

This will change all our book pkeys in our book table. SELECT * FROM books;

book_pkey | name                 | author
1001        Relational Theories    101
1002        Object Practices       102

Now we come to object databases.
In contrast to relational databases, where SQL provides a rudimentary standard[1] object database products differ greatly.

The strengths of most engines:

(Common strength 1) a very tight language binding

The above relational language, SQL, is not a programming language with features like building a graphical user interface. Therefore you need another "programming language". Let's assume you use Java:

class Author{
  String firstname;
  String lastname;
}

class Book{
  String name;
  Author author;
}

Let's create the objects, as they would be generated by entries into a form:

Book book1 = new Book();

book1.name = "Relational Theories";
book1.author = new Author();
book1.author.firstname = "Tom";
book1.author.lastname = "Theoretician";

Book book2 = new Book();

book1.name = "Object Practices";
book1.author = new Author();
book1.author.firstname = "Pat";
book1.author.lastname = "Practitioner";

All the above would happen for both approaches, a relational and an object database.

If we would use a relational database to store these two books and the two authors, our programming code would have to now create and use 4 INSERT statements as I have illustrated in the relational example.

Object databases are easier to work with since they understand objects directly. All you need to do is something like:

Database.store(book1);
Database.store(book2);

The object database engine knows, where to look for the name and the author information in the book variable.

Imagine more complex examples with many more variables. Storing objects with object databases is far less work since you do not have to take objects apart and spread values into tables.

(Common strength 2) support for inheritance hierarchies

Object oriented languages support "inheritance", a feature to specify "a class similar to this one but with a little bit more".

An example:

class ScienceBook extends Book{
  Science science;
}

Now how would you represent that with a relational database? You have two choices:
- Add "science" to your original book table.

• Add another table "sciencebooks" and create a relation to your original "books" table.

Both solutions are terrible:
- The first completely bloats the book table with empty
columns for unused information. Imagine you have cookbooks, psychologybooks, musicbooks... ...you know what I mean.
- The second makes querying extremely difficult since you
may have to relate tons of tables, which can make your query statement very complex and unperformant.

Object databases will understand inheritance. They will handle class hierarchies very efficiently. Your code can remain the same as in the simple example: Database.store(book);

(3) Some further advantages that object databases may provide:

• automatic schema management Some object databases recognize your programming languages classes automatically. You can simply program in your programming language and the database will always hold the stored representation in sync. This is very nice during development.
• higher performance for certain tasks. Since the engine does not need to convert object data to SQL-strings and parse it in a query parser the advantage is obvious. Some engines may even operate "in-process" with your application, if they are written in the same programming language. This can completely reduce the driver overhead to zero.
• more safety and easier refactoring To use relational databases, a lot of your code deals with SQL-Strings. Code in these strings can not be analysed by the compiler of your programming language. Once you start changing your code, you need to search through the entire application for these string representations. This is error prone and can be extremely difficult, if some of these strings are generated dynamically during runtime.Since object databases use objects the compiler will report any possible problem to you before, you deliver your application to your customer.
• Object identity management Object databases may manage, how your objects are put back together during queries. Consider you have two queries that return the same object:
  • a query asking for the author of a book.
  • a query asking for an author directly. You only want the same author object instantiated only once. If your application was already working with it before your query, you want a reference to this author object returned and not a new one.
• Fast ID lookup. Object databases typically assign unique IDs to objects. These IDs are very direct references to objects and may provide very fast access times which remain completely constant, no matter how high the data volume is.

This performance advantage may be very desirable in stateless web applications where you need constant re-retrieval of objects for all sessions. You may achieve a better performance with one object database system than with a load-balanced system of 30 relational database servers. Imagine the price difference.

Object databases can make life very simple. You are invited to download our engine from the website and to experiment: http://www.db4o.com

[1] Although SQL is said to be a standard, the different dialects of various vendors make it very difficult to exchange products, once you start using more advanced features. Especially ORACLE, the market leader, is trying very hard to bind customers to their own product by using a lot of constructs which are different to the ANSI standard.

I hope you see more clearly now.

Kind regards,
Carl

---
Carl Rosenberger
db4o - database for objects - http://www.db4o.com