Considerable academic research on database technology over the past decade has been focused on new, post-relational data models. Just as the relational model provided clear-cut advantages over the earlier hierarchical and network models, the goal of this research was to develop new data models that would overcome some of the disadvantages of the relational model. Much of this research has focused on how to merge the principles of object-oriented programming and design with traditional database characteristics, such as persistent storage and transaction management.
In addition to the academic research, in the early and mid-1990s, some large venture capital investments flowed into a group of startup software companies whose goal was to build a new generation of data management technologies. These companies typically started with the object data structures used by an object-oriented program to manage its in-memory data, and extended them for disk-based storage and multiuser access. Enthusiastic supporters of these object-oriented databases (OODBs) firmly believed that they would mount a serious challenge to the relational model and become the dominant database architecture by the end of the decade. That scenario proved far off the mark, but the object database vendors have had a significant impact on their relational rivals.
1. Object-Oriented Database Characteristics
Unlike the relational data model, where Codd’s 1970 paper provided a clear, mathematical definition of a relational database, there is no single definition of an object-oriented database. However, the core principles embodied in most object- oriented databases include:
- Objects. In an object-oriented database, everything is an object and is manipulated as an object. The tabular, row/column organization of a relational database is replaced by the notion of collections of objects. Generally, a collection of objects is itself an object and can be manipulated in the same way that other objects are manipulated.
- Classes. Object-oriented databases replace the relational notion of atomic data types with a hierarchical notion of classes and subclasses. For example, VEHICLES might be a class of object, and individual members (instances) of that class would include a car, a bicycle, a train, or a boat. The VEHICLES class might include subclasses called CARS and BOATS, representing a more specialized form of vehicle. Similarly, the CARS class might include a subclass called CONVERTIBLES, and so on.
- Inheritance. Objects inherit characteristics from their class and from all of the higher-level classes to which they belong. For example, one of the characteristics of a vehicle might be “number of passengers.” All members of the CARS, BOATS, and CONVERTIBLES classes also have this attribute, because they are subclasses of VEHICLES. The CARS class might also have the attribute “number of doors,” and the CONVERTIBLES class would inherit this attribute. However, the BOATS class would not inherit the attribute.
- Attributes. The characteristics that an object possesses are modeled by its attributes. Examples include the color of an object, or the number of doors that it has, and its English-language name. The attributes are related to the object they describe in roughly the same way that the columns of a table relate to its rows.
- Messages and methods. Objects communicate with one another by sending and receiving When it receives a message, an object responds by executing a method, a program stored within the object that determines how it processes the message. Thus, an object includes a set of behaviors described by its methods. Usually, an object shares many of the same methods with other objects in higher-level classes.
- Encapsulation. The internal structure and data of objects is hidden from the outside world (encapsulated) behind a limited set of well-defined interfaces. The only way to find out about an object, or to act on it, is through its methods, whose functions and behaviors are clearly specified. This makes the object more predictable and limits the opportunities for accidental data corruption.
- Object identity. Objects can be distinguished from one another through unique object identifiers, usually implemented as an abstract pointer known as an object handle. Handles are frequently used to represent relationships among objects; an object points to a related object by storing the object’s handle as one of its data items (attributes).
These principles and techniques make object-oriented databases well suited to applications involving complex data types, such as computer-aided design or compound documents that combine text, graphics, and spreadsheets. The database provides a natural way to represent the hierarchies that occur in complex data. For example, an entire document can be represented as a single object, composed of smaller objects (sections), composed of still smaller objects (paragraphs, graphs, and so on). The class hierarchy allows the database to track the type of each object in the document (paragraphs, charts, illustrations, titles, footnotes, and so on).
Finally, the message mechanism offers natural support for a graphical user interface. The application program can send a “draw yourself” message to each part of the document, asking it to draw itself on the screen. If the user changes the shape of the window displaying the document, the application program can respond by sending a “resize yourself” message to each document part, and so on. Each object in the document bears responsibility for its own display, so new objects can easily be added to the document architecture.
2. Pros and Cons of Object-Oriented Databases
Object-oriented databases have stirred up a storm of controversy in the database community. Proponents claim that object databases are essential to create a proper match between the programming and database data models. They claim that the rigid, fixed, row/column structure of relational tables is a holdover from the punch-card era of data processing with its fixed data fields and record orientation. A more flexible model, where classes of objects can be similar to one another (that is, share certain attributes) but also different from one another is essential, they claim, to effectively model real-world situations.
Another claim is that the multitable joins that are an integral part of the relational data model inherently create database overhead and make relational technology unsuitable for the ever-increasing performance demands of today’s applications. Finally, since objects are well-established as the in-memory data model for modern programs, the proponents claim that the only natural data model is one that transparently extends the in-memory model to permanent, shared, disk-based, multiuser storage.
Opponents of object-oriented databases are just as adamant in their claims that object-oriented databases are unnecessary and offer no real, substantive advantages over the relational model. They claim that the handles of object-oriented databases are nothing more than the embedded database pointers of prerelational hierarchical and network databases, recycled with different names. They point out that, like these earlier database technologies, the object-oriented databases lack the strong underlying mathematical theory that forms the basis of relational databases. The lack of object database standards and the absence of a standardized query language like SQL are reflections of this deficiency, and have prevented the development of vendor- independent tools and applications that have been essential to the development of the database industry.
In response to claims of inferior performance, they point to the use of relational technology in some of the most performance-demanding enterprise applications. They are also careful to draw a distinction between the external relational model of data and the underlying implementation, which may well contain embedded pointers for performance acceleration. Finally, they claim that any mismatch between object- oriented programming and relational databases can be addressed by technologies like JDBC and other object-to-relational interfaces.
3. Objects and the Database Market
In the marketplace, pure object-oriented databases have gained some success in applications with very complex data models and those where the object-oriented model of classes and inheritance closely parallels the real world. However, the object database companies have had real difficulty breaking through into the mainstream. Many have not survived into the first decade of the twenty-first century. The survivors have had a hard time reaching the $100 million annual revenue mark, and achieving sustainable profits, and have experienced significant management changes. In contrast, the largest relational database vendors have continued to experience steady growth. The largest have annual revenues measured in billions of dollars per year, proving that relational database technology clearly continues to dominate the database market today.
Not surprisingly, the object-oriented and relational camps have had a substantial impact on one another. With the slow marketplace acceptance of object-oriented technology, the object-oriented vendors have focused on some of the factors that created the success of the relational generation two decades ago. They have formed standards groups, such as the Object Data Management Group (ODMG), to standardize object-oriented database technology. Several have added relational adapters, with standard interfaces such as ODBC and SQL, as optional layers for relational access to their databases. Several have focused on the international standards process and have worked to put strong object-oriented capabilities into the SQL3 standard. The net result has been a trend toward embracing or coexisting with the relational world, rather than competing with it.
The object-oriented challenge has had a significant impact on the relational mainstream as well. Several features that began as relational capabilities (for example, stored procedures) are now being touted as providing object-oriented advantages (for example, encapsulation). Vendors have also steadily added onto their relational databases selected object-oriented capabilities, such as abstract data types. The resulting object-relational databases provide a hybrid of relational and object capabilities. They stretch the relational model—some would say past the breaking point—to incorporate features such as tables within tables, which model the relationships between object classes.
One of the major vendors, Informix Software, gained its object-relational capabilities by acquisition, buying Illustra Software. Illustra’s object-relational technology was based on the Postgres work at the University of California at Berkeley, a follow-up to the university’s pioneering relational database system, Ingres. The Informix version of the Illustra product was renamed Informix Universal Server. Another of the major vendors, Oracle Corporation, evolved its own mainstream database system to include object-relational technologies. Oracle8, introduced in 1998, embodies several years of intensive Oracle development in this area, and Oracle9 further expanded it.
The object-oriented database vendors and the relational vendors’ response to it have also had a major impact on the SQL standards efforts. The most significant change to the SQL2 standard addressed in the work on SQL3 was the addition of object capabilities. When the SQL3 work was finally approved as the SQL:1999 official standard, the new object-oriented capabilities nearly doubled the size of the SQL language specification in terms of page count. The acquisition and development of object-relational databases by the industry leaders, and the formal adoption of object extensions to SQL, signal the growing synergy between SQL and the world of object technology.
Source: Liang Y. Daniel (2013), Introduction to programming with SQL, Pearson; 3rd edition.