 |
|
|
|
 |
|
Object Relational
Interactions with Oracle |
|
|
The Oracle database features strongly as a relational database management system (RDBMS), but
what is sometimes overlooked is its strength and support of object-relational capabilities. In its
traditional RDBMS role, the database focuses on efficient storage and management of data based
on a scalar set of data types. The object-relational (OR) capability extends the relational model to
provide persistence features that integrate extensible types and operations natively into the database.
This chapter first introduces the difference between object database management systems (ODBMSs)
and relational database management systems. With that backdrop we introduce how an object-relational
database (ORDBM) bridges the gap between the two technologies. We introduce Oracle’s support
for object types in the database and how it relates to Unified Modeling Language (UML) and the
Java programming language.
Rather than recap the basic SQL syntax and access patterns for object types in the database, we refer
you to the application walkthrough in Chapter 9 of the Oracle Database Object Relational Developer’s
Guide—Object Relational Features. Examples in this chapter extend the syntax shown in that guide
and relate that application to the OE sample schema. We focus on showing some of the advanced
capabilities such as the following:
? Programmatic access to oracle objects through Java
? Object views over existing relational data
? Declaring SQL types based on existing Java classes
The chapter also provides an overview of the JPublisher code generation tool.Object Relational
Chapter 18, “Introduction to Java Database Programming,” introduced the issue of impedance mismatch
between an object-oriented (OO) programming language (Java) and using a relational database as a
persistent store. To recap briefly, OO languages allow the definition of complex objects and promote
encapsulation of business logic. Reuse and extensibility is natural in these languages through their
support for inheritance and polymorphism (dynamic method dispatching and substitutability).
The impedance mismatch becomes apparent when trying to map these OO language properties to a
RDBMS, which is merely capable of understanding two-dimensional structures (tables) of scalar data
types (number, char, date). An RDBMS requires additional application services to handle persistence,
query capability, concurrent access, security, and caching of objects as they are materialized from and
stored into relational tables. These services are commonly referred to as persistence services.
Of course, the impedance mismatch is only an issue when you are mapping to a relational database. This
section takes a step back to look at how pure object databases play in this space and how they compare
to a relational database. With that backdrop, we introduce Oracle’s object-relational capability, which
bridges the gap between the two. Object-relational support gives developers the flexibility to build and
deploy appropriate structures in the database for an application.
ODBMS and RDBMS and ORDBMS
An ODBMS doesn’t have to deal with impedance mismatch and persistence services to map the OO
language constructs to the database. This is because it natively stores instances of user-defined objects,
instead of decomposing the objects down to rows and columns. An ODBMS only understands objects
and provides orthogonal persistence, where a developer need not be aware that some objects are persistent
and others are not. Persistence is completely transparent to the developer. The ODBMS solution is
shown in Figure 21-1 (A).Clearly there are benefits here, since a developer enjoys the object-oriented programming model without
having to deal with any persistence issues, implicitly or explicitly. Any modified objects are transparently
flushed to the database as and when required.
Language
ODBMS
(A)
Language
Object/Relational
Access Layer
ORDBMS
(B)
Language
Relational
Access Layer
RDBMS
(C)
488
Chapter 21
There are a number of downsides associated with this approach and ODBMSs in general, primarily:
? There is a lack of standard tools for interoperating with ODBMS, such as standards for connectivity,
online analytical processing, or reporting.
? Most ODBMS implementations are based on an in-memory object tree and are only scalable to
the extent of maximum physical memory available on a machine.
? The long-term viability of pure ODBMS vendors is questionable, given that they have less than
2 percent of the global database market share, with a declining trend.
? Concurrent use and locking is an issue, especially with long-running transactions. This impedes
the scalability of the system with a large user base.
Chapter 18 showed another (more commonly used) set of solutions based on using a persistence framework
as an access layer over a RDBMS; see Figure 21-1 . Three variations of relational access layers were
discussed to address persistence issues: pure JDBC, J2EE Entity Enterprise Java Beans (EJBs), and
OracleAS TopLink. The benefits of using a persistence framework with an RDBMS include the following:
? It is a tried and tested platform, with good tools for monitoring and managing the system.
? It has a track record in performance and scalability to support a large user base.
? It has full and complete ACID support for short- and long-running transactions
However, object purists would claim that the downside of the RDBMS approach is that too much is lost
in the relational access layer and that this layer detracts from the benefits gained by using an OO language.
The third approach, shown in Figure 21-1 (B), is the use of an ORDBMS to narrow the gap between a
native object database and relational database. An ORDBMS provides an avenue to extend the scalar
types in a database to define custom data types reflective of the business domain. Persistence is neither
orthogonal nor transparent with this approach, but there is a smaller gap between the object-oriented
language and underlying data—structures—hence, a simpler mapping layer.
With the advancements in JDBC 3.0 and SQL3, support for ORDBMS is becoming more mainstream and
standardized. With this evolution, vendors such as Oracle have focused on making it simpler and more
productive to use object-relational features. Oracle has a strong object-relational capability in the server
and development tools such as JPublisher (discussed later) and OracleAS TopLink.Introducing Oracle Objects
Oracle has provided native support for custom data types (referred to as object types, SQL types, or just
types) since release 8.1.x. Object types in the database enable developers to better represent the data
structures required for an application and simplify access to them. Object types minimize the objectrelational
impedance mismatch and hence reduce the need for a mapping layer between client-side
objects and the database columns and tables that contain the data.
To illustrate, consider the pure relational implementation for the OE schema purchase order example.
The data for this application is normalized across a number of different tables (orders, order_items,
product_information, etc.). Each table consists of columns based on scalar data types (e.g., date,
489
Object Relational Interactions with Oracle
varchar2). Primary and foreign key constraints are created to provide identity and relationships between
the tables. Business operations are then written in PL/SQL or as Java Stored Procedures against these
tables. So there are plenty of schema objects—but it is not obvious how to visualize, track, and relate the
relationships between these schema objects and the original business operations around a purchase order.
This section walks through an implementation of the purchase order example in an object-relational model.
It shows the basic constructs and how to relate a UML class model into object-type definitions in the database.
The constructs shown are an extension of the Purchase Order sample application from Chapter 9 of the
Oracle Database Object Relational Developer’s Guide—Object Relational Features, which is a part of the standard
Oracle documentation set. Figure 21-2 depicts an object-oriented perspective of this application as a UML
class diagram, the key classes being Customer, Stock (i.e., a catalog item) and Purchase Order (generated
by Customer to purchase one or more Stock items).SapereOnLine |
|
|
|
|
|
|
|
ORACLE
|
|
|
|
|
| |
|
 |
|
|
|
|
