Object Tables   «Prev  Next»

Lesson 1

Object Relational Database Management Systems

Professional DBAs that have worked with real-world business applications may think, how does the object-relational approach work with modern Oracle?
Oracle8i was an object-relational database management system (ORDBMS), which means that users could define additional kinds of data, specifying both the structure of the data and the ways of operating on the data and use these types within the relational model. This approach added value to the data stored within a database.
User-defined data types make it easier for application developers to work with complex data such as images, audio, and video. Object types store structured business data in its natural form and allow applications to retrieve it that way. For this reason, they work efficiently with applications developed using oject-oriented programming techniques.
The object-relational model allows users to define new sets of data types and models drawn from the object programming languages. This means you can create persistent objects[1] within the database and access them through an API (application programming interface) from C++, Java, and other programming languages. This object-relational approach[2] specifies both the structure of the data and the methods of operating on the data. We will look at the details of defining methods later in the course. In the next lesson, we will begin by explaining the reasons to use Oracle objects.

Work with Your Own Exception Objects

Oracle's implementation of the EXCEPTION datatype has some limitations. An exception consists of an identifier (a name) with which you can associate a number and a message. You can raise the exception, and you can handle it. That is all there is to it.. Consider the way that Java approaches this same situation: all errors derive from a single Exception class. You can extend that class, adding other characteristics about an exception that you want to keep track of (error stack, context-sensitive data, etc.). An object instantiated from an Exception class is like any other kind of object in Java. You certainly can pass it as an argument to a method
PL/SQL does not let you do that with its native exceptions. This fact should not stop you from implementing your own exception object. You can do so with Oracle object types or with a relational table of error information. Regardless of implementation path, the key insight here is to distinguish between an error definition (error code is -1403, name is no data found, cause is "implicit cursor did not find at least one row") and a particular instance of that error (I tried to select a company for this name and did not find any rows.). There is, in other words, just one definition of the NO_DATA_FOUND exception, but there are many different instances or occurrences of that exception.
Oracle does not distinguish between these two representations of an error, but we should and we need to.
Here is an example of a simple exception object hierarchy to demonstrate the point. First, the base object type for all exceptions:
/* File on web: exception.ot */
name VARCHAR2(100),
description VARCHAR2(4000),
help_text VARCHAR2(4000),
recommendation VARCHAR2(4000),
error_stack CLOB,
call_stack CLOB,
created_on DATE,
created_by VARCHAR2(100)

Module objectives

When you have completed this module, you will be able to:
  1. Understand the reasons to use Oracle objects versus relational tables
  2. Understand the different terms for Oracle objects
  3. Describe the Structured Query Language (SQL) techniques that allow you to query object tables
  4. Determine when to use collections and variable size arrays
  5. Determine when to use nested tables in querying
  6. Write SQL to query object tables

[1]Persistent object: An object that is stored or saved. Within Oracle, an object is stored within the database.
[2]Object-relational: The object-relational model allows users to define object types, specifying both the structure of the data and the methods of operating on the data, and to use these datatypes within the relational model.