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

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

Figure 11.2

Adding operations to

the definitions of

EMPLOYEE and

DEPARTMENT.

362 Chapter 11 Object and Object-Relational Databases

declared for each class, and the signature (interface) of each operation is included in

the class definition. A method (implementation) for each operation must be defined

elsewhere using a programming language. Typical operations include the object con-

structor operation (often called new), which is used to create a new object, and the

destructor operation, which is used to destroy (delete) an object. A number of object

modifier operations can also be declared to modify the states (values) of various

attributes of an object. Additional operations can retrieve information about the

object.

An operation is typically applied to an object by using the dot notation. For exam-

ple, if

d is a reference to a DEPARTMENT object, we can invoke an operation such as

no_of_emps by writing d.no_of_emps. Similarly, by writing d.destroy_dept, the object

define class EMPLOYEE

type tuple ( Fname: string

;

Minit: char;

Lname: string;

Ssn: string;

Birth_date: DATE;

Address: string;

Sex: char;

Salary: float;

Supervisor: EMPLOYEE;

Dept: DEPARTMENT; );

operations age: integer;

create_emp: EMPLOYEE;

destroy_emp: boolean;

end EMPLOYEE;

define class DEPARTMENT

type tuple ( Dname: string

;

Dnumber: integer;

Mgr: tuple ( Manager: EMPLOYEE;

Start_date: DATE; );

Locations: set (string);

Employees: set (EMPLOYEE);

Projects set(PROJECT); );

operations no_of_emps: integer;

create_dept: DEPARTMENT;

destroy_dept: boolean;

assign_emp(e: EMPLOYEE): boolean;

(* adds an employee to the department *)

remove_emp(e: EMPLOYEE): boolean

;

(* removes an employee from the department *)

end DEPARTMENT

;

11.1 Overview of Object Database Concepts 363

referenced by d is destroyed (deleted). The only exception is the constructor opera-

tion, which returns a reference to a new

DEPARTMENT object. Hence, it is customary

in some OO models to have a default name for the constructor operation that is the

name of the class itself, although this was not used in Figure 11.2.

The dot nota-

tion is also used to refer to attributes of an object—for example, by writing

d.Dnumber or d.Mgr_Start_date.

Specifying Object Persistence via Naming and Reachability. An ODBS is

often closely coupled with an object-oriented programming language (OOPL). The

OOPL is used to specify the method (operation) implementations as well as other

application code. Not all objects are meant to be stored permanently in the data-

base. Transient objects exist in the executing program and disappear once the pro-

gram terminates. Persistent objects are stored in the database and persist after

program termination. The typical mechanisms for making an object persistent are

naming and reachability.

The naming mechanism involves giving an object a unique persistent name within

a particular database. This persistent object name can be given via a specific state-

ment or operation in the program, as shown in Figure 11.3. The named persistent

objects are used as entry points to the database through which users and applica-

tions can start their database access. Obviously, it is not practical to give names to all

objects in a large database that includes thousands of objects, so most objects are

made persistent by using the second mechanism, called reachability. The reachabil-

ity mechanism works by making the object reachable from some other persistent

object. An object B is said to be reachable from an object A if a sequence of refer-

ences in the database lead from object A to object B.

If we first create a named persistent object N, whose state is a set (or possibly a bag)

of objects of some class C, we can make objects of C persistent by adding them to the

set, thus making them reachable from N.Hence,N is a named object that defines a

persistent collection of objects of class C. In the object model standard, N is called

the extent of C (see Section 11.3).

For example, we can define a class

DEPARTMENT_SET (see Figure 11.3) whose

objects are of type

set(DEPARTMENT).

We can create an object of type

DEPARTMENT_SET, and give it a persistent name ALL_DEPARTMENTS, as shown in

Figure 11.3. Any

DEPARTMENT object that is added to the set of ALL_DEPARTMENTS

by using the add_dept operation becomes persistent by virtue of its being reachable

from

ALL_DEPARTMENTS. As we will see in Section 11.3, the ODMG ODL standard

gives the schema designer the option of naming an extent as part of class definition.

Notice the difference between traditional database models and ODBs in this respect.

Default names for the constructor and destructor operations exist in the C++ programming language.

For example, for class EMPLOYEE, the default constructor name is EMPLOYEE and the default destruc-

tor name is ~EMPLOYEE. It is also common to use the new operation to create new objects.

As we will see in Section 11.3, the ODMG ODL syntax uses set<DEPARTMENT> instead of

set(DEPARTMENT).

364 Chapter 11 Object and Object-Relational Databases

Figure 11.3

Creating persistent

objects by naming

and reachability.

define class DEPARTMENT_SET

type set (DEPARTMENT);

operations add_dept(d: DEPARTMENT): boolean;

(* adds a department to the DEPARTMENT_SET object *)

remove_dept(d: DEPARTMENT): boolean;

(* removes a department from the DEPARTMENT_SET object *)

create_dept_set: DEPARTMENT_SET;

destroy_dept_set: boolean;

end DEPARTMENT_SET;

...

persistent name ALL_DEPARTMENTS: DEPARTMENT_SET;

(* ALL_DEPARTMENTS is a persistent named object of type DEPARTMENT_SET *)

...

d:= create_dept;

(* create a new DEPARTMENT object in the variable d *)

...

b:= ALL_DEPARTMENTS.add_dept(d);

(* make d persistent by adding it to the persistent set ALL_DEPARTMENTS *)

In traditional database models, such as the relational model, all objects are assumed

to be persistent. Hence, when a table such as

EMPLOYEE is created in a relational

database, it represents both the type declaration for

EMPLOYEE and a persistent set of

all

EMPLOYEE records (tuples). In the OO approach, a class declaration of

EMPLOYEE specifies only the type and operations for a class of objects. The user

must separately define a persistent object of type set(

EMPLOYEE) or

bag(

EMPLOYEE) whose value is the collection of references (OIDs) to all persistent

EMPLOYEE objects, if this is desired, as shown in Figure 11.3.

This allows transient

and persistent objects to follow the same type and class declarations of the ODL and

the OOPL. In general, it is possible to define several persistent collections for the

same class definition, if desired.

11.1.5 Type Hierarchies and Inheritance

Simplified Model for Inheritance. Another main characteristic of ODBs is that

they allow type hierarchies and inheritance. We use a simple OO model in this sec-

tion—a model in which attributes and operations are treated uniformly—since

both attributes and operations can be inherited. In Section 11.3, we will discuss the

inheritance model of the ODMG standard, which differs from the model discussed

here because it distinguishes between two types of inheritance. Inheritance allows the

definition of new types based on other predefined types, leading to a type (or class)

hierarchy.

Some systems, such as POET, automatically create the extent for a class.

11.1 Overview of Object Database Concepts 365

A type is defined by assigning it a type name, and then defining a number of attrib-

utes (instance variables) and operations (methods) for the type.

In the simplified

model we use in this section, the attributes and operations are together called

functions, since attributes resemble functions with zero arguments. A function

name can be used to refer to the value of an attribute or to refer to the resulting

value of an operation (method). We use the term function to refer to both attrib-

utes and operations, since they are treated similarly in a basic introduction to inher-

itance.

A type in its simplest form has a type name and a list of visible (public) functions.

When specifying a type in this section, we use the following format, which does not

specify arguments of functions, to simplify the discussion:

TYPE_NAME: function, function, ..., function

For example, a type that describes characteristics of a PERSON may be defined as

follows:

PERSON: Name, Address, Birth_date, Age, Ssn

In the PERSON type, the Name, Address, Ssn, and Birth_date functions can be imple-

mented as stored attributes, whereas the

Age function can be implemented as an

operation that calculates the

Age from the value of the Birth_date attribute and the

current date.

The concept of subtype is useful when the designer or user must create a new type

that is similar but not identical to an already defined type. The subtype then inher-

its all the functions of the predefined type, which is referred to as the supertype.For

example, suppose that we want to define two new types

EMPLOYEE and STUDENT

as follows:

EMPLOYEE: Name, Address, Birth_date, Age, Ssn, Salary, Hire_date, Seniority

STUDENT: Name

, Address, Birth_date, Age, Ssn, Major, Gpa

Since both STUDENT and EMPLOYEE include all the functions defined for PERSON

plus some additional functions of their own, we can declare them to be subtypes of

PERSON. Each will inherit the previously defined functions of PERSON—namely,

Name, Address, Birth_date, Age, and Ssn.For STUDENT, it is only necessary to define

the new (local) functions

Major and Gpa, which are not inherited. Presumably, Major

can be defined as a stored attribute, whereas Gpa may be implemented as an opera-

tion that calculates the student’s grade point average by accessing the

Grade values

that are internally stored (hidden) within each

STUDENT object as hidden attributes.

For

EMPLOYEE, the Salary and Hire_date functions may be stored attributes, whereas

Seniority may be an operation that calculates Seniority from the value of Hire_date.

In this section we will use the terms type and class as meaning the same thing—namely, the attributes

and operations of some type of object.

We will see in Section 11.3 that types with functions are similar to the concept of interfaces as used in

ODMG ODL.

366 Chapter 11 Object and Object-Relational Databases

Therefore, we can declare EMPLOYEE and STUDENT as follows:

EMPLOYEE subtype-of PERSON: Salary, Hire_date, Seniority

STUDENT subtype-of PERSON: Major

, Gpa

In general, a subtype includes all of the functions that are defined for its supertype

plus some additional functions that are specific only to the subtype. Hence, it is pos-

sible to generate a type hierarchy to show the supertype/subtype relationships

among all the types declared in the system.

As another example, consider a type that describes objects in plane geometry, which

may be defined as follows:

GEOMETRY_OBJECT: Shape, Area, Reference_point

For the GEOMETRY_OBJECT type, Shape is implemented as an attribute (its

domain can be an enumerated type with values ‘triangle’, ‘rectangle’, ‘circle’, and so

on), and

Area is a method that is applied to calculate the area. Reference_point speci-

fies the coordinates of a point that determines the object location. Now suppose

that we want to define a number of subtypes for the

GEOMETRY_OBJECT type, as

follows:

RECTANGLE subtype-of GEOMETRY_OBJECT: Width, Height

TRIANGLE S subtype-of GEOMETRY_OBJECT: Side1

, Side2, Angle

CIRCLE subtype-of GEOMETRY_OBJECT: Radius

Notice that the Area operation may be implemented by a different method for each

subtype, since the procedure for area calculation is different for rectangles, triangles,

and circles. Similarly, the attribute

Reference_point may have a different meaning for

each subtype; it might be the center point for

RECTANGLE and CIRCLE objects, and

the vertex point between the two given sides for a

TRIANGLE object.

Notice that type definitions describe objects but do not generate objects on their

own. When an object is created, typically it belongs to one or more of these types

that have been declared. For example, a circle object is of type

CIRCLE and

GEOMETRY_OBJECT (by inheritance). Each object also becomes a member of one

or more persistent collections of objects (or extents), which are used to group

together collections of objects that are persistently stored in the database.

Constraints on Extents Corresponding to a Type Hierarchy. In most ODBs,

an extent is defined to store the collection of persistent objects for each type or sub-

type. In this case, the constraint is that every object in an extent that corresponds to

a subtype must also be a member of the extent that corresponds to its supertype.

Some OO database systems have a predefined system type (called the

ROOT class or

the

OBJECT class) whose extent contains all the objects in the system.

Classification then proceeds by assigning objects into additional subtypes that are

meaningful to the application, creating a type hierarchy (or class hierarchy) for the

system. All extents for system- and user-defined classes are subsets of the extent cor-

This is called OBJECT in the ODMG model (see Section 11.3).

11.1 Overview of Object Database Concepts 367

responding to the class OBJECT, directly or indirectly. In the ODMG model (see

Section 11.3), the user may or may not specify an extent for each class (type),

depending on the application.

An extent is a named persistent object whose value is a persistent collection that

holds a collection of objects of the same type that are stored permanently in the

database. The objects can be accessed and shared by multiple programs. It is also

possible to create a transient collection, which exists temporarily during the execu-

tion of a program but is not kept when the program terminates. For example, a

transient collection may be created in a program to hold the result of a query that

selects some objects from a persistent collection and copies those objects into the

transient collection. The program can then manipulate the objects in the transient

collection, and once the program terminates, the transient collection ceases to exist.

In general, numerous collections—transient or persistent—may contain objects of

the same type.

The inheritance model discussed in this section is very simple. As we will see in

Section 11.3, the ODMG model distinguishes between type inheritance—called

interface inheritance and denoted by a colon (:)—and the extent inheritance con-

straint—denoted by the keyword

EXTEND.

11.1.6 Other Object-Oriented Concepts

Polymorphism of Operations (Operator Overloading). Another characteris-

tic of OO systems in general is that they provide for polymorphism of operations,

which is also known as operator overloading. This concept allows the same

operator name or symbol to be bound to two or more different implementations of

the operator, depending on the type of objects to which the operator is applied. A

simple example from programming languages can illustrate this concept. In some

languages, the operator symbol “+” can mean different things when applied to

operands (objects) of different types. If the operands of “+” are of type integer, the

operation invoked is integer addition. If the operands of “+” are of type floating

point, the operation invoked is floating point addition. If the operands of “+” are of

type set, the operation invoked is set union. The compiler can determine which

operation to execute based on the types of operands supplied.

In OO databases, a similar situation may occur. We can use the

GEOMETRY_OBJECT example presented in Section 11.1.5 to illustrate operation

polymorphism

in ODB.

In this example, the function

Area is declared for all objects of type

GEOMETRY_OBJECT. However, the implementation of the method for Area may

differ for each subtype of

GEOMETRY_OBJECT. One possibility is to have a general

implementation for calculating the area of a generalized

GEOMETRY_OBJECT (for

In programming languages, there are several kinds of polymorphism. The interested reader is referred

to the Selected Bibliography at the end of this chapter for works that include a more thorough discus-

sion.

368 Chapter 11 Object and Object-Relational Databases

example, by writing a general algorithm to calculate the area of a polygon) and then

to rewrite more efficient algorithms to calculate the areas of specific types of geo-

metric objects, such as a circle, a rectangle, a triangle, and so on. In this case, the

Area

function is overloaded by different implementations.

The ODMS must now select the appropriate method for the

Area function based on

the type of geometric object to which it is applied. In strongly typed systems, this

can be done at compile time, since the object types must be known. This is termed

early (or static) binding. However, in systems with weak typing or no typing (such

as Smalltalk and LISP), the type of the object to which a function is applied may not

be known until runtime. In this case, the function must check the type of object at

runtime and then invoke the appropriate method. This is often referred to as late

(or dynamic) binding.

Multiple Inheritance and Selective Inheritance. Multiple inheritance occurs

when a certain subtype T is a subtype of two (or more) types and hence inherits the

functions (attributes and methods) of both supertypes. For example, we may create a

subtype

ENGINEERING_MANAGER that is a subtype of both MANAGER and

ENGINEER. This leads to the creation of a type lattice rather than a type hierarchy.

One problem that can occur with multiple inheritance is that the supertypes from

which the subtype inherits may have distinct functions of the same name, creating an

ambiguity. For example, both

MANAGER and ENGINEER may have a function called

Salary. If the Salary function is implemented by different methods in the MANAGER

and ENGINEER supertypes, an ambiguity exists as to which of the two is inherited by

the subtype

ENGINEERING_MANAGER. It is possible, however, that both ENGINEER

and MANAGER inherit Salary from the same supertype (such as EMPLOYEE) higher

up in the lattice. The general rule is that if a function is inherited from some common

supertype, then it is inherited only once. In such a case, there is no ambiguity; the

problem only arises if the functions are distinct in the two supertypes.

There are several techniques for dealing with ambiguity in multiple inheritance.

One solution is to have the system check for ambiguity when the subtype is created,

and to let the user explicitly choose which function is to be inherited at this time. A

second solution is to use some system default. A third solution is to disallow multi-

ple inheritance altogether if name ambiguity occurs, instead forcing the user to

change the name of one of the functions in one of the supertypes. Indeed, some OO

systems do not permit multiple inheritance at all. In the object database standard

(see Section 11.3), multiple inheritance is allowed for operation inheritance of

interfaces, but is not allowed for

EXTENDS inheritance of classes.

Selective inheritance occurs when a subtype inherits only some of the functions of

a supertype. Other functions are not inherited. In this case, an

EXCEPT clause may

be used to list the functions in a supertype that are not to be inherited by the sub-

type. The mechanism of selective inheritance is not typically provided in ODBs, but

it is used more frequently in artificial intelligence applications.

In the ODMG model, type inheritance refers to inheritance of operations only, not attributes (see

Section 11.3).

11.2 Object-Relational Features: Object Database Extensions to SQL 369

11.1.7 Summary of Object Database Concepts

To conclude this section, we give a summary of the main concepts used in ODBs

and object-relational systems:

■

Object identity. Objects have unique identities that are independent of their

attribute values and are generated by the ODMS.

■

Type constructors. Complex object structures can be constructed by apply-

ing in a nested manner a set of basic constructors, such as tuple, set, list,

array, and bag.

■

Encapsulation of operations. Both the object structure and the operations

that can be applied to individual objects are included in the type definitions.

■

Programming language compatibility. Both persistent and transient

objects are handled seamlessly. Objects are made persistent by being reach-

able from a persistent collection (extent) or by explicit naming.

■

Type hierarchies and inheritance. Object types can be specified by using a

type hierarchy, which allows the inheritance of both attributes and methods

(operations) of previously defined types. Multiple inheritance is allowed in

some models.

■

Extents. All persistent objects of a particular type can be stored in an extent.

Extents corresponding to a type hierarchy have set/subset constraints

enforced on their collections of persistent objects.

■

Polymorphism and operator overloading. Operations and method names

can be overloaded to apply to different object types with different imple-

mentations.

In the following sections we show how these concepts are realized in the SQL stan-

dard (Section 11.2) and the ODMG standard (Section 11.3).

11.2 Object-Relational Features:

Object Database Extensions to SQL

We introduced SQL as the standard language for RDBMSs in Chapters 4 and 5. As

we discussed, SQL was first specified by Chamberlin and Boyce (1974) and under-

went enhancements and standardization in 1989 and 1992. The language continued

its evolution with a new standard, initially called SQL3 while being developed, and

later known as SQL:99 for the parts of SQL3 that were approved into the standard.

Starting with the version of SQL known as SQL3, features from object databases

were incorporated into the SQL standard. At first, these extensions were known as

SQL/Object, but later they were incorporated in the main part of SQL, known as

SQL/Foundation. We will use that latest standard, SQL:2008, in our presentation of

the object features of SQL, even though this may not yet have been realized in com-

mercial DBMSs that follow SQL. We will also discuss how the object features of SQL

evolved to their latest manifestation in SQL:2008.

370 Chapter 11 Object and Object-Relational Databases

The relational model with object database enhancements is sometimes referred to

as the object-relational model. Additional revisions were made to SQL in 2003 and

2006 to add features related to XML (see Chapter 12).

The following are some of the object database features that have been included in

SQL:

■

Some type constructors have been added to specify complex objects. These

include the row type, which corresponds to the tuple (or struct) constructor.

An array type for specifying collections is also provided. Other collection

type constructors, such as set, list, and bag constructors, were not part of the

original SQL/Object specifications but were later included in the standard.

■

A mechanism for specifying object identity through the use of reference type

is included.

■

Encapsulation of operations is provided through the mechanism of user-

defined types (UDTs) that may include operations as part of their declara-

tion. These are somewhat similar to the concept of abstract data types that

were developed in programming languages. In addition, the concept of user-

defined routines (UDRs) allows the definition of general methods (opera-

tions).

■

Inheritance mechanisms are provided using the keyword UNDER.

We now discuss each of these concepts in more detail. In our discussion, we will

refer to the example in Figure 11.4.

11.2.1 User-Defined Types and Complex Structures for Objects

To allow the creation of complex-structured objects, and to separate the declaration

of a type from the creation of a table, SQL now provides user-defined types

(UDTs). In addition, four collection types have been included to allow for multival-

ued types and attributes in order to specify complex-structured objects rather than

just simple (flat) records. The user will create the UDTs for a particular application

as part of the database schema. A UDT may be specified in its simplest form using

the following syntax:

CREATE TYPE TYPE_NAME AS (<component declarations>);

Figure 11.4 illustrates some of the object concepts in SQL. We will explain the exam-

ples in this figure gradually as we explain the concepts. First, a UDT can be used as

either the type for an attribute or as the type for a table. By using a UDT as the type

for an attribute within another UDT, a complex structure for objects (tuples) in a

table can be created, much like that achieved by nesting type constructors. This is

similar to using the struct type constructor of Section 11.1.3. For example, in Figure

11.4(a), the UDT

STREET_ADDR_TYPE is used as the type for the STREET_ADDR

attribute in the UDT USA_ADDR_TYPE. Similarly, the UDT USA_ADDR_TYPE is in

turn used as the type for the

ADDR attribute in the UDT PERSON_TYPE in Figure

11.4(b). If a UDT does not have any operations, as in the examples in Figure 11.4(a),

it is possible to use the concept of

ROW TYPE to directly create a structured attribute

11.2 Object-Relational Features: Object Database Extensions to SQL 371

Figure 11.4

Illustrating some of the object

features of SQL. (a) Using UDTs

as types for attributes such as

Address and Phone, (b) Specifying

UDT for PERSON_TYPE, (c)

Specifying UDTs for STUDENT_TYPE

and EMPLOYEE_TYPE as two sub-

types of PERSON_TYPE

(a) CREATE TYPE STREET_ADDR_TYPE AS

(

NUMBER VARCHAR (5),

STREET_NAME VARCHAR (25),

APT_NO VARCHAR (5),

SUITE_NO VARCHAR (5)

);

CREATE TYPE USA_ADDR_TYPE AS (

STREET_ADDR STREET_ADDR_TYPE,

CITY VARCHAR (25),

ZIP VARCHAR (10)

);

CREATE TYPE USA_PHONE_TYPE AS (

PHONE_TYPE VARCHAR (5),

AREA_CODE CHAR (3),

PHONE_NUM CHAR (7)

);

(b) CREATE TYPE PERSON_TYPE AS (

NAME VARCHAR (35),

SEX CHAR,

BIRTH_DATE DATE,

PHONES USA_PHONE_TYPE ARRAY [4],

ADDR USA_ADDR_TYPE

INSTANTIABLE

NOT FINAL

REF IS SYSTEM GENERATED

INSTANCE METHOD AGE

() RETURNS INTEGER;

CREATE INSTANCE METHOD AGE() RETURNS INTEGER

FOR PERSON_TYPE

BEGIN

RETURN /* CODE TO CALCULATE A PERSON’S AGE FROM

TODAY’S DATE AND SELF.BIRTH_DATE */

END

;

);

COURSENO CHAR (8),

SEMESTER VARCHAR (8),

YEAR CHAR (4),

GRADE CHAR

);

CREATE TYPE STUDENT_TYPE UNDER PERSON_TYPE AS (

MAJOR_CODE CHAR (4),

STUDENT_ID CHAR (12),

DEGREE VARCHAR (5),

TRANSCRIPT GRADE_TYPE ARRAY [100]

(continues)