Call now: 252-767-6166  
Oracle Training Oracle Support Development Oracle Apps

 E-mail Us
 Oracle Articles
New Oracle Articles

 Oracle Training
 Oracle Tips

 Oracle Forum
 Class Catalog

 Remote DBA
 Oracle Tuning
 Emergency 911
 RAC Support
 Apps Support
 Oracle Support

 SQL Tuning

 Oracle UNIX
 Oracle Linux
 Remote s
 Remote plans
 Application Server

 Oracle Forms
 Oracle Portal
 App Upgrades
 SQL Server
 Oracle Concepts
 Software Support

 Remote S


 Consulting Staff
 Consulting Prices
 Help Wanted!


 Oracle Posters
 Oracle Books

 Oracle Scripts

Don Burleson Blog 







Donald Burleson
Author's Bio | E-Mail



Sneak Preview

Don Burleson
OTJ, Winter1996

Object-Oriented Primer: An Oracle8 Preview

To prepare you for the upcoming release of Oracle8, this article reviews the principles and practices of object orientation, and provides you with sneak previews of some of Oracle8's planned new object-oriented extensions.

According to the word on the street, Oracle8 is due out in April 1997, although it will probably be released sometime in the second quarter. In preparation for this release of Oracle's latest relational database, which will have object-oriented extensions, this article provides you with a review of the principles and practices of object orientation and a look at some of the object-oriented features scheduled to ship with Oracle8.

The Object Layer

Rather than rebuild the Oracle engine as an object-oriented architecture, Oracle has decided to keep the base relational engine and add object functionality on top of the standard relational architecture. While claiming to be an active member in the Object Management Group (OMG), Oracle has departed from the OMG's standard for "pure" object databases as defined by the Object Data Management Group. Oracle's intent is to provide a generic relational database while extending the architecture to allow for objects. The object layer of Oracle8 offers the following features: abstract data typing, definition of aggregate objects, coupling of data and behavior, abstraction, inheritance, polymorphism, encapsulation, and extensibility.

Abstract Data Typing (ADTs)

Rather than being constrained by the basic relational data types of INT VARCHAR and FLOAT, Oracle8 allows the definition of data types that may be composed of many subtypes. For example, the following data definition could be implemented in Oracle8 as an address data type:


  05 ZIP-CODE        NUMBER(5).

This way, you can define and address aggregate data types in a table definition just like any other relational data type. The following example shows the phone_nbr and address data types being used in a table definition:

CREATE table Customer (
  cust_name     VARCHAR(40),
  cust_phone    phone_nbr,
  cust_address  address);

In Figure 1, a single data "field" in a table may be a range of values or an entire table. This concept is called "complex" or "unstructured" data typing. You may use this approach to define the domain of values for a specific field in a relational database. This ability to "nest" data tables allows relationship data to be incorporated directly into the table structure. For example, the Occupations field in the table establishes a one-to-many relationship between an employee and his or her valid occupations. Also, note the ability to nest the entire Skills table within a single field. In this example, only valid skills may reside in the Skills field, which implements the relational concept of "domain integrity."

Definition of Aggregate Objects

In Oracle8, you can define and optionally preassemble aggregate objects. For example, a report_card may be defined for a university database. The report_card object may be defined such that it is assembled at runtime from its atomic components (similar to an Oracle view), or it may be preassembled and stored in the database. These aggregate objects can have methods (stored procedures) attached to them, such that an Oracle object couples data and behavior together.

Coupling of Data and Behavior

The Oracle8 engine allows for the direct coupling of a database entity (a table or object) with a set of predefined behaviors. This way, calls to Oracle are made by specifying an object name and the method that is associated with the object. For example:

customer.add_new("Jones", 123,  

 "other parms");

This call tells Oracle to invoke the add_new procedure that is attached to the customer object, using the supplied parameters. As you might expect, this new way of invoking database calls has important ramifications for Oracle developers and DBAs. For developers, applications will become SQL-less and will consist of calls to stored procedures. Of course, this has the important benefit of making applications portable across platforms, while also making it very easy to find and reuse code. In addition, because each method is encapsulated and tested independently, you can assemble the pretested methods with other methods without unintended side effects.

For DBAs, methods will dramatically change the way that they function. Instead of managing only data and tables, the Oracle8 DBA will also be responsible for managing objects and their associated methods. These new "object administrator" functions will need to be defined so that developers know the functions of all methods and all parameters for each method.


Abstraction within Oracle8 is defined as the conceptual (not concrete) existence of classes within the database. Consider a database that has a class hierarchy that includes classes that do not have objects. A military database may contain the conceptual entities of Division, Battalion, Squadron, and Platoon. The function of this database is to track the platoons, and the entity classes of Division, Battalion, and Squadron may not have associated objects. This is not to say that there is no purpose for abstract classes: When a class is defined, it is associated with behaviors, and these behaviors will be inherited by each object in the Platoon class. From a database perspective, there will be no instances of any objects except Platoon, but higher levels in the class hierarchy will contain behaviors that the Platoon objects inherit.


Inheritance is defined as the ability of a lower-level object to inherit, or access, the data structures and behaviors associated with all classes above it in the class hierarchy. Multiple inheritance refers to the ability of an object to inherit data structures and behaviors from more than one superclass.

To illustrate, Figure 2 shows an application of this system to a vehicle dealership. Occurrences of items to a dealership are VEHICLES, and beneath the VEHICLE class are subclasses for CAR and BOAT. The CAR subclass may be further partitioned into subclasses for VAN and SEDAN. The VEHICLE class contains the data items unique to vehicles, including the vehicle ID and the year of manufacture. The CAR class, because it ISA VEHICLE, inherits the data items of the VEHICLE class. The CAR class might also contain data items such as the number of axles and the gross weight of the vehicle. Each time a subclass is created, it inherits all of the data items and behaviors from the appropriate higher classes. Because the VAN class ISA CAR, which in turn ISA VEHICLE, objects of the VAN class inherit all of the data structures and behaviors relating to the car subclass and VEHICLE class.

It is critical to the understanding of inheritance to note that inheritance happens at different times during the life of an object.

  • Object Creation Inheritance of Data Structures - At object creation time, inheritance is the mechanism whereby the initial data structure for the object is created. Only data structures are inherited, never data.
  • It is a common misconception that data is inherited, such that an order may inherit the data items for the customer that placed an order.
  • Inheritance is used only to create the initial, empty data structures for the object.
  • In the example in Figure 2, all vehicles inherit data definitions in the VEHICLE class, but an object of a lower-level subclass, say SAILBOAT, inherits data structures that only apply to sailboats, such as sail_size.
  • Runtime Inheritance of Methods -Inheritance also occurs at runtime when a call to a method (stored procedure) is made. For example,assume that the following call is made to the SAILBOAT object:
sailboat.compute_rental_charges( );

The database will first search for the compute_rental_charges in the SAILBOAT subclass, and if it is not found, the database will search up the class hierarchy until compute_rental_charges is found.

Not all classes within a generalization hierarchy will have objects associated with them. The object-oriented paradigm allows for abstraction, which means that a class may exist only for the purpose of passing inherited data and behaviors. The classes VEHICLE and CAR probably would not have any associated concrete objects, but objects within the VAN class would inherit from the abstract VEHICLE and CAR classes. Multiple inheritance is also demonstrated by the AMPHIBIOUS_CAR class. Any instances of this class will inherit data and behaviors from both the CAR and the BOAT subclasses.

There is a very big difference between one-to-many relationships and isa relationships. In Figure 2, the entire class hierarchy describes vehicles associated with the ITEM entity in the overall database, and class hierarchies do not imply data relationships between the classes. Although one customer may place many orders, it is not true that one CAR may have many SEDANS.


Polymorphism is the ability of different objects to receive the same message and behave in different ways. This concept has many parallels in the real world. For example, a volcanic eruption may have many different effects on living things in its area. Poisonous gases may kill all air-breathing animals while at the same time nourishing the small marine organisms. The single behavior, ERUPTION, has different effects upon objects within the animal class. Another analogy can be found in the business world. For a personnel manager, the event of PROMOTION will cause different behaviors, depending on the class of EMPLOYEE that receives the PROMOTION. MANAGEMENT objects will receive stock options and country club memberships that are not offered to JANITOR objects.

The concept of polymorphism originally came from the programming concept of "overloading," which refers to the ability of a programming function to perform more than one type of operation, depending upon the context in which the function is used. Consider the following Basic program:

REM  Sample Basic program to show polymorphism

REM  Increment the counter


REM  Concatenate the String

N$ = "Mr. Burleson"

S$ = "Hello there, " + N$


In this example, the operator "+" is used to indicate addition in one context and concatenation in another context. But what determines the way in which the operator will function? Clearly, the Basic compiler knows that the "+" operator means addition when used in the context in which a number is passed as an argument, and it knows that concatenation is required when character strings are passed as an argument to the operator.

Polymorphism implies that you may create a standard interface for a related group of objects. The specific action performed by the object will depend upon the message passed to the interface. Because you are no longer concerned with the internal constructs of the object, you can create extremely complex programs. To use the object, you only need to understand the interface.

In the real world, polymorphism can be described by looking at standard interfaces. In most PC-based software, the F1 key has a special meaning. Pressing F1 will invoke a context-sensitive help function. These help functions have vastly different methods and different data storage techniques, but the standard interface (F1) is polymorphic, and it invokes different internal mechanisms depending on the type of software.

All communication between objects and their behaviors is accomplished with "messages" that are passed as behaviors. Consider two objects, RUSH_ORDER and COD_ORDER, that belong to the ORDER class. When a message such as PREPARE_INVOICE is called, it may contain sub-behaviors, such as PREPARE_INVOICE and COMPUTE_CHARGES. The message PREPARE_INVOICE directs the system to compute the shipping changes. The message will cause different procedures to be invoked, depending upon whether the receiving object is a RUSH_ORDER object or a COD_ORDER object, even if both are objects within the order class. A rush order would include overnight mail calculations, and the COD order would contain additional computations for the total amount due. This is equivalent to the procedural language code shown in Figure 3.


Encapsulation means that each object within the system has a well-defined interface with distinct borders. In plain English, encapsulation refers to the "localized" variables that may be used within an object behavior and that cannot be referenced outside of that behavior. Encapsulation closely parallels the concept of information hiding. Encapsulation also ensures that all updates to a database are performed by way of the behaviors associated with the database objects.

You can enclose code and data together in a "black box," and these boxes can then function independently of all other objects within the system. From a programming perspective, an object is an encapsulated routine of data and behaviors. Objects may contain "public" variables that are used to handle the interfaces to the object and "private" variables that are known only to the object. Once created, an object is treated as a variable of its own type. For example, an object of class CAR is created as a routine with a data type called CAR, and it is treated as a compound variable by the program.

Encapsulation is used in nondatabase object-oriented applications to ensure that all operations are performed through the programmer-defined interface, and that data will never be modified outside of the application shell. But what about ad hoc queries and updates? It appears that declarative database languages, such as SQL (which allows "external" retrieval and update), do not follow the dictates of encapsulation and are therefore inconsistent with object-oriented database management.

For example, a relational database could be defined to have a behavior called ADD_LINE_ITEM, which checks inventory levels for an item and adds an item to an order only if sufficient stock is available. This behavior ensures that orders are not entered for out-of-stock items. With a language such as SQL, the object-oriented behavior could be bypassed and LINE_ITEM records could be added without regard for inventory levels.

Because encapsulation and SQL are clearly incompatible, encapsulation may be violated in Oracle8 by using ad hoc tools such as SQL*Plus.


Extensibility is the ability of the Oracle8 engine to add new behaviors to an existing application without affecting the existing application shell. This ability is an especially powerful concept that will enable Oracle8 to extend existing classes and will ensure that the introduction of a new object class results in no unintended side effects.

Consider a company that provides payroll services to businesses in many states. Some payroll computations are global (GROSS_PAY = HOURS_WORKED * PAYRATE), and others are specific to a municipality or state. Using Oracle8, an existing object class definition can be extended, such that the new object behaves exactly like its super-class definition, but with whatever exceptions are specified. For example, if New York City instituted a new payroll rule for New York City residents, then the general definition for New York state payroll customers could be extended with a new class definition for New York City payroll customers. The only method that would be attached to this class definition would be the code specific to New York City; all other methods would be inherited from the existing superclasses.

Objects Are in Your Future

Largely as a result of the phenomenal success of object-oriented projects in the scientific industry, there has been an explosive interest in object technology solutions for all types of applications. This interest has lead virtually every relational database vendor to promise object-oriented features in 1997, but it remains to be seen how object orientation will be accepted in the mainstream data-processing marketplace. In addition, nobody has ever agreed exactly what it means to be object oriented, and Oracle's flavor of objects may not be the same as Sybase's and Informix's interpretation of objects.

Regardless, Oracle 8 has firmly embraced object technology, and there can be no doubt that developers and DBA will rapidly begin to take advantage of the object features in 1997. Only then will it become clear if the promises of object technology can be realized for corporate data-processing specialists. As developers become accustomed to using objects and the features of Oracle8, they will be able to create systems that are far easier to maintain and create.

During the 1980s, Don Burleson established himself as an authority on database system architectures while serving on the faculty of several major universities. He is currently a senior DBA for a Fortune 50 company. He is also the author of Managing Distributed Databases (Wiley & Sons, 1995) and the forthcoming Oracle Performance and Tuning (Que, 1996). You can email Don at


 --In this figure, a single data "field" in
a table may be a range of values or an entire table. This concept is called
"complex" or "unstructured" data typing. You can use
this approach to define the domain of the values for a specific field in
a relational database. 


 --This figure illustrates the object-oriented idea
of inheritance. Occurrences of items to a dealership are VEHICLES, and beneath
the VEHICLE class are subclasses for CAR and BOAT. The CAR subclass may
be further partitioned into subclasses for VAN and SEDAN. 


 --An example of polymorphism. This figure contains
two objects, RUSH_ORDER and COD_ORDER, that belong to the ORDER class. When
a message such as PREPARE_INVOICE is called, it may contain sub-behaviors,
directs the system to compute the shipping changes. The message will cause
different procedures to be invoked, depending on whether the receiving object
is a RUSH_ORDER object or a COD_ORDER object. The equivalent procedural
language code is shown at the bottom of this figure.





Burleson is the American Team

Note: This Oracle documentation was created as a support and Oracle training reference for use by our DBA performance tuning consulting professionals.  Feel free to ask questions on our Oracle forum.

Verify experience! Anyone considering using the services of an Oracle support expert should independently investigate their credentials and experience, and not rely on advertisements and self-proclaimed expertise. All legitimate Oracle experts publish their Oracle qualifications.

Errata?  Oracle technology is changing and we strive to update our BC Oracle support information.  If you find an error or have a suggestion for improving our content, we would appreciate your feedback.  Just  e-mail:  

and include the URL for the page.


Burleson Consulting

The Oracle of Database Support

Oracle Performance Tuning

Remote DBA Services


Copyright © 1996 -  2017

All rights reserved by Burleson

Oracle ® is the registered trademark of Oracle Corporation.

Remote Emergency Support provided by Conversational