In the last ten years, those of us who spend our lives with computers have probably seen and heard a lot about object-oriented (OO) programming and how it has revolutionized software development. Proponents cite the time-worn analogy with the integrated circuit (IC), which has allowed computer hardware manufacturers to bind together larger and larger reusable units into more and more powerful machines. "If only software people could match the pace of the hardware people," lament the advocates of objects. If we could build systems using reusable "software ICs," programming would be faster and more reliable, and we could address complex problems with relative ease. Detractors argue that, in contrast to relational theory, object approaches have no mathematical foundation, and they also shudder at the thought of turning the average corporate programmer into the rocket scientist needed to code in strangely popular OO languages. How many PL/SQL developers do you know, for example, who can also program in C++? For most of us, one look at the mysteriously juxtaposed punctuation marks gives us the heebie jeebies.
Of course, object orientation is much more than "programming in C++," just as relational databases are much more than "programming in SQL." The application programming language is only the last tool in the life cycle; techniques, methods, and user interfaces can now bear the object-oriented moniker. In fact, many Oracle users have been practicing at least some aspects of object orientation for years using solid engineering design principles, with SQL and PL/SQL as tools. If you model your system using entity-relationship diagrams, you have experience with "entities" that share many characteristics with objects. Not that I date from the Mesozoic era of computing history, but allow me to point out that the idea that programmers can modularize code into reusable fragments, and that data structures can include rich typing systems, predate Smalltalk and Simula, the first object languages.
Maybe you're a true believer in the software IC, or maybe your response is "objects, schmobjects, who needs `em?", or maybe objects haven't even been on your radar screen because you're living with Oracle, and Oracle is, well, a relational database, with only rows and columns. That used to be true. Now with Oracle's objects option, the database can contain not only rows and columns, but also complex data structures which encapsulate both data and behavior.
Because objects may be new to many readers, this chapter will introduce objects concepts and terminology before plunging into the details of the Oracle objects option. First we'll look at the objects option in the context of the relational features of the Oracle server, and give some examples of places where objects can be used. To put the subject in the broader technology context, we'll also step back to look at what it means to be object-oriented, and how Oracle fulfills the object motif. Next, we'll show an extended example of creating and using Oracle objects for a hypothetical pet store, introducing salient points about using objects in a step-by-step fashion. Only then will we take a more in-depth look at the syntax and rules of usage in both PL/SQL and SQL. We'll also present four different technical strategies for applying object approaches in a new application. Finally, we'll look at housekeeping and the unpleasant business of modifying object designs, and conclude with a few words on making your object initiative work.
Although this chapter covers all aspects of using objects in PL/SQL, we don't have space to cover every possible aspect of using objects in the server. Some of the things we don't discuss in detail include: triggers on object tables (since objects do not alter what you already know about triggers from Oracle7); ways of using PL/SQL objects with the Oracle Call Interface (OCI) for C or C++; and some of the physical storage considerations of objects.
When a mainstream vendor like Oracle Corporation ventures into new technology waters, it is virtually certain that the change will be evolutionary rather than revolutionary. True to form, Oracle8's relational capabilities are still the mainstay of Oracle Corporation's flagship database server, and these capabilities satisfy the need for compatibility with older Oracle versions. But with the objects option, Oracle8 allows programmers to use a new set of datatypes and models drawn from object programming languages, allowing persistent objects [ 1 ] to be created in the database and accessed, via an API, from C++, Smalltalk, Object COBOL, Java, and other languages.
Contrast this "object-relational" database approach with the true "object-oriented databases" (OODBs) that first appeared commercially in the mid-1980s. Pure OODBs are most successful in problem domains characterized by complex, often versioned, data (such as engineering, CASE, or CAD); they typically extend the type system of object-oriented languages to allow for persistent objects. Oracle8, on the other hand, extends the programming system of the database to allow for operations, and extends conventional datatypes to include complex structures. While these object extensions to SQL and PL/SQL sometimes look as if they were designed merely to confuse the programmer, object types in Oracle, properly implemented, can be the cornerstone of an overall object strategy. (And at least they don't use alien punctuation!)
The first big hurdle to cross is the nomenclature; object technology in general, and Oracle8 in particular, seem to litter us with terms that seem familiar but aren't. For example, even prior to Oracle8, Oracle did have objects -- that is, tables, indexes, packages, procedures, etc. -- in fact, you can see them all in the USER_OBJECTS view. Now we have something most precisely called object types, which can have object instances , the latter of which are referred to simply as objects. Even more ironically, these objects don't show up in the USER_OBJECTS view (object types do, though). Confused? To keep things straight in this chapter, items you've always seen in USER_OBJECTS I'll call the database objects , and Oracle8 objects I'll call simply objects .
Rather than lob all the new terminology at you in eye-glazing detail, I'll introduce the most important terms first, and present the others as needed. These terms are not strictly from the lexicon of object-oriented purists, but are defined in an Oracle context.
To give you a better sense of how object technology works in Oracle, let's look at some specific code samples that use objects. The following examples use a simple object type, Pet_t. Don't worry too much about what all the syntax means yet; we'll review it in detail later. First, let's define the object type:
CREATE TYPE Pet_t AS OBJECT ( tag_no INTEGER, name VARCHAR2(60), MEMBER FUNCTION set_tag_no (new_tag_no IN INTEGER) RETURN Pet_t );
This object type has two attributes, tag_no and name, and one method, set_tag_no . But the method won't do anything until we create the associated body for the object type:
CREATE TYPE BODY Pet_t AS MEMBER FUNCTION set_tag_no (new_tag_no IN INTEGER) RETURN Pet_t IS the_pet Pet_t := SELF; -- initialize to "current" object BEGIN the_pet.tag_no := new_tag_no; RETURN the_pet; END; END;
Using this object type, here are some code fragments illustrating different applications of the type. Object types can serve as the datatype of any of a number of different entities.
CREATE TABLE pets OF Pet_t; -- Now we can create an object (object instance) of type Pet_t INSERT INTO pets VALUES (Pet_t(23052, 'Mambo'));
An object type can serve as the datatype of a column . The column is then said to contain column objects. Different columns in a table could be of different object types. (The example below also uses Address_t, an object assumed to be already defined. Curiously enough, it contains attributes and methods appropriate to street addresses.)
CREATE TABLE families ( surname VARCHAR2(50), favorite_pet Pet_t, address Address_t);
An object type can serve as the datatype of a local variable . Here, we declare and initialize an object variable in one statement. The initialization uses the automatically available constructor which has the same name as the datatype:
DECLARE my_pet Pet_t := Pet_t(23052, 'Mambo'); ^ ^ ^ | | constructor | type variable
CREATE FUNCTION find_pet (the_tag_no IN NUMBER) RETURN Pet_t IS the_pet Pet_t; CURSOR pet_cur IS SELECT VALUE(p) FROM pets p WHERE tag_no = the_tag_no; BEGIN OPEN pet_cur; FETCH pet_cur INTO the_pet; CLOSE pet_cur; RETURN the_pet; END;
CREATE TYPE homeless_pet_t AS TABLE OF pet_t;
An object type can serve as the datatype of a "field" in a record variable. Nothing terribly exotic here:
In practical terms, object types live inside the Oracle database rather than inside PL/SQL programs. That is, you must issue the SQL DDL statement, CREATE TYPE ... AS OBJECT in order to create a type; only then can you use the type within PL/SQL. Once created, an object type defines an interface to a set of data. There is no good analogy for this behavior in Oracle7. An object type isn't really like a table, since it holds no data, but you can create tables based on the type.
An object type is a bit more like a package that contains only type declarations and functions that operate on those types. This is especially true since the object type, like the package, can have a separate "body" section in which to implement its procedures and functions (methods). There are key differences, though; perhaps most significantly, code in the object type body can only be invoked on a particular object. That is, you cannot call a method unless you also indicate an object instance on which to apply it. In addition, you can't create a table based on a package specification, the way you can create a table from an object type, and object types cannot include constants, exceptions, cursors, or datatypes. Table 18.1 compares the new object features with features of tables and packages.
Whether or not you have a background in the object-oriented world, you might find it useful to review some of the characteristics of objects and how they are implemented in Oracle. This section does not try to present a complete treatment of objects, but only a primer on the core principles.[ 2 ]
In a frequently cited work on the object approach, James Rumbaugh introduces four characteristics of objects: identity, classification, inheritance, and polymorphism.[ 3 ] Using this taxonomy as a starting point, let's dive in.
An object is a "thing," like a pet, or a contract, or a holiday, which is discrete and identifiable, which shares characteristics with other like objects. One of the major thrusts of object orientation is that its approach to modeling and implementing systems relies on an intuitive mapping of the problem space -- the actual pet, for example -- to a programmatic or database representation. The argument goes that the relational world is a bit artificial when it introduces one table to hold a list of animals, and another table to hold a list of vaccinations that the animal has received.
Since each object has identity, each object also has a unique identifier or handle . Even if all the properties of two different objects are identical, each has a different identity. Often, object-oriented programming systems assign invisible arbitrary numbers to serve as handles.
In Oracle8, unique object identifiers are automatically assigned to objects when they are stored as "table objects." It turns out that this identifier is stored in a hidden 16-byte RAW field. This "object identifier," or OID, can be referenced from columns in other tables, much as a primary key can be referenced from a foreign key.
Just as the human observer groups real-world objects into categories, so can the programmer in an object-oriented programming language. Objects are put into categories which share characteristics or properties, as well as legal operations on the category, or methods. In many languages, these categories are called classes . A more generic academic term for a class is an abstract data type or ADT ; in fact, early beta versions of Oracle8 used the term "ADT" rather than "object type."
The actual object, such as the red-haired mutt named Mambo, is known as an instance of a class or object type Dog, in much the same way that a row in a relational table can be described as an instance of a relation.
Although there are few things that object practitioners agree on, one is that any language that claims to be object-oriented must support inheritance . Inheritance allows for hierarchies in which each child has characteristics of its parent . Each level in the type hierarchy has properties which can be shared by those beneath it; lower levels can have their own specialized attributes or functions as well.
As an example, our Dog type might exist as a subtype of a Pet type. So if a Pet has a name, each Dog would have a name, and you would not need to define this property a second time. The Dog type might extend the Pet type by including a dog-specific attribute such as is_house_trained. Note that this hierarchy allows the inheriting of properties and methods; it is not a hierarchy of data, like an Oracle CONNECT BY scheme.
From an object programming standpoint, the bad news is that Oracle 8.0 does not directly support inheritance. You cannot create a user-defined object type as a subtype of another. As a corollary, you cannot reuse method definitions. The good news, though, is that the ANSI and ISO committees working on object-oriented extensions to SQL are forming a position on how inheritance should behave in object-relational databases.[ 4 ] If history is any indicator, Oracle will move quickly to adopt as much of the new standard (known as SQL3), as possible. As we go to press, SQL3 is still a bit fluid, and the Oracle user community still has an opportunity to communicate to Oracle the most important inheritance features from a user perspective. Do we need multiple inheritance? Do we have to have late method binding? If you have an opinion, let Oracle know!
Although inheritance gets much attention in object technologies, it is one of several types of relationships that can be incorporated into an object model or, in some languages, an object implementation. Inheritance is often described as an is-a relationship; that is, a Dog is-a Pet.[ 5 ] Other prominent relationships include aggregation and association. Aggregation occurs where one object is composed, at least in part, of other objects; you could call it a part-of relationship: a Tail is part-of a Dog. Association is a more generic, usually named relationship, indicating some other link between object types, as in a Dog gets examined by a Veterinarian.
While these relationship types are common in object modeling nomenclatures such as the Unified Modeling Language (UML),[ 6 ] relational models rarely categorize them using these names. However, a kind of pseudo-inheritance is available in an entity-relationship (ER) model that uses supertype/subtype entities, which can be transformed into several different physical implementations. Aggregation and association can be represented as named relationships among entities and then transformed into foreign keys. The Oracle objects extension does give us the ability to create relationships using a new kind of pointer called a reference (REF), described later in this chapter.
Polymorphism, by one definition, means that a given operation behaves consistently even when applied to different datatypes. You can implement polymorphism in at least two different ways, even without the Oracle objects option:
The idea here is that a common core of functionality exists across the population of object types; each object knows how to respond to the requests sensibly. The classical form of polymorphism is one in which an object is not of a single type but actually represents many types, all of which are descendants of some common supertype; this behavior in fact exists in PL/SQL's implicit datatype conversions. For example, you can add a real number to an integer using a polymorphic "+" operator.
While object-oriented programming languages have special features to support object identity, classification, inheritance, and polymorphism, software developers can adopt the general themes of object orientation in many languages. These themes[ 7 ] include:
When I first learned about "information hiding," I said to myself, "Why in the world do we want to hide information? Isn't more better?" That was before I had worked on systems from the Jackson Pollock[ 8 ] school of design. Now I can say with conviction that hiding the internals of a software construct, and carefully limiting its public interface, is a good thing. Not only does it make for fewer unnecessary bits competing for attention in my limited biological CPU, it also brings clarity to application design, and keeps other modules from relying on the unsavory details.
One beautiful way that PL/SQL supports information hiding is by separating specifications from bodies and allowing separate recompilation. This separation is available to both packages (since Oracle7) and object types. In addition, package bodies can include "private" local variables, procedures, and functions which cannot be invoked outside the package.
Oracle 8.0.3 does not support private methods inside an object body, but we can hope that such a feature will appear in a future release.
Encapsulation, a sister concept to information hiding, asserts that you can only "get at" an object's contents using predefined functions. The extreme degree of encapsulation asserts that no data can be viewed or modified except through explicitly defined (or inherited) methods. This allows the programmer to retain control of the data, and helps reduce the impact of schema changes. By establishing cleanly defined object interfaces, we can develop decoupled, reusable modules that can be made to fit together gracefully even when future requirements change.
Encapsulation was gracefully achievable as early as Oracle7 using packages. By putting all DML into procedures and functions and requiring applications to use these modules rather than issuing direct INSERT, UPDATE, or DELETE statements, developers can realize enormous long-term benefits. Oracle objects extend the encapsulation options available to programmers to include object methods.
Oracle still allows server-side database triggers on object tables. In one sense, these triggers violate encapsulation because they allow PL/SQL code to modify object contents directly. However, in keeping with Oracle's hybrid object-relational strategy, you can use triggers if they make sense to your application.
The concept of abstraction includes both data abstraction and functional abstraction. An example of abstraction is a purchase order.[ 9 ] With a programming system that allows us to implement abstract datatypes, we can represent a purchase order as a purchase order object, rather than as a parent table, plus a child table of line items, plus a number of applications to manage the tables. In the real world, purchase orders can be created, edited, completed, and destroyed. In our object-oriented program, a single purchase order ADT would be defined using whatever complex data structures are appropriate, and would include methods for each of the corresponding real world operations.
One assumption about abstraction is that dealing with fewer "things" in the program can reduce the likelihood of errors. In addition, only by the practice of abstraction can we possibly build and maintain extremely large, distributed systems.
With the Oracle objects option, the essential structure we use to create an abstraction is the object type. While PL/SQL packages can also implement an ADT, programmers have typically used packages only for the abstraction of complex processing. Objects, on the other hand, are designed to encourage both process abstraction and data abstraction. These abstractions can encompass complex, multi-level structures. For example, an Oracle object may contain other embedded objects, collections (similar to arrays), and references (pointers) to other objects.
In a typical relational application, there is a database schema consisting of a number of possibly normalized tables, plus a body of application code that manipulates the data. During design, analysts model the entity relationship graph separately from the module hierarchy, and this can result in the need for complex cross-reference matrices which can be costly to develop and more challenging to maintain.
In contrast, in an object model, the data and the legal operations on the data are co-located. In an object implementation, attributes and methods are welded into a single reusable part. A good object design means that there are fewer interconnections to deal with, increasing the likelihood of both reusability and adaptability.
Oracle now directly supports this object programming theme, storing data in object attributes (persistent or not), with behavior defined by object methods.
It is common knowledge that changing a database's table design after the applications are built is a risky and expensive proposition. Database professionals have for years known that data structures are more stable than processes. That's why we require large scheduling windows (and expensive support tools) for entity-relationship modeling and database design.
Object programming carries this argument one step further, into the design of applications themselves. A well-designed object application, rather than being a hierarchy of sequential procedures exchanging flow of control, is more akin to a community of objects exchanging messages.
Non-object approaches, by contrast, often emphasize functional decomposition: breaking a problem, and its solution, into a series of processing steps. One problem with this type of approach is that, over time, the processes in the problem space are likely to change, and this will force extensive changes in the application. An object-oriented decomposition of the same problem, if properly designed, would require fewer changes.
Copyright (c) 2000 O'Reilly & Associates. All rights reserved.