The database is the heart of any enterprise system. The shared business objects that make up an enterprise need some way to make sure they are saved across time. The database provides that storage mechanism. Any language that is going to claim to be an enterprise language therefore needs to have strong, reliable database connectivity.
Several important database concepts form the core of this book’s discussion. This book assumes some basic familiarity with Java and databases. You should have a basic understanding of SQL and transaction management. Building on this foundation, we will discuss JDBC and how it can be used to execute SQL against any potential database engine.
The Java database API, JDBC, requires that the database being used
support ANSI SQL2 as the query language. The SQL language itself is worthy of a tiny
mini-industry within the publishing field, so covering it is well
beyond the scope of this book.[1] The SQL in this book,
however, stays away from the more complex areas of the language and
instead sticks with basic DELETE,
INSERT, SELECT, and
UPDATE statements. For a short overview of SQL,
check out Chapter 2.
The only additional level of complexity I use consists of stored procedures in the later chapters. Stored procedures are precompiled SQL stored on the database server and executed by naming the procedure and passing parameters to it. In other words, a stored procedure is much like a database server function. Stored procedures provide an easy mechanism for separating Java programmers from database issues and improving database performance.
JDBC is in a SQL-level API that allows you to embed SQL statements as arguments to methods in JDBC interfaces. To enable you to do this in a database-independent fashion, JDBC requires database vendors (such as those mentioned earlier in this chapter) to furnish a runtime implementation of its interfaces. These implementations route your SQL calls to the database in the proprietary fashion it recognizes. As the programmer, though, you do not ever have to worry about how it is routing SQL statements. The façade provided by JDBC gives you complete freedom from any issues related to particular database issues; you can run the same code no matter what database is present.
Transaction management involves packaging related database transactions into a single unit and handling any error conditions that result. To get through this book, you need only to understand basic transaction management in the form of beginning a transaction and either committing it on success or aborting it on failure. JDBC provides you with the ability to auto-commit any transaction on the atomic level (that is, statement by statement) or wait until a series of statements have succeeded (or failed) and call the appropriate commit (or rollback) method.
A Java application can use one of three major database architectures:
Relational database
Object database
Object-relational database
The overwhelming majority of today’s database applications use relational databases. The JDBC API is thus heavily biased toward relational databases and their standard query language, SQL. Relational databases find and provide relationships between data, so they collide head-on with object solutions such as Java, since object-oriented philosophy dictates that an object’s behavior is inseparable from its data. In choosing the object-oriented reality of Java, you need to create a translation layer that maps the relational world into your object world. While JDBC provides you with access to relational databases, it leaves the issue of object-to-relational mapping up to you.
Object databases, on the other hand, do not attempt to separate object data from behavior. The best way to think of an object database is as a permanent store of objects with which your applications can interface. This object-oriented encapsulation of data, however, makes it difficult to relate data as well as relational databases do. Additionally, with JDBC so tightly bound to SQL, it is difficult to create JDBC drivers to run against an object database. As of the writing of this book, Sun, in cooperation with the Object Database Management Group (ODMG), is working on a specification for a Java object database API.
Object-relational databases enjoy a “best of both worlds” advantage by providing both object and relational means of accessing data. Until recently, object relational databases have relied almost entirely on C++ objects to act as their object store. With all of the excitement around Java, however, object-relational vendors are starting to enable their systems to support database objects written and extended in Java. In this realm, your Java objects do not need to map relational data into business objects. For the sake of easy, ad hoc querying, however, an object-relational database also provides complex relational queries; sometimes these queries can even be done in an ANSI SQL superset language.
[1] O’Reilly is publishing a SQL reference guide, SQL in a Nutshell, by Kevin Kline with Daniel Kline.
Get Database Programming with JDBC & Java, Second Edition now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
