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.
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?
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.
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.
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.
to application design, development, and database
management that differs from traditional approaches.
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
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.
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."
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?