|
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: 03 ADDRESS.
05 STREET-ADDRESS VARCHAR(30).
05 CITY-ADDRESS VARCHAR(30).
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
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
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
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
COUNTER = COUNTER + 1
REM Concatenate the String
N$ = "Mr. Burleson"
S$ = "Hello there, " + N$
END
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
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
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 76443.2751@compuserve.com.
FIGURE 1 --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.
FIGURE 2 --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.
FIGURE 3 --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,
such as PREPARE_INVOICE and COMPUTER_CHARGES. The message PREPARE_INVOICE
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.
|
|
| 
