Object Oriented Oracle Wenny Rahayu pdf download

https://ebookgate.com/product/object-oriented-oracle-wenny-
rahayu/

Get Instant Ebook Downloads – Browse at https://ebookgate.com

Instant digital products (PDF, ePub, MOBI) available
Download now and explore formats that suit you...

The principles of object oriented JavaScript Zakas

https://ebookgate.com/product/the-principles-of-object-oriented-
javascript-zakas/

ebookgate.com

PHP Object Oriented Solutions 1st Edition David Powers

https://ebookgate.com/product/php-object-oriented-solutions-1st-
edition-david-powers/

ebookgate.com

Object Oriented Programming with C 2 e Second Edition

Sahay

https://ebookgate.com/product/object-oriented-programming-
with-c-2-e-second-edition-sahay/

ebookgate.com

Object Oriented Design and Patterns 2nd Edition Cay S.

Horstmann

https://ebookgate.com/product/object-oriented-design-and-patterns-2nd-
edition-cay-s-horstmann/

ebookgate.com
Object oriented programming with ABAP Objects 1st Edition
James Wood

https://ebookgate.com/product/object-oriented-programming-with-abap-
objects-1st-edition-james-wood/

ebookgate.com

Object oriented programming in C 7th print. with

corrections Edition Lafore

https://ebookgate.com/product/object-oriented-programming-in-c-7th-
print-with-corrections-edition-lafore/

ebookgate.com

Management of the Object Oriented Development Process 1st

Edition Liping Liu

https://ebookgate.com/product/management-of-the-object-oriented-
development-process-1st-edition-liping-liu/

ebookgate.com

ActionScript 3 0 design patterns object oriented

programming techniques 1st ed Edition William Sanders

https://ebookgate.com/product/actionscript-3-0-design-patterns-object-
oriented-programming-techniques-1st-ed-edition-william-sanders/

ebookgate.com

Beginning C 3 0 an introduction to object oriented

programming 1st Edition Jack Purdum

https://ebookgate.com/product/beginning-c-3-0-an-introduction-to-
object-oriented-programming-1st-edition-jack-purdum/

ebookgate.com
Object-Oriented
Oracle™

Johanna Wenny Rahayu

La Trobe University, Australia

David Taniar
Monash University, Australia

Eric Pardede
La Trobe University, Australia

IRM Press
Publisher of innovative scholarly and professional
information technology titles in the cyberage

Hershey • London • Melbourne • Singapore

Acquisitions Editor: Renée Davies
Development Editor: Kristin Roth
Senior Managing Editor: Amanda Appicello
Managing Editor: Jennifer Neidig
Copy Editor: Shanelle Ramelb
Typesetter: Cindy Consonery
Cover Design: Lisa Tosheff
Printed at: Yurchak Printing Inc.

Published in the United States of America by

IRM Press (an imprint of Idea Group Inc.)
701 E. Chocolate Avenue, Suite 200
Hershey PA 17033-1240
Tel: 717-533-8845
Fax: 717-533-8661
E-mail: cust@idea-group.com
Web site: http://www.irm-press.com

and in the United Kingdom by

IRM Press (an imprint of Idea Group Inc.)
3 Henrietta Street
Covent Garden
London WC2E 8LU
Tel: 44 20 7240 0856
Fax: 44 20 7379 3313
Web site: http://www.eurospan.co.uk

Copyright © 2006 by Idea Group Inc. All rights reserved. No part of this book may be reproduced,
stored or distributed in any form or by any means, electronic or mechanical, including photocopying,
without written permission from the publisher.

Product or company names used in this book are for identification purposes only. Inclusion of the
names of the products or companies does not indicate a claim of ownership by IGI of the trademark
or registered trademark.

Library of Congress Cataloging-in-Publication Data

Object-oriented Oracle / Wenny Rahayu, David Taniar and Eric Pardede, editors.
p. cm.
Summary: " The book covers comprehensive and fundamental aspects of the implementation of
object-oriented modeling in a DBMS that was originated as a pure Relational Database, Oracle"--
Provided by publisher.
Includes bibliographical references and index.
ISBN 1-59140-810-5 (hardcover : alk. paper) -- ISBN 1-59140-607-2 (softcover : alk. paper) -- ISBN
1-59140-608-0 (ebook : alk. paper)
1. Oracle (Computer file) 2. Object-oriented methods (Computer science) I. Rahayu, Wenny, 1968-
II. Taniar, David. III. Pardede, Eric, 1975-
QA76.9.D26O23 2005
005.1'1--dc22
2005005340

British Cataloguing in Publication Data

A Cataloguing in Publication record for this book is available from the British Library.

All work contributed to this book is new, previously-unpublished material. The views expressed in this
book are those of the authors, but not necessarily of the publisher.
 Object-Oriented
O r a cl e ™

Table of Contents

Preface ................................................................................................. viii

Chapter I. Object-Relational Approaches ............................................ 1

Object-Oriented Conceptual Model ................................................ 1
Static Aspects of OOCM ................................................................. 2
Objects and Classes .................................................................... 3
Inheritance Relationships .............................................................. 4
Association Relationships ............................................................. 6
Aggregation Hierarchies ............................................................... 7
Dynamic Aspects of OOCM .......................................................... 12
Generic Methods ....................................................................... 13
User-Defined Methods ............................................................... 14
New Era of Object-Relational Approaches .................................. 15
OOCM Implemented on Relational Databases .......................... 16
Object Wrappers on Relational Systems .................................... 16
Extended Relational Systems ...................................................... 17
Object-Oriented System and RDBMS Coexistence .................. 18
OODBMS and RDBMS Interoperation .................................... 19
Object-Relational Database System ............................................. 20
Case Study .................................................................................... 21
Summary ....................................................................................... 23
References ..................................................................................... 24
Chapter Problems ......................................................................... 25
Chapter Solutions ......................................................................... 27
Chapter II. Object-Oriented Features in Oracle™ ............................ 31
Relational-Model Features ........................................................... 31
Object-Oriented Features ............................................................. 34
Object Types and User-Defined Types ...................................... 34
Collection Types ........................................................................ 35
Object Identifiers ....................................................................... 36
Relationships using Ref ............................................................... 38
Cluster ....................................................................................... 39
Inheritance Relationships using Under ........................................ 40
Encapsulation ............................................................................. 41
Summary ....................................................................................... 47
References ..................................................................................... 47
Chapter Problems ......................................................................... 48
Chapter Solutions ......................................................................... 49

Chapter III. Using Object-Oriented Features .................................... 51

Using Inheritance Relationships ................................................... 51
Union Inheritance Implementation ............................................... 52
Mutual-Exclusion Inheritance Implementation ............................. 54
Partition Inheritance Implementation ........................................... 56
Multiple Inheritance Implementation ........................................... 57
Using Association Relationships ................................................... 59
Creating an Association Relationship by a Primary-Key
and Foreign-Key Relationship ............................................ 60
Creating an Association Relationship by Object
References .......................................................................... 62
Primary Keys: Foreign Keys vs. Object References in an
Association Relationship ............................................................. 65
Using Aggregation Relationships ................................................. 67
Implementing Existence-Dependent Aggregation using the
Clustering Technique ........................................................... 67
Implementing Existence-Dependent Aggregation using the
Nesting Technique .............................................................. 70
Implementing Existence-Independent Aggregation ....................... 73
Case Study .................................................................................... 76
Summary ....................................................................................... 81
References ..................................................................................... 81
Chapter Problems ......................................................................... 81
Chapter Solutions ......................................................................... 83
Chapter IV. Object-Oriented Methods .............................................. 89
Implementation of Encapsulation Using Stored Procedures
or Functions and Grant Mechanisms ...................................... 90
Stored Procedures or Functions ................................................ 90
Grant .......................................................................................... 97
Implementation of Encapsulation Using Member Procedures
or Functions ............................................................................. 98
Case Study .................................................................................. 102
Summary ..................................................................................... 107
References ................................................................................... 108
Chapter Problems ....................................................................... 108
Chapter Solutions ....................................................................... 111

Chapter V.Generic Methods ............................................................. 114

Implementation of Methods in Inheritance Hierarchies ............. 115
Implementation of Methods in Union Inheritance ...................... 116
Implementation of Methods in Mutual-Exclusion
Inheritance ................................................................................ 126
Implementation of Methods in Partition Inheritance .................. 133
Implementation of Methods in Multiple Inheritance .................. 135
Implementation of Methods in Association Relationships .......... 138
Implementation of Methods in Aggregation Relationships ......... 142
Implementation of Methods in Aggregation Relationships
Using the Clustering Technique ......................................... 145
Implementation of Methods in Aggregation Relationships
Using the Nesting Technique ............................................ 146
Case Study .................................................................................. 151
Summary ..................................................................................... 159
Chapter Problems ....................................................................... 159
Chapter Solutions ....................................................................... 163

Chapter VI. User-Defined Queries ................................................... 170

User-Defined Queries in Inheritance Hierarchies ....................... 170
Subclass Query ........................................................................ 171
Superclass Query ..................................................................... 172
User-Defined Queries in Association Relationships .................... 175
Referencing Query ................................................................... 175
Dereferencing Query ................................................................ 177
User-Defined Queries in Aggregation Hierarchies ..................... 178
Part Query ............................................................................... 179
 Whole Query ........................................................................... 181
User-Defined Queries Using Multiple Collection Types ............. 184
Varray Collection Type ............................................................ 184
Nested-Table Collection Type .................................................. 186
User-Defined Queries with Object References ........................... 187
VALUE ................................................................................... 188
DEREF .................................................................................... 190
IS DANGLING ....................................................................... 190
Object Table vs. Object Attribute ............................................... 191
Clustering Technique vs. Index-Organization Table .................. 193
Case Study .................................................................................. 194
Summary ..................................................................................... 202
Chapter Problems ....................................................................... 202
Chapter Solutions ....................................................................... 206

Chapter VII. University Case Study ................................................. 210

Problem Description ................................................................... 210
Problem Solution ........................................................................ 217
Campus_T Table ...................................................................... 217
Faculty_T Class and Part Classes ........................................... 218
Building_T Class and Part Classes .......................................... 221
Degree_T Class ....................................................................... 224
Person_T Class, the Subclasses, and the Enrolls_In Table ...... 227
Subject_T Class and Takes Table ........................................... 240
Sample Database Execution ....................................................... 243
Generic Methods Sample ......................................................... 243
User-Defined Methods Sample ................................................ 247
Building Case Application .......................................................... 249
Summary ..................................................................................... 275

Chapter VIII. Retailer Case Study ................................................... 276

Problem Description ................................................................... 276
Problem Solution ........................................................................ 282
Company_T Class and the Subclasses .................................... 284
Shareholders_T Class and Own_Shares Table ........................ 285
Management_T Class and the Subclasses ................................ 288
Store_T Class and the Department_T Part Class .................... 290
Employee_T Class and the Subclasses .................................... 294
Maker_T Class ........................................................................ 300
Item_T Class and Available_In Table ....................................... 301
 Customer_T Class ................................................................... 303
Transaction_T Class ................................................................. 306
Building Tools Using Oracle™ Developer ................................ 307
Creating a Form Using the Data-Block Form ......................... 308
Creating a Form Using a Custom Form .................................. 315
Summary ..................................................................................... 323

About the Authors .............................................................................. 324

Index ................................................................................................... 326

viii

Preface

Why This Book?

Object orientation has now invaded traditional relational database-manage-

ment systems. Oracle™ without exception has included object-oriented fea-
tures in its system. SQL is now richer due to these additional features. How-
ever, the object-oriented elements in Oracle™ will not be fully utilized without
a proper database design. For example, a database application designed us-
ing a traditional database modeling, such as entity-relationship (E/R) model-
ing, will not be able to make use of most object-oriented features in Oracle™.
This is simply due to the absence of object-oriented elements in the design.
Even with a proper object-oriented design, without careful transformation from
design to implementation, many of the object-oriented features will be lost.
Object-Oriented Oracle™ addresses this need by not only explaining the
new object-oriented features in Oracle™, but most importantly how these
features can be fully utilized in database applications. We put a heavy empha-
size on how an object-oriented conceptual model is implemented in Oracle™.
This includes the static aspect of an object-oriented conceptual model, in-
cluding the inheritance, association, and aggregation relationships, as well as
the dynamic aspect covering generic object-oriented methods and user-de-
fined queries.
Just as we enjoyed writing this book, we hope that you will enjoy reading it,
and most importantly gain valuable lessons from it. We trust that this book will
give you a comprehensive insight into object-oriented Oracle™.
 ix

Distinguishing Features

Object-Oriented Oracle™ presents the right mix between theoretical and

practical lessons on object-oriented features of Oracle™.
In the theoretical part, it describes the foundation of object-oriented concepts
and how they are used in the implementation. The importance of these con-
cepts is invaluable because without this understanding, the new object-ori-
ented features offered by Oracle™ will not be fully utilized. Therefore, these
theoretical elements serve as the foundation of object orientation in Oracle™.
In the practical part, the book contains two case studies (Chapters VII and
VIII) that thoroughly explain the development of a database application using
the object-oriented technology of Oracle™. The case studies start with the
description of an application, followed by the appropriate object-oriented
designs. The designs are then transformed for implementation in Oracle™.
Each chapter also contains extensive examples and code. These examples
and code will give readers a better understanding of how object-oriented
elements are used in Oracle™.
At the end of each chapter, a set of problems, together with their solutions,
are given. These will be suitable exercises for the classroom. The solutions
will be useful for both students and their teachers.

Topical Coverage

Object-Oriented Oracle™ contains eight chapters.

Chapter I starts with object-relational approaches that cover the object-ori-
ented conceptual model. There have been many approaches in amalgamating
the object-oriented model with database systems, from which the new era of
object-relational databases is born.
Chapter II explains object-oriented features in Oracle™. These include the
use of type and object in conjunction with table creation, varray, and nested
table. These features, together with the ref relationships, index cluster, and
the under clause for subtyping, change the whole concept of database model-
ing.
Chapter III describes how these object-oriented features should be properly
used in Oracle™. This includes how the object-oriented conceptual model
described in Chapter I is implemented using the features presented in Chapter
x

II. This chapter particularly focuses on the static aspect of the object-oriented
conceptual model, including the inheritance, association, and aggregation re-
lationships.
Chapter IV justifies how the dynamic aspect of the object-oriented concep-
tual model (encapsulation and object-oriented methods) is implemented using
the new features of Oracle™, namely member procedures and functions.
Chapter V describes generic methods in Oracle™. This covers generic meth-
ods found in the object-oriented conceptual model, including the inheritance,
association, and aggregation relationships. The generic methods comprise typi-
cal database operations (e.g., update, delete, and insert) applied to the mem-
ber attributes of a class. The use of generic methods is a direct implementation
of object-oriented encapsulation features.
Chapter VI focuses on user-defined queries. New SQL features, covering
referencing and dereferencing using ref, super- and subclass accesses using
treat, nesting techniques using the and table, are explained. The chapter also
discusses the varray and nested-table collection types, object references deref,
the is dangling clause, and object attributes.
Chapter VII introduces a university case study that contains a database to
maintain the running of courses in a university. This case study shows the en-
tire database-application development life-cycle process from the object-ori-
ented design to transformation for implementation in Oracle™.
Finally, Chapter VIII presents another case study based on a retailer-chain
company. In addition to using the object-oriented conceptual model for the
database design, implementation is carried out using Oracle™ Form Devel-
oper. The aim is to show how a window-based database application can be
developed using the object-oriented technology in Oracle™.

Intended Audience

Object-Oriented Oracle™ is intended for the following audiences.

• Database Practitioners
Object orientation in Oracle™ has now opened a wide opportunity in
exploring new ways for building database applications. This book shows
how object-oriented features can be adapted for database-application
development. It describes not only the practical aspects of database-
application development, but also the theoretical foundations that lead to
 xi

the use of the object-oriented technology in database applications using

Oracle™. The two case studies included in this book show the two
flavours of database applications using the object-oriented technology
as their foundation whereby the first application is a text-based applica-
tion, and the second is window-based using Oracle™ Form Developer.
• College Students and Teachers
This book is suitable as a textbook for database courses at any level: an
introductory database course whereby this book can be used as a supple-
ment to the standard database-management textbook, or an advanced
database course concentrating on object-oriented database development.
Students who are learning the standard material of SQL are now able to
learn, at the same time, the new object-oriented features of SQL. Fur-
thermore, students are now able to relate how a database design, in this
case using an object-oriented method, can smoothly be implemented in
Oracle™, thus making the entire database-application-development life
cycle transparent.
• General IT Readers
General IT readers who are keen on the new technology of Oracle™ will
find this book useful and informative. Object orientation has been an
interesting topic in general due to the popularity of object-oriented pro-
gramming languages, like C++ and Java. The object-oriented concepts,
which underpin these programming languages, have been widely under-
stood. However, their applications to database systems have not been
broadly explored. This book demonstrates how object-oriented features
could be used easily in Oracle™, and most of all, how they could be
used appropriately and efficiently.
• IT Researchers
Object orientation in relational database systems has been an active re-
search area in the last decade. Many researchers have proposed meth-
ods for transforming object-oriented design to relational database imple-
mentation. Other groups of researchers have been concentrating on ob-
ject-relational databases. Due to the increasing trend whereby most da-
tabase-management-system vendors are positioning themselves in the ob-
ject-oriented tracks, there are plenty of research opportunities in this
important area. This book will give researchers the basic foundation for
amalgamating two different elements: object-oriented and relational da-
tabase systems.
xii

Feedback and Comments

Although we have fully tested all code included in this book, should there be
any problems or confusion about the code, please do not hesitate to contact
us.
We would appreciate if you could also share any other comments or feedback
with us so that we can incorporate them in a future edition. Comments and
feedback may be sent directly to the publisher at

Object-Oriented Oracle™
Idea Group Inc.
701 East Chocolate Avenue, Suite 200
Hershey, PA 17033-1240, USA
 xiii

Acknowledgments

Object-Oriented Oracle™ would not have been published without the sup-
port of a number of parties. We owe them our gratitude.
First of all, we would like to thank Mehdi Khosrow-Pour and Jan Travers of
Idea Group Publishing for believing in us on this project. They supported our
ideas in writing a book on this topic, and only because of their encouragement
and trust, this book becomes a realization.
We would also like to thank the team at Idea Group for keeping the schedule
on track. Their communication and support were very efficient and profes-
sional. We were glad for this opportunity to collaborate with them.
Finally, we would like to express our sincere thanks to our respective em-
ployers, the Department of Computer Science and Computer Engineering, La
Trobe University, Australia, and the School of Business Systems, Monash
University, Australia, for the facilities and time that we received during the
writing of this book. Without these, the book would not have been written in
the first place.

J. W. Rahayu
D. Taniar
E. Pardede

Melbourne, June 20, 2005

 Object-Relational Approaches 1

Chapter I

Object-Relational
Approaches

This book focuses on the implementation of an object-oriented model into

object-relational DBMS using Oracle™. All aspects of the object-oriented
model, particularly those that play a significant role in database implementation,
will be discussed in this book.
The object-oriented modeling technique is an important issue in this book
because it is the underlying notion behind the development of the object-
relational approaches. Therefore, in this chapter we will start with an outline of
the object-oriented conceptual model (OOCM).

Object-Oriented Conceptual Model

An OOCM encapsulates the structural and static as well as behavioral and

dynamic aspects of objects. The static aspects consist of the classes and
objects, and the relationships between them, namely, inheritance, association,
and aggregation. Each of these relationships is associated with a set of
constraints. The dynamic aspect of the OOCM is divided into two types of
methods: generic and user defined.
The object-oriented method promised to improve software quality and effi-
ciency. One of the most enticing promises is that of real reusability: reusability

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
2 Rahayu, Taniar and Pardede

of codes, program portions, designs, formal specifications, and also commer-

cial packages. As software-development cost increases, more developers see
the benefit of using reusable components. Solving the reusability problem
essentially means reducing the effort required to write codes; hence, more
effort can be devoted to improving other factors such as correctness and
robustness.
The main idea of the object-oriented method is that it provides a more natural
way to model many real-world situations. The model obtained by the object-
oriented method will be a more direct representation of the situations, providing
a better framework for understanding and manipulating the complex relation-
ships that may exist.
The basic segment of the object-oriented system is an object. Everything that
exists and is distinguishable is an object. Each object has one or more unique
attributes that make it distinguishable from the others.
However, several objects can also have the same structure of attributes and
operations. Only after the attributes’ values are given can an object be
recognized. A set of attribute structures and operations applicable to those
attributes is called a class.
In the object-oriented method, we also recognize the concept of encapsula-
tion. Basically, from an outside point of view, each object is just a thing or a
person (such as a student named Jennie, Andy, etc.). However, if each object
is explored in greater detail, it actually consists of some attributes (identity,
name, status, gender, etc.) for which each object has its own value and so is
distinguishable, as are the operations that are applicable to those sets of data
(print details, set details, etc.). In other words, an object is simply an
encapsulation of data and their operations.

Static Aspects of OOCM

The static aspects of OOCM involve the creation of the objects and classes that
also includes decisions regarding their attributes. In addition, the static aspects
of OOCM are also concerned with the relationship between objects, that is,
inheritance, association, and aggregation.

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
 Object-Relational Approaches 3

Objects and Classes

An object can be a physical object, such as a computer, vehicle, or person. It

can be an event such as a queue in front of the teller, sales, and so forth.
People’s roles such as that of an officer, tutor, student, and so forth can also
be classified as objects.
An object is a data abstraction that is defined by an object name as a unique
identifier, valued attributes (instance variables) that give a state to the object,
and methods or routines that access the state of the object. It is convenient to
use a graphical notation to represent an object model. We will use a notation
that is a modified UML notation (Booch, Rumbaugh, & Jacobson, 1999). The
modifications will be clarified throughout this discussion. Most of these relate
to the semantics and definitions of some terms such as composition, aggrega-
tion, and so forth. An object is often drawn as a rectangle having an object name
and its properties (attributes and methods). With far fewer details, an object is
often shown as a square with the object name only. Figure 1.1 gives an
illustration of a graphical notation for objects.
The state of an object is actually a set of values of its attributes. The specified
methods are the only operations that can be carried out on the attributes in the
object. The client of the object cannot change the state except by method
invocation. Thus, an object encapsulates both state and operations. In some
languages, the methods are procedures and functions. A procedure may or may
not have arguments, and it can be used to access the attributes of an object. A
function is similar to a procedure, but it returns a value.
Objects are the basic run-time entities in an object-oriented system. An object
can be created only during run time. Figure 1.2 shows an example where at run
time an object Staff with name Adam is a staff member in the computer-science
department.

Figure 1.1. Object

Person
object
ID name
name attributes
address

get_age ( ) methods

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
4 Rahayu, Taniar and Pardede

Figure 1.2. Object as run-time entity

Staff

name = ‘Adam’
work = Department

put_staff ( ) name = ‘Computer Science’

set_staff ( ) mail = 39

set_details ( )
put_details ( )

Each object has an identity, called object identity (OID). An OID is an

invariant property of an object that distinguishes it logically and physically from
all other objects. An OID is therefore unique. Two objects can be equal without
being identical.
Along with objects, we also need to understand classes. It is important to
distinguish between them, and they should not be confused.
A class is a description of several objects that have similar characteristics
(Dillon & Tan, 1993). Coad and Yourdon (1990) described class as a set of
specifications that characterizes and is applicable to a collection of objects.
Objects of the same class have common methods and, therefore, uniform
behavior. Class is a compile-time notion, whereas objects exist only at run time.
Therefore, a class has three aspects: the type as attributes and applicable
routines, a container of objects of the same type, and an instantiation
mechanism, such as to create.

Inheritance Relationships

An inheritance relationship is generally known as a generalization or special-

ization relationship, in which the definition of a class can be based on other
existing classes. Given that a class inherits from another class, the former class
is known as a subclass, whereas the latter is the superclass.
A subclass is a class that inherits from at least one generalized class that is the
superclass. Consequently, a subclass must have all the properties of the
superclass, and may have others as well. In other words, a subclass is more
specialized than the superclass. Inheritance is a key feature of the object-
oriented paradigm.

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
 Object-Relational Approaches 5

Figure 1.3. Inheritance relationship as an extension

Person superclass
name
address

is a

Student subclass
student_ID
major

Consider Figure 1.3 as an example. Suppose there are two classes: Person and
Student. In this case, every student must be a person, so Student class inherits
from Person class. All features that apply to a person are applicable to a
student, and every student is a person. A student will also have a name and an
address from Person class. Moreover, a student can have additional features.
Therefore, the inheritance mechanism can be viewed as an extension of a
superclass.
On the other hand, rather than being considered as an extension, inheritance
can be viewed as a restriction on the superclass by hiding previously exported
features of the superclass. Figure 1.4 shows an example of using inheritance as
a restriction. Beside features such as name, address, and so forth, Employee
class has an attribute salary, whereas Volunteer class, which is a special case
of employee, does not receive any salary.

Figure 1.4. Inheritance relationship as a restriction

Emp loyee superclass

salary

is a

Vo lunteer subclass
no_salary

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
6 Rahayu, Taniar and Pardede

If several classes have considerable commonality, it can be factored out in a

deferred or abstract class. The differences are provided in several subclasses
of the deferred class. A deferred class provides only a partial implementation
of a class or no implementation at all. From the design point of view, a deferred
class provides the global view of a class, although the details have not yet been
implemented.

Association Relationships

Association refers to a connection between object instances. Association is

basically a reference from one object to another that provides access paths
among objects in a system.
Objects are connected through an association link. The link can have a
specified cardinality, such as one-to-one, one-to-many, and many-to-many. In
addition to this, in object orientation, collection types have also been intro-
duced and can characterize an association link.

One-to-One Association

In this type, only one object can be connected with another object of the other
type for the particular association link, and vice versa.
For example, in Figure 1.5, Staff class and Office class are connected through
a work_in association link. The link is one-to-one type because only one staff
can work in one office, and one office can have only one staff working in it.

One-to-Many Association

In this type, the first object can be connected only with one of the second
object, but the second object can connect with many of the first object.

Figure 1.5. One-to-one association

1 work_in 1
Staff Office

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
 Object-Relational Approaches 7

Figure 1.6. One-to-many association

1… enrolled_in 1
Student Department

Figure 1.7. Many-to-many association

1… takes 1…
Student Subject

For example, in Figure 1.6, Student class and Department class are connected
through an enrolled_in association link. The link is one-to-many type because
one student can enroll only in one department, but one department can have
many students enrolled in it.

Many-to-Many Association

In this type, one object can be connected with many objects of the other type
for the particular association link, and vice versa.
For example, in Figure 1.7, Student class and Subject class are connected
through a takes association link. The link is a many-to-many type because one
student can take many subjects, and one subject can be taken by many
students.

Aggregation Hierarchies

Aggregation is a tightly coupled form of association (Rumbaugh, Blaha,

Premerlani, Eddy, & Lorensen, 1991). The main difference between aggrega-
tion and association is the underlying semantic strength. While an aggregation
forms a method of organization that exactly maps human thinking, an associa-
tion is a mere mapping between objects in an application (Coad & Yourdon,
1991).
Aggregation is a composition or “part-of” relationship, in which a composite
object (whole) consists of other component objects (parts). This relationship
is used extensively in the areas of engineering, manufacturing, and graphics

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
8 Rahayu, Taniar and Pardede

design. In these applications, when a composite object is created, one may

merely want to know the type of the parts involved without being bothered with
the details. At other times, one may need the details of a particular part only
(Dillon & Tan, 1993).
In an aggregation relationship, in which one whole can have many parts
associated with it through a part-of relationship, the entire part-of relationship
is viewed as one composition, not several association relationships. Let us
consider an aggregation relationship between a PC (personal computer) as a
whole and its parts consisting of the hard disk, monitor, keyboard, and CPU
(Figure 1.8). It would be inappropriate to model the aggregation as an
association since the composition semantic would be lost in the association.
Modeling the above example as an association will form several association
relations, namely, the PC and hard disk, PC and monitor, PC and keyboard,
and PC and CPU. Instead of creating one composition, we will end up with
several associations.
Because the relationship between the whole and the parts is very clearly
designated in aggregation relationships, we should be able to retrieve all
aggregate parts that belong to a whole by identifying the whole only. For
example, when a PC object is accessed, the aggregate parts Hard Disk,
Monitor, Keyboard, and CPU that belong to that PC can also be identified.
Implementing the above aggregation as an association will require us to go
through every association relationship in order to retrieve all parts that belong
to a whole.
Dillon and Tan (1993), Dittrich (1989), and Kim (1990) identify four types of
composition: sharable dependent, sharable independent, nonsharable depen-
dent, and nonsharable independent. We will refer to nonsharable and sharable
as exclusive composition and nonexclusive composition, and dependent
and independent as existence-dependent and existence-independent com-
position, respectively.

Figure 1.8. Aggregation

PC

Hard Disk Monitor Keyboard CPU

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
 Object-Relational Approaches 9

Existence-Dependent and Existence-Independent Composition

When the existence of the part object is fully dependent on the whole object,
then the aggregation relationship is of an existence-dependent type. In this type
of aggregation, whenever the whole object is removed, then all its associated
part objects will also be removed. Thus, no part object can exist without an
associated whole object. This is the most common type of aggregation, where
the whole object is more like a container object. When the existence of a part
object is independent of any whole object, we will have an existence-
independent aggregation.
Existence-dependent and existence-independent compositions are two aggre-
gation types in which the dependencies between the whole object and its part
objects are significant.
Figure 1.9 shows an example of an existence-dependent composition. In the
example, a Course Outline object is an encapsulation of several part objects,
that is, Course Objectives, Course Contents, and Course Schedule. When a
whole object is accessed, its part objects can be identified without the necessity
to trace every link from the Course Outline object. In an existence-dependent
type of composition, the deletion of a course outline will cause the deletion of
that particular course outline and all of its elements.
In an existence-independent type of composition, the existence of the part is
independent. For example, in Figure 1.10, if for some reason Travel Docu-
ments is removed, the ticket, itinerary, and passport still exist.

Figure 1.9. Existence-dependent composition

Course Outline

1… 1… 1…
Course Objectives Course Content Course Schedule

Figure 1.10. Existence-independent composition

Travel Documents

1… 1… 1…
Tickets Itinerary Passport

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
10 Rahayu, Taniar and Pardede

Exclusive and Nonexclusive Composition

When in an aggregation relationship a particular part object can be shared by

more than one whole object, then we have a nonexclusive type. Otherwise,
when each part object is exclusive to a particular whole only, then it is an
exclusive type of aggregation.
Creating an exclusive composition means that the whole object is the sole
owner of the part objects. The need for exclusiveness arises particularly when
modeling physical objects, such as vehicles, bridges, electronic devices, and so
forth. In order to capture the semantics of such applications, the aggregation
relationship should emphasise the exclusivity; for example, a laptop does not
share a CPU or hard disk with other laptops.
In the example shown in Figure 1.11, we need to ensure that every part object
is exclusively owned by a particular whole only.
In a nonexclusive composition, a part of one whole object may be shared or
referenced by other whole objects, and thus the part is not exclusive. For
example, a binary file or a text file can be referenced by more than one directory
(see Figure 1.12).
It is important to note that in UML, the term composition refers to exclusive and
dependent aggregation. However, we use composition interchangeably with
aggregation and use qualifications to distinguish between the different categories.

Figure 1.11. Exclusive composition

Laptop

1 1
CPU Hard Disk

Figure 1.12. Nonexclusive composition

Directory

1…

1… 1…
Binary File Text File

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
 Object-Relational Approaches 11

Homogeneous Composition

The previous examples are categorized into a heterogeneous composition since

one whole object may consist of several different types of part objects. In
contrast, homogeneous composition implies that one whole object consists of
part objects of the same type.
In the example shown by Figure 1.13, a Hard Disk object consists of several
Hard-Disk Controllers. Once we add another type under the whole, the type
has changed into heterogeneous composition.
The main advantage of modeling the homogeneous type of composition is that
the model is flexible enough for further extensions or modifications to include
components of another type. In the case of a mixture of homogeneous and
heterogeneous components, the homogeneous composition is indicated by the
cardinality, namely, 1 to n.

Multilevel Composition Objects or Complex Objects

In many applications, the composition hierarchy may span an arbitrary number

of levels. If one gets a composite or aggregated object design that has

Figure 1.13. Homogeneous composition

Hard Disk
1
1…
Hard-Disk Controller

Figure 1.14. Entertainment-unit complex object

Entertainment Unit AGGREGATE

(level 1 of path 1)
1
AGGREGATE 1 1
(level 2 of path 1) Visual Unit Audio Unit
AGGREGATE
1 (level 2 of path 2)
1 1
Screen Projector

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
12 Rahayu, Taniar and Pardede

component objects that are themselves composite or aggregated objects, then

one gets a two-level aggregation or composition hierarchy. This hierarchy
could be repeated to several levels of composition or aggregation. Because of
the arbitrary number of the part-of relationships between the objects, the
objects involved in the composition are also known as complex objects.
Figure 1.14 shows an example of an entertainment-unit multilevel composition
hierarchy. The aggregation relationships in each level of the composition can be
seen as a type of simple aggregation relationship (e.g., existence dependent or
independent, exclusive or nonexclusive, or homogenous). However, a multi-
level composition hierarchy may include different types of aggregation relation-
ships at each level of the composition.

Dynamic Aspects of OOCM

Dynamic aspects can be called implementation or behavioral aspects of

OOCM. They involve the creation of the routines. Routines are specified as
operations or methods, which are defined in the class that describes the object.
The specified routines are the only operations that can be carried out on the
attributes in the object. The client of the object cannot change the state
(attributes) except by routine call. Routines form the interface between the state
of an object and the user.
Routines are implemented in OOCM using the encapsulation concept. Encap-
sulation, also known as information hiding, prevents the client programs from
seeing the internal part of an object where the algorithm of the routines and the
data structures are implemented, which does not need to be known by the
clients. Figure 1.15 shows the encapsulation of an object.

Figure 1.15. Encapsulation of attributes and routines

Object

Attributes

Client Programs Routines

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
 Object-Relational Approaches 13

Methods as a routine can be divided into two main parts: the generic method
and user-defined method.

Generic Methods

Generic methods are used to access attributes of an object. The concept behind
the need for generic methods is encapsulation, in which attributes associated
with an object can be accessed directly only by the methods of the object itself.
In object orientation, attributes refer to simple or primitive types (such as
integer, string, etc.), user-defined objects (such as Person, Student, etc.), or
collection types (such as list, array, set, and bag). Generic methods should
provide ways for accessing the different types of attributes.
Generic methods may have the following operations: retrieval, update,
delete, or insert. The retrieval generic methods are methods to retrieve the
attributes’ values. They are actually read-only methods and are often known as
queries. The update generic methods are used to update the values of the
specified attributes. The delete generic methods are used to delete the specified
attributes’ values. Since the update and the delete generic methods manipulate
the values of the specified attributes, they are often associated with the data-
manipulation language (DML). The insert generic methods insert new values to
the specified attributes. This is similar to the concept of object creation in an
object-oriented environment.
All of the above operations (i.e., retrieve, update, delete, and insert) can be
applied to inheritance, association, and aggregation hierarchies. Generic meth-
ods on inheritance hierarchies are methods that access attributes in inheritance
hierarchies. Normally, the method is declared in a subclass and accesses the
value of the superclasses’ attributes, and it may also access local attributes
(attributes of the subclass) as well.
Generic methods on association structures are methods that access attributes
of classes along an association structure. If two classes are associated through
an association relationship, methods declared in one class may access at-
tributes of the other class.
Generic methods on aggregation hierarchies are methods that access attributes
of other specified classes in an aggregation hierarchy. If the method is declared
in a whole class, the methods may access attributes of its part classes. The
opposite is applied if the method is declared in a part class, where it may access
attributes of the whole class as well as its own. Figure 1.16 illustrates the

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
14 Rahayu, Taniar and Pardede

Figure 1.16. A taxonomy for generic methods

Retrieve Update Delete Insert

Inheritance

Association

Aggregation

taxonomy of generic methods in object orientation. The matrix indicates the

operations in generic methods including retrieve, update, delete, and insert, and
object hierarchies including inheritance, association, and aggregation hierar-
chies.
In the transformation of generic methods into object-relational operations, we
consider all of the operations specified above (i.e., retrieval, update, delete,
and insert) and operations on object hierarchies (i.e., inheritance, association,
and aggregation).
In this book, a semiautomatic transformation of object-oriented generic
methods into a set of object-relational operations is presented. These relational
operations can subsequently be implemented as stored procedures. The
transformation rules are determined by the different types of attributes being
accessed by the generic methods (result type), as mentioned above, and the
structure of the objects that own the generic methods.

User-Defined Methods

As suggested by the name, user-defined methods are nongeneric methods that

are defined by users in order to perform certain database functionality. In this
book, the representation of user-defined methods in object-relational data-
bases is presented. The functions and expressions used to represent user-
defined methods are supported by most commercial database systems avail-
able today. Ways by which to optimise queries that access the stored
procedures are also described.

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
 Object-Relational Approaches 15

New Era of
Object-Relational Approaches

As mentioned in the previous sections, object-oriented concepts provide an

excellent basis for modeling because the object structures permit analysts and
designers to focus on a problem at a high level of abstraction, but with a resulting
design that can be easily and practically implemented. In the past few years,
more software has been written using the object-oriented paradigm. Many
prototypes as well as commercial object-oriented DBMSs (OODBMSs) such
as O2, Versant, POET, ONTOS, Objectivity, GemStone, and ObjectStore
have been developed by both industrial and research laboratories around the
world (Deux, 1990; Kim, 1990; Robie, Lapp, & Achach, 1998; Stonebraker,
1990).
Nevertheless, object-oriented databases are still not as widely used as rela-
tional databases (RDBs) that rest on a firm formal foundation. Stonebraker
(1996) reports that the OODBMS market is 100 times smaller in comparison
with the RDBMS market, and it is expected that this figure will be maintained
in many years to come. It is a fact that RDBs still largely dominate the database
community. RDBMS technology is considered mature and has been the basis
of a large number of applications around the world. However, the relational
approach, when used to model real-world problems, is not nearly strong
enough to model all the different kinds of relationships, both static and dynamic.
This also includes the fact that the relational model has a lack of semantic
features and an inability to represent complex structures and operations (Kim,
1995).
The object-oriented data model has significant benefits in the areas of semantic
data modeling. These rich semantics are lacking in the relational model. On the
other hand, in the implementation of the data model, there are major strengths
of the existing RDBMS that OODBMS does not have. These include RDBMS’s
widespread acceptance as well as the simplicity of the query processing.
The above reasons have stimulated the emergence of a new approach in the
development of database systems, namely, the object-relational approach. In
general, this approach is a method of combining both object-oriented and
relational approaches with the aim of incorporating the advantages of each and
eliminating their drawbacks.
In the next sections, the object-relational approach is grouped into five major
categories.

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
16 Rahayu, Taniar and Pardede

OOCM Implemented on Relational Databases

Despite the differences between the object-oriented and the relational para-
digm, in reality, most of object-based development systems are still using the
RDBMS engine as their persistence mechanism. Therefore, a transformation
from object-oriented models into relational structures and operations is crucial.
Much work has been done in this area, where each structure in the OOCM is
transformed into implementation in pure RDBMS (Rahayu, Chang, Dillon, &
Taniar, 2000, 2001). This method is especially useful when the RDBMS
chosen for the implementation is a pure RDB that does not support object-
oriented extensions (SQL 92 standard).

Object Wrappers on Relational Systems

An object wrapper (see Figure 1.17) is basically a layer on top of a

conventional RDB engine that simulates object-oriented features. One of the
main aims of this layer is to transform object queries (OQL) submitted by users
into relational queries. OQL is an enhanced relational query with additional
capabilities to understand arbitrary complex types as well as user-defined
operations. Thus, the user is allowed to interact with the system through the
object wrapper as if it were an OODBMS even though the underlying
mechanism is RDBMS.
It is necessary to have a solid transformation methodology that can be used by
the object wrapper to perform the translations of the object-oriented features
to their relational equivalent for interaction with the underlying RDBMS. The
transformation methodology should not only provide translation techniques,
but also ensure efficient access to the result of the translation process.

Figure 1.17. Object wrappers on relational systems

Object Wrapper

SQL
User
Applications OQL
RDBMS

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
 Object-Relational Approaches 17

Figure 1.18. Extended relational systems

Extended
Relational System

User SQL
Applications Object-
Oriented
Features
RDBMS

Extended Relational Systems

In this category, relational systems are extended in order to support object-

oriented features (see Figure 1.18). The extensions include the support of
object identifiers, inheritance structures, complex type representations, and
user-defined operations.
The SQL3 standard and the forthcoming SQL4 may provide the solution to
standardizing the extensions to RDBMS. However, until now, work on SQL4
is still ongoing, and none of the existing extended relational systems fully
supports the standard, even for SQL3.
There are several different approaches that belong to this category. One of the
approaches used for capturing the concept of complex structures is to allow
relations to have attributes that are also relations, thereby abandoning the first
normal form of the relational model. The model, which is known as the nested-
relations or NF2 (nonfirst normal form) data model (Scheck & Scholl, 1986),
can be used to represent composite objects and set-valued attributes. An
example is a DBMS prototype developed by Dadam et al. (1986) that supports
the NF2 model.
Another approach in this category is an extension of a conventional SQL that
is used to retrieve and manipulate data. For example, POSTGRES (Stonebraker,
1986) provides an extended SQL called POSTQUEL query with the ability to
capture the concept of abstract data types (encapsulated data structures and
methods), inheritance structures, and object identity. Another example is
Starburst (Lindsay & Haas, 1990; Schwarz et al., 1986) that extends the
relational algebra and supports user-defined operations and complex types.
Oracle™ 8 and above provide the implementation of most of the above
extensions. It allows the creation of objects and user-defined types, encapsu-
lation of data structure and methods, complex relationships including inherit-

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
18 Rahayu, Taniar and Pardede

Figure 1.19. Object-relational coexistence approach

User Applications

Object-Oriented API/Gateway RDBMS

Programming

ance and referencing, as well as composition through nested tables and

collection types. Because of this, we will use Oracle™ throughout this book to
demonstrate the design and implementation of object-relational databases.

Object-Oriented System and RDBMS Coexistence

As opposed to a hybrid system in which both object-oriented and relational

systems are combined into a single system, the coexistence approach provides
an interface that allows object-oriented systems to access and manipulate a
relational system by encapsulating RDB entities such as tables and queries into
objects. For example, Borland Database Engine API for Borland C++ Builder
allows an object-oriented programming language C++ to access standard data
sources in Paradox, dBase, or Interbase format. Similar interfaces such as
Microsoft Jet Database Engine are used by Microsoft Visual C++.
This coexistence approach (see Figure 1.19) is obviously quite attractive to
many commercial vendors. The main reason for this is that the cost of building
the overall system is minimized by taking the two systems (object-oriented
system and RDBMS) and letting them coexist. The work required to accom-
modate the new functionality in both systems and to let them communicate in
a coexistent environment is far less than the effort needed to combine both
systems into a single hybrid system.
Even though no attempt is made to enforce the storage of the object instances
within the schema for the RDBMS, it is essential to have a solid methodology
for the transformation of the object model into the associated relational
schemas that ensures correctness and efficiency of the data storage and
retrieval.

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
 Object-Relational Approaches 19

Figure 1.20. OODBMS-RDBMS interoperation

OODBMS RDBMS

Translator
User User
Applications Applications

OODBMS and RDBMS Interoperation

In the interoperation approach (see Figure 1.20), a request from an originating

database side is translated and routed to a target database side for processing.
The result is then returned to the originator of the request. To achieve
transparency of the interoperation process, translation between the different
models of the participating database systems must be performed during the
data interchange (Ramfos et al., 1991). There are two major translations
needed in this approach:

• schema translations, where the schema of the target database is translated

into the data-definition language (DDL) of the originating database side,
and
• query translations, where a query in the DML of the originating database
side (posed against the above produced schema) is translated into the
DML of the target database side.

This approach is frequently used in a multi-DBMS. A multi-DBMS is a system

that controls multiple translators (or gateways), one for each remote database
(Kim, 1995). In this type of environment, it is possible for one application
program to work with data retrieved from both one OODBMS and one or
more RDBMSs.
To develop a comprehensive translator, the identification of the schemas and
operations owned by each of the participant database sides, OODBMS and
RDBMS, needs to be fully understood. A complete methodology that supports

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
20 Rahayu, Taniar and Pardede

the theoretical mapping from the originating schema into the target schema is
essential. Ideally, this mapping methodology should cover both the structural
component as well as the dynamic component of the database systems.

Object-Relational Database System

The relational data model has a sound theoretical foundation, is based on the
mathematical theory of relations and first-order logic, and gives the users a
simple view of data in the form of two-dimensional tables. Many DBMSs use
this relational model. Even nonrelational systems are often described as having
supporting relational features for commercial purposes. The model’s objec-
tives were specified as follows.

• To allow a high degree of data independence. The application programs

must not be affected by modifications to the internal data representation,
particularly by the changes of file organizations, record orderings, and
access paths.
• To provide substantial grounds for dealing with data semantics, consis-
tency, and redundancy problems.
• To enable the expansion of set-oriented DMLs.
• To become an extensible model that can describe and manipulate simple
and complex data.

The first two objectives have been achieved by the relational model, mainly
because of the simplicity of the relational views presenting the data in two-
dimensional tables and the application of the normalization theory to database
design.
The third objective has been achieved by the use of relational algebra, which
manipulates tables in the same way that arithmetical operators manipulate
integers, and by nonprocedural languages based on logical queries specifying
the data to be obtained without having to explain how to obtain them.
The last objective is the essence of current developments concerning extended
relational and object-relational models.

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
 Object-Relational Approaches 21

Case Study

The Australian Education Union (AEU) keeps the records of its properties and
activities in a database using an object-oriented concept. Property can be
divided into two main categories: building and vehicle. Beside these two, there
are also other minor properties that are not categorized into building and
vehicle. Each building has several rooms and each room has computers in it.
Some of the rooms also have overhead projectors (OHPs).
The union employees’ records are kept in a separate class. Employees can be
divided into two types: office staff and organizers. Management is not included
in these two categories, although their data is also kept in the employee class.
While office staff work only internally in the union, the organizers have to
represent teachers in the area to which they have been assigned. One organizer
can represent many teachers, but one teacher can have only one organizer as
her or his representation. For this purpose, each organizer has been given one
vehicle, and that vehicle may be used only by that particular organizer. Each
organizer will be assigned only one area, which can be divided into several
suburbs. The area and suburb data are also kept in separate classes.
The union also keeps records for teachers who are union members. All of these
teachers have to work in government schools. Although it is not common, a
teacher can work in more than one school. The type of school that can liaise
with AEU has to be categorized into one of the three distinct types: primary
school, secondary school, and technical college (TechC).
We will draw an object-oriented model of the AEU database and determine the
type where necessary. We will identify the objects and the relationships as
follows.

• Identify Objects
To start with, we know that there will be a union object to store the data
about the AEU organization. It also has a property object that can be
divided into building and vehicle objects. Furthermore, there is a room
object that is composed of PC and OHP objects.
Next, we will need an employee object for AEU’s employee records.
Their types are also objects: Office Staff and Organizer. For working area
and suburb, we need two new objects as well.

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
22 Rahayu, Taniar and Pardede

Finally, as employees will need to work with teachers, we need a teacher

object. Along with that, the additional objects of School and its special-
izations—Primary, Secondary, and TechC—will be added.
• Identify Relationships
There will be three types of relationships that we need to recognize before
producing the object-oriented model diagram.
First, we need to identify inheritance relationships. Inheritance can be
shown by the generalization-specialization feature. One of them is be-
tween Employee and its specializations Office Staff and Organizer.
Property can also be specialized into Vehicle and Building. And the last
one is the specialization of School into Primary, Secondary, and TechC.
Second, we need to identify association relationships. This relation is
usually the most frequent relation in an object-relational system. From the
union object there are two associations: one to Property (one to many)
and the other one to Employee (one to many). Organizer has three

Figure. 1.21. Object-oriented diagram of AEU case study

1… 1 1 1…
works has
Employee Union Property

1 uses 1
Office Staff Organizer Vehicle Building
1
1 1
represents 1…
assigned in
Rooms
1 1…
1
Area Teacher
1 1…
1… 1…
1…
PC OHP
Suburb
teaches in

1…
School

Primary Secondary TechC

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
 Object-Relational Approaches 23

association relationships, that is, associations to Vehicle (one to one),

Area (one to one), and Teacher (one to many). The last association
relation is between Teacher and School (many to many).
The last relationship type is aggregation. Building has two levels of
aggregation. The first level is homogeneous aggregation to Room, and the
second level is to PC and OHP. Another homogeneous aggregation
relationship is between Area and Suburb.

After identifying the objects and their relationships, we can draw down the
object-oriented model for the AEU case study as it is shown in Figure 1.21.

Summary

An approach to a new model in database systems is needed due to the limitation

of the relational model that is widely used commercially. The relational model
is not rich enough to represent the high complexity of real-world problems. On
the other hand, the object-oriented model that is well recognized as a very
powerful approach to model high-complexity problems, such as in procedural
languages, is not a well-known database system model. Also, users still like the
ease of use of the relational model.
Although the most widely used model of current database systems is a relational
model, it can also be extended to adopt the concept of the object-oriented
model. In an object-oriented model, the objects encapsulate their attributes
and their methods from other objects, thereby facilitating the concept of
information hiding. This model also accommodates the structural relationship of
classes and objects, which can be categorized into inheritance, association, and
aggregation, and the implementation of methods that consist of generic methods
and user-defined methods.

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
24 Rahayu, Taniar and Pardede

References

Ambler, S. W. (1997). Mapping objects to relational databases. In Building

object applications that work. SIGS Books.
Booch, G., Rumbaugh, J., & Jacobson, I. (1999). The unified modeling
language user guide. Reading, MA: Addison-Wesley.
Coad, P., & Yourdon, E. (1990). Object-oriented analysis. Englewood
Cliffs, NJ: Yourdon Press.
Coad, P., & Yourdon, E. (1991). Object-oriented design. Englewood Cliffs,
NJ: Yourdon Press.
Dadam, P., et al. (1986). A DBMS prototype to support extended NF2
relations: An integrated view on flat tables and hierarchies. Proceedings
of the ACM SIGMOD Conference.
Deux, O. (1990). The story of O2. IEEE Transactions on Data and
Knowledge Engineering TKDE, 2(1), 91-108.
Dillon, T. S., & Tan, P. L. (1993). Object-oriented conceptual modeling.
Prentice-Hall.
Dittrich, K. R. (1989). Object-oriented database systems for information
systems of the future. In Seminar notes. Melbourne, Australia.
Halper, M., Geller, J., & Perl, Y. (1992). “Part” relations for object-oriented
databases. Proceedings of the 11th International Conference on the
Entity-Relationship Approach.
Kim, W. (1990). Introduction to object-oriented databases. The MIT
Press.
Kim, W. (1995). Modern database systems. Addison-Wesley.
Lindsay, B. G., & Haas, L. M. (1990). Extensibility in the starburst experimen-
tal database system. In IBM symposium: Database systems of the 90s
(pp. 217-248). Springer-Verlag.
Rahayu, J. W., Chang, E., Dillon, T. S., & Taniar, D. (2000). A methodology
for transforming inheritance relationships in an object-oriented concep-
tual model to relational tables. Information and Software Technology
Journal, 42(8), 571-592.
Rahayu, J. W., Chang, E., Dillon, T. S., & Taniar, D. (2001). Performance
evaluation of the object-relational transformation methodology. Data and
Knowledge Engineering, 38(3), 265-300.

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
 Object-Relational Approaches 25

Ramfos, A., et al. (1991). A meta-translation system for object-oriented to

relational schema translations. In M. S. Jackson & A. E. Robinson (Eds.),
The Proceedings of the Ninth British National Conference on Data-
bases (BNCOD).
Robie, J., Lapp, J., & Achach, D. (1998). XML query language (XQL). The
Query Languages Workshop.
Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F., & Lorensen, W. (1991).
Object-oriented modeling and design. Prentice Hall.
Scheck, H. J., & Scholl, M. H. (1986). The relational model with relation-
valued attributes. Information Systems, 11(4).
Schwarz, P. M., Chang, W., Freytag, J. C., Lohman, G. M., McPherson, J.,
Mohan, C., et al. (1986). Extensibility in the starburst database system.
Proceedings of OODBS 1986 (pp. 85-92).
Stonebraker, M. (1986). Object management in postgres using procedures.
Proceedings of OODBS 1986 (pp. 66-72).
Stonebraker, M. (1990). The postgres DBMS. Proceedings of SIGMOD
1990 (p. 394).

Chapter Problems

1. List five major categories of an object-relational approach.

2. Discuss the static and dynamic aspects of an object-oriented model.
3. Discuss the background of object-relational DBMS (ORDBMS) devel-
opment.
4. Explain the terms existence-dependent, existence-independent, exclu-
sive–composition, and nonexclusive composition for aggregation rela-
tionships.
5. Each postgraduate student at L University needs to maintain a list of
references that he or she needs for research. For this purpose, references
used are categorized into four types: book, article in a journal, conference
paper, and PhD thesis. A reference can be included in one type only. The
fields of each type of reference are listed in the following table.

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
26 Rahayu, Taniar and Pardede

Reference Type Fields

Book title of the book, list of authors, publisher
Article Journal title of the paper, list of authors, title of the journal,
volume, editor, publisher
Conference Paper title of the paper, list of authors, title of the conference,
publisher
PhD Thesis title of the thesis, author, school

Assuming that there are five classes, that is, References, Book,
Article_Journal, Conference_Paper, and PhD_Thesis, develop the class
hierarchy for the above description, and draw the corresponding class
diagram. You also need to identify the relationship between references
and another class, Postgraduate. Assume some attributes where neces-
sary.
6. AllBooks Library wants to extend its database by using the object-
oriented concept. For this purpose, in the database the authors are
categorized according to their backgrounds: industry based or academic.
If the author is an academic, the database needs to be further categorized
into research or teaching staff. They found that many academics are also
involved in industry and vice versa. However, it is found that an academic
may simultaneously be involved in both research and teaching. To simplify
the database, the developer decides that an academic can only be
recorded as a research staff or a teaching staff depending on his or her
primary role.
In the database, the books that the authors have written or edited are kept
in a different object named Course_Manual. For each datum in
Course_Manual, there are descriptions of each chapter that are kept as
another object. Draw the diagram for the object-oriented model de-
scribed above.
7. A new fast-food company, Hungry Burger, has just opened its first
restaurant in the country. One of its main menu items is called Huge Meal.
The Huge Meal package includes a big special hamburger, a drink, and a
generous-size bag of fries. The construction of the hamburger at Hungry
Burger has a special order that has to be followed. On the lower half of
the bun, kitchen staff will put a slice of meat patty, followed by two pieces
of lettuce, a slice of cheese, and a slice of tomato. The fries are made of
potatoes fried in grease. The hamburger and the fries may be sold
separately or with another package on the menu.

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
 Object-Relational Approaches 27

Draw the aggregation diagram for Hungry Burger’s Huge Meal. Explain
the dependency, order, and also the exclusiveness where necessary.
8. The Fast Run Bicycle Company is a major bicycle retailer. Unlike other
bicycle companies, it assembles its own bicycles to meet the customers’
requirements. The three main components are seats, frames, and wheels.
These three main components are inherited from the part class and these
parts are bought from several manufacturers. There are three categories
of bicycles assembled by Fast Run: racing, mountain, and road bicycles.
From the description given, draw a diagram for Fast Run that shows the
aggregation, inheritance, and association relationships.

Chapter Solutions

1. Five major categories of an object-relational approach are as follow.

• OOCM implemented on relational databases

• Object wrappers on relational systems
• Extended relational systems
• Object-oriented systems and RDBMS coexistence
• OODBMS and RDBMS interoperation

2. Static aspects of an object-oriented model include the object and class

data structure that facilitates encapsulation, and the relationships that can
be divided into three major divisions: inheritance, association, and aggre-
gation. The dynamic aspects of an object-oriented model include the
implementation of methods or operations, both generic methods and user-
defined methods.
3. ORDBMS is developed to add the desirable features of the object-
oriented model to the relational database system. RDBMS has been
widely used commercially and in addition, it is also reasonably simple to
implement. However, RDBMS cannot be used to represent certain
complex problems.

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
28 Rahayu, Taniar and Pardede

An object-oriented model can capture most complex-problem domains;

however, the database based on the object-oriented model, OODBMS,
is still not as widely used. It is expected that instead of replacing the earlier
RDBMS, OODBMS will coexist in order to serve some specific problem
areas only. Therefore, the combination of both strengths have been
explored and implemented in the new database system: ORDBMS.
4. Existence-dependent composition is the type of aggregation where the
part objects are totally dependent on the whole object. Thus, by removing
the whole object, we will automatically remove the part objects. On the
other side, existence independent is the type of aggregation where the part
object can still exist although its whole object is removed.
Exclusive composition is the type of aggregation where the whole object
is the sole owner of the part object. On the other side, nonexclusive
composition is the type of aggregation where a part object of one whole
object may be shared or referenced by other whole objects.
5. There is an inheritance relationship between the reference object to the
subclass type.
The association between Postgraduate and References is many to many,
where each reference can be used by many postgraduates, and each
postgraduate can refer to many references.
refers to
Postgraduate References
1… 1…
name ID
address year
degree get_ID ( )
get_name ( )

Book Article_Journal Conference_Paper PhD_Thesis

title title title title
authors authors authors author
publisher title_journal title_conference school
year volume publisher
editor
publisher

6. There is an inheritance relationship between superclass Author and its

subclasses. There is also an aggregation relationship between the
Course_Manual and Chapter classes, which in this case is homogeneous.
The whole object consists of part objects that are the same type.

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
 Object-Relational Approaches 29

writes
Author Course_Manual
1

homogeneous
Industry_Based Academic
1…
Chapter

Research_Staff Teaching_Staff

7. The aggregation at Level 1 is existence independent because the part

object can be sold separately without the whole object. It is an exclusive
composition because one part, for example, one hamburger, can only be
a composite of one whole part.
The aggregation at Level 2 is existence dependent. There is room for
argument for this one. Although all parts can exist on their own, they do
not have value. This aggregation is also an exclusive composition because
one part, for example, one particular bun, can only be a part of one
particular hamburger.
Huge Meal

1 1 1
Hamburger Drink Fries

1 1

1 1 1… 1 1 1… 1…
Bun Meat Lettuce Cheese Tomato Potato Grease

8. Bicycle is an aggregation of Seat, Frame, and Wheel. The type is an

exclusive composition as a particular part can only be incorporated into
a particular whole. It is also an existence-dependent composition because
the seat, frame, and wheels do not have their own value at Fast Run unless
they are assembled into a bicycle.
The bicycle class also has an inheritance relationship to the racing,
mountain, and road bicycles. The parts class with the seat, frame, and
wheel classes show another inheritance relationship.

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
30 Rahayu, Taniar and Pardede

Finally, there is a one-to-many association relationship between Custom-

ers and Bicycle, and a many-to-many relationship between Parts and
Manufacturers.
Racing_Bicycle Mountain_Bicycle Road_Bicycle

sold to
Bicycle Customers
1… 1
1

1 1 2
Seat Frame Wheel

made by
Parts Manufacturers
1… 1…

Copyright © 2006, Idea Group Inc. Copying or distributing in print or electronic forms without written
permission of Idea Group Inc. is prohibited.
Another Random Scribd Document
with Unrelated Content
 *** END OF THE PROJECT GUTENBERG EBOOK IN THE GARDEN
***

Updated editions will replace the previous one—the old editions will
be renamed.

Creating the works from print editions not protected by U.S.

copyright law means that no one owns a United States copyright in
these works, so the Foundation (and you!) can copy and distribute it
in the United States without permission and without paying
copyright royalties. Special rules, set forth in the General Terms of
Use part of this license, apply to copying and distributing Project
Gutenberg™ electronic works to protect the PROJECT GUTENBERG™
concept and trademark. Project Gutenberg is a registered trademark,
and may not be used if you charge for an eBook, except by following
the terms of the trademark license, including paying royalties for use
of the Project Gutenberg trademark. If you do not charge anything
for copies of this eBook, complying with the trademark license is
very easy. You may use this eBook for nearly any purpose such as
creation of derivative works, reports, performances and research.
Project Gutenberg eBooks may be modified and printed and given
away—you may do practically ANYTHING in the United States with
eBooks not protected by U.S. copyright law. Redistribution is subject
to the trademark license, especially commercial redistribution.

START: FULL LICENSE

THE FULL PROJECT GUTENBERG LICENSE
 PLEASE READ THIS BEFORE YOU DISTRIBUTE OR USE THIS WORK

To protect the Project Gutenberg™ mission of promoting the free

distribution of electronic works, by using or distributing this work (or
any other work associated in any way with the phrase “Project
Gutenberg”), you agree to comply with all the terms of the Full
Project Gutenberg™ License available with this file or online at
www.gutenberg.org/license.

Section 1. General Terms of Use and

Redistributing Project Gutenberg™
electronic works
1.A. By reading or using any part of this Project Gutenberg™
electronic work, you indicate that you have read, understand, agree
to and accept all the terms of this license and intellectual property
(trademark/copyright) agreement. If you do not agree to abide by all
the terms of this agreement, you must cease using and return or
destroy all copies of Project Gutenberg™ electronic works in your
possession. If you paid a fee for obtaining a copy of or access to a
Project Gutenberg™ electronic work and you do not agree to be
bound by the terms of this agreement, you may obtain a refund
from the person or entity to whom you paid the fee as set forth in
paragraph 1.E.8.

1.B. “Project Gutenberg” is a registered trademark. It may only be

used on or associated in any way with an electronic work by people
who agree to be bound by the terms of this agreement. There are a
few things that you can do with most Project Gutenberg™ electronic
works even without complying with the full terms of this agreement.
See paragraph 1.C below. There are a lot of things you can do with
Project Gutenberg™ electronic works if you follow the terms of this
agreement and help preserve free future access to Project
Gutenberg™ electronic works. See paragraph 1.E below.
1.C. The Project Gutenberg Literary Archive Foundation (“the
Foundation” or PGLAF), owns a compilation copyright in the
collection of Project Gutenberg™ electronic works. Nearly all the
individual works in the collection are in the public domain in the
United States. If an individual work is unprotected by copyright law
in the United States and you are located in the United States, we do
not claim a right to prevent you from copying, distributing,
performing, displaying or creating derivative works based on the
work as long as all references to Project Gutenberg are removed. Of
course, we hope that you will support the Project Gutenberg™
mission of promoting free access to electronic works by freely
sharing Project Gutenberg™ works in compliance with the terms of
this agreement for keeping the Project Gutenberg™ name associated
with the work. You can easily comply with the terms of this
agreement by keeping this work in the same format with its attached
full Project Gutenberg™ License when you share it without charge
with others.

1.D. The copyright laws of the place where you are located also
govern what you can do with this work. Copyright laws in most
countries are in a constant state of change. If you are outside the
United States, check the laws of your country in addition to the
terms of this agreement before downloading, copying, displaying,
performing, distributing or creating derivative works based on this
work or any other Project Gutenberg™ work. The Foundation makes
no representations concerning the copyright status of any work in
any country other than the United States.

1.E. Unless you have removed all references to Project Gutenberg:

1.E.1. The following sentence, with active links to, or other

immediate access to, the full Project Gutenberg™ License must
appear prominently whenever any copy of a Project Gutenberg™
work (any work on which the phrase “Project Gutenberg” appears,
or with which the phrase “Project Gutenberg” is associated) is
accessed, displayed, performed, viewed, copied or distributed:
 This eBook is for the use of anyone anywhere in the United
States and most other parts of the world at no cost and with
almost no restrictions whatsoever. You may copy it, give it away
or re-use it under the terms of the Project Gutenberg License
included with this eBook or online at www.gutenberg.org. If you
are not located in the United States, you will have to check the
laws of the country where you are located before using this
eBook.

1.E.2. If an individual Project Gutenberg™ electronic work is derived

from texts not protected by U.S. copyright law (does not contain a
notice indicating that it is posted with permission of the copyright
holder), the work can be copied and distributed to anyone in the
United States without paying any fees or charges. If you are
redistributing or providing access to a work with the phrase “Project
Gutenberg” associated with or appearing on the work, you must
comply either with the requirements of paragraphs 1.E.1 through
1.E.7 or obtain permission for the use of the work and the Project
Gutenberg™ trademark as set forth in paragraphs 1.E.8 or 1.E.9.

1.E.3. If an individual Project Gutenberg™ electronic work is posted

with the permission of the copyright holder, your use and distribution
must comply with both paragraphs 1.E.1 through 1.E.7 and any
additional terms imposed by the copyright holder. Additional terms
will be linked to the Project Gutenberg™ License for all works posted
with the permission of the copyright holder found at the beginning
of this work.

1.E.4. Do not unlink or detach or remove the full Project

Gutenberg™ License terms from this work, or any files containing a
part of this work or any other work associated with Project
Gutenberg™.

1.E.5. Do not copy, display, perform, distribute or redistribute this

electronic work, or any part of this electronic work, without
prominently displaying the sentence set forth in paragraph 1.E.1
with active links or immediate access to the full terms of the Project
Gutenberg™ License.

1.E.6. You may convert to and distribute this work in any binary,
compressed, marked up, nonproprietary or proprietary form,
including any word processing or hypertext form. However, if you
provide access to or distribute copies of a Project Gutenberg™ work
in a format other than “Plain Vanilla ASCII” or other format used in
the official version posted on the official Project Gutenberg™ website
(www.gutenberg.org), you must, at no additional cost, fee or
expense to the user, provide a copy, a means of exporting a copy, or
a means of obtaining a copy upon request, of the work in its original
“Plain Vanilla ASCII” or other form. Any alternate format must
include the full Project Gutenberg™ License as specified in
paragraph 1.E.1.

1.E.7. Do not charge a fee for access to, viewing, displaying,

performing, copying or distributing any Project Gutenberg™ works
unless you comply with paragraph 1.E.8 or 1.E.9.

1.E.8. You may charge a reasonable fee for copies of or providing

access to or distributing Project Gutenberg™ electronic works
provided that:

• You pay a royalty fee of 20% of the gross profits you derive
from the use of Project Gutenberg™ works calculated using the
method you already use to calculate your applicable taxes. The
fee is owed to the owner of the Project Gutenberg™ trademark,
but he has agreed to donate royalties under this paragraph to
the Project Gutenberg Literary Archive Foundation. Royalty
payments must be paid within 60 days following each date on
which you prepare (or are legally required to prepare) your
periodic tax returns. Royalty payments should be clearly marked
as such and sent to the Project Gutenberg Literary Archive
Foundation at the address specified in Section 4, “Information
 about donations to the Project Gutenberg Literary Archive
Foundation.”

• You provide a full refund of any money paid by a user who

notifies you in writing (or by e-mail) within 30 days of receipt
that s/he does not agree to the terms of the full Project
Gutenberg™ License. You must require such a user to return or
destroy all copies of the works possessed in a physical medium
and discontinue all use of and all access to other copies of
Project Gutenberg™ works.

• You provide, in accordance with paragraph 1.F.3, a full refund of

any money paid for a work or a replacement copy, if a defect in
the electronic work is discovered and reported to you within 90
days of receipt of the work.

• You comply with all other terms of this agreement for free
distribution of Project Gutenberg™ works.

1.E.9. If you wish to charge a fee or distribute a Project Gutenberg™

electronic work or group of works on different terms than are set
forth in this agreement, you must obtain permission in writing from
the Project Gutenberg Literary Archive Foundation, the manager of
the Project Gutenberg™ trademark. Contact the Foundation as set
forth in Section 3 below.

1.F.

1.F.1. Project Gutenberg volunteers and employees expend

considerable effort to identify, do copyright research on, transcribe
and proofread works not protected by U.S. copyright law in creating
the Project Gutenberg™ collection. Despite these efforts, Project
Gutenberg™ electronic works, and the medium on which they may
be stored, may contain “Defects,” such as, but not limited to,
incomplete, inaccurate or corrupt data, transcription errors, a
copyright or other intellectual property infringement, a defective or
damaged disk or other medium, a computer virus, or computer
codes that damage or cannot be read by your equipment.

1.F.2. LIMITED WARRANTY, DISCLAIMER OF DAMAGES - Except for

the “Right of Replacement or Refund” described in paragraph 1.F.3,
the Project Gutenberg Literary Archive Foundation, the owner of the
Project Gutenberg™ trademark, and any other party distributing a
Project Gutenberg™ electronic work under this agreement, disclaim
all liability to you for damages, costs and expenses, including legal
fees. YOU AGREE THAT YOU HAVE NO REMEDIES FOR
NEGLIGENCE, STRICT LIABILITY, BREACH OF WARRANTY OR
BREACH OF CONTRACT EXCEPT THOSE PROVIDED IN PARAGRAPH
1.F.3. YOU AGREE THAT THE FOUNDATION, THE TRADEMARK
OWNER, AND ANY DISTRIBUTOR UNDER THIS AGREEMENT WILL
NOT BE LIABLE TO YOU FOR ACTUAL, DIRECT, INDIRECT,
CONSEQUENTIAL, PUNITIVE OR INCIDENTAL DAMAGES EVEN IF
YOU GIVE NOTICE OF THE POSSIBILITY OF SUCH DAMAGE.

1.F.3. LIMITED RIGHT OF REPLACEMENT OR REFUND - If you

discover a defect in this electronic work within 90 days of receiving
it, you can receive a refund of the money (if any) you paid for it by
sending a written explanation to the person you received the work
from. If you received the work on a physical medium, you must
return the medium with your written explanation. The person or
entity that provided you with the defective work may elect to provide
a replacement copy in lieu of a refund. If you received the work
electronically, the person or entity providing it to you may choose to
give you a second opportunity to receive the work electronically in
lieu of a refund. If the second copy is also defective, you may
demand a refund in writing without further opportunities to fix the
problem.

1.F.4. Except for the limited right of replacement or refund set forth
in paragraph 1.F.3, this work is provided to you ‘AS-IS’, WITH NO
OTHER WARRANTIES OF ANY KIND, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR ANY PURPOSE.

1.F.5. Some states do not allow disclaimers of certain implied

warranties or the exclusion or limitation of certain types of damages.
If any disclaimer or limitation set forth in this agreement violates the
law of the state applicable to this agreement, the agreement shall be
interpreted to make the maximum disclaimer or limitation permitted
by the applicable state law. The invalidity or unenforceability of any
provision of this agreement shall not void the remaining provisions.

1.F.6. INDEMNITY - You agree to indemnify and hold the Foundation,

the trademark owner, any agent or employee of the Foundation,
anyone providing copies of Project Gutenberg™ electronic works in
accordance with this agreement, and any volunteers associated with
the production, promotion and distribution of Project Gutenberg™
electronic works, harmless from all liability, costs and expenses,
including legal fees, that arise directly or indirectly from any of the
following which you do or cause to occur: (a) distribution of this or
any Project Gutenberg™ work, (b) alteration, modification, or
additions or deletions to any Project Gutenberg™ work, and (c) any
Defect you cause.

Section 2. Information about the Mission

of Project Gutenberg™
Project Gutenberg™ is synonymous with the free distribution of
electronic works in formats readable by the widest variety of
computers including obsolete, old, middle-aged and new computers.
It exists because of the efforts of hundreds of volunteers and
donations from people in all walks of life.

Volunteers and financial support to provide volunteers with the

assistance they need are critical to reaching Project Gutenberg™’s
goals and ensuring that the Project Gutenberg™ collection will
remain freely available for generations to come. In 2001, the Project
Gutenberg Literary Archive Foundation was created to provide a
secure and permanent future for Project Gutenberg™ and future
generations. To learn more about the Project Gutenberg Literary
Archive Foundation and how your efforts and donations can help,
see Sections 3 and 4 and the Foundation information page at
www.gutenberg.org.

Section 3. Information about the Project

Gutenberg Literary Archive Foundation
The Project Gutenberg Literary Archive Foundation is a non-profit
501(c)(3) educational corporation organized under the laws of the
state of Mississippi and granted tax exempt status by the Internal
Revenue Service. The Foundation’s EIN or federal tax identification
number is 64-6221541. Contributions to the Project Gutenberg
Literary Archive Foundation are tax deductible to the full extent
permitted by U.S. federal laws and your state’s laws.

The Foundation’s business office is located at 809 North 1500 West,

Salt Lake City, UT 84116, (801) 596-1887. Email contact links and up
to date contact information can be found at the Foundation’s website
and official page at www.gutenberg.org/contact

Section 4. Information about Donations to

the Project Gutenberg Literary Archive
Foundation
Project Gutenberg™ depends upon and cannot survive without
widespread public support and donations to carry out its mission of
increasing the number of public domain and licensed works that can
be freely distributed in machine-readable form accessible by the
widest array of equipment including outdated equipment. Many
small donations ($1 to $5,000) are particularly important to
maintaining tax exempt status with the IRS.

The Foundation is committed to complying with the laws regulating

charities and charitable donations in all 50 states of the United
States. Compliance requirements are not uniform and it takes a
considerable effort, much paperwork and many fees to meet and
keep up with these requirements. We do not solicit donations in
locations where we have not received written confirmation of
compliance. To SEND DONATIONS or determine the status of
compliance for any particular state visit www.gutenberg.org/donate.

While we cannot and do not solicit contributions from states where

we have not met the solicitation requirements, we know of no
prohibition against accepting unsolicited donations from donors in
such states who approach us with offers to donate.

International donations are gratefully accepted, but we cannot make

any statements concerning tax treatment of donations received from
outside the United States. U.S. laws alone swamp our small staff.

Please check the Project Gutenberg web pages for current donation
methods and addresses. Donations are accepted in a number of
other ways including checks, online payments and credit card
donations. To donate, please visit: www.gutenberg.org/donate.

Section 5. General Information About

Project Gutenberg™ electronic works
Professor Michael S. Hart was the originator of the Project
Gutenberg™ concept of a library of electronic works that could be
freely shared with anyone. For forty years, he produced and
distributed Project Gutenberg™ eBooks with only a loose network of
volunteer support.
Project Gutenberg™ eBooks are often created from several printed
editions, all of which are confirmed as not protected by copyright in
the U.S. unless a copyright notice is included. Thus, we do not
necessarily keep eBooks in compliance with any particular paper
edition.

Most people start at our website which has the main PG search
facility: www.gutenberg.org.

This website includes information about Project Gutenberg™,

including how to make donations to the Project Gutenberg Literary
Archive Foundation, how to help produce our new eBooks, and how
to subscribe to our email newsletter to hear about new eBooks.
Welcome to Our Bookstore - The Ultimate Destination for Book Lovers
Are you passionate about books and eager to explore new worlds of
knowledge? At our website, we offer a vast collection of books that
cater to every interest and age group. From classic literature to
specialized publications, self-help books, and children’s stories, we
have it all! Each book is a gateway to new adventures, helping you
expand your knowledge and nourish your soul
Experience Convenient and Enjoyable Book Shopping Our website is more
than just an online bookstore—it’s a bridge connecting readers to the
timeless values of culture and wisdom. With a sleek and user-friendly
interface and a smart search system, you can find your favorite books
quickly and easily. Enjoy special promotions, fast home delivery, and
a seamless shopping experience that saves you time and enhances your
love for reading.
Let us accompany you on the journey of exploring knowledge and
personal growth!

ebookgate.com