1 Introduction to Oracle Objects

Object Types

An object type is a kind of datatype. You can use it in the same ways that you use more familiar datatypes such as NUMBER or VARCHAR2. For example, you can specify an object type as the datatype of a column in a relational table, and you can declare variables of an object type. You use a variable of an object type to contain a value of that object type. A value of an object type is an instance of that type. An object instance is also called an object. Example 1-1 shows how to create a user-defined object type named person_typ.

CREATE TYPE person_typ AS OBJECT (
  idno           NUMBER,
  name           VARCHAR2(30),
  phone          VARCHAR2(20),
  MAP MEMBER FUNCTION get_idno RETURN NUMBER );
/

CREATE TYPE BODY person_typ AS
  MAP MEMBER FUNCTION get_idno RETURN NUMBER IS
  BEGIN
    RETURN idno;
  END;
END;
/

Object types also have some important differences from the more familiar datatypes that are native to a relational database:

• A set of object types does not come ready-made with the database. Instead, you define the specific object types you want by extending built-in types with user-defined ones as shown in Example 1-1.

• Object types are composed of parts, called attributes and methods.

  • Attributes hold the data about an object's features of interest. For example, a student object type might have name, major, and graduation date attributes. An attribute has a declared datatype which can in turn be another object type. Taken together, the attributes of an object instance contain that object's data.

  • Methods are procedures or functions provided to enable applications to perform useful operations on the attributes of the object type. Methods are an optional element of an object type. They define the behavior of objects of that type and determine what (if anything) that type of object can do.

  • Object types are less generic than native datatypes. In fact, this is one of their major virtues. You can define object types to model the actual structure of the real-world entities, such as customers and purchase orders, that application programs deal with. This can make it easier and more intuitive to manage the data for these entities. In this respect object types are like Java and C++ classes.

You can think of an object type as a blueprint or template which defines structure and behavior. An instantiation of the object type creates an object built according to the template. Object types are database schema objects, subject to the same kinds of administrative control as other schema objects.

You can use object types to model the actual structure of real-world objects. Object types enable you to capture the structural interrelationships of objects and their attributes instead of flattening this structure into a two-dimensional, purely relational schema of tables and columns. With object types you can store related pieces of data in a unit along with the behaviors defined for that data. Application code can then retrieve and manipulate these units as objects.

Objects

When you create a variable of an object type, you create an instance of the type and the result is an object. An object has the attributes and methods defined for its type. Because an object instance is a concrete thing, you can assign values to its attributes and call its methods.

You use the CREATE TYPE statement to define object types. In Example 1-1, the CREATE TYPE statement define the object type person_typ.

The indented elements idno, name, and phone in the CREATE TYPE statements are attributes. Each has a datatype declared for it. These are simplified examples and do not show how to specify member methods.

Defining an object type does not allocate any storage. After they are defined, object types can be used in SQL statements in most of the same places you can use types like NUMBER or VARCHAR2.

For example, you might define a relational table to keep track of your contacts:

CREATE TABLE contacts (
  contact         person_typ,
  contact_date    DATE );

INSERT INTO contacts VALUES (
  person_typ (65, 'Vrinda Mills', '1-800-555-4412'), '24 Jun 2003' );

The contacts table is a relational table with an object type as the datatype of one of its columns. Objects that occupy columns of relational tables are called column objects.

Object Methods

Methods are functions or procedures that you can declare in an object type definition to implement behavior that you want objects of that type to perform. For example, a method is declared in Example 1-1 to allow comparisons between person_typ objects.

The general kinds of methods that can be declared in a type definition are:

• Member

• Static

• Constructor

A principal use of methods is to provide access to the data of an object. You can define methods for operations that an application is likely to want to perform on the data so that the application does not have to code these operations itself. To perform the operation, an application calls the appropriate method on the appropriate object.

For example, the following SQL statement uses the get_idno() method to display the Id number of persons in the contacts table:

SELECT c.contact.get_idno() FROM contacts c;

You can also define static methods to compare object instances and to perform operations that do not use any particular object's data but instead are global to an object type.

A constructor method is implicitly defined for every object type, unless this default constructor is over-written with a user-defined constructor. A constructor method is called on a type to construct or create an object instance of the type.

Type Inheritance

Type inheritance adds to the usefulness of objects by enabling you to create type hierarchies by defining successive levels of increasingly specialized subtypes that derive from a common ancestor object type, which is called a supertype of the derived types. Derived subtypes inherit the features of the parent object type but extend the parent type definition. The specialized types can add new attributes or methods, or redefine methods inherited from the parent. The resulting type hierarchy provides a higher level of abstraction for managing the complexity of an application model.

For example, specialized types of persons, such as a student type or a part-time student type with additional attributes or methods, might be derived from a general person object type. See "Inheritance in SQL Object Types".

Type Evolution

Using an ALTER TYPE statement, you can modify, or evolve, an existing user-defined type to make the following changes:

• Add and drop attributes

• Add and drop methods

• Modify a numeric attribute to increase its length, precision, or scale

• Modify a varying length character attribute to increase its length

• Change a type's FINAL and INSTANTIABLE properties

Dependencies of a type to be altered are checked using essentially the same validations applied for a CREATE TYPE statement. If a type or any of its dependent types fails the type validations, the ALTER TYPE statement rolls back.

Metadata for all tables and columns that use an altered type are updated for the new type definition so that data can be stored in them in the new format. Existing data can be converted to the new format either all at once or piecemeal, as it is updated. In either case, data is always presented in the new type definition even if it is still stored in the format of the older one.

Object Tables

An object table is a special kind of table in which each row represents an object. For example, the following statement creates an object table for person_typ objects:

CREATE TABLE person_obj_table OF person_typ;

You can view this table in two ways:

• As a single-column table in which each row is a person_typ object, allowing you to perform object-oriented operations

• As a multi-column table in which each attribute of the object type person_typ; such as idno, name, and phone; occupies a column, allowing you to perform relational operations

For example, you can execute the following instructions:

INSERT INTO person_obj_table VALUES (
       1, 'John Smith', '1-800-555-1212');

SELECT VALUE(p) FROM person_obj_table p
        WHERE p.name = 'John Smith';

The first statement inserts a person_typ object into person_obj_table, treating person_table as a multi-column table. The second selects from person_obj_table as a single-column table, using the VALUE function to return rows as object instances. See "VALUE" for information on the VALUE function

By default, every row object in an object table has an associated logical object identifier (OID) that uniquely identifies it in an object table. In a distributed and replicated environment, the system-generated unique identifier lets Oracle identify objects unambiguously.

Row Objects and Column Objects

Objects that are stored in complete rows in object tables are called row objects. Objects that are stored as columns of a table in a larger row, or are attributes of other objects, are called column objects.

Object Views

An object view is a way to access relational data using object-relational features. It lets you develop object-oriented applications without changing the underlying relational schema.

Oracle allows the creation of an object abstraction over existing relational data through the object view mechanism. You access objects that belong to an object view in the same way that you access row objects in an object table. Oracle also supports materialized view objects of user-defined types from data stored in relational schemas and tables. By using object views, you can develop object-oriented applications without having to modify existing relational database schemas.

Object views also let you exploit the polymorphism that a type hierarchy makes possible. A polymorphic expression can take a value of the expression's declared type or any of that type's subtypes. If you construct a hierarchy of object views that mirrors some or all of the structure of a type hierarchy, you can query any view in the hierarchy to access data at just the level of specialization you are interested in. If you query an object view that has subviews, you can get back polymorphic data—rows for both the type of the view and for its subtypes.

References

A REF is a logical pointer to a row object that is constructed from the object identifier (OID) of the referenced object and is an Oracle built-in datatype. REFs and collections of REFs model associations among objects, particularly many-to-one relationships, thus reducing the need for foreign keys. REFs provide an easy mechanism for navigating between objects. You can use the dot notation to follow the pointers. Oracle does joins for you when needed, and in some cases can avoid doing joins.

You can use a REF to examine or update the object it refers to. You can also use a REF to obtain the object it refers to. You can change a REF so that it points to a different object of the same object type hierarchy or assign it a null value.

The following example illustrates a simple use of a REF.

CREATE TYPE emp_person_typ AS OBJECT (
  name     VARCHAR2(30),
  manager  REF emp_person_typ );
/
CREATE TABLE emp_person_obj_table OF emp_person_typ;

INSERT INTO emp_person_obj_table VALUES (
   emp_person_typ ('John Smith', NULL));
   
INSERT INTO emp_person_obj_table
  SELECT emp_person_typ ('Bob Jones', REF(e))
    FROM emp_person_obj_table e
    WHERE e.name = 'John Smith';

In declaring a column type, collection element, or object type attribute to be a REF, you can constrain it to contain only references to a specified object table. Such a REF is called a scoped REF. Scoped REF types require less storage space and allow more efficient access than unscoped REF types.

The following example shows REF column contact_ref scoped to person_obj_table which is an object table of type person_typ.

CREATE TABLE contacts_ref (
  contact_ref   REF person_typ SCOPE IS person_obj_table,
  contact_date  DATE );

To insert a row in the table, you could issue the following:

INSERT INTO contacts_ref
  SELECT REF(p), '26 Jun 2003'
    FROM person_obj_table p
    WHERE p.idno = 1;

A REF can be scoped to an object table of the declared type (person_typ in the example) or of any subtype of the declared type. If scoped to an object table of a subtype, the REF column is effectively constrained to hold references only to instances of the subtype (and its subtypes, if any) in the table.

It is possible for the object identified by a REF to become unavailable through either deletion of the object or a revoking of privileges. Such a REF is called dangling. Oracle SQL provides a predicate (called IS DANGLING) to allow testing REFs for this condition.

Dangling REFs can be avoided by defining referential integrity constraints. See "Rules for REF Columns and Attributes".

Accessing the object referred to by a REF is called dereferencing the REF. Oracle provides the DEREF operator to do this. Dereferencing a dangling REF returns a null object. For example:

SELECT DEREF(c.contact_ref), c.contact_date FROM contacts_ref c;

Oracle also provides implicit dereferencing of REFs. For example, to access the manager's name for an employee, you can use a SQL expression similar to the following:

SELECT e.name, e.manager.name FROM emp_person_obj_table 
  WHERE e.name = 'Bob Jones';

In the example, e.manager.name follows the pointer from the person's manager, and retrieves the manager's name. Following the REF like this is allowed in SQL, but not in PL/SQL.

You can obtain a REF to a row object by selecting the object from its object table and applying the REF operator. For example, you can obtain a REF to the person with identification number 1 as follows:

DECLARE 
  person_ref REF person_typ;
BEGIN 
  SELECT REF(p) INTO person_ref
    FROM person_obj_table p 
    WHERE p.idno = 1;    
END;/

The query must return exactly one row.

Collections

For modeling multi-valued attributes and many to many relationships, Oracle supports two collection datatypes: varrays and nested tables. Collection types can be used anywhere other datatypes can be used. You can have object attributes of a collection type in addition to columns of a collection type. For example, you might give a purchase order object type a nested table attribute to hold the collection of line items for a given purchase order.

You use the CREATE TYPE statement to define collection types. In Example 1-3, the CREATE TYPE statements define the object types people_typ and dept_persons_typ.

CREATE TYPE people_typ AS TABLE OF person_typ;
/

CREATE TYPE dept_persons_typ AS OBJECT (
  dept_no    CHAR(5),
  dept_name  CHAR(20),
  dept_mgr   person_typ,
  dept_emps  people_typ);
/

In this simplified example, people_typ is a collection type, specifically a nested table type. The dept_persons_typ object type has an attribute people_typ of this type. Each row in the people_typ nested table is an object of type person_typ which was defined in Example 1-1.