Beginning Java Databases

Chapter 1: Relational Databases and Java

Data is the foundation of all but the most trivial application development. Whether the application is a video game storing a user's score in memory or an accounting package saving a customer's order, it will need to load, manipulate, and store data in some form or another. The relational database, although not the only option, is currently by far the most common means of storing this data.

In this chapter we will:

• Give a foundation in the basics of relational databases
• Introduce the Structured Query language (SQL), the standard programming interface for retrieving and manipulating data in relational databases
• Introduce the JDBC Application Programming Interface, through which Java supports relational databases (and thus the ability to execute SQL commands from our Java programs)
• Install the Cloudscape database and the sample Music Store database that we will use throughout this book

Persisting Data

The Java language defines a vast array of data structures with which we can store information in our programs, from the simple variable to arrays, vectors, and nodes. The idea behind persisting that data is simple: your program has knowledge about some kind of information or data at one point in time and you want to be able to access that same information and maybe even update it or delete it at a point of time in the future.

Almost any kind of program you could mention will involve some kind of persistent data - even those you might not immediately associate with the need for data storage, until you start to think about it. Consider, for example, what happens when you request a web page from you browser (say, http://www.wrox.com). Your request will go through a 'naming server' that will convert your URL into an IP address, by performing a database lookup. The data needed to do this conversion database must be persistent and is continuously updated.

If your program handles only small amounts of data, then you may be able to simply store that data in a text file on disk, or make use of Java's object serialization. However, if it handles a significant amount of data, then it is likely to store that data in a relational database. Let's briefly consider the first two of these options before moving on to discuss the need to write Java applications that are driven by a relational database.

Persistence in .lava

There are several ways that we can persist data in Java. Some of the examples include utilizing flat files, serializing objects and using a database. Depending on the amount and type of data that you need to persist, you might choose a different implementation.

Flat Files

We can write to and read from flat files that are stored in the file system on disk. This is a viable option when all you need to store are some configuration settings, a text document to be printed out later, or an XML document for transfer to some other part of the world. For a very small set of data that is not updated very often, the overhead of something as complex as a database might be excessive.

If you have more than a small set of static data, a flat file implementation might be too costly. If the data is going to be queried, then traversing through a file to search for records to read and/or update data can be very expensive in terms of memory and application time. Also, there is not a natural way to relate the information between different files. Of course you could create some sort of key into another file, but trying to query against multiple flat files would be very inefficient.

If you have to deal with updating or deleting the data in files then you need to deal with ways to control access to the files to avoid locking problems. This is a much more difficult problem than it sounds like. If you lock the whole file so that one user can update a record in that file, you can take a very serious performance hit. Trying to figure out which record in a flat file is going to be updated and locking that one only is not an easy task either.

Sometimes, you may want to store more complex data. For example, you may wish to store the state of your application at a given point in time so that a user can return to the application at some future time and find it in the state in which it was left. In such a scenario, a flat file would be very cosily. You would have to go through all of the active objects that contained any data that needed to be persisted and put it in a format that could be written to disk and then read it back into memory later. This also creates a maintenance problem. Any time that you add new functionality into your classes, you need to ensure that the mechanism that you used to persist the data to disk is updated to reflect those changes.

Object Serialization

To handle the case when you need to store the state of your system, Java has the option of making your objects serializable. Making an object serializable simply means that you want to be able to write the object out over some stream and read it back in later. Examples of streaming are sending the output to a file on your disk or over a network connection to another computer. When you define your classes, you simply have your class implement the java.io.Serializable interface.

Once you have implemented the interface, you are now abstracted away from having to know about how the file I/O is going to work or the format of the files. You do not even need to worry about any changes to the structure of the object since that will all be taken care of for you. If you change the structure of your Java class, because you implemented the serializable interface, Java will take care of ensuring that any new variables and methods are added when the object is written out and that they are repopulated when the object is read in.

Java's object is commonly implemented in distributed programming and is very useful when you wish to store an object's state and then recreate a copy of that object in a different application. Instead of having to make several remote method calls to populate the data in the remote object, you can just stream the remote object over the network to another computer where it can be recreated. However, again, it is only really effective for handling small amounts of data - it is not a good implementation in general for overall persistence.

Relational Databases

The persistence mechanism that we use exclusively in this book is the relational database. A database is really a collection of entities, or objects. These objects control how the data is stored and how it is managed.

In a relational database the basic data storage entity is a table. Each entity will have a specific set of attributes (or properties) that define the sort of data that is stored in that entity. In the diagram below, the attributes of our CustomerAddress table are NAME, ADDRESS, and TEL#. In the relational database we refer to these attributes as columns or fields. If we take our object analogy further, then each instance of our entity will have identical attributes but will be uniquely characterized by the values of these attributes. In the database, an instance of our object is analogous to a row, or record, in the table. The following diagram illustrates a table and its associated nomenclature...