Lecture Notes

Lecture Notes: CS/MIS 43 -- 5/13/03

Object-Oriented Database Processing

Introduction: To apply the precision of relational mathematics to software was a brilliant idea; RDBMS has eliminated the ad hoc, seat-of-your-pants kinds of design decisions from DBMS design, and continues to provide a sound definition for the ways to do things. It has been an enormous advance.

The problem: RDBMS was developed with an eye to "applications of the day". And "the day" was 1970. Typical applications were characterized by:

Uniformity. Large numbers of similarly structured data items, all having the same size.
Fixed-length, small records, in 1NF (atomic fields)

Originally, business databases dealt with numbers and short text elements. DBMSs were designed to probide good performance for this type of data. Just look at the types of data that can be stored and at the commands available to manipulate that data. Because most business applications were transaction-oriented, this focus worked well. Businesses were content to store simple items such as account balances, product numbers, names and dates.

These applications continue to exist. So, what has changed?

In the last few years, computers have been asked to handle increasingly complex types of data, including images, sound, and video. At this point most of these objects are handled as separate files, with individual programs to create and manipulate this type of data. In a sense the industry is back at the program-and-file stage of data storage for these more complex objects. Because relational databases are so good at handling basic data types, it is natural to ask whether databases can also improve the storage, searching, and manipulation of more complex objects.

CAD: Current version of items, relationships among its components, its relationship to other parts, old versions.

CASE: Store source code -- current and earlier versions, data dictionaries, information about relationships of modules, classes, ..., historical information.

Multimedia Databases: Photos, videos, sound, email, ...

OIS: Document creation & maintenance, appointment calendars,

Hypertext Databases:

Such applications motivate us to consider the next step, involving complex data objects. We must determine whether it is possible to create a true object-oriented DBMS. That is, can a DBMS store and manipulate entirely new objects that are defined by the developer? Storing objects is one step; manipulating and searching the objects is more difficult.

Consider fundamental data types such as numbers, text, dates, images, sound, and video. Handling some of these types offers two basic complications:

Many of them require more space; an image might take a few megabytes, and a 10-minute, high-resolution video might well require a few gigabytes. Relational databases have been designed and optimized to handle millions of rows of short pieces of data.

Some kinds of data are not manipulated in traditional ways. Sorting sound clips based on the sounds stored isn't the kind of data manipulation we are accustomed to, and searching a number of images to find those containing a horse requires methods that come from artificial intelligence.

The bottom line is that it is difficult for a database to handle complex objects. Even conceptually, there is no clear answer on what the database system should be able to do with these objects. For now, most systems are content to simply store and retrieve the objects. Most systems provide a data type specifically designed to hold large, undefined chunks of binary data -- we think of the BLOB type in SQL.

So we are motivated to introduce objects into our databases. That being the case, we begin to confront possibilities and challenges. The first challenge is to work inheritance into a typical relational database. As we saw in Chapter 3, the ER model has been extended to include inheritance and class hierarchies (Section 3.1, page 56). We saw in Chapter 4 that the translation into tables was done in one of two or three ways -- either create a single table for the union of all the subclasses of a class (involves many null values) or create separate tables for each class and link them together with the primary key of the base class (Rules 10-12, page 88). Neither of these approaches is entirely satisfactory.

Another challenge of an object model arises from the methods of the classes. While each object has data that are peculiar to it, and will be stored separately, the methods of a class are common to all objects of that class. This leads to issues regarding the storage of these methods. Those issues are magnified when inheritance is involved. How is a method inherited from a base class made accessible to objects of the subclasses?

Object Persistence:

We describe the concept as it relates to objects in databases.
Pointers (references) to in-memory objects need to be transformed into pointers to disk addresses. This is known as swizzling. There are costs involved, and issues as to how and when to perform this operation.

ODBMS Advantages/Disadvantages vis a vis RDBMS

*Advantages*	*Disadvantages*
Integrated with programming language	Requires object-oriented programming
Automatic method storage	Little existing data in object form
User-defined types	Nonexistent (or poor) query and reporting tools.
Complex data readily processed	Limited concurrency control and transaction management
Automatic persistent object IDs	Unproven performance
Single-level memory	Substantial change and learning required

Two Basic Approaches

There have been many attempts to do this; we focus on two, which are resulting in languages called Object Query Language (OQL), and SQL3.

OQL/ODL: attempt to bring the best of SQL into the O-O world. (Section 3.2, Ch 17)

SQL3: attempt to bring the best of O-O into the relational world.

Adherents of the competing camps give different answers to the question, "How important is the relation?"

OQL/ODL say, "Not very". Employ objects of all types, some are sets or bags of structures (relations).

SQL3 say "Still the fundamental data structuring concept". Objects and classes are always contained within a relation.

OQL/ODL: In working with RDMBS, we ordinarily embed SQL calls in a program written in a host language. In O-O, the OQL
calls are "embedded" in persistent versions of O-O languages -- Java, C++, Smalltalk.

The persistent versions of the O-O languages are more tightly coupled with the OQL language.
OQL statements (select - from - where) produce objects as values. It is possible to assign any host-language variable of the proper type a value that is the result of an OQL expression.
Management of and distinction between persistent and transient objects is an issue that needs to be dealt with (by the system).
ODMG-93: Consortium of object database vendors. Produce a equence of interfaces.

SQL3: The Object-Relational approach

The key is to allow complex types -- no more insistence on 1NF.
Types for attributes can be classes
Inheritance can occur at the level of types, or tables
User-written functions can be generated without a host language.

Comparison

SQL3 (ORDBMS):

Commonly used for complex data like multimedia.
Good protection of data from programming errors.
High-level optimization of I/O enhances query performance.
But the declarative language (SQL3) imposes performance penalty for apps running in main memory.

OQL/ODL (OODMBS):

Persistent programming languages perform main memory operations faster.
Provide low-overhead access to persistent data.
More susceptible to data corruption due to programming errors.
Usually, less powerful query capabilities.
Commonly used in CAD.

Final Exam

Wednesday @ 1:15 (A) or Saturday @ 3:30 (B) In Olin 213.

IF there are to be changes between the sections, they must be finalized Thursday in class.