Will Oracle8 Be Universal?

By David Wells

Oracle's commitment to object/relational technology has been largely disparaged. But with Oracle8, the company is trying to bring O/R into the mainstream.

Oracle's marketing for its launch of Oracle8 in June focused on scalability improvements and the product's role in the Network Computing Architecture (NCA). Oracle8, however, also includes a range of significant object/relational functionality -- about which Oracle was uncharacteristically quiet, devoting no more than 20 percent of its publicity efforts.

Some of Oracle's competitors have suggested that the company was attempting to suppress interest in object/relational technology, an effort consistent with rumors that it has little to offer in the area. Detailed evaluation, however, firmly establishes the object/relational credentials of Oracle8. Hopefully for the universal server market, Oracle will begin to make a concerted attempt to sell its object/relational technology into the mainstream, rather than taking the more cautious niche marketing approach of some of its competitors. In general, vendors have failed to convince the market of the merits of this technology. Consequently, most developers--even those of straightforward mainstream information systems--are missing out on some good, practical business benefits.

Oracle's View of O/R
Oracle has been promising users object/relational functionality since 1992. According to the company, the product's five-year evolution was driven by a compromise between market pull and the need to rewrite portions of the system in a sensible order.

Oracle6 included some low-level architectural rewrites for performance improvements (for SMP and MPP parallelism and row-level locking, for example). Oracle7 included modifications--mainly to the top half of the server--that added functionality, such as stored procedures and two-phase commit. Oracle 7.3, released in the first quarter of 1996, was the first version that Oracle chose to call a "universal server" because of its support for better-integrated document search (the ConText Option) and spatial data types (the Spatial Data Option). Now, Oracle8 incorporates major architectural changes, not only for object/relational functionality, but also to improve backup and recovery and introduce new features for very large database (VLDB) scalability.

Oracle's overall strategy is an interesting mix of the conservative and the innovative. The company's pragmatic approach to object/relational technology is relatively conservative, yet NCA (see the sidebar "Where Oracle8 Plugs In") is one of the first really significant commitments to a CORBA-based distributed object technology from a major independent software vendor. Furthermore, Oracle's commitment to using Oracle8 as a repository for its own application-development tools enables better support for design applications than is offered by many competing object/relational databases.

In context, Oracle's strategy appears to be extremely sensible. Oracle R&D has always been market-driven, and little mainstream market pull existed for object/relational technology prior to 1996. As a result, when Informix and IBM started to raise the profile of object/relational technology in mid-1996, by appearances, Oracle was caught flat-footed. Some of the very aggressive statements and advertising copy emanating from the company appeared to encourage this impression; Oracle was, supposedly, attempting to discredit a rival technology it was not in a position to offer. The solid object/ relational technology offered by Oracle8 firmly refutes such a view.

Oracle still believes that the demand for better VLDB scalability is at least as important as that for object/relational technology, and that, although demand for the latter is now growing, low adoption cost is extremely important.

The company has also stated that business logic does not belong solely in the database server, and that many components are more suited to deployment on an application server. The company contrasts this approach with what it regards as the "server-centric" architectures offered by Informix-Universal Server and IBM's DB2 Universal Database.

Object/Relational Extensions
Oracle8's object/relational extensions, with the principal exception of large-object support and INSTEAD-OF triggers, can be licensed separately from the rest of the Oracle8 server as an Object Option. Additional Built-in Data Types. Oracle8 offers four extended-relational data types: extended large object support, offering improved content management; two kinds of collection data types, VARRAYs and nested tables; and an extended data type that implements pointers.

The two kinds of collection data type are provided to provide support for nonscalar domains. VARRAYs allow arrays to be stored in columns; most Oracle8 types, including object types, can be stored in VARRAYs. A number of restrictions on VARRAYs make them unsuitable for some purposes. For example, a maximum size must be declared, and currently VARRAYs and their contents cannot be fully accessed from SQL (although they can be accessed from PL/SQL or application 3GL code).

The other collection type is nested tables. As the name implies, nested tables allow table-valued columns to be stored. Unlike VARRAYs, nested tables are fully accessible from SQL.

The final extended data type implements pointers, which Oracle8 calls REFs. REFs are implemented using Oracle8's system-generated object identifiers, allowing pointers to objects in object tables to be stored and navigated. REFs can be manipulated and navigated from SQL using the REF, DEREF, and VALUE keywords. They also play a major part in the operation of the client object cache, which offers substantial support for pointer-following.

Object Types. Oracle8 object types allow the definition and storage of named record structures, for example:

CREATE TYPE customer_type AS OBJECT (
	name VARCHAR2(20),
	no_of_purchases NUMBER,
	MEMBER FUNCTION get_no_of_purchases RETURN 
		NUMBER);

Object types can contain any Oracle8 types as members, including VARRAYs, nested tables, and other object types. In the early Oracle8 beta releases, Oracle called object types "abstract data types"--the term used in the SQL3 draft standard and academic contexts--but later decided that "object types" is a clearer and more straightforward term. (In fact, Oracle8 object types are a generalization of SQL3's named row types and abstract data types.)

Object types can define methods, which can be implemented in PL/SQL or call 3GL functions. Methods are similar to stored procedures and can be invoked from SQL or PL/SQL to calculate and return information about objects of the type and/or to modify it. Every object type has at least one method: its constructor method, a system-defined function that creates an object of the given type. Special methods can optionally be implemented to change the sort order and comparison operations for the object type, in addition to any general methods that may be appropriate for the type.

Object types can be used in two ways. First, object tables can be defined using an object type to specify the type of table as a whole:

CREATE TABLE customers OF customer_type

In this example, each row in the resulting customer table will contain a customer object, with member attributes as specified by the customer_type declaration (in other words, "name" and "no_of_ purchases"). Oracle8 adds a "hidden" column containing a system-generated, unique object ID for each row/object. This object ID can be used in pointers (REFs) to objects in the table, either from other tables and/or to implement pointers between objects in the table itself. As an option, the object ID can be indexed for faster lookup of REFs.

Second, object types can be used to define the types of columns. In this application, object-type names are used in the place of basic-type names when defining the types of columns in a table, which may either be a regular or object one. The customer_type declared above, for example, could be used to define a structured "customer" column in a regular table. The members of such a "column object" are accessed from SQL using extended dot notation; for example, by SELECT my_table.customer.name.

These two applications of object types--object tables and column objects--correspond to the two possible ways of mapping structured objects to a relational schema. Oracle8 supports both.

Client Object Cache. Oracle8 also provides significant object manipulation facilities for client-side applications. A client object cache has been implemented and can be manipulated using either new Oracle8 Oracle Call Interface (OCI) calls, a C/C++ embedded SQL precompiler (purchased separately), or a planned C++ class library and runtime environment driven by the forthcoming Oracle Object Database Designer (a development of Designer/2000).

Using the OCI-level interface, objects from Oracle8 object tables can be loaded into the cache after using an extended SQL query to retrieve their object IDs and manipulated there. Any changes can then be flushed back to the server. The extended OCI calls also allow applications to "chase" pointers to other objects, which will be paged into the client cache as required. The object cache supports a configurable degree of prefetching into the cache of objects referenced by the base object. This feature is similar to the "object paging" functionality provided by some object database systems.

The precompiler offers a higher-level view of the same functionality designed for mainstream database developers. A more detailed OCI-level interface is more suitable for design-application developers.

Oracle8 also provides an Object Type Translator (OTT), which can generate appropriate C structures to be used with the client object cache by client applications.

Oracle's support for multiversion read consistency extends to cached object data and improves scalability by obviating the need for object-cache clients to impose read locks on the database. Each cache client sees its own private version of the database at the point where it first accessed ("pinned") objects for manipulation.

The client object cache can provide multithreading, with each thread owning its own database session and seeing a private section of the cache corresponding to its own transaction.

Object Views. Oracle8 also provides object views, which are particularly valuable for "test driving" object/relational functionality as well as for retrofitting existing databases without changing the schema. Object views are similar to conventional relational views, except that they can also add strong typing, complex (non�first normal form) structures, methods, and referenceability to existing relational data.

Multitable object views can be made updatable by the provision of a new kind of trigger--an INSTEAD-OF trigger--that will intercept SQL commands to update the view and take appropriate action. INSTEAD-OF triggers can also be used to make any conventional relational view updatable.

Some simple but useful object views are inherently updatable. For example, an object view can make a customer table comprising several columns containing fragments of an address appear as if it contains a single column containing suitably structured "address" column objects. Because such structures are automatically updatable, they can be retrofitted easily to the existing schema.

"Virtual objects" defined by an object view can also be manipulated using the client-side functionality described earlier as if they were "real" objects from object tables. To create suitable object IDs for the virtual objects, object-table definitions must specify an appropriate unique composite key for the object view.

Object views are not exactly equivalent to object tables due to some minor restrictions. It is not, for example, usually possible to store REFs to the virtual objects in object views because such pointers must be constructed using a composite primary key and may be subject to change (unlike system-generated object IDs).

Future Enhancements. Oracle has not yet formally announced either a timeframe or specific functionality for Oracle8.1. Based on Oracle's previous release history, however, it should go to general release in the second half of 1998 with enhancements such as Java support for database-managed functions (stored procedures and methods), explicit support for inheritance between tables, extensibility services for database cartridges. A time-series cartridge is scheduled for availability sometime before the introduction of Oracle8.1.

Evaluating Oracle8 Functionality
Many database buyers are largely uninterested in the object/relational technology race. Thus far, no vendor has explained the benefits of the technology in a way that makes sense to mainstream users. Moreover, the leading relational-database products all offer substantially different features under the same object/relational banner. On what basis should users compare them?

The nature and value of object/relational technology is difficult to communicate because--unlike the relational model--it is not a single, well-formed concept. Rather, the object/relational paradigm is a loosely-related assembly of many individually useful components. In fact, more than 120 aspects of DBMS functionality have been termed "object/relational," from inheritance and polymorphism to large-object support, extensible indexing, and complex object caching and clustering. Some of these aspects are included in the SQL3 standardization effort while others (caching and clustering, for example) are not. The leading products implement substantially different subsets of this functionality.

Given this state of affairs, it's no surprise that many potential users of the technology are confused. Arguments among vendors about which technology pieces are mandatory for "real" object/relational databases have not been helpful.

To clear this confusion and side-step the vendor battles, a model can be used to group features, not in terms of how they're implemented, but by the nature of their value to the database end user. This approach allows products to be compared in terms that address the concerns of real-world users, rather than those of technologists.

Advanced database functionality can (and should) deliver eight dimensions of business value:

1. Next-generation data processing applications--the ability to easily and quickly build database-oriented IT systems that satisfy more of their users' requirements. Features that contribute to this dimension include table-level inheritance, extensible domain handling, SQL3-like row types, and user-defined functions.

2. Content management--the ability to derive value from mixing text, documents, and multimedia information with the structured data in existing IT systems. Features that contribute to this dimension include good large-object support and the ability to search text from SQL queries.

3. Design applications--the more specialized benefits of implementing applications that handle complex data and transactions such as in CAD, CASE, or office automation. These applications are the niche in which pure object-database systems have been most successful. Features contributing to this dimension include support for nontraditional transaction types, object identity, and pointer navigation.

4. Object-oriented integration--the benefit of having a database system that offers better support for the object technology and techniques adopted by users, such as object-oriented programming languages and Object Request Brokers (ORBs)

5. Adaptability--cost reductions and/ or improved productivity gained from database systems that make it easier to modify existing applications when requirements change

6. Manageability--the cost reductions associated with easier management of a database system and its applications. The addition of nontraditional or extended types may, for example, make databases more difficult to manage unless the extensions are well integrated with DBA tools.

7. "Universal" tunability--the value of being able to achieve acceptable performance from database applications across a range of application types and technical architectures through software tuning (rather than by buying more hardware). Relevant features in this dimension include extensible indexing, the ability to easily deploy into different architectural environments, and complex-object caching and clustering.

8. Ease of adoption--the value of being able to take advantage of the new technology without incurring significant costs, retraining staff, or modifying existing applications. In this dimension, SQL-standards conformance and interoperability with legacy databases and applications are significant.

Based on this model, the object/relational functionality offered by the five market-leading database products--Oracle8, Informix-Universal Server, DB2 Universal Database, Sybase Adaptive Server, and Microsoft SQL Server (in conjunction with OLE DB)--can be evaluated. The model can be applied equally well to pure relational or pure object databases and can be used to illustrate the relationship among the different technologies and how they have evolved.

Figure 1 illustrates how this model defines the somewhat elusive universal server concept. Because a universal server may be expected to handle any type of data for any kind of application--as well as provide good manageability, tunability, and so on--an "ideal" universal server should score perfectly in each of these eight dimensions. Based on these criteria, significant progress has been made in the dimensions that are most interesting to mainstream database users. But although the object/relational releases of 1997 have moved significantly closer to the universal-server ideal, there is still considerable room for improvement.

Figure 2 shows the model applied to Oracle8. As the figure illustrates, Oracle8 offers substantial and valuable object/relational functionality, confounding rumors in early 1997 that it would have little to offer in this area. Oracle has responded effectively to the challenges posed by Informix and IBM with their 1996 releases, and Oracle8 will play a major part in bringing object/relational technology to mainstream users.

The Next Step
As illustrated in Figure 2, Oracle8.1 will likely add extensibility support that enables additional tuning options and the development of third-party extensions (cartridges) similar to Informix's DataBlade modules. In the meantime, Oracle has the opportunity to sell practical object/relational technology in the mainstream, potentially outflanking the more niche-oriented marketing of IBM and Informix. It is unfortunate, however, that Oracle (like Informix but unlike IBM) has chosen to offer Oracle8's object/relational functionality as a separately-priced option. This strategy may deny many mainstream IT users the opportunity to experiment with the functionality, and tends to encourage the view that object/relational technology is suitable only for early adopters.

David Wells is a senior consultant at Ovum, an international information technology and telecommunications analyst group with offices in Boston, London, and Melbourne. He has 15 years of IT experience in R&D for advanced DBMS functionality, and is the lead author of Ovum Evaluates: Object/Relational Databases (1997). You an reach David via email at [email protected].