Study And Overview Of Object Oriented Database Computer Science Essay


With the advancement of data modeling, the development of the object oriented paradigm brought a significant change in how we look data and the procedures that operate on data. Previously data and their relations were stored in a database and procedures were stored in an application program. But with the development of the object oriented notion, we began to combine entity's procedures with the data. As a result, entities became self contained units and can be reused and moved around with considerable ease.

Limitations of Relational Database

Relational databases represent data as if they are organized in a two-dimensional table. With the advent of SQL, a standard language for accessing data was established. RDBMS had both logical and physical structure and performed well on many business applications. Unlike the object oriented approach, the basic approach of the relational theory was that, data and the programs that use it were independent of each other. This was and is the fundamental difference between the two approaches. However the relational theory suffered many limitations:

Object identity:

Lady using a tablet
Lady using a tablet


Essay Writers

Lady Using Tablet

Get your grade
or your money back

using our Essay Writing Service!

Essay Writing Service

Entities in a relational model gave no independent existence. In the relational theory objects can only be identified and accessed indirectly through the identification of those attributes which characterize them.

Explicit relationships:

In the relational approach the identities of relationships have no explicit representation. Here relations are recovered by executing query operations on the database. Besides this, in the relational model, there are hidden semantics. Consider the following example:

In the above diagram, the Appraisal relation, and also the Appraiser and Appraise roles are hidden.

Also, considering the above example, the relationship becomes a relation connecting two other relations. Thus the difference between an entity and a relation is quite blurred.

Structured Data Objects:

The first normal form demands that the values for attributes in a tuple must be atomic. But in some cases we need to consider attributes which are complex, where values of domains are themselves tuples.







Supervisor ID









Besides this, relational model also restricts collection-types, such as sets, lists and multi-sets. This can be explained with the following example:






Computer Consultancy



{Kolkata, Mumbai, Bangalore, Kochi}




{Delhi, Chennai, Kolkata}

Human Resource



{Singapore, UK, Mumbai}

Generalization and Inheritance

The entities that we model often follow a natural hierarchical structure. Relational databases have no scope for expressing this concept of hierarchy. Also, inheritance is not a part of the relational model.


In a relational model, for recording explicitly special queries on a database like for read-only queries, we require to create views. This however introduces overhead as the system needs to maintain the current value. Also, for updating values, there is no mechanism available in the relational model. These are maintained outside the relational model.

Before we groove into deeper concepts, we first discuss here some basic concepts. There are many real life applications, where RDBMS works quite successfully - and remarkable good DBMS packages are also available. Two very popular open-source RDBMS products - MySQL and PostgreSQL are quite successfully running in real life applications. However there are situations where we require something more than what RDBMS gives us. This is why we require ODBMS. We would now discuss when to use ODBMS. We use ODBMS when:

We are using embedded DBMS Applications: Applications which require super-fast response time, we generally seek embedded DBMS. In such cases use of RDBMS involves much overhead due to object-relational mapping and requires greater administration support during the deployment of updated class schemes to the installed bases. Use of Java or DOT NET in such cases could be wise since they require a self contained, non-intrusive and easy to deploy persistence solution.

Lady using a tablet
Lady using a tablet


Writing Services

Lady Using Tablet

Always on Time

Marked to Standard

Order Now

Complex object relationship: Some applications involve complex data structures, where classes define multiple cross references among themselves. This is difficult to model in a RDBMS. In RDBMS, relationships in objects are dealt using the concept of foreign keys. On the contrary, most ODBMSes induces reachability persistence i.e. if object A references object B, and object A is persistent, then object B becomes persistent automatically. This reachability is handled by the ODBMS engine thereby maintaining the details of the references when objects are stored and linking them up when objects are fetched.

Changing data structures: In certain applications, there are chances where new data members or object relations are added. This situation is very difficult to handle in RDBMS, where the schema and the query code needs to be modified to fit in the required changes. ODBMS on the other hand allow this as we can mix the old and new objects in the database with ease and convenience.

While using deep object structures: Often it is required to organize data in form of graphs or trees. A very deep tree structure presents a lengthy parent, child, grandchild to the programmer and is very difficult to handle it in RDBMS. On the contrary, ODBMS can handle such cases using reachability persistence as explained before, where the programmer has to control to fetch or store individual twigs, a branch or the whole tree; integrity being preserved the DB engine.

We are programming in an OO Language: While programming in OOL, it is preferable to use ODBMS instead of RDBMS especially when multiple applications access the same database. This is because if we use RDBMS, we need to write code to pass back and forth row objects fetched from the database and actual objects in our applications. Also, we have to write translation code for object-schema mapping and that too need to be synchronized in all different applications. On the other hand, by using ODBMS, the access is same from all applications since the applications that are stored and fetched are manipulated in the same way.

When objects include Collections: There might be certain applications that have members like a List, or a Set. A collection within an object generally represents a one-to-many relationship. If we try to model this using RDBMS, we would require an intermediate table that links up the parent object and the objects in the collection; whereas in ODBMS we fetch and store the parent along with its member collection with a single call.

The development team uses Agile methodology: Most developments today use agile technology. An ODBMS fits more smoothly in agile development than RDBMS. According to Scott Ambler, agile methodologies uses refactoring, agile modeling, continual regression testing, configuration management and separate sandboxes for developers to work in. RDBMS complicates such things due to technical and cultural impedance mismatch, and the current lack of tool support. ODBMS make it easier to be agile.

Data access is through navigation rather than query: Let us imagine the case when we need to access data in a highly networked structure. In RDBMS, we do so by simply firing a series of SQL SELECT statements, whereas in ODBMS, navigation through such structures is mainly done using the native language's constructs, thereby making the code simpler to understand.

Need for Complex Datatype

Traditional database applications use conceptually simple data types in data processing. But in recent years, complex data types gave grown more important. Complex data types have grown more important in recent years. For example, as we had shown before that Addresses can be viewed as a single string, separate attributes for each part or composite attributes which are not in the first normal form. Also, it is often convenient to store multivalued attributes as-is, without creating a separate relation to store the values in first normal form.

Complex data finds it application in computer-aided design, computer aided software engineering and multimedia and image databases. With complex datatypes and object orientation, we can represent E-R model concepts, like identity of entities, multivalued attributes, and generalization and specialization directly, without a complex translation to the relational model.

Collection and Large Object Types

Lady using a tablet
Lady using a tablet

This Essay is

a Student's Work

Lady Using Tablet

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.

Examples of our work

There are four types of LOB (Large OBjects):

CLOB: The character LOB object which is used to store character data.

NCLOB: The National character set LOB type which is generally used to store multiple byte character data like Non-English characters.

BLOB: It is used to store binary data; hence called binary LOB.

BFILE: A binary file stored outside of the database in the host operating system file system, but accessible from database tables. BFILEs can be accessed from your application on a read-only basis.

The LOB can store up to 128 terabytes of data and a table can have multiple LOB columns. A LOB consists of two parts:

The LOB Locator: A pointer that specifies the location of the LOB data.

The LOB data: The actual character or byte data stored in the LOB.

Depending upon the size of the data stored in a CLOB, NCLOB or BLOB, the data is stored either inside or outside the table. If the data is less than 4KB, it is stored in the same table, else it is stored outside. Now consider the following piece of code:













The above three code snippets, creates three tables CLOB_EXAMPLE, BLOB_EXAMPLE and BFILE_EXAMPLE. We now see how to populate the CLOBs and BLOBs with data. We now fire the INSERT statement to populate the tables CLOB_EXAMPLE and BLOB_EXAMPLE as shown:



In both the above cases, we have used the TO_CLOB to convert a text to a CLOB and TO_BLOB to convert the numbers to a BLOB. For modifying values, we may write:


SET CLOB_CONTENT = TO_CLOB('Jack and Jill went up the Hill')



SET BLOB_CONTENT = TO_BLOB('11111100000001100101')


Oracle Multimedia uses LOBs to create datatypes that could be used for multimedia application such as Multimedia ORDAudio, ORDDoc, ORDImage, and ORDVideo. Oracle Multimedia uses the database infrastructure to define object types, methods, and LOBs necessary to represent these specialized types of data in the database.

Collection Types and Structured Types

Collection types represents collection of elements like basic type, structured type or another collection type or arrays and are mapped into Oracle VARRAY and nested table types. We can create new or edit existing collection types.

Structured types on the other hand may be defined as user defined data types that have attribute and methods. Methods enable us to define behaviors for structured types. Structured types can also be part of a supertype and subtype inheritance hierarchy. A structured type can be defined based on a basic data type, a distinct type, another structured type, or a reference to structured type or it can be defined as a collection type.

Structure types can be declared as follows:

create type Department as

(DNo varchar(5),

Dname varchar(10),

DLocation varchar(20))

create type Employee as

(EmployeeID number,

EmployeeName varchar(20),

EmployeeAddress varchar(50),

DateOfJoining date,

department Department)

create table employee of Employee

The first statement defines a type called Department, which has three components: a number, a name and a location. The second statement defines a structured type Employee, which contains an ID, a name, address, date of joining and a department (of type Department). These types referred above are called structured types. And finally, a table employee containing tuples of type Employee is created.

A structured type can also have methods defined on it. We declare methods as part of the type definition of a structured type:

create type Employee as

(EmployeeID number,

EmployeeName varchar(20),

EmployeeAddress varchar(50),

DateOfJoining date,

salary integer,

department Department)

method calculateSalary(noOfDaysWorked integer)

Later we define the method body separately as:

create method calculateSalary(noOfDaysWorked integer) for Employee


set ownSalary = (noOfDaysWorked * wagePerDay)


Data Definition

An object oriented database comprises of objects and object classes linked via a number of abstraction mechanisms. We will now discuss a little on objects, object classes and the abstraction mechanisms:


Normally in a relational data model, two identical tuples or rows fundamentally refer to the same object. Thus, relational model were typically referred to as value-oriented model. This was overcome in the object oriented data model where two identical records can refer to two distinct objects via the notion of a unique system generated identifier.

An object may be redefined as a package of data and procedures. The attributes of the object contain the data and the object's methods define the procedures. Methods are activated by messages passed between objects.

All objects also posses the property of encapsulation. This is the process of packaging together of both data and process within a defined interface and controlled access across that interface. Encapsulation is implicit in the definition of an object since all manipulation of objects must be done via defined procedures attached to objects.

Object classes

An object class is nothing but grouping of similar objects. It is used to define the attributes, methods and relationships common to a group of objects. Also, we know that objects are instances of some class and hence they possess the same attributes and methods.


We had already discussed in the relational database design chapter the importance of the abstract mechanism generalization and also discussed previously the role of aggregation in data modeling.

Generalization allows us to declare certain object classes as subclasses of other object classes. For instance, as already cited in the previous chapters, that Engineer, Secretary and Technician might all be declared subclasses of an Employee class. Aggregation on the other hand, is the process by which a higher level object is used to group together a number of lower-level objects. For instance, a batch entity might be built up of an assembly of participants.


The generalization hierarchy associates with it the idea of the process of inheritance. There are two major types of inheritance: structural inheritance and behavioral inheritance.

In structural inheritance a subclass is said to inherit the attributes of its superclass. Hence, suppose an employee class has attributes name, address, salary, then a subclass such as engineer will also be defined by such attributes. In behavioral inheritance a subclass is said to inherit the methods of its superclass. Hence, if the employee class has a method calculatePay, then a subclass such as manager will also be characterized with this method.

A subclass also inherits participation in the relationship sets in which its superclass participates. A subclass may itself have further subclasses specified on it; it then forms a hierarchy or a lattice. If in a hierarchy, a given entity set is involved as a lower-level entity set in only one ISA relationship then the entity sets have only single inheritance.

Figure 14.1: Single Inheritance

If an entity set is a lower-level entity set in more than one ISA relationship, then the entity set has multiple inheritance, and the resulting structure is said to be a lattice. In a lattice or hierarchy, a subclass inherits attributes not only of its direct superclass, but also of all its predecessor super classes. A subclass with more than one superclass is called a shared subclass. All of the superclass - subclass relationships we have seen thus far have a single superclass. A shared subclass is subclass in more than one distinct superclass - subclass relationships, where each relationship has a single superclass (multiple inheritance).

Figure 14.2: Multiple Inheritance

Inheritance can be implemented at the level of types or at the level of tables. We will discuss them one by one.

With multiple inheritance a class may have more than one superclass. The class/subclass relationship is represented by a directed acyclic graph (DAG). This is particularly useful when objects can be classified in more than one way which are independent of each other.

Type Inheritance

To explain type inheritance let us first consider the type definition for employee:

create type Employee as

(EmployeeID number,

EmployeeName varchar(20),

EmployeeAddress varchar(50),

DateOfJoining date)

Let us suppose that we want to store some extra information in the database about employee who are engineers, secretaries and technicians. Since engineers, secretaries and technicians are also employee, we can use inheritance to define the engineer type, secretary type and technician types.

create type Engineer

under Employee

(EngType varchar(10))

create type Secretary

under Employee

(TypingSpeed varchar(10))

create type Technician

under Employee

(TGrade varchar(10))

All the three i.e. engineer, secretary and technician inherit the attributes of Employee - i.e. ID, name, address and date of joining. Engineer, secretary and technician are said to be subtypes of Employee and Employee is a supertype of engineer, secretary and technician.

Methods of a structured type are inherited by its subtypes, just as attributes are. But, a subtype can redefine the effect of a method by declaring the method again, using overriding method in place of method in the method declaration.

The above example cited above is an example of single inheritance. We would also cite an example of multiple inheritance.

Multiple inheritance allows a class to inherit from multiple classes. Consider the example of a class named Performer to inherit from a class named Vocals, a class named Guitarist, and a class named Drummer.






Figure 14.3: Type inheritance for Multiple inheritance

Let us now define the Human class as follows:

create type Musician as

(Name varchar2(10),

DateOfBirth date,

Age integer,

Address varchar2(50))

We now define Person, Musician and Worker as follows:

create type Vocals

under Musician

(Sex char(1),

salary integer,

Type varchar2(50))

method sing()

create type Guitarist

under Musician

(GuitarStyle varchar2(10),

salary integer)

method playGuitar()

create type Drummer

under Musician

(DrumType varchar2(10))

method playDrums()

Now we would show how to implement the type Performer, which involves multiple inheritance. Performer can be implemented as:

create type Performer

under Vocals, Guitarist, Drummer

Performer would inherit all the attributes of Vocals, Guitarist and Drummer. In SQL as in most other languages, a value of a structured type must have exactly one "most-specific type." That is, each value must be associated with one specific type, called its most-specific type, when it is created.

Table Inheritance

In the previous section, we have defined type inheritance. Here we will discuss table inheritance. For example, we define the employee table as:

create table employee of Employee

We now define the tables Engineer, Secretary and Technician as sub-tables of employee, as shown below:

create table engineer of Engineer

under employee

create table secretary of Secretary

under employee

create table technician of Technician

under employee

The types of the sub-tables must be subtypes of the type of the parent table. Thereby, every attribute present in employee is also present in the sub-table. Further, when we declare engineer, secretary and technician as sub-tables of employee, every tuple present in engineer, secretary or technician is implicitly present in employee.

Multiple inheritance is possible with tables, just as it is possible with types. Consider the following as follows:

create table performer of Performer

under Vocals, Guitarist, Drummer

As a result of the declaration, every tuple present in the performer table is also implicitly present in the Vocals, Guitarist and in the Drummer table, and in turn in the Musician table. It is noteworthy to mention that tuples in a sub-table corresponds to tuples in a parent table if they have the same values for all inherited attributes. But, each tuple of the super table can correspond to at most one tuple in each of its immediate sub tables.

Object identity and Reference types

An object retains its identity even if some or all of the values of variables or definitions of methods change over time. Object identity is a stronger notion of identity than in programming languages or data models not based on object orientation. This comprises of:

Value - This is data value such as primary key value used in relational systems.

Name - These are supplied by user and are used for variables in procedures.

Built-in - It is identity built into data model or programming language. No user supplied identifier is required and it is the form of identity used in object oriented systems.

Object identifiers

Object identifiers are used to uniquely identify objects. Object identifiers are usually unique and not two objects have the same identifier. Each object has only one object identifier. As for example, Depandant_Parent field of a person object may be an identifier of another person object. It can be stored as a field of an object to refer to another object. It can be system generated or external, such as social-security number. System generated identifiers are easier and convenient to use but cannot be accessed across database systems. It may be redundant if unique identifier already exists.

Object containment

Each component in a design may contain other components and this can be modeled as containment of objects. Objects containing other objects are called composite objects. As for example consider the following figure:












Figure 14.4: Object Containment

Multiple levels of containment create a containment hierarchy. In such cases, links are interpreted as is-part-of instead of is-a. Object containment allows data to be viewed at different granularities by different users.

We all know that object oriented languages provide the ability to refer to objects. An attribute of a type can be a reference to an object of a specified type. As for example, we can define a type Course with a field courseID and a field link which is a reference to the type Student, and a table course of type Course, as follows:

create type Course (

courseID varchar(10),

link ref(Student) scope student


create table course of Course

Here, the reference is restricted to tuples of the table student. For initializing a reference attribute, the identifier of the tuple that is to be referenced is required. So, to create a tuple with the reference value, we first create the tuple with a null reference and then set the reference separately:

insert into course

values ('C001', null)

update course

set link = (select ref(s) from student where SName = 'Ravi')

where courseID = 'C001'

Referenced table must have an attribute that stores the identifier, called the self-referential attribute:

create table student of Student

ref is EnrollmentID system generated;

Defining a Schema

Defining a schema for an Object Oriented database means defining object classes. We define here simple object classes for a company database described below:









RELATIONSHIP Department worksOn INVERSE departmentRegisters

RELATIONSHIP SET(Domain) belongsToDomain INVERSE domainSkill



RELATIONSHIP Department worksOn INVERSE departmentRegisters


ATTRIBUTE EmployeeDetails: Employee,

ATTRIBUTE domainDetails: Domain

We may explain the schema definition as follows:

Each class is defined by a unique name in the schema: Employee, Engineer, Secretary and Project.

Three classes are defined on super classes. The Employee class is said to form a subclass of a system class (meta-class) called object.

The attributes of the class Employee have been defined on pre-established data types integer, character and date. These are said to be simple attributes since they take a literal value and are defined on a standard data type such as integer.

The subclasses Engineer and Secretary contain no attribute declarations, but contain relationship declarations for worksOn. For instance, the Engineer class is declared as being related to the Department class. It is implicitly defined as a one-to-many link from Engineer to Domain since the relationship is implemented as a set of Domain identifiers. Both relationships have inverses defined. The inverse indicates a name for the traversal of the relationship from the linked class. Hence, the inverse relationship from Domain to Engineer is defined as domainSkill. This traversal will be defined in the Domain class and is also likely to be one-to-many.

The class Project might be considered one in which the concept of aggregation was important. We might define a Project as being made up of Employee and Domain details. The two attributes in this class are complex attributes since they contain collections and/or references - values that refer to other objects. Here the attributes are defined as references to specific instances of other classes.

Persistent Programming Languages

Persistent programming languages (PPL) are those programming languages that allow objects to exist even after the program has been closed down. PPL generally deals with persistent data. A programmer can manipulate persistent data directly and there is no need to fetch it into memory and store it back to disk, unlike embedded SQL. There is no need for explicit format (type) changes. Format changes are carried out transparently by system. Without a persistent programming language, format changes become a burden on the programmer since more code is to be written and there are more chances of bugs.

However the persistent programming languages suffer from certain drawbacks. Due to power of most programming languages, it is easy to make programming errors that damage the database. Also, the Complexity of languages makes automatic high-level optimization more difficult and PPL do not support declarative querying as well as relational databases.

Persistence of objects

Persistent objects differ from transient objects in the sense that persistent objects is for permanent storage, whereas transient is for memory. Transient and persistent objects can access each other mutually. Accessing a persistent object leads to loading the object into the transient heap. It is not accessed from transient objects any more, it will be written back to the persistent heap. A transient object becomes persistent as soon as it can be reached from a persistent root. Approaches to make transient objects persistent include:

Persistence by class - This is to declare all objects of a class to be persistent. This approach is simple but inflexible.

Persistence by creation - To extend the syntax for creating objects to specify that that an object is persistent.

Persistence by Marking - An object that is to persist beyond program execution is marked as persistent before program termination.

Persistence by reachability - To declare (root) persistent objects; objects are persistent if they are referred to (directly or indirectly) from a root object. It is easier for programmer, but more overhead for database system and similar to garbage collection.

Object-Oriented versus Object-Relational Databases

We now have arrived to the last topic of this chapter. Here we will discuss how object oriented databases differ from object relational databases. We tabulate here the distinguishing features:


Object Relational Database

Object Oriented Database

Use of datatypes

Object-relational databases are object-oriented databases built above the relational model and uses complex datatypes, but aim at making data modeling and querying easier.

Persistent programming language-based OODBs uses very complex datatypes, with no data translation required. Can handle arbitrary complexity; users can write methods and on any structure.

Querying capability

Object relational databases have powerful querying capability.

Querying capability of Object oriented database is poor.


Object relational databases provide high level of security.

Security is compromised in Object oriented Database.

Simplicity of development

Provides independence of data from application, good for simple relationships.

Objects are a natural way to model; can accommodate a wide variety of types and relationships.

Extensibility and content

Limited mostly to new data types.

Can handle arbitrary complexity; users can write methods and on any structure.

Performance versus


Level of safety varies with vendor, must be traded off; achieving both requires extensive testing.

Level of safety varies with vendor; most ODBMSs allow programmers to extend DBMS functionality by defining new classes.

Legacy people and the

universality of SQL

Can take advantages of

RDBMS tools and developers.

SQL accommodated, but intended for object oriented programmers.

The keyword "inverse" is used in which of the following?




All of the above

Which of the following is true concerning an ODBMS?

They have the ability to store complex data types on the Web.

They are overtaking RDBMS for all applications.

They are most useful for traditional, two-dimensional database table applications.

All of the above.

Which of the following is an unordered collection of elements that may contain duplicates?





Which of the following is true concerning the following statement: class Manager extends Employee

Manager is a concrete class and a superclass.

Manager is a concrete class and a subclass.

Manager is an abstract class and a superclass.

Manager is an abstract class and a subclass.

In object-oriented databases, what is the name given to the ability of objects to exist after an application program has terminated:

Static Binding


Two phase commit

Object integrity

What is the essential difference between object-oriented and conventional systems?

OO is more reusable

OO uses inheritance

OO systems reduce development costs

Changes to data structures are localized


Justify including attributes in class descriptions.

Define object identity.

What is multiple inheritance? When should it be used?

How can inheritance be implemented in a relational database?

Why can the performance of a pure object-oriented database exceed a relational or object-relational one?

Define 'object' (one sentence). Name the four components of an object.