Chapter 5. Datastore Mappings

JDO supports the storage of your object model in a variety of datastore architectures. The primary datastore architectures envisioned for use with JDO are:

Relational database

Organized as a set of tables, each containing a set of rows and columns. A column can store values of a particular atomic type. Each table cell in a particular row and column stores a value of the column's type. The value stored can be a null value. Instances are identified uniquely by the value of primary-key columns. Relationships are defined, and may be enforced, by annotating specific columns as foreign keys that reference columns in a table.

Pure object database

An extension of the JVM object model. Domain objects are stored with their primitive fields, just as instances are stored in the JVM. Instances are identified by a system-generated unique identifier. References are stored as objects, including instances of system-defined classes. Unreferenced instances are garbage collected. An extent is not an intrinsic construct in a pure object database; it is implemented as a class containing a set of objects. In this model, any reference type can be shared among multiple objects, and changes made to the instance of the reference type are visible to all objects that reference it.

Hybrid object database

Organized as a set of class extents, each containing a set of instances in which primitive and complex fields are stored. Domain objects are stored with their primitive fields; some complex field types (e.g., collections of primitive types and reference types) are also stored with the domain object. Instances are identified by a system-generated unique identifier. Unreferenced instances must be deleted explicitly.

Application Programming Interface (API)

Defined by an API to an abstract domain model. The API defines methods to create, read, update, and delete abstract domain instances. The underlying datastore implementation is completely hidden by the API. Many complex system products use this type of architecture.

The JDO 1.0.1 Specification does not specify a standard for mapping to specific datastores. JDO implementations support one or more datastores and often provide a means for you to direct the mapping process by specifying additional, vendor-specific metadata. These mapping directives can be placed in the JDO metadata files or in an implementation-specific location. Some vendors allow you to specify the mapping via a graphical environment that depicts the Java and datastore models, allowing you to associate items in the two models to define a mapping. Regardless of where this vendor-specific mapping information is placed, it does not affect your Java source code.

Current JDO implementations provide support for relational databases, as well as pure and hybrid object databases. As JDO implementations become available for other database architectures, other mapping facilities will likely be considered. For example, there are databases based on the XML data model. Mappings might soon be defined between the XML database and a set of Java classes. Such an interface would likely be based on the Java Architecture for XML Binding (JAXB) standard.

SQL is the dominant relational language in use. Today, most Java applications access a relational database through Java Database Connectivity (JDBC), which provides an interface for Java applications to issue SQL commands to a relational database. Since a relational database uses the relational data model, which is different from Java's object model, a mapping is required between the modeling constructs of Java and the relational database.

Since relational databases are prevalent, and because most people are familiar with the relational data model, we will focus on the mapping strategies and approaches employed when JDO is used with a relational database. However, much of the discussion is fairly generic and can apply to other database architectures.