When your next Java application calls for a database backend, before you reach for JDBC and a relational database, stop for a moment and consider another possibility: an object database.

As we hope to show in this article, an object database may not only simplify coding chores, but its capabilities may enable application solutions that you would otherwise not thought of.

Of course, the most apparent benefit you'll get from using an object database is the fact that you won't have to wrestle with two paradigms - object and relational - in a single application. The design of your application code and the design of your database will be object-oriented throughout.

However, the advantages you'll derive from an object database go beyond the simple fact that an object database is more easily incorporated into a project already written in an object- oriented language. One exceptional advantage of an object database is its ability to store structure as well as data. Put another way, its ability to preserve the structure that you've already built into your application. With a relational database, you have to tear down and reassemble that structure as you move data between the application and the database.

Typically, when one thinks of a database, one thinks of a repository of data. In a relational database, the information in the database is organized - more or less - along the lines of normalized data corralled into the proper tables. Data is arranged in "tuples," which tends to gather related information together. But any sort of higher-level data structures must be implemented in the SQL code (procedures) that access the data. Not so with an object database, which can mingle data with data structures in the same database. In fact, with the "right" object database engine, you can add new data structures to an existing database at will (or, rather, as the situation dictates).

We will illustrate what we mean using an example that combines two data structures. As our database engine, we will choose the open source object database db4o (available from www.db4objects.com).

Homemade Thesaurus
We will use as our illustration the data structures that one would employ to create something like ThinkMap's Visual Thesaurus (www.visualthesaurus.com). Visual Thesaurus is a clever visual interface that represents words as existing in a network of connected nodes. Each node is a word, and the connections represent relationships between synonyms.

Our intent here is not to create our own version of Visual Thesaurus, instead, we're going to imagine what sorts of data structures might exist "behind" the user interface of a Visual-Thesaurus-like application and consider how we might represent those structures. Finally, we want to illustrate how we could use an object database to store our imaginary thesaurus' data.

Let's design our data structures from the bottom up. So, on the ground floor, we'll need a structure for storing each word. This structure will need to take into account the fact that a given word often has multiple parts of speech. Furthermore, each part of speech will connect to a different network of synonyms. Consequently, we'll decompose this structure into two classes. First, a POSSynonyms class that will identify the part of speech and hold an array of references to the synonyms corresponding to that part of speech. The class looks like this:

public class POSSynonyms
{
      private int pos; // Part of speech
      private ThesaurusEntry[] synonyms; // Synonyms

      ... POSSynonyms methods ...
}

Obviously, this class depends on the ThesaurusEntry class, which is shown below:

public class ThesaurusEntry
{
      private string theWord:
      private POSSynonyms[] posSyns;

      ... ThesaurusEntry methods ...
}