EXPERIMENT-5

Part A

Aim:
1. Study and usage of any Object Oriented Database Management Systems software

Prerequisite: Object Oriented Concepts, SQL Server, SQL, Programming Language concepts.

Outcome: Create programs to execute on XML and relational database systems

Theory:
An object-oriented database is a collection of object-oriented programming and relational database.
There are various items which are created using object-oriented programming languages like C++,
Java which can be stored in relational databases, but object-oriented databases are well-suited for
those items.

An object-oriented database is organized around objects rather than actions, and data rather than
logic. For example, a multimedia record in a relational database can be a definable data object, as
opposed to an alphanumeric value.

Elements of Object oriented data model

Objects

The real world entities and situations are represented as objects in the Object oriented database
model.

Attributes and Method

Every object has certain characteristics. These are represented using Attributes. The behaviour of
the objects is represented using Methods.

Class

Similar attributes and methods are grouped together using a class. An object can be called as an
instance of the class.

Inheritance

A new class can be derived from the original class. The derived class contains attributes and
methods of the original class as well as its own.

Practice Exercise:
1. Give basic OODBMS syntax constructs.

2. Show how OO features are implemented in DBMS?

3. How transaction and concurrency control is achieved in OODBMS?

4. Brief any one OODB Software.

Code and output:

Answer 1:

Declarations

Source code ex-

Relationships

1. Object Structure: 

● The structure of an object refers to the properties that an object is made up of.
These properties of an object are referred to as an attribute. Thus, an object is a real
 world entity with certain attributes that makes up the object structure. Also an
object encapsulates the data code into a single unit which in turn provides data
abstraction by hiding the implementation details from the user. 

● The object structure is further composed of three types of components: Messages,

Methods, and Variables. These are explained as following below. 
Messages – 
A message provides an interface or acts as a communication medium between an
object and the outside world. A message can be of two types: 

a. Read-only message: If the invoked method does not change the value of a
variable, then the invoking message is said to be a read-only message. 
 

b. Update message: If the invoked method changes the value of a variable,

then the invoking message is said to be an update message. 
 

Methods – 
When a message is passed then the body of code that is executed is known as a
method. Every time when a method is executed, it returns a value as output. A
method can be of two types: 

c. Read-only method: When the value of a variable is not affected by a

method, then it is known as read-only method. 
 

d. Update-method: When the value of a variable changes by a method, then it

is known as an update method. 
 

Variables – 
It stores the data of an object. The data stored in the variables makes the object
distinguishable from one another. 

2. Object Classes: 
An object which is a real world entity is an instance of a class. Hence first we need to
define a class and then the objects are made which differ in the values they store but
share the same class definition. The objects in turn corresponds to various messages
and variables stored in it. 

Example – 
 

class CLERK

{ //variables
char name;
 string address;
int id;
int salary;

//methods
char get_name();
string get_address();
int annual_salary();
};
An OODBMS also supports inheritance in an extensive manner as in a database there may
be many classes with similar methods, variables and messages. Thus, the concept of class
hierarchy is maintained to depict the similarities among various classes. 
The concept of encapsulation that is the data or information hiding is also supported by
object oriented data model. And this data model also provides the facility of abstract data
types apart from the built-in data types like char, int, float. ADT’s are the user defined
data types that hold the values within it and can also have methods attached to it. 
Thus, OODBMS provides numerous facilities to it’s users, both built-in and user defined.
It incorporates the properties of an object oriented data model with a database
management system, and supports the concept of programming paradigms like classes
and objects along with the support for other concepts like encapsulation, inheritance and
the user defined ADT’s (abstract data types).
3. Object Identity:
Any object has 2 properties i.e. state & behaviour hence, it’s similar to the program
variable but object has complex structure.
● There are two types of object :-
1.) Transient object 2.) Persistent object
1.) Transient object: - These objects exist during the execution but destroy ones the
program terminates.
2.) Persistent object: - These objects persist & store into database even if program
terminate. Whenever any object created DBMS assigns unique identifier called as
object identity & its abbreviated as OID.
OID is used for two purposes.

● To identity each objects uniquely.

● Make reference to another object.

● Properties of OID

● Its unique
 ● Its system generated

● Its invisible to the user

● It’s not possible t perform operation on OID

● It’s in mutable i.e. once its generated

● It cannot be regenerated

● It has along integer values

● Object structure

Every object has internal structure that can be specified by using 6 types of type
constructor (AST LAM)…

1. ATDM: - Internal structure of object consists of automatic values that may be of

type integer float, character, string, data etc.

2. SET:- Internal structure of object, consist of collection of OID’s of other objects that
may be constructed from different type constructor its denoted by {i1 , i2 , i3 , …}

3. Tuples:- Internal structure of object, consist of collection of OID’s other objects that
may be constructed from different type constructor its denoted by {a1 : i1 ; a2 : i2 ;
a3 : i3, …} where a1 , a2 , a3 , … be the attributers & i1 , i2 , i3 be OID’s

4. List :- Its similar to the set but it’s an ordered collection its denoted by { i1 , i2 , i3 ,
…}

5. ARRAY: - It’s similar to list but it has limitations I.e. it’s of fixed size.

6. MULTISET or bag: - It’s similar to the set but it may contain duplicate. Any object
structure is represented

By triplet i.e. {I, C, V}

I = Object identifier.
E = type constructer.
V = value.
For e.g.:- Let us consider the following relation.

Dno Dname ---

5 Research ---

For above 2 relations object structure can be created as follows:-

01 = <i1, atom,="" 5="">
02 = <i2, atom,="" “research="">”
03 = <i3, atom,="" “l1”&gt;<="" p="">
04 = <i4, atom,="" “l2”&gt;<="" p="">
05 = <i5, set,="" <i3,="" i4="" &gt;<="" p="">
06 = <i6, tuple="" ;&lt;="" dno;="" i="" 1,="" d="" name="" i2,="" coc="">
● Type constructor
It’s used to define the data structure for object oriented, DB there are six types of
type constructor. (Refer objects structure)
Let us consider employee & department relation.
Type constructor can be created as follows:-

Define type employees

Type (id: integer;

Name: string,

Gender: string,

DOB: date,

Address: string,

Salary: Float

Manager: Employee,

D no: Department.)

End;

Define type name

Type (fname

Mname

Dname)

End;

Define type address

Type (apt no:

Area:
 City:

Pin code:

End; )

Define type department

Type (dno: integer

Dname: string

Location: set (string), manager

Employees)

End;

ODL-Attribute Types
Attribute types – atomic or structured

Atomic Types

integer, float, character, string, boolean, and enumerated types

Enumerated types - enum enumName {list of literals }attributename

Ex: attribute enum FacultyRank{instructor, assistant, associate, professor} rank;

Structured Types

Struct typename { attribute datatype pair list }identifier ;

Ex: attribute Struct Addr{string street, string city, string state, string zip} address;

If type used again for other classes, identify the class it was defined in, using the scoped
name- class name, double colon, and the type name

Ex: If we defined Addr type in Person class, and we need a NewAddress field in another
class in the same schema,
attribute newAddress Person::Addr

Collection Types

Set<typename> Set--a finite number of unordered values of one datatype, specified in

angled brackets

List<datatype> List--a finite list of elements of a single type

Array<float, n> Array-set of elements all of the same type, with an index indicating

position of each element; constructor requires datatype and number of elements

Bag<datatype> Bag or multiset-similar to a set, but permits duplicate values

Dictionary <K,V> Dictionary-where K and V are some datatypes- used to construct pairs

of values, <k,v> where k is a key type and v is some range type
Answer 2:

Defining objects - Class definitions

In the Object-oriented approach, everything can, in some way, be described as an object. The term
usually applies to a person, place or thing that a computer application may need to deal with. In
traditional database terms, an object can be likened to an entity in an E-R diagram, but instead of the
entity merely containing attributes, it can also contain methods, sometimes known as operations. These
methods are fragments of program code, which are used to carry out operations relevant to the object in
question. For example, a Customer object, as well as having the traditional data items we might expect
to see in a Customer table, may include operations such as CREATE A NEW CUSTOMER INSTANCE
(constructor), REMOVE A CUSTOMER INSTANCE (destructor), CHANGE CUSTOMER DETAILS
(transformer), etc.
The attributes and methods for groups or classes of objects of the same type are described in a class
definition. Each particular object is known as an instance of that class. The class definition is like a
template, therefore, which defines the set of data items and methods available to all instances of that
class of object. Some Object database systems also permit the definition of database constraints within
class definitions, a feature which might be considered to be a specific case of method definition.
Example of class definition
Consider the object type 'book' as might exist in a library database. Information to be held on a book
include its title, date of publication, publisher and author. Typical operations on a book might be:
● Take a book out on loan.
● Reserve a book for taking out on loan when available.
● A Boolean function which returns true if the book is currently on loan and false otherwise. The
above operations will be implemented as methods of class 'book'.
The class book may be defined by the following structure:
class book
properties
title : string;
date_of_Publication : date;
published_by : publisher;
written_by : author;
operations
create () -> book;
loan (book, borrower, date_due);
reserve (book, borrower, date_reserved);
on_loan (book) -> boolean;
end book;
A method can receive additional information, called parameters, to perform its task. In the above class,
loan method expects a book, borrower and date due for it to perform the loan operation. Parameters are
put in the parenthesis of a method. When a method performs its task, it can return data back to the caller
method.
An important point to note here is that data abstraction as provided by the class mechanism allows one
to define properties of entities in terms of other entities. Thus we see from the above example that the
properties published_by and written_by are defined in terms of the classes 'publisher' and 'author'
respectively. Outline class definitions for author and publisher could be as follows:
class author
properties
surname : string;
initials : string;
nationality : country;
year_of_birth : integer;
year_of_death : integer;
operations
create () -> author;
end author.
class publisher
properties
name : string;
location : city;
operations
create () -> publisher;
end publisher.

Inheritance
When defining a new class, it can either be designed from scratch, or it can extend or modify
other classes - this is known as inheritance. For example, the class ‘manager’ could
inherit all the characteristics of the class ‘employee’, but also be extended to
encompass features specific to managers. This is a very powerful feature, as it allows the
reuse and easy extension of existing data definitions and methods (note that inheritance is not
just restricted to data; it can apply equally to the methods of a class). Some systems only
permit the inheritance of the data items (sometimes called the state or properties) of a class
definition, while others allow inheritance of both state and behaviour (the methods of a class).
Inheritance is a powerful mechanism, as it provides a natural way for applications or systems
to evolve. For example, if we wish to create a new class of product, we can easily make use of
any previous development work that has gone into the definition of data structures and
methods for existing products, by allowing the definition of the new class to inherit them.
Example of class definitions to illustrate inheritance:
As an example, we might take the object classes 'mammal', 'bird' and 'insect', which may be defined as
subclasses of 'creature'. The object class 'person' is a subclass of 'mammal', and 'man' and 'woman' are
subclasses of 'person'. Class definitions for this hierarchy might take the following form:
class creature
properties
type : string; weight : real;
habitat : ( ... some habitat type such as swamp, jungle, urban);
operations
create () -> creature;
predators (creature) -> set (creature);
life_expectancy (creature) -> integer;
end creature.
class mammal inherit creature;
properties
gestation_period : real;
operations
end mammal.
class person inherit mammal;
properties
surname, firstname : string;
date_of_birth : date;
origin : country;
end person.
class man inherit person;
properties
wife : woman;
operations
end man.
class woman inherit person;
properties
husband : man;
operations
end woman.
The inheritance mechanism may be used not only for specialisation as described above, but for
extending software modules to provide additional services (operations). For example, if we have a class
(or module) A with subclass B, then B provides the services of A as well as its own. Thus B may be
considered as an extension of A, since the properties and operations applicable to instances of A are a
subset of those applicable to instances of B.
This ability of inheritance to specify system evolution in a flexible manner is invaluable for the
construction of large software systems. For database applications, inheritance has the added advantage
of providing the facility to model natural structure and behaviour.
It is possible in some systems, to inherit state and/or behaviour from more than one class. This is known
as multiple inheritance; it is only supported in some Object-oriented systems.

Encapsulation
Encapsulation in object oriented means an object contains both the data structures and the methods to
manipulate the data structures. The data structures are internal to the object and are only accessed by
other objects through the public methods. Encapsulation ensures that changes in the internal data
structure of an object does not affect other objects provided the public methods remains the same.
Encapsulation provides a form of data independence.
Review question 2
● Describe the difference between methods and messages in Object-oriented systems.
● Describe a situation in which it may be necessary to provide two different constructor methods
for instances of an object.
● Describe the main advantages of inheritance.
● Describe the concept of encapsulation in Object-oriented systems.

Answer 3:

TRANSACTION

A transaction can be defined as a group of tasks. A single task is the minimum

processing unit which cannot be divided further.
Let’s take an example of a simple transaction. Suppose a bank employee
transfers Rs 500 from A's account to B's account. This very simple and small
transaction involves several low-level tasks.
A’s Account
Open_Account(A)
Old_Balance = A.balance
New_Balance = Old_Balance - 500
A.balance = New_Balance
Close_Account(A)

B’s Account
Open_Account(B)
Old_Balance = B.balance
New_Balance = Old_Balance + 500
B.balance = New_Balance
Close_Account(B)

ACID Properties
A transaction is a very small unit of a program and it may contain several lowlevel
tasks. A transaction in a database system must
maintain Atomicity, Consistency, Isolation, and Durability − commonly known as
ACID properties − in order to ensure accuracy, completeness, and data integrity.
● Atomicity − This property states that a transaction must be treated as an atomic
unit, that is, either all of its operations are executed or none. There must be no
state in a database where a transaction is left partially completed. States should be
defined either before the execution of the transaction or after the
execution/abortion/failure of the transaction.
● Consistency − The database must remain in a consistent state after any
transaction. No transaction should have any adverse effect on the data residing in
the database. If the database was in a consistent state before the execution of a
transaction, it must remain consistent after the execution of the transaction as well.
● Durability − The database should be durable enough to hold all its latest updates
even if the system fails or restarts. If a transaction updates a chunk of data in a
database and commits, then the database will hold the modified data. If a
transaction commits but the system fails before the data could be written on to the
disk, then that data will be updated once the system springs back into action.
● Isolation − In a database system where more than one transaction are being
executed simultaneously and in parallel, the property of isolation states that all the
transactions will be carried out and executed as if it is the only transaction in the
system. No transaction will affect the existence of any other transaction.

Serializability
When multiple transactions are being executed by the operating system in a
multiprogramming environment, there are possibilities that instructions of one
transactions are interleaved with some other transaction.
● Schedule − A chronological execution sequence of a transaction is called a
schedule. A schedule can have many transactions in it, each comprising of a
number of instructions/tasks.
● Serial Schedule − It is a schedule in which transactions are aligned in such a
way that one transaction is executed first. When the first transaction completes its
cycle, then the next transaction is executed. Transactions are ordered one after the
 other. This type of schedule is called a serial schedule, as transactions are executed
in a serial manner.
In a multi-transaction environment, serial schedules are considered as a
benchmark. The execution sequence of an instruction in a transaction cannot be
changed, but two transactions can have their instructions executed in a random
fashion. This execution does no harm if two transactions are mutually
independent and working on different segments of data; but in case these two
transactions are working on the same data, then the results may vary. This ever-
varying result may bring the database to an inconsistent state.
To resolve this problem, we allow parallel execution of a transaction schedule, if
its transactions are either serializable or have some equivalence relation among
them.

Equivalence Schedules
An equivalence schedule can be of the following types −

Result Equivalence

If two schedules produce the same result after execution, they are said to be
result equivalent. They may yield the same result for some value and different
results for another set of values. That's why this equivalence is not generally
considered significant.

View Equivalence

Two schedules would be view equivalence if the transactions in both the

schedules perform similar actions in a similar manner.
For example −
● If T reads the initial data in S1, then it also reads the initial data in S2.
● If T reads the value written by J in S1, then it also reads the value written
by J in S2.
● If T performs the final write on the data value in S1, then it also performs
the final write on the data value in S2.

Conflict Equivalence

Two schedules would be conflicting if they have the following properties −

● Both belong to separate transactions.

● Both accesses the same data item.
● At least one of them is "write" operation.
Two schedules having multiple transactions with conflicting operations are said to be
conflict equivalent if and only if −

● Both the schedules contain the same set of Transactions.

● The order of conflicting pairs of operation is maintained in both the schedules.
Note − View equivalent schedules are view serializable and conflict equivalent schedules
are conflict serializable. All conflict serializable schedules are view serializable too.

States of Transactions
A transaction in a database can be in one of the following states −

● Active − In this state, the transaction is being executed. This is the initial state of
every transaction.
● Partially Committed − When a transaction executes its final operation, it is said
to be in a partially committed state.
● Failed − A transaction is said to be in a failed state if any of the checks made by
the database recovery system fails. A failed transaction can no longer proceed
further.
● Aborted − If any of the checks fails and the transaction has reached a failed state,
then the recovery manager rolls back all its write operations on the database to
bring the database back to its original state where it was prior to the execution of
the transaction. Transactions in this state are called aborted. The database recovery
module can select one of the two operations after a transaction aborts −
o Re-start the transaction
o Kill the transaction
● Committed − If a transaction executes all its operations successfully, it is said to
be committed. All its effects are now permanently established on the database
system.
CONCURRENCY CONTROL

In a multiprogramming environment where multiple transactions can be executed

simultaneously, it is highly important to control the concurrency of transactions. We have
concurrency control protocols to ensure atomicity, isolation, and serializability of
concurrent transactions. Concurrency control protocols can be broadly divided into two
categories −

● Lock based protocols

● Time stamp based protocols

Lock-based Protocols
Database systems equipped with lock-based protocols use a mechanism by which any
transaction cannot read or write data until it acquires an appropriate lock on it. Locks are
of two kinds −
● Binary Locks − A lock on a data item can be in two states; it is either locked or
unlocked.
● Shared/exclusive − This type of locking mechanism differentiates the locks
based on their uses. If a lock is acquired on a data item to perform a write
operation, it is an exclusive lock. Allowing more than one transaction to write on
the same data item would lead the database into an inconsistent state. Read locks
are shared because no data value is being changed.
There are four types of lock protocols available −

Simplistic Lock Protocol

Simplistic lock-based protocols allow transactions to obtain a lock on every object

before a 'write' operation is performed. Transactions may unlock the data item
after completing the ‘write’ operation.

Pre-claiming Lock Protocol

Pre-claiming protocols evaluate their operations and create a list of data items on
which they need locks. Before initiating an execution, the transaction requests the
system for all the locks it needs beforehand. If all the locks are granted, the
transaction executes and releases all the locks when all its operations are over. If
all the locks are not granted, the transaction rolls back and waits until all the locks
are granted.
Two-Phase Locking 2PL

This locking protocol divides the execution phase of a transaction into three parts.
In the first part, when the transaction starts executing, it seeks permission for the
locks it requires. The second part is where the transaction acquires all the locks.
As soon as the transaction releases its first lock, the third phase starts. In this
phase, the transaction cannot demand any new locks; it only releases the
acquired locks.

Two-phase locking has two phases, one is growing, where all the locks are being
acquired by the transaction; and the second phase is shrinking, where the locks
held by the transaction are being released.
To claim an exclusive (write) lock, a transaction must first acquire a shared (read)
lock and then upgrade it to an exclusive lock.

Strict Two-Phase Locking

The first phase of Strict-2PL is same as 2PL. After acquiring all the locks in the
first phase, the transaction continues to execute normally. But in contrast to 2PL,
Strict-2PL does not release a lock after using it. Strict-2PL holds all the locks until
the commit point and releases all the locks at a time.
Strict-2PL does not have cascading abort as 2PL does.

Timestamp-based Protocols
The most commonly used concurrency protocol is the timestamp based protocol.
This protocol uses either system time or logical counter as a timestamp.
Lock-based protocols manage the order between the conflicting pairs among
transactions at the time of execution, whereas timestamp-based protocols start
working as soon as a transaction is created.
Every transaction has a timestamp associated with it, and the ordering is
determined by the age of the transaction. A transaction created at 0002 clock time
would be older than all other transactions that come after it. For example, any
transaction 'y' entering the system at 0004 is two seconds younger and the
priority would be given to the older one.
In addition, every data item is given the latest read and write-timestamp. This lets
the system know when the last ‘read and write’ operation was performed on the
data item.

Timestamp Ordering Protocol

The timestamp-ordering protocol ensures serializability among transactions in
their conflicting read and write operations. This is the responsibility of the protocol
system that the conflicting pair of tasks should be executed according to the
timestamp values of the transactions.

● The timestamp of transaction T  is denoted as TS(T ).

i i

● Read time-stamp of data-item X is denoted by R-timestamp(X).

● Write time-stamp of data-item X is denoted by W-timestamp(X).
Timestamp ordering protocol works as follows −
● If a transaction Ti issues a read(X) operation −
o If TS(Ti) < W-timestamp(X)
▪ Operation rejected.
o If TS(Ti) >= W-timestamp(X)
▪ Operation executed.
 o All data-item timestamps updated.
● If a transaction Ti issues a write(X) operation −
o If TS(Ti) < R-timestamp(X)
▪ Operation rejected.
o If TS(Ti) < W-timestamp(X)
▪ Operation rejected and Ti rolled back.
o Otherwise, operation executed.

Thomas' Write Rule

This rule states if TS(Ti) < W-timestamp(X), then the operation is rejected and
T  is rolled back.
i

Time-stamp ordering rules can be modified to make the schedule view

serializable.
Instead of making T  rolled back, the 'write' operation itself is ignored.
i

Answer 4:

A. ObjectDB Object Database

ObjectDB is a powerful Object-Oriented Database Management System (ODBMS). It is compact,
reliable, easy to use and extremely fast. ObjectDB provides all the standard database management
services (storage and retrieval, transactions, lock management, query processing, etc.) but in a way
that makes development easier and applications faster. 

● ObjectDB Database Key Features

● 100% pure Java Object-Oriented Database Management System (ODBMS).
● No proprietary API - managed only by standard Java APIs (JPA 2 / JDO 2).
● Extremely fast - faster than any other JPA / JDO product.
● Suitable for database files ranging from kilobytes to terabytes.
● Supports both Client-Server mode and Embedded mode.
● Single JAR with no external dependencies.
● The database is stored as a single file.
 ● Advanced querying and indexing capabilities.
● Effective in heavy loaded multi-user environments.
● Can easily be embedded in applications of any type and size.
● Tested with Tomcat, Jetty, GlassFish, JBoss, and Spring.

B. Objectivity/DB

Objectivity/DB is a scalable, high performance, distributed Object Database

(ODBMS). It is extremely good at handling complex data, where there are many
types of connections between objects and many variants.
 
Objectivity/DB runs on 32 or 64-bit processors running Linux, Mac OS X, UNIX
(Oracle Solaris) or Windows.
 
There are C++, C#, Java and Python APIs.
 
All platform and language combinations are interoperable. For example, objects
stored by a program using C++ on Linux can be read by a C# program on
Windows and a Java program on Mac OS X.
 
Objectivity/DB generally runs on POSIX filesystems, but there are plugins that can
be modified for other storage infrastructure.
 
Objectivity/DB client programs can be configured to run on a standalone laptop,
networked workgroups, large clusters or in grids or clouds with no changes to the
application code.

Observation & Learning:

We observed and learned the queries of OODBMS and how they work.

Conclusion:
We successfully completed the task of OODBMS.