CHAPTER - 1

Concepts for Object-Oriented Databases

16.3 OBJECT-ORIENTED DATABASE MANAGEMENT SYSTEMS

Object-oriented database Management systems (OODBMS) provide a closer integration
with an object-oriented programming language such as Python, C#, C++, Java, or
Smalltalk. An object-oriented database system extends the concept of object-oriented
programming language with persis-tence, concurrency control, data recovery, security, and other
capabilities as shown in Figure 16.1.
Data Object
encapsulation identity
Inheritance Polymorphism

Object-oriented
programming

+
Integrity Archive
Security Database Recovery
capabilities
Versioning Query

Transactions Concurrency
Persistence

Fig. 16.1 An object-oriented database management system

Some object-oriented databases are well suited for available object-oriented programming lan-
guages while others have their own programming languages. OODBMSs are built upon the same data
model as used by the object-oriented programming languages.

16.3.1 Characteristics of Object-Oriented Databases

Object-oriented databases combine the object-oriented programming concepts and database capabilities
to provide an integrated application development system. In addition to basic object-oriented program-
ming concepts such as encapsulation, inheritance, polymorphism, and dynamic binding, object-oriented
database also supports persistence and versioning.
Persistence is one of the most important char- Learn More
acteristics of object-oriented database systems. In In C++, the objects are made persistent
an object-oriented programming language (OOPL), at the time of their creation by defining
objects are transient in nature, that is, they exist only them using the overloaded new opera-
during program execution and disappear after the tor. The overloaded new operator accepts
program terminates. In order to convert an OOPL some more arguments for specifying the
into a persistent programming language (or database database in which the object should be
programming language), the objects need to be made created. On the other hand, in Java, one
persistent, that is, objects should persist even after or more objects are explicitly declared as
the program termination. OO databases store persis- persistent and all other objects that can be
referred through those persistent objects
tent objects permanently on the secondary storage
also become persistent.
so that they can be retrieved and shared by multiple

Page - 1
programs. The data stored in OO database is accessed directly from the object-oriented program-
ming language using the native type system of the language. Whenever a persistent object is cre-
ated, the system returns a persistent object identifier. Persistent OID is implemented through a
persistent pointer, which points to an object in the database and remains valid even after the
termination of program.
Another important feature of OODBMS is versioning . Versioning allows maintaining multiple
versions of an object, and OODBMS provide capabilities for dealing with all the versions of the
object. This feature is especially useful for designing and engineering applications in which the older
version of the object that contains tested and verified design should be retained until its new version
is tested and released.

16.3.2 ODMG Object Model

The object data management group (ODMG), a subgroup of the object management group (OMG),
has designed the object model for object-oriented database systems. The OMG is a pool of hundreds
of object vendors whose purpose is to set standards for object technology. In 1993, the first release
of the ODMG was published which was called ODMG-93 or ODMG 1.0 standard. Later, it was
revised into ODMG 2.0, which included a common architecture and definitions for an OODBMS,
definitions for an object model, an object definition language (ODL), and object query language
(OQL). Various concepts and terminologies related to object model are discussed here.
⇒ Objects: An object is the most basic element of an object model and it consists of two compo-
nents: state (attributes and relationships) and behavior (operations). An object in the object model
is described by four characteristics, namely, identifier, name, lifetime, and structure.
 Identifier: Each object is assigned a unique system generated identifier (OID) that identifies
it within the database.
 Name: Some objects are also assigned a unique name within a particular database that can
be used to refer to that object in the program. We can use the name of an object as an entry
point to the database, that is, by locating an object by its unique name we can also locate
other objects that are referenced from it.
 Lifetime: The lifetime of an object specifies whether the object is persistent (that is a data-
base object) or transient (a programming language object).
 Structure: The structure of an object specifies how the object is created using a certain type
constructor. Various type constructors used in the object model are atom, tuple (or row),
set, list, bag, and array. We have already discussed tuple and array type constructors in Sec-
tion 16.2.1. All the basic atomic values such as integers, real numbers, Booleans, character,
strings, etc. are represented using atom constructor. The list type constructor is used to rep-
resent a collection of objects in some specific order (ascending or descending), whereas, set
and bag are used to represent an unordered collection of objects. Note that all the objects in
a set must be distinct while a bag can have duplicate objects. The objects in the object model
can be classified as atomic objects (created using atom type constructor) or collection objects
(created using set, list, bag, or array type constructor).
⇒ Literal: A literal is basically a constant value that does not have an object identifier. It can be of
three types, namely, atomic, collection, and structured. Atomic literals correspond to the values
of basic data types of the object model including long, short, and unsigned integers, floating
point numbers, Boolean values, character, string, and enumeration type values. Collection liter-
als define a value that is a collection of objects or values such as set, array, list, bag, etc., but the
collection itself does not have an object identifier. Structured literals correspond to the values
that are constructed using the tuple type constructor. Structured literals include built-in structures

Page - 2
 like Date, Interval, Time, and Timestamp, as well as user-defined structures that can be
created using the struct type constructor.
⇒ Atomic (user-defined) objects: A user-defined object that is not a collection object is called an
atomic object. In order to create object types (or instances) for atomic objects, the class key-
word is used which specifies the properties (state) and operations (behavior) for the object types.
The properties define the state of an object type and are described by attributes and relationships.
Attributes specify the features of an object and can be simple, enumerated, structured, or com-
plex type, and relationships specify how one object is related to another. In the object model,
only binary relationships are explicitly represented and a pair of inverse references (specified
using the keyword relationship) is used to represent each binary relationship. In addition to
properties, each object type can also have a number of operation signatures, which include name
of operation, type of arguments passed, return type, and name of exceptions (optional) that can
occur during operation execution.
⇒ Interface: Unlike a class that specifies both the abstract state and abstract behavior of an object
type, an interface specifies only the abstract behavior of an object type. The operations that are to
be inherited by the user-defined objects or other interfaces for a specific application are defined in
an interface. In addition, an interface cannot be instantiated that means objects cannot be created
for an interface. An interface is defined using the keyword interface.

NOTE An interface may also specify properties (along with the operations) of an object
type; however, these cannot be inherited from the interface.

⇒ Inheritance: The object model employs two types of inheritance relationships. One is behavior
inheritance or interface inheritance in which the supertype is an interface and the subtype
is either a class or an interface. The behavior inheritance is specified using the colon (:) sym-
bol. Another kind of inheritance relationship is EXTENDS relationship, which requires both
the supertype and the subtype to be classes. This type of inheritance is specified using the key-
word extends, and it cannot be used for implementing multiple inheritance. However, multiple
inheritance is permitted for behavior inheritance that allows an interface or a class to inherit
behavior from more than one interface. Note that if a class is used as a subtype in multiple inheri-
tance then it can inherit state and behavior from at most one other class using extends in addi-
tion to inheriting from several interfaces via (:).
⇒ Extents: In ODMG object model, an extent can be declared for any object type (defined using
class declaration), and it contains all the persistent objects of that class. An extent is given a name
and is declared using the keyword extent. Whenever extents are declared, the database system
automatically enforces set/subset relationship between the extents of a supertype and its subtype.
For example, if two classes A and B define extents all_A and all_B, and B is subtype of class A,
then the collection of objects in all_B must be a subset of those in all_A.

16.3.3 Object Definition Language (ODL)

Object definition language, a part of ODMG 2.0 standard, has been designed to represent the struc-
ture of an object-oriented database. ODL serves the same purpose as DDL (part of SQL), and is used
to support various constructs specified in the ODMG object model. The database schema is defined
independently of any programming language, and then the specific language bindings are used to
map ODL constructs to the constructs in specific programming languages like C++, Java, or Small-
talk. The main purpose of ODL is to model object specifications (classes and interfaces) and their

Page - 3
characteristics. Any class in the design process has three characteristics that are attributes, relation-
ships, and methods. The syntax for defining a class in ODL is shown here.
class <name>
{
<list of properties>
};
Here, class is a keyword and the list of properties may be attributes, relationships, or methods.
For example, consider the Online Book database and its objects BOOK, AUTHOR, PUBLISHER, and
CUSTOMER. The object BOOK can be defined as shown here (for simplicity we have taken only three
attributes).
class BOOK
{
attribute string ISBN;
attribute string Book_title;
attribute enum Book_type
{Novel,Textbook,Languagebook} Category;
};
In this example, a field Category as an enum is defined which can take either Novel or Text-
book or Languagebook as its value. Similarly, all other objects can also be defined.

An entity in E-R data model or a tuple in relational data model corresponds to an object in object data
model, and an entity set or a relation corresponds to a class.

In order to sale these books to the customers, a relationship needs to be specified between the
BOOK object and the CUSTOMER object. To connect a CUSTOMER object with a BOOK object, a rela-
tionship needs to be defined in the CUSTOMER class as shown here.
relationship set <BOOK> purchases
Here, for each object of the class CUSTOMER, there is a reference to BOOK object and the set of
these references is called purchases. This relationship helps us to find the books purchased by a
particular customer. However, if we want to access the customers based on the book then the inverse
relationship should be specified in the BOOK class as shown here.
relationship set <CUSTOMER> purchasedby
Now, this pair of inverse references (or relationships) can be connected by using the keyword
inverse in each class declaration. For example, the relationship set between book and customer is
specified in both BOOK and CUSTOMER classes as shown here.
class BOOK
{
…
…
relationship set <CUSTOMER> purchasedby
inverse CUSTOMER :: purchases;
};

Page - 4
 class CUSTOMER
{
attribute string Cust_id;
attribute string Name;
attribute struct Address //structured literal
{short H_no,string street,string city,string state,
string country} address;
relationship set <BOOK> purchases
inverse BOOK :: purchasedby;
…
…
};
Similarly, other relationship sets between book and author, book and publisher can also be speci-
fied. In addition to relationships, operations (or methods) can also be specified by including their
signatures within the class declaration. The parameters specified in the methods must have one of the
three different modes, namely, in, out, or inout. The in parameters are arguments to the method,
the out parameters are returned from the method and a value is assigned to each out parameter that
a user can process. The inout parameters combine the features of both in and out. They contain
values to be passed to the method and the method can set their values as return values. For example,
a method find_cust() that finds the name of the customer residing in a particular city, can be
included in the CUSTOMER class definition as follows.
class CUSTOMER
{
attribute string Cust_id;
attribute string Name;
attribute struct Address //structured literal
{short H_no,string street,string city,string state,
string country} address;
relationship set <BOOK> purchases
inverse BOOK :: purchasedby;
void find_cust(in string city; out string cust_name)
raises(city_not_valid);
};
Here, the name of the city is passed as a parameter to find_cust() method and the name of
the customer belonging to that city is returned. In case, an empty string is passed as a parameter for
city name, an exception city_not_valid is raised.
Suppose we want to store information about jour- Learn More
nals in our database. Since a journal is also a book, we Some of the object-oriented database sys-
can use inheritance to define the Journal class using tems also support selective inheritance,
the keyword extends as shown in this example. which allows a subtype to inherit only some
of the functions of a supertype. The func-
class JOURNAL extends BOOK tions not to be inherited by the subtype are
{ mentioned using the EXCEPT clause.
attribute string VOLUME;
attribute string Emailauthor1;
attribute string Emailauthor2;
};

Page - 5
 To implement multiple inheritances, consider a class BOOK_SOLD that stores information about
the books sold and the customers who have purchased those books. This class can be derived from
both BOOK and CUSTOMER classes as shown here.

class BOOK_SOLD extends BOOK : CUSTOMER

{
void purchase(in string ISBN;in string card_no;in short pin)
raises (ISBN_not_valid,card_not_valid,pin_not_valid);
};

In purchase() method, the ISBN of the book to be purchased, credit/debit card number, and
the pin number of the customer are passed as arguments. If the ISBN of the book, card number, or the
pin number is not correct, the exception ISBN_not_valid, card_not_valid, or pin_not_
valid is raised, respectively.
Like the relation instance of a relation schema, ODL defines an extent of a class, which contains
the current set of the objects of that class. For example, an extent books of the class BOOK can be
defined as shown here.

class BOOK (extent books)

{
… //same as in
… //BOOK class
};

Similarly, an extent FirstCustomer of the class CUSTOMER can also be defined as shown
here.

class CUSTOMER (extent FirstCustomer)

{
… //same as in
… //CUSTOMER class
};

A class with an extent can have one or more keys associated with it that uniquely identify each
object in the extent. A key for a class can be declared using the keyword key. For example, the CUS-
TOMER class definition can be modified to include a key as shown here.

class CUSTOMER (extent FirstCustomer key Cust_id)

{
… //same as in
… //CUSTOMER class
};

Here, Cust_id has been defined as a key for the CUSTOMER class, thus, no two objects in the
extent FirstCustomer can have the same value for Cust_id.
In ODL, various schema constructs like class, interface, relationships, and inheritance can be
represented graphically. The graphical notations for representing ODL schema constructs are shown
in Table 16.1.

Page - 6
 Using these notations, a graphical object database schema for Online Book database can be rep-
resented as shown in Figure 16.2.

Table 16.1 Graphical notations for representing ODL schema constructs

Schema Construct Graphical Notation

Interface

Class

Relationships . . 1:1

. . . 1:N

. . . . M:N

Inheritance
LJ Interface inheritance via “:”

t Class inheritance via “extends”

AUTHOR
Publishes
PUBLISHER
Writes
Published by
Written by
Purchased by
BOOK CUSTOMER
Purchases

JOURNAL
BOOK_SOLD

Fig. 16.2 Graphical object database schema for Online Book database

Page - 7
16.3.4 Object Query Language (OQL)
Object Query Language (OQL) is a standard query language designed for the ODMG object model.
It resembles SQL (used for relational databases) but it also supports object-oriented concepts of the
object model, such as object identity, inheritance, relationship sets, operations, etc. An OQL can query
object databases either interactively (that is by writing ad hoc queries) or OQL queries can be embed-
ded in object-oriented programming languages like C++, Java, Smalltalk, etc. An embedded OQL
query results in objects that match with the type system of that programming language.
Each query in OQL needs an entry point to the database for processing. Generally, the name of
an extent of a class is used as an entry point; however, any named persistent object (either an atomic
object or a collection object) can also be used as a database entry point. Using an extent name as an
entry point in a query returns a reference to a persistent collection of objects. In OQL, such a col-
lection is referred to by an iterator variable (similar to tuple variable in SQL) that ranges over each
object in the collection.
The basic OQL syntax is “SELECT-FROM-WHERE” as for SQL. For example, the query to
retrieve the titles of all textbooks can be specified as
SELECT b.Book_title
FROM books b
WHERE b.Category = ‘Textbook’;
Here, books is an extent of class BOOK and b is an iterator variable. The query retrieves only
the persistent objects that satisfy the condition and the collection of these objects is referred to by b.
For each textbook object in b, the value of Book_title is retrieved and displayed. As the type of
Book_title is a string, the result of the query is a set of strings.

NOTE An iterator variable can also be specified using other syntax such as “b in books”
or “books as b”.
In order to access the related attributes and objects of the object under collection, we can specify
a path expression. It starts at the persistent object name or at the iterator variable, then it is followed
by zero or more relationship set names or attribute names connected using the dot notation. To under-
stand the path expression, consider a query that displays the titles of all the books purchased by Allen,
which is shown here.
SELECT b.Book_title
FROM books b
WHERE b.purchasedby.Name = ‘Allen’;
Here, the query retrieves a collection of all the books that are purchased by the customer Allen
using the path expression b.purchasedby.Name. If Allen has purchased more than one copy of
the same book the query will result in a bag of strings. With the use of DISTINCT clause the same
query will return a set of strings as shown here.
SELECT DISTINCT b.Book_title
FROM books b
WHERE b.purchasedby.Name = ‘Allen’;
If we want to retrieve a list of books purchased by Allen, we can use ORDER BY clause. For
example, the following query results in a list of books purchased by Allen in the ascending order by
Category and in the descending order by Price.

Page - 8
 SELECT DISTINCT b.Book_title
FROM books b
WHERE b.purchasedby.Name = ‘Allen’
ORDER BY b.Category ASC, b.Price DESC;
If the type of result returned from a query is a structure then the keyword struct need to be
used within the query. For example, a query to retrieve the location of the publisher who publishes
the book having ISBN either 003-456-533-8 or 001-354-921-1 in ascending order of name can be
written as
SELECT struct(name:p.Pname,loc:p.Address, s:p.State, ph:p.Phone)
FROM publishers p
WHERE p.publishes.ISBN=‘003-456-533-8’
OR p.publishes.ISBN=‘001-354-921-1’
ORDER BY name;
Here, the type of result returned by the query is a structure that is composed of name, address,
state, and phone number of the publisher. Note that publishers is an extent of PUBLISHER
class and the expressions name:p.Pname, loc:p.Address, s:p.State, ph:p.Phone
represent aliasing of Pname as name, Address as loc, State as s, and Phone as ph,
respectively.
In addition, a number of aggregate operators like SUM, AVG, COUNT, MAX, and MIN can also be
used in OQL, since most of the OQL queries result in a collection. Out of these operators, the COUNT
operator returns an integer value, while other operators return the same type as the type of the operand
collection. The following query returns the average price of books purchased by Allen.
AVG (SELECT b.Price
FROM books b
WHERE b.purchasedby.Name = ‘Allen’);
If we want a query to return only a single element from a singleton collection (that contains only
one element), the keyword ELEMENT can be used. For example, the following query retrieves the
single object reference to the books having price greater than $34 and less than $40.
ELEMENT(SELECT b
FROM books b
WHERE b.Price > 34 AND b.Price < 40);
A host language variable can also be used to hold the result of an OQL query. For example, con-
sider the following statement in which a set<BOOK> type variable Costly_Books stores the list
of books having price greater than $30.
Costly_Books = SELECT b.Book_title
FROM books b
WHERE b.Price > 30
ORDER BY b.Price DESC;

16.4 OODBMS VERSUS ORDBMS

In the earlier sections, we have discussed the important features of both OODBMS and ORDBMS.
It is clear from our discussion that the two kinds of object databases are similar in terms of their
functionalities. Both the databases support structured types, object identity and reference types, and

Page - 9
inheritance. In addition, both support a query language for accessing and manipulating complex data
types, and common DBMS functionality such as concurrency control and recovery. These two data-
bases have certain differences also which are listed in Table 16.2.

Table 16.2 Differences between OODBMS and ORDBMS

OODBMS ORDBMS

It is created on the basis of persistent program- It is built by creating object-oriented extensions of

ming paradigm. a relational database system.
It supports ODL and OQL for defining and It supports an extended form of SQL.
manipulating complex data types.
It aims to achieve seamless integration with Such an integration is not required as SQL:1999
object-oriented programming languages such allows us to embed SQL commands in a host
as C++, Java, or Smalltalk. language.
Query optimization is difficult to achieve in The relational model has a very strong foundation
these databases. for query optimization, which helps in reducing the
time taken to execute a query.
The query facilities of OQL are not supported The query facilities are the main focus of ORDBMS.
efficiently in most OODBMS. The querying in these databases is as simple as in
relational database system, even for complex data
types and multimedia data.
It is based on object-oriented programming It provides good protection against programming
languages; any error of data type made by pro- errors.
grammer may affect many users.

  SUMMARY  
1. The concept of object was implemented in the database system in two ways, which resulted in
object relational and object database systems.
2. SQL:1999 extends the SQL to support the complex data types and object-oriented features.
3. Structured type is a form of user-defined type that allows representing complex data types.
4. Structured data types are defined using type constructors, namely, row and array. Row type is used
to specify the type of a composite attribute of a relation.
5. Methods can also be defined on the structured types. The methods are declared as part of the type
definition.
6. In object-relational database system, inheritance can be used in two ways: for reusing and refin-
ing types (type inheritance) and for creating hierarchies of collection of similar objects (table
inheritance).
7. A subtype can override the method of supertypes just by using OVERRIDING METHOD instead
of METHOD in the method declaration.
8. The concept of subtable came into existence to incorporate the implementation of generalization/
specialization of an E-R diagram.
9. The value of OID can be used to refer to the object from anywhere in the database.

Page - 10
10. The referenced table must have an attribute that stores the identifier of the row. This attribute,
known as self-referential attribute, is specified by using REF IS clause.
11. An object-oriented database system extends the concept of object-oriented programming lan-
guage with persistence, concurrency control, data recovery, security, and other capabilities.
12. Persistence is one of the most important characteristics of object-oriented database systems in
which objects persist even after the program termination.
13. OID is implemented through a persistent pointer, which points to an object in the database and
remains valid even after the termination of program.
14. Versioning allows maintaining multiple versions of an object, and OODBMS provide capabilities
for dealing with all the versions of the object.
15. The object data management group (ODMG), a subgroup of the object management group
(OMG), has designed the object model for object-oriented database systems.
16. An object is the most basic element of an object model and it consists of two components: state
(attributes and relationships) and behavior (operations).
17. Each object is assigned a unique system generated identifier OID that identifies it within the
database.
18. The lifetime of an object specifies whether the object is persistent (that is a database object) or
transient (a programming language object).
19. The structure of an object specifies how the object is created using a certain type constructor. Var-
ious type constructors used in the object model are atom, tuple (or row), set, list, bag, and array.
20. A literal is basically a constant value that does not have an object identifier.
21. In ODMG object model, an extent can be declared for any object type (defined using class dec-
laration), and it contains all the persistent objects of that class. An extent is given a name and is
declared using the keyword extent.
22. Object definition language, a part of ODMG 2.0 standard, has been designed to represent the
structure of an object-oriented database. The main purpose of ODL is to model object specifica-
tions (classes and interfaces) and their characteristics.
23. OQL is a standard query language designed for the ODMG object model. It resembles SQL (used
for relational databases) but it also supports object-oriented concepts of the object model, such as
object identity, inheritance, relationship sets, operations, etc.

  KEY TERMS  
 Object relational database systems  Versioning
 Object-orientedda tabases ystems  ODMG object model l
 Structuredtype s  Object data management group
 Inheritance (ODMG)
 Typeinh eritance  Object management group (OMG)
 Tableinhe ritance  Objects
 Objectide ntifier (OID)  Literal
 Self-referentiala ttribute  Atomic literals
 Persistence  Collection Literals
 Persistentpointe r  Structured Literals
 Atomic(user-defined) objects

Page - 11