Chapter-5

OBJECT ORIENTED
DATABASES
 Introduction
• Object-oriented databases (OODBs) evolved
from a need to support object-oriented
programming.
• The first OODBs appeared in the late 1980s

• OODBs are based on the object model and use

the same conceptual models as
– Object-Oriented Analysis,
– Object-Oriented Design and
– Object-Oriented Programming Languages.
2

2
 Object Analysis
• Object-Oriented Analysis (OOA) is concerned with
developing software engineering requirements and
specifications that expressed as a system's object
model
– composed of a population of interacting objects
• OOA can yield:
– Maintainability
– Reusability
– Productivity

• An object is a representation of a real-life entity or

abstraction.

3
 … Object Analysis
• Object model: definition of objects in the system
– the object name,
– the object attributes, and
– object relationships to other objects.
• Object-Oriented Design (OOD) is concerned with
developing an object-oriented model of a software
system to implement the identified requirements.
• Two Phases:
– High level
• Objects
– Low level
• Attributes, Methods, …

4
 Database Design Stages
1. Planning and Analysis
2. Conceptual Design
3. Implementation (Logical) Design
4. Implementation

5
 CONCEPTUAL DESIGN
• Conceptual design covers
– Data requirement modeling.
– Functional requirement modeling.

• The two common conceptual models for

Relational Database system are
– Entity – Relationship (E/R) model
– Object-Oriented Data Language (ODL) model
6

6
Object Definition Language (ODL)
Data Model
 Overview
• Object Definition Language (ODL) is an object-
oriented approach in a database design that is
standardized by the ODGM (Object Data
Management Group).
• OOP Concepts
– Complex Types
• Structures (Records), Reference (Pointers) and Collections

– Classes and Objects

• State and Behavior

– Objects Identity
– Inheritance
8
 ODL Design and Syntax
• Elements of ODL Classes
– Attributes
– Relationships
– Methods

• ODL class declaration

– Name for the class
– Optional key declaration(s)
– Extent declaration
– Element declarations
9
 EXAMPLE ON PROBLEM ANALYSIS
• The problem is to design a database system for “XYZ
Software Share Company” based on the following
information.
– The company runs various projects with a total of 68 full-time
employees and over 120 part-time employees.
– A project has a unique id and a name that may be designed for a
new software development or for a release of a new version of
software that had been developed by the company.
– The projects are having start date, due date, complete date and
status that describe their progress. Every project is lead by a
senior manager organized into teams of five to eight
programmers coordinated by a team leader.
10

10
 … EXAMPLE (CLASSES)
– The COMPANY runs various PROJECTS with a total of 68 FULL-
TIME EMPLOYEES and over 120 PART-TIME EMPLOYEES.
– A project has a unique id and a name that may be designed for a
new SOFTWARE development or for a release of a new VERSION
of software that had been developed by the company.
– The projects are having start date, due date, complete date and
status that describe their progress. Every project is lead by a
SENIOR MANAGER organized into teams of five to eight
PROGRAMMERS coordinated by a TEAM LEADER.
– The owners of the projects are the CUSTOMERS of the company.
A single customer can own one or more projects. The customers
have unique id, name and address.

11

11
 … EXAMPLE (ATTRIBUTES)
– The company runs various projects with a total of 68 full-time
employees and over 120 part-time employees.
– A project has a unique id and a name that may be designed for a
new software development or for a release of a new version of
software that had been developed by the company.
– The projects are having start date, due date, complete date and
status that describe their progress. Every project is lead by a
senior manager organized into teams of five to eight
programmers coordinated by a team leader.
– The owners of the projects are the customers of the company. A
single customer can own one or more projects. The customers
have unique id, name and address.

12

12
 ODL Design and Syntax
• Declaration
class <name> {
<list of element declarations, separated by semicolons>
};

attribute <type> <name>;

attribute enum <typename>
– Attribute{<enumlist1>, <enumlist2>,…}<name>;
attribute struct <typename>
{<type> <name1>, <type> <name2>,…}<name>;

relationship <type> <name>

inverse <relationship>;
13
 … ODL Design and Syntax
Example
• class Employee {
attribute string empId;
attribute string name;
attribute integer age;
attribute enum Gender {Male, Female} gender;
attribute struct Address {string city, string hAddr,
string phone} address;
relationship <Teams> assigned;
:
};

14
 Relationships
• Relationship Type
– Set:- Set<T>
– Bag (Multiset):- Bag<T>
– List:- List<T>
– Array:- Array<T, i>

• Inverse Relationships
– Inverse phrase

• Multiplicity of Relationships
– Many-to-many relationships
– One-to-many relationships
– One-to-one relationships
15
 … Relationships
• Example
class Employee {
:
relationship Set <Team> assigned;
:
};

class Team {
:
relationship Set <Employee> formed;
:
};


16
 … Relationships
• Example
class Employee {
relationship Set <Team> assigned
inverse Team::formed;
};
class Team {
relationship Set <Employee> formed;
inverse Employee::assigned;
};


17
 Inheritance
• Inheritance in is indicated by the colon operator “:”
class <Subclass> : <Superclass> {
<list of element declarations>
};

• Example
class PartTimeEmployee : Employee {
attribute real hourlPay;
attribute integer contractPeriod;
relationship Set <TimeSchedule> works
inverse TimeSchedule::working;
};

18
 Keys in ODL
• Declaration
(key <list of keys>)

(extent <extent name> key <list of keys>)

• Extent

class Employee (extent Employees key EmpId, NationalId, (Name, BDate)) {

attribute string empid;
attribute string name;
• Example
:
relationship Set <Teams> assigned;
inverse Teams::formed;
:
}; 19
Object - Relational Data
Model
 From ODL to Relational Model

• ODL Class to Relations

• Attributes
• ODL Relationships to Relations

21
 ODL Class to Relations

• ODL classes are directly mapped to relations

• Attributes
– Non-atomic attributes
• one attribute for each field of the structure

– Set-valued attributes
• one tuple for each value
• new relation and establishing a many-to-many relationship for each set-
valued attribute
• multiple attributes sets for each set-valued attribute

22
 … ODL Design to Relational
class Employee (extent Employees key EmpId, NationalId, (Name, BDate)){
attribute string empid;
attribute string name;
attribute integer age;
attribute enum Gender {Male, Female} gender;
attribute struct Address {string city, string hAddr, string phone} address;
};

– Employees (empId, name, age, gender, city, hAddr, phone)

23
 … ODL Design to Relational
class Employee (extent Employees key EmpId, NationalId, (Name, BDate)){
:
attribute struct set Address {string city, string hAddr, string phone}
address;
};

• One tuple for each value

– Employees (empId, name, age, gender, city, hAddr, phone)

• New relation
– Employees (empId, name, age, gender)
– Address (phone, hAddr, city, hAddr, empId)

24
 ODL Relationships to Relations

• ODL relationships are represented by relations of one

of the declarations from the inverse pairs.
• For many-to-one or one-to-one relationship the
relationship relation can be combined with the many
side relation.
– Passing the primary key of the one side to the many
side.

25
 … ODL Design to Relational
class Employee {
relationship Set <Team> assigned
inverse Team::formed;
};

class Team {
relationship Set <Employee> formed;
inverse Employee::assigned;
};
– Employees(EmpId, Name, Age, Gender, City, HAddr, Phone)
– Teams(TeamId, Name, Descr)
– Assigned(EmpId, TeamId)

26
 … ODL Design to Relational
class Project {
relationship <Customer> ownedBy
inverse Customers::owns;
};

class Customer {
relationship Set <Project> owns;
inverse Projects::ownedBy;
};

– Projects(ProjId, Name, SDate, DDate, CustId)

– Customers(CustId, Name, Address) 27
Object – Oriented
Databases
 Object Oriented Databases
• ODBMS - the application and the database
use exactly the same object model.
• RDBMS - object model for the application and
a relational-data model for the database.

• OODBS
– Storing and Sharing objects
– No universally-acknowledged standard
– Benefits:
• Storage of complex data structures 29
 … Object Oriented Databases
• The type of database application should
dictate the choice of database management
technology.

• Application Category
– Data Collection
• RDBMS
• Eg. Inventory System

– Information Analysis
30
• ODBMS
 Features of OODBS
• Applications handling BLOBs (binary large
objects),
• Modeling and creation of data as objects,
• New media types by creating new objects,
• Less code to develop,
• Reduced development time,
• Reduced maintenance costs.

31
 Technical Issues on OODBS
• Object-Relational databases (ORDBS)
– RDBMS vendors began developing and marketing
OR databases in part in response to the perceived
threat from OO databases.
– OR databases work via an object layer that sits
atop a conventional tabular relational engine
• Performance.
– OO databases can store data sets in their entirety
and thus typically run faster than relational
databases, which must break data sets into parts
for storage within tables and then reassemble 32
 Technical Issues on OODBS
• Standardization.
– The ODMG group created an OQL (Object Query
Language) standard, but very few database
vendors implemented it.
– Relational databases use the long-established SQL
(Structured Query Language) standard.
– SQL, used for querying and updating a relational
database, serves as a user interface and
application program interface to an RDBMS.

33