Simple Object Persistence with the db4o Object Database
Simple Object Persistence with the db4o Object Database
by Jim Paterson
12/01/2004
Many Java applications need to deal with persistent data. In most cases,
this means interfacing with a relational database, possibly a legacy database
or an industry standard Database Management System (DBMS). The JDBC API and
drivers for most database systems provide a standard way of using SQL to execute database queries.
However, the interface is complicated by the "impedance mismatch" between
the domain object model of the application and the relational model of the
database. The object model is based on software engineering principles and
models the objects in the problem domain, while the relational model is based
on mathematical principles and organizes data for efficient storage and retrieval.
Neither model is particularly better than the other, but the problem
is that they are different and do not always sit together comfortably
in the same application.
Some solutions to this problem, such as Hibernate and
Java Data Objects, are designed to
provide the developer with transparent
persistence: the application deals with persistent objects using
an object-oriented API without the need for SQL code to be embedded in the
Java code. Container Managed Persistence (CMP) does a similar job for EJB
containers, but it is not a general persistence facility for the Java platform.
In any of these solutions, the objects are mapped to tables in a Relational
DBMS (RDBMS) by the underlying framework, which
generates the SQL required to store and retrieve object attributes. The more
complex the object model, the more difficult the mapping. Descriptors, usually
XML files, need to be created to define the mappings.
Inheritance and many-to-many relationships, in particular, add complexity as these
relationships cannot be directly represented in the relational model. Inheritance
hierarchies can be mapped onto a set of tables in different ways; the choice results in a tradeoff between storage efficiency and query complexity,
as a separate join table is required to implement a many-to-many relationship.
Storing objects in a database, which itself uses an object model, offers another
solution. A variety of Object Oriented DBMS (OODBMS) products was developed,
particularly during the 1990s, but such tools can be complex to configure and can
require the use of an object definition language. The objects are stored as objects,
but they are not native to the application language.
These products have not had a major impact on the market
outside some niche areas, and effort appears now to be mainly concentrated
on object-oriented APIs for relational databases as well as on hybrid object-relational
databases.
Embedded Databases
In some applications the overhead of an industrial strength DBMS is unnecessary,
and data storage requirements are better provided with a small-footprint, embeddable
database engine. SQLite, for example, provides
a self-contained SQL database engine.
But since the interface with Java is through a JDBC driver, such SQL-based solutions
are still affected by the impedance mismatch.
In many cases persistence could be achieved more simply using an embedded
object database engine. This is a good time to look at db4o.
Created by Carl Rosenberg, db4o was at one time only
available commercially, but now it is open source and has recently been
licensed under the GPL.
db4o has some interesting features:
No impedance mismatch–objects are stored as they are
Automatic management of the database schema
No changes to classes to make them storable
Seamless Java (or .NET) language binding
Automated data bindings
Installation by adding a single 250Kb library file (Java jar or .NET DLL)
A single database file
Automatic schema versioning
Query-By-Example
S.O.D.A. (Simple Object Database Access), an open
source query API
What Is It Good For?
db4o has been chosen for applications in embedded systems in which zero administration, reliability, and
low footprint are critical features.
In Germany, BMW Car IT, for example, uses it in an embedded car electronics prototype.
Die Mobilanten, also in Germany, uses
db4o in a PDA-based solution for mid-sized utilities.
In the U.S., Massie Systems' retinal imaging system for infant eye diagnosis relies on db4o to
power its client imaging session database.
The sheer simplicity of the way in which you store objects with db4o is also
attractive for teaching purposes. The University of Essex and Texas A&M
University uses db4o for teaching and research purposes. At my own college,
for students learning how to apply object-oriented concepts in their projects,
the need to interface with a relational database can have a negative influence
on their approach to design of their domain models. Using db4o allows them
to work with persistent data without the distraction of conflicting data models
and without the need to spend a significant amount of time learning to use
a tool such as Hibernate or a complex OODBMS. Also, learning about
the concepts of an object-oriented query API may prove useful in the future.
Same API, Different Storage
Sometimes you just have to use a relational database. From the Java developer's
point of view, transparent persistence is the ideal. If persistence is implemented
through an object-oriented API , then the developer does not have to learn
different techniques to make use of different kinds of data stores. Although
db4o is not JDO-compliant (it is easier to use as a result), its creators
have partnerships with other open source projects including
MySQL and Hibernate and are
working toward a single, consistent object persistence API that will interface
with object databases including db4o itself, relational databases, and alternative
storage schemes such as Prevayler.
If doing things the JDO way is important to you, then you might look at
ObjectDB, which is a JDO-compliant pure object database.
An Example
This example shows how simple it is to create a database and store objects.
It also illustrates two query methods: Query-By-Example (QBE) and the
more flexible S.O.D.A query API. The full source code of this example is available in the resources section below. [co: This doesn't properly target down to the Resources section -- js]
To run it you need to add the db4o JAR file to your classpath and execute the
main class Db4oTest.java.
The two classes in the example represent a baseball Team and
a Player. To make things a bit
more interesting, we also have a Pitcher class. Pitcher is
a subclass of
Player and adds one extra field on top of the ones it inherits. Team has
an attribute that is a list of Player objects, which can, of course,
include Pitcher
objects. Team, Player, and Pitcher objects
are "Plain Old Java Objects" with no persistence code. No unique key attributes are required as an
object database automatically stores objects with unique object identifiers (OIDs).
Player class
public class Player {
protected String name;
protected int squadNumber;
protected float battingAverage;
protected Team team;
public Player(String name, int squadNumber,
float battingAverage){
this.name = name;
this.squadNumber = squadNumber;
this.battingAverage = battingAverage;
}
public void setName(String n){this.name = n;}
public String getName(){return this.name;}
public void setSquadNumber(int s){this.squadNumber = s;}
public int getSquadNumber(){return this.squadNumber;}
public void setBattingAverage(final float b) {
this.battingAverage = b; }
public float getBattingAverage(){
return this.battingAverage;}
public void setTeam(Team t) {this.team = t;}
public Team getTeam() {return this.team;}
public String toString() {
return name + ":" + battingAverage;
}
}
Pitcher class
public class Pitcher extends Player{
private int wins;
public Pitcher(String name, int squadNumber,
float battingAverage, int wins) {
super(name,squadNumber,battingAverage);
this.wins = wins;
}
public void setWins(final int w){this.wins = w;}
public int getWins() {return this.wins;}
public String toString() {
return name + ":" + battingAverage + ", " + wins;
}
}
Team class
import java.util.List;
import java.util.ArrayList;
public class Team {
private String name;
private String city;
private int won;
private int lost;
private List players;
public Team(String name, String city,
int won, int lost){
this.name = name;
this.city = city;
this.won = won;
this.lost = lost;
this.players = new ArrayList();
}
public void addPlayer(Player p) {
players.add(p);
}
public void setName(String n){this.name = n;}
public String getName(){return this.name;}
public void setStadium(String c){this.city = c;}
public String getCity(){return this.city;}
public void setPlayers(List p){players = p;}
public List getPlayers(){return players;}
public void setWon(int w) {this.won = w;}
public int getWon(){return this.won;}
public void setLost(int l) {this.lost = l;}
public int getLost() {return this.lost;}
public String toString() {
return name;
}
}
First, we set up some test data to work with:
// Create Players
Player p1 = new Player("Barry Bonds", 25, 0.362f);
Player p2 = new Player("Marquis Grissom", 9, 0.279f);
Player p3 = new Player("Ray Durham", 5, 0.282f);
Player p4 = new Player("Adrian Beltre", 29, 0.334f);
Player p5 = new Player("Cesar Izturis", 3, 0.288f);
Player p6 = new Player("Shawn Green", 15, 0.266f);
// Create Pitchers
Player p7 = new Pitcher("Kirk Rueter",46, 0.131f, 9);
Player p8 = new Pitcher("Kazuhisa Ishii",17, 0.127f, 13);
// Create Teams
Team t1 = new Team("Giants", "San Francisco", 91, 71);
Team t2 = new Team("Dodgers", "Los Angeles", 93, 69);
// Add Players to Teams
t1.addPlayer(p1); p1.setTeam(t1);
t1.addPlayer(p2); p2.setTeam(t1);
t1.addPlayer(p3); p3.setTeam(t1);
t2.addPlayer(p4); p4.setTeam(t2);
t2.addPlayer(p5); p5.setTeam(t2);
t2.addPlayer(p6); p6.setTeam(t2);
// Add Pitchers to Teams
t1.addPlayer(p7); p7.setTeam(t1);
t2.addPlayer(p8); p8.setTeam(t2);