This TechNote presents working Java code
for accessing two different kinds of databases.
It is entertaining to write applets that do glitzy things on your screen.
But if that's all Java could do,
it wouldn't be worth the effort for an enterprise developer to learn.
Much of the work your code really needs to do
involves accessing information in databases back at the server.
This TechNote discusses three different approaches to database access,
and shows you how to implement two of them using Java.
Sample code and extensive commentary is provided for these two.
If you need to use Java to access a database,
you'll find the basic concepts and some very reusable code right here.
You're welcome to take this code and use it in your own applications.
What is not covered here is how the client applet communicates with a distant server.
This interesting topic will be discussed in its own TechNote.
Three Approaches to Database Access
With much of the world's corporate data residing in Relational Databases,
you'll need to write code that can get into those mountains of information.
Java provides easy access via JDBC (Java DataBase Connectivity).
This is a standard low-level API that lets your applications
access most current or future relational database systems,
without system-specific knowledge.
Although relational databases are conceptually simple,
things don't always fit into rows and columns
as nicely as some of the relational gurus would like to have us think.
The object lattices we build in Java
contain an enormous amount of information in their structure alone.
Converting these complex structures into row/column formats
can range from a minor programming nuisance to a nearly-impossible task.
Object Databases address this problem directly:
if you're programming in objects,
then store and retrieve objects,
and access them by traversing the application's natural object structure.
Java is a fairly powerful programming language.
For many corporate applications, it's overpowered.
If you're doing basic forms that tie into relational databases,
Netscape's JavaScript and LiveWire
can probably handle your task very nicely.
Since this TechNote is specific to Java,
we won't do more than mention them here.
Two Solutions to the Same Problem:
What's the same? What's different?
This TechNote contains two sample applications
that differ mostly in their underlying database mechanisms.
One uses SQL to interact with relational databases.
Almost any RDBMS in existence will work as a back end.
The other uses an object storage engine called
PSE
from Object Design, Inc.
This is the entry point into Object Design's line of ODBMS products.
PSE is free and quite useful;
other ODI products are substantially more powerful.
The material on this page is important to your understanding of the examples.
But if you've already read this page,
you can skip to a detailed discussion of the code now,
and download the compressed source files.
Follow these links to learn more about
Using Java with JDBC and SQL,
and Using Java with PSE.
If you want to keep reading here,
you'll have another opportunity to follow these links later.
These two database applications are an extension of a simple address book applet,
which illustrates several important techniques of good object programming.
If your interest is confined to database access, continue reading here.
If you also want to understand how the user interface is built
and the reasons for building it this way,
you might want to go look at the
simple example now.
You'll find code and discussion of several classes that are reused here,
and an explanation of the variable naming conventions.
When you look at the user interface for these database example applets,
you'll see that screen design is not emphasized here.
Building pretty screens is a vital part of good software design,
but the level of detail required to do a really nice interface,
even for this elementary example,
would make the database aspects of the code harder to see.
The user interface is simple and adequate, nothing more.
Having said this, however,
these programs demonstrate the reuse of existing large-scale interface components
from the aforementioned address book example.
This is what these applets look like when they're running.
You'll find instructions on how to use them a little farther down the page.
Because we at Netscape don't know who will be reading (and entering) data,
the applet running here only manages the data you enter,
and that data will not persist across invocations.
If you download, compile, and test the code for these examples,
they will look and behave exactly as this one does,
except that the data you enter will persist from one invocation to the next.
Testing was carried out on Netscape 3.01, 4.0PR3, and the JDK1.1 AppletViewer.
The demo on this page works on all of these platforms,
but some features of the compiled standalone examples don't work under 3.01 or 4.0PR3
(bugs in external windows).
Furthermore, the behavior of the TAB key differs;
be sure to press RETURN after every data field entry.
Clearly, this applet performs the four basic functions of SQL:
deleting, inserting, selecting, and updating records from a database.
Some people would call this a CRUD application,
where CRUD stands for Create-Read-Update-Delete,
which means the same thing.
These next two applets are controlled by the first.
If you download the code, compile, and test it,
these subordinate applets appear in separate windows.
How do you use this application?
Enter your name, address, and phone in the three fields of the first applet.
Then press the Insert button.
This adds you to the database and resets the UI
so that you can enter the next record.
Add information on your family and friends, too, just to make it interesting.
The data you enter here never leaves your machine,
so you don't have to worry that everyone you know
will suddenly be on another mailing list.
When you press Select,
the second applet shows you all the data you entered.
If you want to see a subset of the data,
enter a name, address, and/or phone as the basis for a query,
then press Select.
Once again, your results are displayed in the second applet,
where you will see all Persons that match the fields you entered.
This subordinate applet displays a copy of the data in the database,
so changing data in this second applet has no lasting effect.
Changes made to the database will not appear until you Select again.
To change a person's data, enter a name, address, and/or phone in the first applet,
then press Update.
Now look at the third applet.
The constraining data is in the form on the left.
Type in replacement data in the form on the right.
When you press the Update button in the third applet,
any records that match the fields on the left will receive the data on the right.
To delete records, enter a name, address, and/or phone
in the fields of the first applet.
When you press Delete,
any records that match in those fields will be deleted.
Some interesting aspects of these examples
are in the classes Person and DbApplet,
and the interface DbManager.
The Person class used here
was taken from the simple address book example.
The two subclasses of Person,
PsePerson
and SqlPerson,
have special methods that simplify interaction with their underlying databases.
PsePerson has methods to identify and copy the requested objects in a query.
SqlPerson has methods that construct clauses for SQL statements.
If you wondered why Person's instance variables,
representing a Person's name, address, and phone,
were of type Object, instead of String,
you'll see one reason now.
It is much easier to code the PSE example
if a Person can hold something other than a String in those variables.
DbApplet is a good example of an abstract class.
It is a common foundation for both user interface applets in this TechNote.
The differences between the relational and object database applets are minor.
The underlying code in DbApplet does almost all of the work.
The classes SqlApplet
and PseApplet are the concrete classes,
which each contain only three short methods.
Whereas DbApplet shows what you can do with inheritance,
DbManager shows what you can do with interfaces.
One goal of this TechNote is to show two very different database mechanisms
providing the same functionality.
Since the external functionality is the same,
the Java messages sent from the DbApplet instances to the DbManager instances
are the same, also.
But the inner workings of the two kinds of DbManager,
PseManager
and SqlManager, are entirely different,
and there is no functionality to share in a common ancestor class.
Still, because the same messages are used,
we define that as a requirement in the interface DbManager,
which is implemented by SqlManager and PseManager.
Several other interfaces are defined in these examples.
They help us to incorporate new functionality into existing patterns in the code.
Follow these links to learn more about the specifics of
Using Java with JDBC and SQL
and Using Java with PSE.
TN-JAVA-02-9704
- Related Reading:
Any sample code included above is provided for your use on an "AS IS" basis, under the Netscape License Agreement - Terms of Use
