An object-oriented approach to software development shifts the focus from building computing procedures that operate on sets of data to modeling business processes. Building software components that model business processes with documented interfaces makes programming more efficient and allows applications to offer more flexible deployment strategies. It also makes applications easier to modify when business conditions change. In addition, because the modeling reflects real business use, application performance may improve as objects are built that don't require excessive manipulation to conform to the real-world behavior of the business processes they represent.
Oracle chose to take an evolutionary approach to object technology by allowing data abstraction, or the creation of such user-defined datatypes as objects and collections as extensions to the Oracle relational database. The Objects and Extensibility features, included with the database since Oracle8i, position Oracle as an object-relational database.
Support of the Java language in Oracle8i and Oracle9i complements this approach. The JVM (formerly JServer) feature is a Java Virtual Machine integrated with the database. It supports the building and running of Java components, as well as Java stored procedures and triggers, in the server.
This section describes the major object-relational features available in Oracle.
Objects created in Oracle are reusable components representing real-world business processes. The objects created using the database Objects and Extensibility features occupy the same role as the table in a standard relational model: the object is a template for the creation of individual "instances" of the object, which take the same role as rows within a table. An object is "instantiated" using Oracle-supplied "constructors" in SQL or PL/SQL.
An object consists of a name, one or more attributes, and methods. Attributes model the structure and state of the real-world entity, while methods model the operations of the entity. Methods are functions or procedures, usually written either in PL/SQL or Java or externally in a language such as C. Methods make up the interface between an object and the outside programming environment. Each method is identified by the name of the object that contains the method and a method name. Each method can have one or more parameters, which are the vehicles for passing data to the method from the calling application.
For example, a purchase order can be represented as an object. Attributes can include a purchase order number, a vendor, a vendor address, a ship-to address, an item number, a quantity, and a price. You can use a method to add an item to the purchase order, delete an item from the purchase order, or return the total amount of the purchase order.
You can store objects as rows in tables or as values in columns. Each row object has a unique object identifier (OID) created by Oracle. Row objects can be referred to from other objects or relational tables. The REF datatype represents such references. For column objects, Oracle adds hidden columns for the object's attributes.
Object views provide a means of creating virtual object tables from data stored in the columns of relational tables in the database. They can also include attributes from other objects. Object views are created by defining an object type, writing a query defining the mapping between data and tables containing attributes for that type, and specifying a unique object identifier. When the data is stored in a relational table, the unique identifier is usually the primary key. This implementation means that you can use object programming techniques without converting existing relational tables to object-relational tables. The trade-off when using this approach is that performance may be less than optimal, because the data representing attributes for an object may reside in several different tables. Hence, it may make sense to convert the relational tables to object tables in the future.
Objects that share the same methods are said to be in the same datatype or class. For example, internal and external purchase orders can be in the same class as purchase orders. Collection types model a number of objects of the same datatype as varying arrays (VARRAYs) if the collection of objects is bounded and ordered or as nested tables if the collection is unbounded and unordered. If a collection has fewer than 4,000 bytes, it is stored as part of the database table; if it is larger, it is stored as a binary large object, or BLOB. Nested table rows are stored in a separate table identified through a hidden NESTED_TABLE_ID by Oracle. Typically, VARRAYs are used when an entire collection is being retrieved and nested tables are used when a collection is being queried, particularly if the collection is large and only a subset is needed.
An application can call object methods through SQL, PL/SQL, Pro*C/C++, Java, OCI, and the Oracle Type Translator (OTT). The OTT provides client-side mappings to object types by generating header files containing C structure declarations and indicators. Developers can tune applications by using a client-side object cache to improve performance.
Inheritance, or the use of one class of objects as the basis for another, more specific class, is one of the most powerful features of object orientation. The child class inherits all the methods and attributes of the parent class and also adds its own methods and attributes to supplement the capabilities of the parent class. The great power of inheritance is that a change in a parent class automatically ripples down to the child classes. Object orientation supports inheritance over many levels of parent, child, and grandchild classes.
Polymorphism describes the ability of a child class to supersede the operation of a parent method by redefining the method on its own. Once a method has been replaced in a child class, subsequent changes to the method in the parent class don't ripple down to the child class or its descendants. In the purchase order example, as shown in Figure 13-1, purchase orders from contracted and noncontracted suppliers inherit the methods and attributes of external purchase orders. However, the procedure for placing the order can exhibit polymorphism because additional approvals may be required for ordering from noncontracted suppliers.
Inheritance and polymorphism were not supported in Oracle8i objects, although the Oracle8i database could act as persistent storage for objects, and an application interface in an object-oriented language such as C++ or Java could add these features to the client-side implementation of objects. Oracle9i added SQL type inheritance to the database, as well as object view hierarchies, type evolution, generic and transient datatypes, function-based indexes for type method functions, and multilevel collections. Oracle Database 10g adds support for remote access to object types.
Several other extensibility features are included in the Objects and Extensibility features. These include:
The ability to create new index types by defining the structure of the index
The ability to store the index data inside or outside the Oracle database
The ability to create user-defined operators for use in standard SQL statements
An interface to the cost-based optimizer to extend support for user-defined object types and indexes
The use of object-relational features is most common today among software developers who are building database extensions. Oracle itself has made use of these features in the creation of many of the database featuresfor example, in the Spatial and interMedia capabilities.
Java has gained wide acceptance as an application language, particularly for building web-based applications, due to its portability and availability on a wide variety of platforms. For Java developers wanting to use the Oracle database as a backend to their applications, Oracle offers support for the two common approaches to accessing the database from a Java program: JDBC and SQLJ. Both of these approaches are based on industry-standard application program interfaces (APIs):
SQLJ
An industry standard typically used when static SQL statements have been embedded into a Java program. SQLJ is similar to other Oracle precompilers in that Java source files are created with calls to the SQLJ runtime (as well as to additional profile files). The Java source code is then compiled, and the application is run with the SQLJ runtime library.
JDBC
Used when the SQL is dynamic, or when a developer wants explicit control over interactions with the database.
SQLJ and JDBC can be mixed in the same program when some SQL is static and other SQL is dynamic.
The Oracle JDBC driver includes the ORACLE.SQL package that contains Java classes representing all the Oracle SQL datatypes. These datatypes include all the numeric types, CHAR, VARCHAR, VARCHAR2, DATE, RAW, ROWID, CLOB, BLOB, BFILE, REF, object types, and collections (VARRAYs or nested tables). This interface allows the use of the Oracle object-relational features (see Section 13.1.1.1) within Java code. Java applets can communicate with the database via the Oracle Net/Net8 protocol (which is separately deployed to the client machines) or in a "thin version" that uses TCP/IP directly.
The thick driver requires the installation of the Oracle Net software on the client machines, while the thin driver doesn't. The Java applet receives additional Java classes that mimic the Oracle Net protocol. Typically, you would install Oracle Net and use the thick driver on middle-tier application servers to communicate with Oracle, because there are relatively few of these servers. The thin driver is more common for browser-based applications, because installing software on the machines with the browsers negates the thin client advantages.
The Oracle JVM in Oracle9i (JServer in Oracle8i) introduced additional component- and object-based development options. Oracle9i and subsequent versions feature a tightly integrated Java Virtual Machine (hence the JVM name) and support for Java stored procedures in the database; these enable component-based development to take place through the use of Enterprise JavaBeans (EJBs) and Common Object Request Broker Architecture (CORBA) objects.
Server-side Java components are referred to as Enterprise JavaBeans, or EJBs, in contrast to client-side reusable interface components, which are referred to as simply JavaBeans. You can deploy EJBs in the database server or with the Oracle Application Server. The tight integration of the Java Virtual Machine in the database makes use of database System Global Area (SGA) memory-management capabilities to provide EJB server scalability beyond what would be expected in most JVM implementations. For example, each client within the JVM requires only about 50-150 KB of memory for session state.
CORBA programmers can develop business logic as CORBA objects and then deploy them in Oracle. However, most organizations are far more likely to have developers with a Java programming background who will program using EJBs. EJBs are programmed at a higher level of abstraction than CORBA objects, so the CORBA level is hidden from the programmer. Furthermore, EJBs are portable across a range of JVMs.
In its initial release, Oracle8i supported the session bean, which is an EJB created by a specific call from the client that usually exists only during a single client/server session. Session beans may be stateless, allowing the EJB server to reuse instances of the bean to service clients, or stateful (i.e., bound to clients directly). Database cache information maintained by stateful session beans is synchronized with the database when transactions occur by using JDBC or SQLJ. Entity Java beans, also known as persistent beans (because they remain in existence through multiple sessions), were not supported in Oracle8i but are supported in Oracle9i and subsequent database JVMs.