Oracle Essentials [Electronic resources] : Oracle Database 10g, 3rd Edition نسخه متنی

13.1 Object-Oriented Development

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.

13.1.1 Object-Relational Features

This section describes the major object-relational features available
in Oracle.

13.1.1.1 Objects 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.

Figure 13-1. Purchase order class hierarchy

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.

13.1.1.2 Other extensibility features

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.

13.1.2 Java's Role

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.

13.1.3 Enterprise JavaBeans

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.