Using a relational database engine in a Java application requires that you map your application’s object model to fields within database tables. An order-entry application, for example, will consist of a header section (which includes order number, date, customer information, shipping information, etc.) and a detail section (which includes one or more line-items of product number, quantity, cost, and so on). A relational implementation would likely be built on at least two tables, one holding the order header records, another holding the line-item records.
With an RDBMS, reading an order from the database into the application requires a search on the order header table, followed by a search on the line-item table. More importantly, after each search, the code will have to instantiate an appropriate object and copy the record information into the object fields. In other words, using an RDBMS, you build and wire the object structure explicitly.
With an object-oriented database, however, both object structure and object data are saved in the database. There are no tables, just an object store into which objects are saved and from which they can be fetched.
So with an object-oriented DBMS, reading an order entry requires but a single search for the proper order object (based, for example, on order number), and a single fetch. (From the programmer’s perspective, the search and fetch will appear as a single operation.) The database engine pulls in the header object, as well as the embedded line items container object and the container’s contents — the line item objects themselves. It’s like the old game of Barrel of Monkeys: Pick up the topmost monkey — in this case, the order header — and all the other monkeys hooked to it are automatically pulled out of the pile. You don’t have to transfer data from tables to objects; the engine does that for you.
Although it may appear that object-oriented DBMSes have relational systems beat, that’s not necessarily the case. Relational database systems are far more widespread than object-oriented databases. Moreover, countless programmers are well-versed in SQL, a skill that travels easily from one RDBMS to another. In addition, corporate data is largely tabular in form, making its representation in a relational system easy and natural. Choosing the right database format, then, depends on where and how your organization must access its information.