Application Development Guide

Why Use the DB2 Object Extensions?

One of the most important recent developments in modern programming language technology is object-orientation. Object-orientation is the notion that entities in the application domain can be modeled as independent objects that are related to one another by means of classification. The external behavior and characteristics of objects are externalized whereas the internal implementation details of the object remain hidden. Object-orientation lets you capture the similarities and differences among objects in your application domain and group those objects together into related types. Objects of the same type behave in the same way because they share the same set of type-specific behaviors, reflecting the behavior of your objects in the application domain.

The object extensions of DB2 enable you to realize many of the benefits of object technology while building on the strengths of relational technology. In a relational system, data types are used to describe the data in columns of tables where the instances (or objects) of these data types are stored. Operations on these instances are supported by means of operators or functions that can be invoked anywhere that expressions are allowed.

With the object extensions of DB2, you can incorporate object-oriented (OO) concepts and methodologies into your relational database.

Object-Relational Features of DB2

Some object-relational features that help you model your data in an object-oriented fashion include the following:

Data types for very large objects
The data you may need to model in your system may be very large and complex, such as text, audio, engineering data, or video. The VARCHAR or VARGRAPHIC data types may not be large enough for objects of this size. DB2 provides three data types to store these data objects as strings of up to 2 gigabytes (GB) in size. The three data types are: Binary Large Objects (BLOBs), single-byte Character Large Objects (CLOBs), and Double-Byte Character Large Objects (DBCLOBs).

User-defined data types
User-defined types let you control the semantics of your objects. For example, your application might require a type called "text" or a type called "address". These types do not exist as built-in types. However, with the object-relational features in DB2, you can define these types and use them in your database.

User-defined types can be further classified in the following ways:

Distinct types
Distinct types are based on existing DB2 built-in data types; that is, internally they are the same as built-in types, but you can define the semantics for those types. DB2 also has built-in types for storing and manipulating very large objects. Your distinct type could be based on one of these large object (LOB) data types, which you might want to use for something like an audio or video stream.

Structured types
Structured types are a way to gather together a collection of object attributes under a single type.

User-defined behaviors
You can write your own routines in SQL or an external language to enable DB2 to operate on your objects. There are two types of user-defined routines:

User-defined functions (UDFs)
UDFs are functions that you can define which, like built-in functions or operators, support the manipulation of objects in SQL queries. UDFs can be used to manipulate column values of any type, not just user-defined types.

User-defined methods
Like UDFs, methods define behavior for objects, but they are tightly encapsulated with a particular user-defined structured type.

Index extensions
Index extensions enable you to specify how DB2 indexes structured types and distinct types. To create an index extension, you must issue a CREATE INDEX EXTENSION statement. The CREATE INDEX EXTENSION statement specifies external table functions that convert values of a structured type or distinct type into index keys and define how DB2 searches through those index keys to optimize its performance.

For information on writing table functions, see Writing User-Defined Functions (UDFs) and Methods. For more information on using index extensions to improve the performance of your applications that use structured types and distinct types, refer to the Administration Guide. For more information on the CREATE INDEX EXTENSION statement, refer to the SQL Reference.

Constraints
Constraints are rules that you define that the database enforces. There are four types of constraints:

Unique
Ensures the unique values of a key in a table. Any changes to the columns that compose the unique key are checked for uniqueness.

Referential integrity
Enforces referential constraints on insert, update, and delete operations. It is the state of a database in which all values of all foreign keys are valid.

Table check
Verify that changed data does not violate conditions specified when a table was created or altered.

Triggers
Triggers consist of SQL statements that are associated with a table and are automatically activated when data change operations occur on that table. You can use triggers to support general forms of integrity such as business rules.

For more information about unique constraints, referential integrity, and table check constraints, refer to the Administration Guide. For more information on triggers, refer to Using Triggers in an Active DBMS.

Using object-oriented features in traditional applications
There is an important synergy among the object-oriented features of DB2. The use of the DB2 object-oriented mechanisms is not restricted to the support of object-oriented applications. Just as C++, a popular object-oriented programming language, is used to implement all sorts of non-object-oriented applications, the object-oriented mechanisms provided by DB2 are also very useful to support all kinds of non-object-oriented applications. The object-relational features of DB2 are general-purpose mechanisms that can be used to model any database application. For this reason, these DB2 object extensions offer extensive support for both non-traditional, that is, object-oriented applications, in addition to improving support for traditional ones.

User-defined Distinct Types

Distinct types are based on existing built-in types. For example, you might have distinct types to represent various currencies, such as USDollar and Canadian_Dollar. Both of these types are represented internally (and in your host language program) as the built-in type that you defined these currencies on. For example, if you define both currencies as DECIMAL, they are represented as decimal data types in the system.

Strong typing
Although you can have different distinct types based on the same built-in type, distinct types have the property of strong typing. With this property of strong typing, you cannot directly compare instances of such types with anything other than another instance of that type. This prevents such semantically nonsensical operations such as directly adding USDollar and Canadian_Dollar without first going through a conversion process. You define which types of operations can occur for instances of a distinct type.

Type behavior
How do you define what operations are allowed on instances of USDollar or Canadian_Dollar? Use user-defined functions to define the allowable behaviors for instances of a distinct type. You can do something as simple as allowing instances of USDollar to be added together by registering a function that is really just the built-in addition operation that takes USDollar as input. You do not have to code an application to define this kind of function.

However, you may want to create a more complex function that can take the USDollar type as input and convert that to the Canadian_Dollar type. For more information about user-defined functions, refer to User-Defined Functions (UDFs) and Methods.

You can implement integrity rules by using constraints.

Large objects
The objects you might model with distinct types might be very large. DB2 also has new built-in types for storing and manipulating very large objects. Your distinct type could be based on one of these large object (LOB) data types, which you might want to use for something like audio or video.

Defining Behavior for Objects: User-defined Routines

To define the behavior for your objects, you can use user-defined functions (UDFs) and methods:

User-defined functions
UDFs are functions that you can define which, like built-in functions or operators, support the manipulation of objects in SQL queries. (UDFs can be used to manipulate column values of any type, not just user-defined types.) Thus, instances of user-defined types (distinct or structured) are stored in columns or rows of tables and manipulated by UDFs in SQL queries. For example, you might define a function AREA that takes an instance of the distinct type LENGTH and an instance of the distinct type WIDTH, computes the area, and returns it to the query:
SELECT ID, area(length, width) AS area
FROM Property
WHERE area > 10000;

Methods
Methods, like UDFs, define behavior for objects, but they differ from functions in the following ways:

To invoke a method on a structured type stored in a column, include the name of the structured type (or an expression that resolves to a structured type), followed by the method invocation operator (..), followed by the name of the method. To invoke a method on a scoped reference of a structured type, include the reference to the structured type using the dereference operator (->), followed by the method invocation operator, followed by the name of the method.

For more information about the object-relational features of DB2, refer to:


[ Top of Page | Previous Page | Next Page ]