Welcome!

PowerBuilder Authors: Dan Joe Barry, Carmen Gonzalez, Ian Thain, Yakov Werde, Paul Slater

Related Topics: PowerBuilder

PowerBuilder: Article

Mixing Data & Data Structures in an Object Database

An introduction to the trie

When your next application calls for a database backend, 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. (Figure 1)

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 ...
}

The first element of this class, theWord, holds the string of the word itself. The second is the array of POSSynonyms.

The result lets us create a network of interconnected synonyms. You can get a feel for what it might look like if you examine Figure 2. The ThesaurusEntry object for the word "heat" would include a posSyns array pointing to a POSSynonyms object for the verb synonyms, and another for the noun synonyms. The verb POSSynonyms object would, in turn, include a synonyms' array that points to ThesaurusEntry objects corresponding to the words boil, seethe, simmer, and so on. The POSSynonyms object would include a synonyms' array pointing to ThesaurusEnty objects for warmth, glow, temperature, and so on.


More Stories By Rick Grehan

Rick Grehan is a QA engineer at Compuware's NuMega Labs, where he has worked on Java and .NET projects. He is also a contributing editor for InfoWorld Magazine. His articles have appeared in Embedded Systems Programming, EDN, The Microprocessor Report, BYTE, Computer Design, and other journals. He is also the coauthor of three books on computer programming.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.