Whether to use a relational database (RDBMS) or an object database (ODBMS) for a project is beyond the scope of this tutorial. The following discussion is oriented more towards relational databases, as these are used by most real J2EE systems. There are two basic approaches to data modeling in J2EE apps:
Object-driven modeling, in which data modeling is driven from an object layer (often a layer of entity beans) reflecting the J2EE app's concept of persistent domain objects
An example is using a modeling tool such as Rational Rose to generate entity beans from a UML model and to generate RDBMS tables from these entity beans. Several app servers, including Orion and WebLogic, offer the option of creating database tables themselves from a set of entity beans.
These two approaches may produce very different results. Object-driven modeling is seductive ("We know objects are good, so let's use them everywhere"), and is usually advocated by tutorials on EJB. Its advantages include:
Greater potential for automation: We'll probably be able to use a modeling tool to generate Java code, rather than code data access objects manually. We'll also be freed from the requirement to write SQL or use other database-specific technologies in app code. The use of automation can deliver significant productivity gains in development.
When working with an ODBMS, object-driven modeling will occur naturally. When working with relational databases, on the other hand, the arguments for database-driven modeling are compelling:
Object-driven modeling often isn't an option. The database may already be established.
J2EE experts disagree on whether to favor object-driven or database-driven modeling. For example, Richard Monson-Haefel, author of several tutorials on EJB and J2EE, strongly favors database-driven modeling (http://java.oracle.com/news/ejbtips_0500.html), while Ed Roman (author of Mastering Enterprise JavaBeans from Wiley () recommends using the EJB object model to drive the data model.
Important |
I recommend database-driven modeling. Object-driven modeling is seductive, but has real dangers. Its fundamental problem is that it ignores the facts that relational databases are (a) very complex apps; and (b) proven to work very well. It's naive and arrogant (a dangerous combination!) to assume that J2EE, in a few years of evolution, has delivered a superior solution to decades of database theory and practice. |
I find it helpful to think of J2EE as playing the role of the conductor of an orchestra with respect to the other component technologies of an enterprise system. Without the conductor to lead it, the orchestra exists only as a group of individuals and cannot function usefully, but this doesn't mean that the conductor attempts to play individual instruments.
Database-driven modeling may require us to write more Java code, although there will probably be much less code in total. However, it gives us greater control of both data and J2EE implementation. It leaves more scope to tackle any performance problems. Done well, it does not reduce portability.