Object Databases for Embedded Applications
By Rick Grehan, db4objects

Increased processor power and greater memory densities can lead to more intelligent embedded applications. Real intelligence, however, involves more than just performing hard-coded actions, however complex they may be; it implies the ability to retain information and act on it later. Such ability demands persistent storage and requires a database. One obviously needs a way to manage amounts of data beyond just a few items.

Most people think of databases in terms of the widely used relational model, as in popular examples such as Oracle and DB2. Applications built on top of relational databases are often constructed along client-server lines, and almost always use SQL as the way to specify data retrieval. Even if you manage to jettison the client-server architecture (by compiling the database management code into your application’s process space), your application will still have two separate parts. One is your application’s workhorse code; the other is the support code for the relational database. You also need intermediary code to handle the translation between application objects and relational tables.

Most applications do not use all SQL commands. So you might try to reduce your application’s footprint by surgically removing support for unneeded ones. Even if you succeed, the processing of SQL still requires an interpreter. Some embedded database systems skirt this problem by allowing SQL commands to be pre-compiled. But this still leaves the translation code described above.

However, with the growing use of object-oriented languages in embedded applications, there is an alternative. A cleaner approach is the storing and retrieving of persistent objects as ... well ... objects. Best of all is a database that preserves object relationships (not merely representing them, as relational databases do). Such a system eliminates code for translating between objects and tables, allowing object navigation as a means of searching and querying.

Of course, a basic query mechanism is required to ’jump-start’ object navigation. That is, you must be able to locate and read from the database a ’root’ object, whose references to other objects can be used to fetch the rest of your persistent data. Properly handled, the query system can eliminate the need for an embedded interpreter.

Readers may test these contentions with the open-source object database db4o. Available from www.db4objects.com in Java and .NET versions, db4o preserves object relationships, and features an easy-to-master query-by-example system that easily meets the requirements outlined above.

Using an object database to support an application constructed with an object oriented language yields a design symmetry that extends beyond the sharing of the word "object." Application objects (and their relationships) need not be torn apart and re-constituted as they move into and out of the database. No query language interpreter is needed, and the class structure becomes the database schema definition. All this means a smaller footprint, and code that is easier to construct and maintain.

Rick Grehan is a QA Lead for Compuware’s NuMega Lab (Nashua, NH).