- The Right Tool at the Right Time
- Types of Databases
- Oracle and Java
This chapter is from the book
This chapter is from the book
This chapter is from the book
Types of Databases
One of Java's chief strengths is that it enforces object-oriented programming. To get a database to work effectively with Java, we have to start with a database that supports objects or, if it doesn't, we must somehow find a way to bridge that gap, translating between Java's objects and whatever the database considers its basic unit of storage. This problem of bridging the gap between object-oriented Java and non-object-oriented databases is often called the mismatched impedance problem.
Object Databases
Considering that such a thing exists, it might seem that the easiest thing to do is to use a database that supports objects directly. That is probably true. In fact, for a while, there was quite a bit of excitement and optimism in the market and in the development community about object databases. A few years ago, the future couldn't have looked brighter for object databases. Unfortunately, for a number of reasons, they have since largely failed in the market except in certain niches, such as embedded databases and multimedia applications.
The main problem with object databases is that they do one thing really well—provide persistence for objects. It is relatively easy to build an object-oriented system using an object database. Unfortunately, the overall performance is not very good; in particular, they are slow in performing ad hoc queries. There is also some question about their ability to scale—that is, the ability to handle large amounts of data and transactions, which is a requirement for large distributed systems, such as popular Web sites.
Object-Relational Databases
Object-relational database are relational databases with object-oriented features added. Among the main characteristics are that the tables can store user- defined datatypes, such as objects; that tables or objects can be nested; and that methods can be associated with the objects in the tables.
Oracle has had object-relational features in its database since release 8. We will explore these features in depth in Chapter 6, "Oracle Object-Relational Features" and its use with Java in Chapter 9, "Advanced JDBC Features." In summary, although it does allow us to model our data as objects within the database, it is still difficult to integrate with a program written in Java. In particular, mapping between Oracle database objects and Java objects is complicated. Oracle database objects support methods, but this is of questionable value, because they are not easily mapped to the Java objects either; this may lead to having similar code in two places, which is certainly not desirable.
Despite these concerns, however, Oracle's object-relational features are useful for developing objects and methods that need to be shared by different applications, especially if those applications are written in different languages.
Relational Databases
Relational database management systems (RDBMSs) are the most popular type of database in the market today. E.F. Codd at IBM established much of the theory behind relational databases in the 1970s. There is an absolute set of criteria that defines a relational database, but because no database product at this writing totally meets it, the following informal description is probably more useful:
Data consists of records stored in tables as rows.
Each record includes a fixed set of fields, with each field corresponding to the columns of the table.
One column must be a primary key—a required and unique value—so each record can be exclusively located.
Views—alternate ways of looking at a table or a set of tables—must include support for inserting, updating, and deleting the appropriate data in the underlying table or tables.
The database must support null—an unknown value not equivalent to zero or a blank.
A high-level relational language—not necessarily, but usually Structured Query Language (SQL)—must be provided to support data definition, data manipulation, and database administration.
Data constraints must be enforced by the database and cannot be bypassed.
RDBMSs are the standard today for a number of simple reasons: They are well studied and well understood. They scale well. Companies such as Oracle have invested extraordinary amounts of time and money in developing versatile, flexible, and powerful products. RDBMSs are so well established that we really need to change the question from, "What is the best way to provide persistence in an object-oriented system?" to "What is the best way to use a relational database to provide persistence for an object-oriented system?" That is, given that relational databases are the industry standard (and for good reasons), what is the best way to bridge the impedance mismatch?
One way to bridge the gap between an object-oriented system and a relational database is to use a mapping layer. (This is covered in Chapter 12, "Object Relational Mapping and Java Data Objects.) Because this layer creates a degree of independence between the database and the rest of the system, it can protect each from the effects of changes in the other. This can improve the maintainability and reusability of the system, both key goals of object-oriented design.