|Oracle9i Application Developer's Guide - Object-Relational Features
Release 1 (9.0.1)
Part Number A88878-01
This chapter describes the advantages and key features of the Oracle9i object-relational model. The chapter contains these topics:
Oracle object types are user-defined data types that make it possible to model complex real-world entities such as customers and purchase orders as unitary entities--"objects"--in the database.
Oracle object technology is a layer of abstraction built on Oracle's relational technology. New object types can be created from any built-in database types and/or any previously created object types, object references, and collection types. Meta-data for user-defined types is stored in a schema that is available to SQL, PL/SQL, Java, and other published interfaces.
Object types and related object-oriented features such as variable-length arrays and nested tables provide higher-level ways to organize and access data in the database. Underneath the object layer, data is still stored in columns and tables, but you are able to work with the data in terms of the real-world entities--customers and purchase orders, for example--that make the data meaningful. Instead of thinking in terms of columns and tables when you query the database, you can simply select a customer. Objects help you see the forest as well as the trees.
Internally, statements about objects are still basically statements about relational tables and columns, and you can continue to work with relational data types and store data in relational tables as before. But now you have the option to take advantage of object-oriented features too. You can begin to use object-oriented features while continuing to work with most of your data relationally, or you can go over to an object-oriented approach entirely. For instance, you can define some object data types and store the objects in columns in relational tables. You can also create object views of existing relational data to represent and access this data according to an object model. Or you can store object data in object tables, where each row is an object.
In general, the object-type model is similar to the class mechanism found in C++ and Java. Like classes, objects make it easier to model complex, real-world business entities and logic, and the reusability of objects makes it possible to develop database applications faster and more efficiently. By natively supporting object types in the database, Oracle enables application developers to directly access the data structures used by their applications. No mapping layer is required between client-side objects and the relational database columns and tables that contain the data. Object abstraction and the encapsulation of object behaviors also make applications easier to understand and maintain.
Below are listed several other specific advantages that objects offer over a purely relational approach.
Database tables contain only data. Objects can include the ability to perform operations that are likely to be needed on that data. Thus a purchase order object might include a method to sum the cost of all the items purchased. Or a customer object might have methods to return the customer's name, reference number, address, or even his buying history and payment pattern. An application can simply call the methods to retrieve the information.
Using object types makes for greater efficiency:
In a relational system, it is awkward to represent complex part-whole relationships. A piston and an engine have the same status in a table for stock items. To represent pistons as parts of engines, you must create complicated schemas of multiple tables with primary key-foreign key relationships. Object types, on the other hand, give you a rich vocabulary for describing part-whole relationships. An object can have other objects as attributes, and the attribute objects can have object attributes too. An entire parts-list hierarchy can be built up in this way from interlocking object types.
Object types let you capture the "thingness" of an entity, that is, the fact that its parts make up a whole. For example, an address may need to contain a number, street, city, state, and zip code. If any of these elements is missing, the address is incomplete. Unlike an address object type, a relational table cannot express that the columns in the table collectively make up an organic whole.
Oracle implements the object-type system as an extension of the relational model. The object-type interface continues to support standard relational database functionality such as queries (
SELECT...FROM...WHERE), fast commits, backup and recovery, scalable connectivity, row-level locking, read consistency, partitioned tables, parallel queries, cluster database, export/import, loader, and so forth. But SQL and various programmatic interfaces to Oracle--including PL/SQL, Java, Oracle Call Interface, Pro*C/C++, OO4O--have been enhanced with new extensions to support objects. The result is an object-relational model, which offers the intuitiveness and economy of an object interface while preserving the high concurrency and throughput of a relational database.
Type inheritance adds to the usefulness of objects by enabling you to create type hierarchies by defining successive levels of increasingly specialized subtypes that derive from a common ancestor object type. Derived subtypes inherit the features of the parent object type but extend the parent type definition. For example, specialized types of customers--a corporate Customer type or a government Customer type--might be derived from a general Customer object type. The specialized types can add new attributes or redefine methods inherited from the parent. The resulting type hierarchy provides a higher level of abstraction for managing the complexity of an application model.
ALTER TYPE statement, you can modify--"evolve"--an existing user-defined type to make the following changes:
Dependencies of a type to be changed are checked using essentially the same validations applied for a
CREATE TYPE statement. If a type or any of its dependent types fails the type validations, the
ALTER TYPE statement rolls back; no new type version is created, and dependent schemna objects remain unchanged.
Metadata for all tables and columns that use an altered type are updated for the new type definition so that data can be stored in them in the new format. Existing data can be converted to the new format either all at once or piecemeal, as it is updated. In either case, data is always presented in the format of the new type definition even if it is still stored in the format of the older one.
In addition to natively storing object data in the server, Oracle allows the creation of an object abstraction over existing relational data through the object view mechanism. You access objects that belong to an object view in the same way that you access row objects in an object table. Oracle materializes view objects of user-defined types from data stored in relational schemas and tables. By using object views, you can develop object-oriented applications without having to modify existing relational database schemas.
Object views also let you exploit the polymorphism that a type hierarchy makes possible. A polymorphic expression can take a value of the expression's declared type or any of that type's subtypes. If you construct a hierarchy of object views that mirrors some or all of the structure of a type hierarchy, you can query any view in the hierarchy to access data at just the level of specialization you are interested in. If you query an object view that has subviews, you can get back polymorphic data--rows for both the type of the view and for its subtypes.
To support the new object-related features, SQL extensions--including new DDL--have been added to create, alter, or drop object types; to store object types in tables; and to create, alter, or drop object views. There are DML and query extensions to support object types, references, and collections.
PL/SQL is Oracle's database programming language that is tightly integrated with SQL. With the addition of user-defined types and other SQL types introduced in Oracle8i, PL/SQL has been enhanced to operate on user-defined types seamlessly. Thus, application developers can use PL/SQL to implement logic and operations on user-defined types that execute in the database server.
Oracle's Java VM is tightly integrated with the RDBMS and supports access to Oracle Objects through object extensions to Java Database Connectivity (JDBC), which provides dynamic SQL, and SQLJ, which provides static SQL. Thus, application developers can use the Java to implement logic and operations on user-defined types that execute in the database server. With Oracle9i, you can now also create SQL types mapped to existing Java classes to provide persistent storage for Java objects.
Database functions, procedures, or member methods of an object type can be implemented in PL/SQL, Java, or C as external procedures. External procedures are best suited for tasks that are more quickly or easily done in a low-level language such as C, which is more efficient at machine-precision calculation. External procedures are always run in a safe mode outside the address space of the RDBMS server. "Generic" external procedures can be written that declare one or more parameters to be of a system-defined generic type. The generic type permits a procedure that uses it to work with data of any built-in or user-defined type.
The Object Type Translator (OTT) provides client-side mappings to object type schemas by using schema information from the Oracle data dictionary to generate header files containing Java classes and C structures and indicators. These generated header files can be used in host-language applications for transparent access to database objects.
Oracle provides an object cache for efficient access to persistent objects stored in the database. Copies of objects can be brought into the object cache. Once the data has been cached in the client, the application can traverse through these at memory speed. Any changes made to objects in the cache can be committed to the database by using the object extensions to Oracle® Call Interface programmatic interfaces.
Oracle Call Interface provides a comprehensive application programming interface for application and tool developers seeking to use the object capabilities of Oracle. Oracle Call Interface provides a run-time environment with functions to connect to an Oracle server, and control transactions that access objects in the server. It allows application developers to access and manipulate objects and their attributes in the client-side object cache either navigationally, by traversing a graph of inter-connected objects, or associatively by specifying the nature of the data through declarative SQL DML. Oracle Call Interface also provides a number of functions for accessing meta-data information at run-time about object types defined in the server. Such a set of functions facilitates dynamic access to the object meta-data and the actual object data stored in the database.
The Oracle Pro*CTM precompiler provides an embedded SQL application programming interface and offers a higher level of abstraction than Oracle Call Interface. Like Oracle Call Interface, the Pro*C precompiler allows application developers to use the Oracle client-side object cache and the Object Type Translator Utility. Pro*C supports the use of "C" bind variables for Oracle9i object types. Furthermore, Pro*C provides new simplified syntax to allocate and free objects of SQL types and access them by either SQL DML, or through the navigational interface. Thus, it provides application developers many benefits, including compile-time type checking of (client-side) bind variables against the schema in the server, automatic mapping of object data in an Oracle9i server to program bind variables in the client, and simple ways to manage and manipulate database objects in the client process.