Chapter 15
Object-Oriented Extensions in Oracle8

by Matt Larson

In This Chapter

•  Introduction

•  The Basic Elements of an Object

•  Object Ordering

•  Type Versus Instantiation of a Type

•  REFs

•  Nested Tables and VARRAYs

•  Using Base Types

•  Object Views

•  Large Objects

Introduction

The object-oriented design model has been in place for over twenty years. The basic concept is to treat everything as an object. This is similar to how we perceive things. For example, an automobile is seen as one object. We do not see the automobile as a collection of small parts. We see it as a single object that is made of many parts. We also store objects in a completed form. This means that we prefer to keep an object put together during its useful lifetime. Imagine how complicated it would be to go to work in the morning if the car needed to be put together before it could be driven. The relational database management systems act in this fashion. It stores items at the lowest atomic level. When an object is needed in a relational database, it must pull all of the parts from various tables inside the database and put them together. When the object is no longer used, it is thrown away. If the object is ever needed again, it must be fully rebuilt.

The Basic Elements of an Object

An object is typically made of attributes and methods. Attributes will hold the data of the object. They may be null or may hold a certain type of value. Attributes can also be changed to reflect a modification in the overall object. Methods are procedures that perform actions against the attributes. The methods are the same across all objects of the same type. Figure 15.1 shows an example of a product object.

Figure 15.1.  The basic elements of an object.

Many types will have attributes but no methods. This will often be the case when an application is converted from a relational database to an object-oriented database. The application must still handle all of the procedures against the data. The database is used solely as a storage mechanism.

The attributes can consist of standard datatypes such as the following:

•  number

•  varchar2

•  char

•  date

•  long

•  long raw

Attributes can also consist of other user-defined datatypes.

•  first_name

•  address

•  sales_order

The following code is an example of a type without attributes:

CREATE OR REPLACE TYPE student_type

AS OBJECT(

first_name varchar2(200),  --standard database datatype

last_name varchar2(200),  --standard database datatype

major major_type  --user-defined datatype, the creation of this type was

 not shown.

); 

Methods

In object-oriented databases, activity performance against an object can be done through methods. This gives the designer more flexibility and control. In these cases, the data should not be accessed directly; it should only be used through methods. Consider the automobile. The person driving the car uses several methods to control the car. One method could be called StartCar(). The StartCar() method is a simple interface to the complex function of starting a car. The person executing this function is not required to understand the complexity. In fact, the internal procedures of StartCar() are implemented differently on many cars.

Programmers can use methods to provide a simple application program interface (API). Other programmers, who use the methods, also prefer to have the data and processes hidden. This frees other programmers from the details of the function. They only need to learn the interface to fully utilize the method. Methods can actually be implemented at two levels.

•  Database level

•  Application level

Currently, most methods are implemented at the application level. These methods are only usable within one application. This allows a certain amount of database independence. An application using standard SQL can easily switch database vendors. However, two applications must duplicate a method to perform the same function. This redundancy can lead to problems when changes need to be made. Implementing methods at the database level allows reuse of those methods. It also allows better control over the data.

Creating a type with methods is a two-step process. First, the type specification must be created. The specification lists all attributes of the type as well as the declaration of the methods. Second, the type body is created which specifies the code of the methods.

Listing 15.1 illustrates several method concepts:

Listing 15.1. Creating a type with methods.

— This is the specification for the type, it is similar to the way

packages are specified.

CREATE OR REPLACE TYPE product_type

AS OBJECT(

— All attributes for the type are declared in the specification.

product_name varchar2(200),

product_description varchar2(4000),

product_price number,

product_price_date date,

— Functions and procedures are declared here.  The code is stored in

the body of the type.

— If methods are not used, then the body is not necessary

MEMBER PROCEDURE AddProduct (p_product_name varchar2,

 p_product_description varchar2, p_product_price number,

 p_product_price_date date),

MEMBER FUNCTION DaysSincePriceChange

RETURN NUMBER

);

/

CREATE TABLE product_table OF product_type;



CREATE OR REPLACE TYPE BODY product_type AS

 MEMBER PROCEDURE AddProduct

 (p_product_name varchar2, p_product_description varchar2, 

p_product_price number, p_product_price_date date) AS

— This is the body of the AddProduct procedure.

 BEGIN

   insert into product_table values (p_product_name,

p_product_description,p_product_price, p_product_price_date);

 END AddProduct;

MEMBER FUNCTION DaysSincePriceChange

RETURN NUMBER IS

BEGIN

    RETURN sysdate-SELF.product_price_date;

END DaysSincePriceChange;

END;

/