Elmasri R., Navathe S.B. Fundamentals of Database Systems

Подождите немного. Документ загружается.

This page intentionally left blank

353

Object and Object-Relational

Databases

n this chapter, we discuss the features of object-

oriented data models and show how some of these

features have been incorporated in relational database systems. Object-oriented

databases are now referred to as object databases (ODB) (previously called

OODB), and the database systems are referred to as object data management sys-

tems (ODMS) (formerly referred to as ODBMS or OODBMS). Traditional data

models and systems, such as relational, network, and hierarchical, have been quite

successful in developing the database technologies required for many traditional

business database applications. However, they have certain shortcomings when

more complex database applications must be designed and implemented—for

example, databases for engineering design and manufacturing (CAD/CAM and

CIM

), scientific experiments, telecommunications, geographic information sys-

tems, and multimedia.

These newer applications have requirements and character-

istics that differ from those of traditional business applications, such as more

complex structures for stored objects; the need for new data types for storing

images, videos, or large textual items; longer-duration transactions; and the need to

define nonstandard application-specific operations. Object databases were pro-

posed to meet some of the needs of these more complex applications. A key feature

of object databases is the power they give the designer to specify both the structure

of complex objects and the operations that can be applied to these objects.

chapter 11

Multimedia databases must store various types of multimedia objects, such as video, audio, images,

graphics, and documents (see Chapter 26).

Computer-aided design/computer-aided manufacturing and computer-integrated manufacturing.

354 Chapter 11 Object and Object-Relational Databases

Another reason for the creation of object-oriented databases is the vast increase in

the use of object-oriented programming languages for developing software applica-

tions. Databases are fundamental components in many software systems, and tradi-

tional databases are sometimes difficult to use with software applications that are

developed in an object-oriented programming language such as C++ or Java.

Object databases are designed so they can be directly—or seamlessly—integrated

with software that is developed using object-oriented programming languages.

Relational DBMS (RDBMS) vendors have also recognized the need for incorporat-

ing features that were proposed for object databases, and newer versions of rela-

tional systems have incorporated many of these features. This has led to database

systems that are characterized as object-relational or ORDBMSs. The latest version

of the SQL standard (2008) for RDBMSs includes many of these features, which

were originally known as SQL/Object and they have now been merged into the

main SQL specification, known as SQL/Foundation.

Although many experimental prototypes and commercial object-oriented database

systems have been created, they have not found widespread use because of the pop-

ularity of relational and object-relational systems. The experimental prototypes

included the Orion system developed at MCC,

OpenOODB at Texas Instruments,

the Iris system at Hewlett-Packard laboratories, the Ode system at AT&T Bell Labs,

and the ENCORE/ObServer project at Brown University. Commercially available

systems included GemStone Object Server of GemStone Systems, ONTOS DB of

Ontos, Objectivity/DB of Objectivity Inc., Versant Object Database and FastObjects

by Versant Corporation (and Poet), ObjectStore of Object Design, and Ardent

Database of Ardent.

These represent only a partial list of the experimental proto-

types and commercial object-oriented database systems that were created.

As commercial object DBMSs became available, the need for a standard model and

language was recognized. Because the formal procedure for approval of standards

normally takes a number of years, a consortium of object DBMS vendors and users,

called ODMG,

proposed a standard whose current specification is known as the

ODMG 3.0 standard.

Object-oriented databases have adopted many of the concepts that were developed

originally for object-oriented programming languages.

In Section 11.1, we describe

the key concepts utilized in many object database systems and that were later incor-

porated into object-relational systems and the SQL standard. These include object

identity, object structure and type constructors, encapsulation of operations and the

definition of methods as part of class declarations, mechanisms for storing objects in

Microelectronics and Computer Technology Corporation, Austin, Texas.

Now called Lucent Technologies.

Formerly O2 of O2 Technology.

Object Data Management Group.

Similar concepts were also developed in the fields of semantic data modeling and knowledge represen-

tation.

11.1 Overview of Object Database Concepts 355

a database by making them persistent, and type and class hierarchies and inheritance.

Then, in Section 11.2 we see how these concepts have been incorporated into the

latest SQL standards, leading to object-relational databases. Object features were

originally introduced in SQL:1999, and then updated in the latest version

(SQL:2008) of the standard. In Section 11.3, we turn our attention to “pure” object

database standards by presenting features of the object database standard ODMG

3.0 and the object definition language ODL. Section 11.4 presents an overview of

the database design process for object databases. Section 11.5 discusses the object

query language (OQL), which is part of the ODMG 3.0 standard. In Section 11.6,

we discuss programming language bindings, which specify how to extend object-

oriented programming languages to include the features of the object database

standard. Section 11.7 summarizes the chapter. Sections 11.5 and 11.6 may be left

out if a less thorough introduction to object databases is desired.

11.1 Overview of Object Database Concepts

11.1.1 Introduction to Object-Oriented Concepts and Features

The term object-oriented—abbreviated OO or O-O—has its origins in OO pro-

gramming languages, or OOPLs. Today OO concepts are applied in the areas of

databases, software engineering, knowledge bases, artificial intelligence, and com-

puter systems in general. OOPLs have their roots in the SIMULA language, which

was proposed in the late 1960s. The programming language Smalltalk, developed at

Xerox PARC

in the 1970s, was one of the first languages to explicitly incorporate

additional OO concepts, such as message passing and inheritance. It is known as a

pure OO programming language, meaning that it was explicitly designed to be

object-oriented. This contrasts with hybrid OO programming languages, which

incorporate OO concepts into an already existing language. An example of the latter

is C++, which incorporates OO concepts into the popular C programming

language.

An object typically has two components: state (value) and behavior (operations). It

can have a complex data structure as well as specific operations defined by the pro-

grammer.

Objects in an OOPL exist only during program execution; therefore,

they are called transient objects. An OO database can extend the existence of objects

so that they are stored permanently in a database, and hence the objects become

persistent objects that exist beyond program termination and can be retrieved later

and shared by other programs. In other words, OO databases store persistent

objects permanently in secondary storage, and allow the sharing of these objects

among multiple programs and applications. This requires the incorporation of

other well-known features of database management systems, such as indexing

mechanisms to efficiently locate the objects, concurrency control to allow object

Palo Alto Research Center, Palo Alto, California.

Objects have many other characteristics, as we discuss in the rest of this chapter.

356 Chapter 11 Object and Object-Relational Databases

sharing among concurrent programs, and recovery from failures. An OO database

system will typically interface with one or more OO programming languages to

provide persistent and shared object capabilities.

The internal structure of an object in OOPLs includes the specification of instance

variables, which hold the values that define the internal state of the object. An

instance variable is similar to the concept of an attribute in the relational model,

except that instance variables may be encapsulated within the object and thus are

not necessarily visible to external users. Instance variables may also be of arbitrarily

complex data types. Object-oriented systems allow definition of the operations or

functions (behavior) that can be applied to objects of a particular type. In fact, some

OO models insist that all operations a user can apply to an object must be prede-

fined. This forces a complete encapsulation of objects. This rigid approach has been

relaxed in most OO data models for two reasons. First, database users often need to

know the attribute names so they can specify selection conditions on the attributes

to retrieve specific objects. Second, complete encapsulation implies that any simple

retrieval requires a predefined operation, thus making ad hoc queries difficult to

specify on the fly.

To encourage encapsulation, an operation is defined in two parts. The first part,

called the signature or interface of the operation, specifies the operation name and

arguments (or parameters). The second part, called the method or body, specifies the

implementation of the operation, usually written in some general-purpose pro-

gramming language. Operations can be invoked by passing a message to an object,

which includes the operation name and the parameters. The object then executes

the method for that operation. This encapsulation permits modification of the

internal structure of an object, as well as the implementation of its operations, with-

out the need to disturb the external programs that invoke these operations. Hence,

encapsulation provides a form of data and operation independence (see Chapter 2).

Another key concept in OO systems is that of type and class hierarchies and

inheritance. This permits specification of new types or classes that inherit much of

their structure and/or operations from previously defined types or classes. This

makes it easier to develop the data types of a system incrementally, and to reuse

existing type definitions when creating new types of objects.

One problem in early OO database systems involved representing relationships

among objects. The insistence on complete encapsulation in early OO data models

led to the argument that relationships should not be explicitly represented, but

should instead be described by defining appropriate methods that locate related

objects. However, this approach does not work very well for complex databases with

many relationships because it is useful to identify these relationships and make

them visible to users. The ODMG object database standard has recognized this need

and it explicitly represents binary relationships via a pair of inverse references, as we

will describe in Section 11.3.

Another OO concept is operator overloading, which refers to an operation’s ability to

be applied to different types of objects; in such a situation, an operation name may

refer to several distinct implementations, depending on the type of object it is

11.1 Overview of Object Database Concepts 357

applied to. This feature is also called operator polymorphism. For example, an opera-

tion to calculate the area of a geometric object may differ in its method (implemen-

tation), depending on whether the object is of type triangle, circle, or rectangle. This

may require the use of late binding of the operation name to the appropriate

method at runtime, when the type of object to which the operation is applied

becomes known.

In the next several sections, we discuss in some detail the main characteristics of

object databases. Section 11.1.2 discusses object identity; Section 11.1.3 shows how

the types for complex-structured objects are specified via type constructors; Section

11.1.4 discusses encapsulation and persistence; and Section 11.1.5 presents inheri-

tance concepts. Section 11.1.6 discusses some additional OO concepts, and Section

11.1.7 gives a summary of all the OO concepts that we introduced. In Section 11.2,

we show how some of these concepts have been incorporated into the SQL:2008

standard for relational databases. Then in Section 11.3, we show how these concepts

are realized in the ODMG 3.0 object database standard.

11.1.2 Object Identity, and Objects versus Literals

One goal of an ODMS (Object Data Management System) is to maintain a direct

correspondence between real-world and database objects so that objects do not lose

their integrity and identity and can easily be identified and operated upon. Hence,

an ODMS provides a unique identity to each independent object stored in the data-

base. This unique identity is typically implemented via a unique, system-generated

object identifier (OID). The value of an OID is not visible to the external user, but

is used internally by the system to identify each object uniquely and to create and

manage inter-object references. The OID can be assigned to program variables of

the appropriate type when needed.

The main property required of an OID is that it be immutable; that is, the OID

value of a particular object should not change. This preserves the identity of the

real-world object being represented. Hence, an ODMS must have some mechanism

for generating OIDs and preserving the immutability property. It is also desirable

that each OID be used only once; that is, even if an object is removed from the data-

base, its OID should not be assigned to another object. These two properties imply

that the OID should not depend on any attribute values of the object, since the

value of an attribute may be changed or corrected. We can compare this with the

relational model, where each relation must have a primary key attribute whose

value identifies each tuple uniquely. In the relational model, if the value of the pri-

mary key is changed, the tuple will have a new identity, even though it may still rep-

resent the same real-world object. Alternatively, a real-world object may have

different names for key attributes in different relations, making it difficult to ascer-

tain that the keys represent the same real-world object (for example, the object

identifier may be represented as

Emp_id in one relation and as Ssn in another).

It is inappropriate to base the OID on the physical address of the object in storage,

since the physical address can change after a physical reorganization of the database.

However, some early ODMSs have used the physical address as the OID to increase

358 Chapter 11 Object and Object-Relational Databases

the efficiency of object retrieval. If the physical address of the object changes, an

indirect pointer can be placed at the former address, which gives the new physical

location of the object. It is more common to use long integers as OIDs and then to

use some form of hash table to map the OID value to the current physical address of

the object in storage.

Some early OO data models required that everything—from a simple value to a

complex object—was represented as an object; hence, every basic value, such as an

integer, string, or Boolean value, has an OID. This allows two identical basic values

to have different OIDs, which can be useful in some cases. For example, the integer

value 50 can sometimes be used to mean a weight in kilograms and at other times to

mean the age of a person. Then, two basic objects with distinct OIDs could be cre-

ated, but both objects would represent the integer value 50. Although useful as a

theoretical model, this is not very practical, since it leads to the generation of too

many OIDs. Hence, most OO database systems allow for the representation of both

objects and literals (or values). Every object must have an immutable OID, whereas

a literal value has no OID and its value just stands for itself. Thus, a literal value is

typically stored within an object and cannot be referenced from other objects. In

many systems, complex structured literal values can also be created without having

a corresponding OID if needed.

11.1.3 Complex Type Structures for Objects and Literals

Another feature of an ODMS (and ODBs in general) is that objects and literals may

have a type structure of arbitrary complexity in order to contain all of the necessary

information that describes the object or literal. In contrast, in traditional database

systems, information about a complex object is often scattered over many relations

or records, leading to loss of direct correspondence between a real-world object and

its database representation. In ODBs, a complex type may be constructed from

other types by nesting of type constructors. The three most basic constructors are

atom, struct (or tuple), and collection.

1. One type constructor has been called the atom constructor, although this

term is not used in the latest object standard. This includes the basic built-in

data types of the object model, which are similar to the basic types in many

programming languages: integers, strings, floating point numbers, enumer-

ated types, Booleans, and so on. They are called single-valued or atomic

types, since each value of the type is considered an atomic (indivisible) sin-

gle value.

2. A second type constructor is referred to as the struct (or tuple) constructor.

This can create standard structured types, such as the tuples (record types)

in the basic relational model. A structured type is made up of several compo-

nents, and is also sometimes referred to as a compound or composite type.

More accurately, the struct constructor is not considered to be a type, but

rather a type generator, because many different structured types can be cre-

ated. For example, two different structured types that can be created are:

struct Name<FirstName: string, MiddleInitial: char, LastName: string>, and

11.1 Overview of Object Database Concepts 359

struct CollegeDegree<Major: string, Degree: string, Year: date>. To create

complex nested type structures in the object model, the collection type con-

structors are needed, which we discuss next. Notice that the type construc-

tors atom and struct are the only ones available in the original (basic)

relational model.

3. Collection (or multivalued) type constructors include the set(T), list(T),

bag(T), array(T), and dictionary(K,T) type constructors. These allow part

of an object or literal value to include a collection of other objects or values

when needed. These constructors are also considered to be type generators

because many different types can be created. For example, set(string),

set(integer), and set(Employee) are three different types that can be created

from the set type constructor. All the elements in a particular collection value

must be of the same type. For example, all values in a collection of type

set(string) must be string values.

The atom constructor is used to represent all basic atomic values, such as integers,

real numbers, character strings, Booleans, and any other basic data types that the

system supports directly. The tuple constructor can create structured values and

objects of the form <a

, a

, ..., a

>, where each a

is an attribute name

and

each i

is a value or an OID.

The other commonly used constructors are collectively referred to as collection

types, but have individual differences among them. The set constructor will create

objects or literals that are a set of distinct elements {i

, i

, ..., i

}, all of the same type.

The bag constructor (sometimes called a multiset) is similar to a set except that the

elements in a bag need not be distinct. The list constructor will create an ordered list

, i

, ..., i

] of OIDs or values of the same type. A list is similar to a bag except that

the elements in a list are ordered, and hence we can refer to the first, second, or jth

element. The array constructor creates a single-dimensional array of elements of

the same type. The main difference between array and list is that a list can have an

arbitrary number of elements whereas an array typically has a maximum size.

Finally, the dictionary constructor creates a collection of two tuples (K, V), where

the value of a key K can be used to retrieve the corresponding value V.

The main characteristic of a collection type is that its objects or values will be a

collection of objects or values of the same type that may be unordered (such as a set or

a bag) or ordered (such as a list or an array). The tuple type constructor is often

called a structured type, since it corresponds to the struct construct in the C and

C++ programming languages.

An object definition language (ODL)

that incorporates the preceding type con-

structors can be used to define the object types for a particular database application.

In Section 11.3 we will describe the standard ODL of ODMG, but first we introduce

Also called an instance variable name in OO terminology.

This corresponds to the DDL (data definition language) of the database system (see Chapter 2).

360 Chapter 11 Object and Object-Relational Databases

Figure 11.1

Specifying the object

types EMPLOYEE,

DATE, and

DEPARTMENT using

type constructors.

the concepts gradually in this section using a simpler notation. The type construc-

tors can be used to define the data structures for an OO database schema. Figure 11.1

shows how we may declare

EMPLOYEE and DEPARTMENT types.

In Figure 11.1, the attributes that refer to other objects—such as

Dept of EMPLOYEE

or Projects of DEPARTMENT—are basically OIDs that serve as references to other

objects to represent relationships among the objects. For example, the attribute

Dept

of EMPLOYEE is of type DEPARTMENT, and hence is used to refer to a specific

DEPARTMENT object (the DEPARTMENT object where the employee works). The

value of such an attribute would be an OID for a specific

DEPARTMENT object. A

binary relationship can be represented in one direction, or it can have an inverse ref-

erence. The latter representation makes it easy to traverse the relationship in both

directions. For example, in Figure 11.1 the attribute

Employees of DEPARTMENT has

as its value a set of references (that is, a set of OIDs) to objects of type

EMPLOYEE;

these are the employees who work for the

DEPARTMENT. The inverse is the reference

attribute

Dept of EMPLOYEE. We will see in Section 11.3 how the ODMG standard

allows inverses to be explicitly declared as relationship attributes to ensure that

inverse references are consistent.

define type EMPLOYEE

tuple ( Fname: string

;

Minit: char;

Lname: string;

Ssn: string;

Birth_date: DATE;

Address: string;

Sex: char;

Salary: float;

Supervisor: EMPLOYEE;

Dept: DEPARTMENT;

define type DATE

tuple ( Year: integer

;

Month: integer;

Day: integer; );

define type DEPARTMENT

tuple ( Dname: string

;

Dnumber: integer;

Mgr: tuple ( Manager: EMPLOYEE;

Start_date: DATE; );

Locations: set(string);

Employees: set(EMPLOYEE);

Projects: set(PROJECT); );

11.1 Overview of Object Database Concepts 361

11.1.4 Encapsulation of Operations

and Persistence of Objects

Encapsulation of Operations. The concept of encapsulation is one of the main

characteristics of OO languages and systems. It is also related to the concepts of

abstract data types and information hiding in programming languages. In traditional

database models and systems this concept was not applied, since it is customary to

make the structure of database objects visible to users and external programs. In

these traditional models, a number of generic database operations are applicable to

objects of all types. For example, in the relational model, the operations for selecting,

inserting, deleting, and modifying tuples are generic and may be applied to any rela-

tion in the database. The relation and its attributes are visible to users and to exter-

nal programs that access the relation by using these operations. The concepts of

encapsulation is applied to database objects in ODBs by defining the behavior of a

type of object based on the operations that can be externally applied to objects of

that type. Some operations may be used to create (insert) or destroy (delete)

objects; other operations may update the object state; and others may be used to

retrieve parts of the object state or to apply some calculations. Still other operations

may perform a combination of retrieval, calculation, and update. In general, the

implementation of an operation can be specified in a general-purpose programming

language that provides flexibility and power in defining the operations.

The external users of the object are only made aware of the interface of the opera-

tions, which defines the name and arguments (parameters) of each operation. The

implementation is hidden from the external users; it includes the definition of any

hidden internal data structures of the object and the implementation of the opera-

tions that access these structures. The interface part of an operation is sometimes

called the signature, and the operation implementation is sometimes called the

method.

For database applications, the requirement that all objects be completely encapsu-

lated is too stringent. One way to relax this requirement is to divide the structure of

an object into visible and hidden attributes (instance variables). Visible attributes

can be seen by and are directly accessible to the database users and programmers via

the query language. The hidden attributes of an object are completely encapsulated

and can be accessed only through predefined operations. Most ODMSs employ

high-level query languages for accessing visible attributes. In Section 11.5 we will

describe the OQL query language that is proposed as a standard query language for

ODBs.

The term class is often used to refer to a type definition, along with the definitions of

the operations for that type.

Figure 11.2 shows how the type definitions in Figure

11.1 can be extended with operations to define classes. A number of operations are

This definition of class is similar to how it is used in the popular C++ programming language. The

ODMG standard uses the word interface in addition to class (see Section 11.3). In the EER model, the

term class was used to refer to an object type, along with the set of all objects of that type (see

Chapter 8).