Software Quarterly

Object Technology and Database Management

By C.M. Saracco and Charles J. Bontempo

C.M. Saracco and Charles Bontempo focus on database issues for IBM's Software Solutions Division and are writing a book on database topics. Saracco has hands-on experience with both object and relational database management systems. Bontempo frequently teaches and consults on both subjects.


Object technology has become an area of intense focus in today's software community. Objects are featured at trade shows, discussed at symposiums, and incorporated in commercial software. Vendors of varied products -- including application-development facilities, operating systems, and decision-support tools -- frequently highlight their "object-oriented" features and benefits to customers.

Even vendors of database management systems (DBMSs) emphasize how they're integrating object technology into their products. Nearly every major relational DBMS vendor has announced or shipped some level of "object" support. Moreover, a number of small vendors now offer object DBMSs that are built not on a relational approach but on a C++ or Smalltalk approach, two popular object-oriented programming languages. And some vendors (including IBM) are even bridging the gap between object technology and relational DBMSs by offering class libraries, object "wrappers," and DBMS gateways (which enable different DBMS products to communicate with one another).

That flurry of activity has left many observers confused and wondering just what all the fuss is about. What is object orientation, and why is it important? What benefits might object technology bring to their businesses? And what does object technology mean for their DBMS products?

Object Technology: A Different Approach

Object technology offers an approach to application design, development, and database management that differs from traditional approaches. The object approach, advocates contend, can provide greater flexibility and code reuse, as well as a better way to model "real world" objects and business processes.


Figure 1. Representing letters in
an object-oriented environment.

To grasp why object technology offers this potential requires an understanding of what the technology represents. This involves learning some basic concepts and terms. Doing so often presents a major stumbling block for many people with traditional programming and database backgrounds, because they find the new jargon nearly incomprehensible. But an understanding can be achieved by focusing on a few fundamental issues.

Relating Code and Data

A key goal of object technology is to enable users to associate more meaning with data. In this approach, when users define new classes or types of objects, they specify what these objects should look like (their characteristics) and what services should be associated with them. Thus, a class definition typically consists of not only attributes or data members, but also some code that is called methods or member functions.

Because of this, the "data" portion of an object is never thought of as existing by itself. Instead, the data portion is perceived as surrounded (or encapsulated) by some code (the methods or member functions) that defines the behavior of the object (or the available services). This code helps capture much of the meaning people associate with different types of real world objects.

An example might help. Imagine that someone sends you two files electronically: FILE_1 and FILE_2. At first, the sender tells you only some general characteristics about the files: both were last updated on the same day, are approximately the same length, and contain primarily alphabetical characters along with some numbers and other symbols (such as punctuation or mathematical signs). With this limited information, you might be tempted to treat these files similarly and subject them to the same types of operations.

However, imagine that the sender later tells you that FILE_1 is the text of a report, while FILE_2 is a C language source code program. Knowing these facts you probably would consider these files to be of fundamentally different types and would expect to interact with them very differently. In other words, you would associate different meaning and behavior with these different types of files. It would be reasonable to check FILE_1 for spelling errors, but not FILE_2. Similarly, it would be reasonable to try to compile FILE_2 (with a C compiler), but not FILE_1.

The object approach tries to capture such semantics by closely associating data and code. Both data attributes and behavior (or services) are captured when new types or classes of objects are defined.

More Flexibility

But modeling real-world objects can require more than an ability to capture behavior. Many everyday objects have an inherent structure that may not be easy to represent in the simple rows and columns of a table in a relational database. When defining new classes, object-oriented programmers can use a variety of structures including linked lists, arrays, and sets. Enabling programmers to create their own types or classes provides them with considerable flexibility. This flexibility can be very useful when the real-world objects they are trying to model can't be easily or intuitively represented in a tabular structure.

Again, an example might help. Consider a business letter, which most people wouldn't readily visualize as rows and columns. Figure 1 illustrates how a "letter" class might be represented in an object-oriented environment. The attributes associated with letters might be an addressee (someone's name and address), the date, the body of the letter (a sequence of text paragraphs), and perhaps some enclosures (electronically represented as pointers to other letters). Methods could provide services such as sending, filing, proofreading and printing the letters, as well as computing their length.

Productivity Aids

Code reuse is achieved largely through class hierarchies and inheritance. Hierarchies enable programmers to specialize existing classes based on new information requirements. Subclasses inherit the attributes and methods of their parent class, so programmers need only to write the code that differentiates these subclasses from their parent.


Object technology offers an approach

to application design, development, and database

management that differs from traditional approaches.



Figure 2. Creating a memo
subclass of the letter class.

For example, the letter class previously described might be subclassed to model memos. Although very similar to letters, memos must carry a "classification" because they might contain company confidential material. In addition, company policy might dictate that confidential memos be encrypted before storage, which affects the "file" method. By creating "memo" as a subclass of "letter," a programmer needs only to write the code necessary to capture the additions or changes. The remaining code is inherited (and reused) from the letter class. Figure 2 illustrates this idea.

This brings up another important concept in object technology: overloading, which enables different methods to share the same name. For example, in the sample hierarchy "file" is the name for the method that will store letters (without encryption) and memos (which may be encrypted first, depending on their security classification). By examining the parameters associated with each method (its signature) or the type of object involved, a compiler can determine the correct method to execute. In this way, overloading can help simplify the system for application programmers.

A final point worth mentioning about the object approach is that it attempts to separate an object's interface from its underlying implementation. This is the notion behind encapsulation. Programmers who carefully construct classes can prevent future internal changes (perhaps in a class's underlying structure) from "breaking" existing applications. The methods of the class -- its only interface to the application program -- remain the same, although the internals may change.


Figure 3. Examples of "object"
extensions in relational DBMSs

Bringing Objects to DBMSs

Various vendors have applied many of these object concepts to DBMS products. Several years ago, object databases emerged commercially, building on object-oriented programming languages such as C++ and Smalltalk. Object DBMSs enable programmers to make objects persistent -- that is, continue to exist beyond the application session -- and provide concurrency control and other necessary features. Some object DBMS vendors have announced or shipped gateways between their products and popular relational DBMSs. IBM and Object Design Inc., for example, are jointly developing a gateway between IBM's DB2 and the ObjectStore object DBMS.

Another means of applying object concepts to database management is through application development tools that provide data access. IBM's VisualAge, based on Smalltalk, is one example. VisualAge enables object-oriented programmers to read and write to data stored in DB2 products and other non-IBM DBMSs.

In addition, relational DBMS vendors have begun applying many of these object concepts to their products. As a result, some relational DBMSs -- such as IBM's DB2/6000 and DB2/2 -- offer support for user-defined types, user-defined functions, triggers, event alerters, procedures, and other features, as shown in Figure 3. Since relational DBMSs are widely used and represent a multibillion dollar industry, it's worth exploring this approach further.

Relational Enhancements

While most relational DBMSs initially offered a limited number of predefined data types (such as integer, decimal, and character), many vendors have enriched their data-type systems to support large objects and user-defined types. Large objects -- binary large objects (BLOBs) -- can be useful for storing such unusual data types as image, sound, and compressed video.

User-defined types are a less common addition in today's commercial environment. In some systems, they enable users to create new data types, with specific semantics and behavior, based on system-supplied types. Thus, an EMPLOYEE_NUMBER type could be derived from the INTEGER type, with comparison operations allowed but arithmetic operations prevented -- since adding or dividing two employee numbers wouldn't make sense.

Triggers, event alerters, stored procedures (sometimes called server procedures), and user-defined functions are among today's relational DBMS features that most closely approximate the methods, or member functions, of an object environment. They help promote code reuse and can provide a more flexible overall environment.

Triggers and event alerters are user-written routines that automatically execute when a given database event occurs, such as an update to a table. Triggers enforce site-specific business policies, providing an additional integrity mechanism. To do so, triggers may consult or update other tables in the DBMS. That's done automatically and is transparent to the user.

Event alerters are similar to triggers and in some systems are a special type of trigger. Instead of affecting internal DBMS activities, alerters can affect external ones. When a certain database event occurs, an alerter could consult or change operating system files, ring a bell, or send an electronic mail message. Thus, whenever more than 10,000 shares of a certain stock were traded, a message could be sent automatically to a broker.

Stored procedures are somewhat like mini-applications. They are a combination of procedural logic statements (such as if-then-else statements and loops) and SQL statements that can simplify repetitive database queries for users. Instead of coding these queries themselves, users can invoke the procedure. Users need not even be aware of what underlying tables are involved or what SQL statements are issued. In client/server environments, stored procedures help reduce network traffic and improve performance.

User-defined functions enable customers to extend SQL to support new functions that may be useful to their businesses. They can also define new behaviors for user-defined types. In some DBMSs, user-defined functions can be overloaded, much as methods in an object environment can be overloaded.

User-defined types, user-defined functions, and large objects can be used synergistically in some systems to support custom structures. For example, a LINE data type could be defined as a 16-byte large object consisting of two pairs of integers that represent the start and end points of the LINE. User-defined functions could be created to understand the internal structure of LINEs, perhaps to compute the length of a single line or return its midpoint.

Other object enhancements may include support for recursive queries -- important for bill-of-materials processing and other applications -- and object-oriented programming languages, such as C++ and Smalltalk. Constraints are sometimes considered an object-oriented feature, as they define the valid range of data values for one or more columns, helping to make the DBMS more "active."

What's Next?

The object approach clearly offers a number of potential benefits that will continue to attract the interest of database users. Vendors of both object and relational DBMSs can be expected to enhance their products over time, as well as improve the connectivity of their systems.

Recognizing the importance of object technology, various organizations are attempting to define standards that will help support application portability and provide necessary services to users of this technology. For example, ANSI/ISO SQL committees are defining standards for many of the relational enhancements discussed earlier. The Object Management Group (OMG) has solicited or approved of many object services relevant to database technology, including persistence, transaction management, and query. And the Object Database Management Group (ODMG) has defined an object model and related programming language bindings designed to promote greater consistency among object DBMSs.

These are important efforts, and they help signal the impact object technology is having on the DBMS industry. Increased flexibility, greater support for complex data structures, and productivity enhancements are likely to be among the areas DBMS vendors will continue to emphasize in the future.

See also:

The Object Of IBM's Attention

Want to Know More?





[SQ] [tell SQ] [get SQ] ["software"]

[ IBM home page | Order | Search | Contact IBM | Help | (C) | (TM) ]