Object Database Systems

1 10/17/2017
Outline
Background
ORDBMS features, advantages,
disadvantages
Stonebrakers View
ADTs & Encapsulation
Inheritance
Objects, OIDs, Rererence types
Structured data types
Database Design for an ORDBMS
ORDBMS Implementation challenges
Comparing OODBMS & ORDBMS
 Background
Relational DBMSs are not good enough for
todays advanced database applications
RDBMS support a small, fixed collection of data
types (e.g. int, date, string), which are adequate
for traditional application domains such as
administrative data processing.
In many application domains, more complex
kind of data must be handled. Such complex data
has to be stored in OS files or specialized data
structures, rather than in a DBMS. Examples of
domains with complex data are CAD/CAM,
multimedia repositories, document mgmt, etc
To support such applications, a DBMS must
support complex data types.
 Background
Need for Complex Data Types
E.g. addresses, an entire address can be viewed
as an atomic data item of string type, but this will
hide details such as street, city, zip code which
can be of interest to queries. If they are
represented by breaking into parts then queries
will be complicated. Better alternative is to allow
structured data type, allow a type address with
subparts city, street etc.
Multivalued attributes: solution to it is creating a
new relation but it is expensive
Advanced Database Applications (such
applications involve complex data
type usage)

1. Computer-Aided Design (CAD)

2. Computer-Aided Manufacturing (CAM)
3. Computer-Aided Software Engineering (CASE)
4. Network Management Systems
5. Office Information Systems (OIS) and
Multimedia Systems
6. Digital Publishing
7. Geographic Information Systems (GIS)
8. Interactive and Dynamic Web sites
9. Other applications with complex and
interrelated objects and procedural data.
10. Multimedia applications: audio, graphic,
video data need to handle.
11. Real time control systems
Weaknesses of RDBMSs
Poor Representation of "Real World" Entities
Limitation in Encapsulating
Data (Structure) with Operations
(Behavior)
Limitation in Dealing with Composition
Limitation in Dealing with Aggregation
Difficulty Handling Recursive Queries
 Object database systems

Object-oriented concepts have been evolving to

handle these types of applications & led to the
development of object-database systems.

Object database systems have

developed along 2 distinct paths:
Object-oriented database systems
Object-relational database systems
 Object-oriented database systems
Object-oriented database systems are proposed as an
alternative to relational systems and are
aimed at application domains where complex
objects play a central role
The approach is heavily influenced by object-
oriented programming languages and can be
understood as an attempt to add DBMS
functionality to a programming language
environment
An alternative to relational systems aims at application
domains where complex objects play a central role
OODBMS examples: O2, GemStone, Iris, objectstore,
object-base.
 ODMG has developed a standard
ODM & OQL which are equivalent of SQL
standard for relational database systems.
Object-relational database systems

Object-relational database systems

Extension of RDBMS with
functionality to support broader class of
applications
Bridge b/w relational & object-oriented paradigms.
ORDBMS examples: Oracle, IBM, and Informix
The SQL:1999 standard extends
SQL to incorporate support for object-relational
model of data.
 Evolution of Database Management Systems
1st Generation
Hierarchical
Network

2nd Generation
Relational Database

3rd Generation
Object Oriented Database
Object-Relational Database
 Evolution of Database Management Systems

First Generation DBMS: Network and Hierarchical

Required complex programs for even simple
queries.
Minimal data independence.
No widely accepted theoretical foundation.

Second Generation DBMS: Relational DBMS

Helped overcome these problems.

Third Generation DBMS: OODBMS and ORDBMS.

 ORDBM
S

12 10/17/2017
 ORDBMSs - Features
It support object oriented capabilities to relational DBMS
& also preserves full relational capabilities
OO features being added include:
User-extensible type
Abstract data types (ADTs)
Encapsulation
Inheritance
Method overloading and binding
Dynamic binding of methods
Object identity
 ORDBMSs

Original term used to

describe such systems was Extended
Relational DBMS (ERDBMS).
Now use Object-Relational DBMS (ORDBMS),
and sometimes Universal Server or Universal
DBMS (UDBMS).
Some analysts predict ORDBMS will have
50% larger share of market than RDBMS.
 Advantages of ORDBMSs
Resolve many of known weaknesses of RDBMS
Reuse and sharing
Reuse comes from the ability to
extend server to perform standard
functionality centrally rather than
having each application coded to do it
Gives rise to increased productivity
both for developer and end-user
Preserves the significant body of knowledge
and experience that has gone into developing
relational applications
Disadvantages of ORDBMSs
Complexity
Increased costs
Proponents of relational approach believe
simplicity and purity of relational model are
lost
Some believe RDBMS is being extended for
what will be a minority of applications
OO purists not attracted by extensions either
SQL now extremely complex
Stonebrakers View
 New Data Types
User-defined abstract data types (ADTs):
New applications image, voice, and video footage,
and these must be stored in the database.Further,
it needs special functions to manipulate these
objects
E.g., we may want to write functions that
produce a compressed version of an image or a
lower resolution image
Structured types: In this application we need
new types built up from atomic types using
constructors for creating sets, tuples, arrays,
sequences, and so on
Inheritance: As the number of data types
grows, it is important to recognize the
commonality between different types and to take
 advantage of it. For example,compressed images
and lower-resolution images are both, at some
level, just images. It is therefore desirable to
inherit some features of image objects while
defining (and later
18 manipulating) image objects
 ADTs & Encapsulation
Combination of an atomic data type & its associated
methods is called an
abstract data type ADT.
Traditional SQL has Built-in ADTs like int, float, string,
etc.
These types have simple methods associated

with them (arithmetic , comparison, equality,

LIKE, etc.)
ORDBMS allows the user to create their own ADTs
if a type cannot be naturally defined in terms of
the built-in types.
CREATE TABLE Frames(frameno integer, image
jpeg-image , category integer);
ADTs & Encapsulation
The label abstract is applied to these types because
the DBMS doesnt need to know how an ADTs data is
stored or how methods work.
It merely needs to know what methods are
available & I/P & O/P types for the methods.
Hiding ADT internals is called as encapsulation.

create or replace type Emp_type as

object( emp_no number(5),
ename
varchar(20),
dwages
number(5),
member function getsal return number,
member function getsal(ndays number)return number
);
ADTs & Encapsulation :How we have
Implemented

create or replace type body

Emp_type as member
function getsal return
number is begin
return
dwages;
end;
member function getsal(ndays number)
return number is begin
return
ndays*dwages; end;
end;
 USER-DEFINED ABSTRACT DATA
TYPES
CREATE TABLE Frames (frameno integer, image jpeg
image, category integer);
In Frames table it has a column image of type
jpeg image, which stores a compressed image
representing a single frame of a film
The jpeg image type is not one of the DBMS's built-
in types and was defined by a user for an application
to store image data compressed using the JPEG
standard
Allowing users to define arbitrary new data types is
a key feature of ORDBMSs and it allows users to store
and retrieve objects of type jpeg image, just like an
object of any other type, such as integer
New atomic data types usually need to have type-
 specific operations defined by the user who creates
them
E.g., one might define operations on an image data
type such as compress, rotate, shrink, and crop. The
combination of an atomic data type and its associated
methods is called an abstract data type, or ADT
22
VARYING ARRAYS :How we have Implemented

It is a set of objects, each with the same data

types.The size of the array is limited when it is
created
When a table is created with a varying array, the
array is a nested table with a limited set of rows
Known as varrays,allow storing repeating attributes in
tables.

CREATE TYPE COMPANY_ADDRESS_TY AS VARRAY(3) OF VARCHAR2(1000);

CREATE TABLE
COMPANY_INFO( COMPANY_NAME
VARCHAR2(50), ADDRESS
COMPANY_ADDRESS_TY);
 Structured Data Types
SQL:1999 introduced two type constructors that allow
to define new types with internal structure.Types
defined using type constructors are called structured
types.So,field values need not be atomic only.

ROW(n1t1,nntn) : A type representing a row, or

tuple, of n fields with fields n1,..nn of types t1,..tn
Row example(SQL:1999) : CREATE TYPE theatre_t AS
ROW(tno integer, name text , address
text , phone text); ROW(filmno : integer,stars :
varchar(25) ARRAY [10])
Illegal usage : (integer ARRAY[5]) ARRAY [10]
Base ARRAY[i] : A type representing an array of(up to) i
base-type items
 CREATE TABLE Films ( filmno integer, title text, stars
VARCHAR(25) ARRAY[10]),director text, budget float);
 Collection Types

SQL:1999 supports only the ROW and ARRAY type

constructors. Other common type constructors
include
Listof(base): a type representing a sequence of base-
type items
Setof(base) : A type representing a set of base-
type items. Sets can not contain duplicate
elements
Bagsof(base) : A type representing a bag of multiset of
base-type items
They can be composed: for example,
ARRAY(ROW(age: integer, sal: integer))
 Types defined using type constructors are called
structured types
Those using listof, ARRAY, bagof, or setof as
the outermost type constructor are sometimes
referred to as collection types, or bulk data
types
 Collection Types
A value of ROW type can appear in a field of a tuple
In SQL:1999 the ROW type has a special role
because every table is a collection of rows- every
table is a set of rows
SQL:1999 also includes a data type called ARRAY,
which allows a field value to be an array
The ROW and ARRAY type constructors can be
freely interleaved and nested to build structured
objects
The listof, bagof, and setof type constructors are not
included in SQL:1999
IBM DB2, Informix UDS, and Oracle 8 support the ROW
constructor
 Inheritance

In object-database systems, inheritance is

supported directly and allows type definitions to
be reused and refined very easily.
It can be very helpful when defining similar but
slightly different classes.
In object-database systems, inheritance can be used
in two ways:
For reusing and refining types
For creating hierarchies of collections of similar but
not identical objects.
 Type Inheritance : HOW IT IS IMPLEMENTED
Inheritance allows a new object type to be created from an
existing object type.We can first create object type that is
more generic and then create object types that are more
specific from generic object type.
Here we create an object type for a person called
person_type and then inherit it into another object type
called student_type
The new object type is called SUBTYPE and the existing one is
called as SUPERTYPE
All the attributes & methods of supertype are inherited into
subtype.
Subtype can add new attributes and methods or even override
existing methods
Oracle 9i supports single inheritance,means,a subtype can
be derived from only one supertype
Create or replace type
type_name as object (
x
 varchar2(2
0), y
varchar2(1
00), z
number(3),
Final member function function_name return varchar2)NOT FINAL;
Type Inheritance : HOW IT IS IMPLEMENTED
If an object type is to be used as supertype then
it must be declared as NOT FINAL
FINAL object types are final and they cannot be
inherited.
When a method is declared FINAL then the
method cannot be overridden in subtype.
function_name function of person_type is
declared as FINAL and it cannot be overridden
Methods are not final by default.They can be
overridden in the subtype
A member can also be defined as FINAL; it is not
to be overridden by subtypes
By default object type is final and subtypes
cannot be derived from it. So giving NOT FINAL for
objects that are to be inherited is mandatory
 Defining types with Inheritance
Inheritance allows us to
capturespecialization explicitly in the
database design.
Create type theater_t as (tno integer,name
text,address rext,phone text) ;
CREATE TYPE theatercafe_t UNDER
theater_t(menu text);
Here theatercafe_t inherits
attributes & methods of theater_t.
Inheritance creates explicit relationship in the
database between the subtype(theatercafe_t)
and the supertype(theater_t).
 Defining types with Inheritance
An object of the subtype is also considered to be
an object of the supertype.
This means that any operations that apply to
the supertype also apply to the subtype.This is
expressed in the following principle:
The substitution Principle : Given a supertype
A and a subtype B, it is always possible to
substitute an object of type B into a legal
expression written for objects of type A, without
producing type errors.
This enables the code reuse; as queries &
methods written for the supertype can be
applied to the subtype without modification.
 OBJECTS, OBJECT IDENTITY, AND REFERENCE
TYPES
In object-database systems, data objects can be
given an object identier (oid), which is some
value that is unique in the database across time
The DBMS is responsible for generating oids and
ensuring that an oid identifies an object uniquely
over its entire lifetime
In some systems, all tuples stored in any table are
objects and are
automatically assigned unique oids; in other
systems, a user can specify the tables for which the
tuples are to be assigned oids
An object's oid can be used to refer (or `point') to it
from elsewhere in the database. Such a reference
has a type (similar to the type of a pointer in a
 programming language), with a corresponding type
constructor : ref(base): a type representing a
reference to an object of type base

32
 OBJECTS, OBJECT IDENTITY, AND REFERENCE
TYPES
Large objects in SQL: SQL:1999 includes a
new data type called LARGE OBJECT or LOB,
with two variants called BLOB (binary large object)
and CLOB (character large object).This standardizes
the large object support found in many current
relational DBMSs
LOBs cannot be included in primary keys, GROUP
BY, or ORDER BY clauses.They can be compared
using equality, inequality, and substring operations
A LOB has a locator that is essentially a
unique id and allows LOBs to be manipulated
without extensive copying.
LOBs are typically stored separately from the data
records in whose fields they appear. IBM DB2,
 Informix, Microsoft SQL Server, Oracle 8, and
Sybase ASE all support LOB

33
URLs and OIDs in SQL:1999
OIDs uniquely identify a single object over all
time, but the web resource pointed at by an URL
can change over time
OIDs are simply identifiers and carry no physical
information about the objects they identify-this makes
it possible to change the storage location of an object
without modifying pointers to the object. But URLs
include network addresses and often file-system names
also, meaning that if the resource identified by the URL
has to move to another file or network address, then all
links to that resource are either incorrect or require a
change
OIDs are autonomatically generated by the DBMS for
each object, whereas URLs are user-generated. URLs,
they often embed semantic information into the URL
via machine, directory; this can become confusing if
 the object's properties change over time
For URLs,deletion can be dangerous, leads to 404
page not found". For OIDs,SQL:1999 allows to say
REFERENCES ARE CHECKED as part of the SCOPE
clause.This is a direct extension of reverential
integrity.
 REFERENCES: How it is
Implemented
This data type acts as a pointer to an object. A REF
can also be used in a manner similar to a foreign key
in a RDBMS.A is used primarily to store an object
identifier.
REF establish relationship between two object
tables, much the same way a primary/foreign key
relationship in relational tables. Relational tables have
difficulty ,if more than one table is needed in a
primary/foreign key relationship related to a single
tabl .e.g an address table that stores addresses from
several entities. The use of REF eliminates this
problem, as unscoped REF can refer to any accessible
object table
A SCOPE clause in a definition forces a set of REFs
 for a given column to be confined to a single object
table
There can be only one REF clause for a given REF
column.REF SCOPE can be set at either the column or
table .
 REFERENCES: How it is
Implemented
REF values can be stored with
or without a ROWID.Storing a REF with a ROWID
speeds dereferencing operations, but takes more
space. If WITH ROWID is not specified with REF
clause, the default is to not store ROWIDs with the
REF values
SCOPE clauses prevent dangling references, as
they will not allow REF values unless the
corresponding entries in the SCOPE table is
present
They are physically separate from the objects that
refer to them
REF are essentially pointers to row objects
Column object would be a varying array; it is an
 object that is treated as a column in a table
A call to a REF returns the OID of the object
instance.An OID is a 128-byte base-64 number, which
isnt very useful except as a handle to the object
instance.
 REFERENCES: How it is
Implemented
To get the value stored in the instance that is
referred to by a REF,the DEREF routine is used. DEREF
returns the values in the object instance referenced by
a specific REF value
REF types have values that are unique
identifiers or OIDs.SQL:1999 requires that a given REF
type must be associated with a specific table.e.g. A
column theater is declared as of type
REF(theater_t).The SCOPE clause specifies that items
in this column are references to rows in the Theater
table
An item of reference type REF(basetype) is not the
same as the basetype item to which it points.To access
the referenced basetype item, a built-in deref() method
is provided along with the REF type constructor.e.g.
 given a table of Nowshowing table, one can access the
name field of the referenced theater_t object with the
syntax Nowshowing.deref(theater).name
Since references to tuple types are common,
some systems provide a java-style arrow operator
Using the arrow notation, the name of the referenced
theater can be accessed with the equivalent syntax
Nowshowing.theater->name
 1. For creating a TYPE
object: CREATE TYPE
DEPT_TY AS OBJECT(
DNAME VARCHAR2(100), ADDRESS VARCHAR2(200));
2. For creating a TABLE object using the
aboveTYPE object: CREATE TABLE DEPT OF
DEPT_TY;
3. For creating a TABLE object that references to the TYPE
object and also specifies the SCOPE:
CREATE TABLE EMP(ENAME VARCHAR2(100), ENUMBER NUMBER,
EDEPT REF DEPT_TY SCOPE IS DEPT);
4. For inserting values in the DEPT table:
INSERT INTO DEPT VALUES(DEPT_TY('Sales', '501 Baliga
Street')); INSERT INTO DEPT VALUES(DEPT_TY('Accounts',
'84 Darya Ganj'));
5. For viewing the
DEPT table: SELECT * FROM
DEPT;
6. For viewing the REF from the
DEPT table: SELECT REF(D) FROM
DEPT D; 00000280kdfkdlldlld
6. For inserting a row into the EMP table for an employee in
Sales department: INSERT INTO EMP SELECT 'Nirmal
Pandey', 1, REF(D) FROM DEPT D
WHERE D.DNAME = 'Sales';
8. For viewing records from the
EMP table: SELECT * FROM
EMP;
9. For viewing the ENAME, ENUMBER and the details of EDEPT
column of the EMP table using the DEREF routine:
SELECT ENAME, ENUMBER, DEREF (EDEPT) FROM EMP;
Output:
Ename Enumber Deref(edept)(Dname,address)

Nirmal Pandey 1 Dept_t(Sales,501 Baliga Street)

 Dereferencing Reference Types
An item of reference type ref(datatype) is not
the same as the datatype item to which it points
In order to access the referenced foo item, a
built-in deref() method is
provided along with the ref type constructor. For
example, given a tuple from the Nowshowing
table, one can access the name field of the
referenced theater_t object with the syntax
Nowshowing.deref(theater).name
Since references to tuple types are common,
some systems provide a java- style arrow
operator
Using the arrow notation, the name of the
referenced theater can be accessed with the
 equivalent syntax Nowshowing.theater->name

40
 Database design for an ORDBMS: Object
Identity

Although reference types and structured types seem

similar, they are actually quite different
E.g. a structured type my theater tuple(tno integer,
name text, address text, phone text) and the
reference type theater ref(theater t)
There are important differences in the way that
database updates affect these two types
Deletion: Objects with references can be affected by
the deletion of objects that they refer, while reference-
free structured objects are not affected by deletion of
other objects
E.g., if the Theaters table were dropped from the
database, an object of type theater might change
value to null, because the theater t object that it
refers to has been deleted, while a similar object of
type my theater would not change value
 Database design for an ORDBMS: Object
Identity

Update: Objects of reference types change value

if the referenced object is updated. Objects of
reference-free structured types change value only
if updated directly.
Sharing vs. Copying : An identified object can
be referenced by multiple reference-type items, so
that each update to the object is reflected in many
places. To get a similar effect in reference-free
types requires updating all copies of an object
 Database design for an ORDBMS: Object
Identity

Storage overhead: Storing copies of a large value in

multiple structured type objects may use much more
space than storing the value once and referring to it
elsewhere through reference type objects. This
additional storage requirement can affect both disk
usage and buffer management(if many copies are
accessed at once)
Clustering: The subparts of a structured object are
typically stored together on disk. Objects with
references may point to other objects that are far
away on the disk, and the disk arm may require
significant movement to assemble the object and its
references together. Structured objects can thus be
more efficient than reference types if they are
typically accessed in their entirety
OODBMS Vs. ORDBMS : SIMILARITIES

Both support user-defined ADTs,structured types,

object identity
,reference types and inheritance
Both support a query language for manipulating
collection types: ORDBMS support an extended
form of SQL and OODBMS support ODL/OQL
 OODBMS Vs. ORDBMS :
Differences
OODBMS try to add DBMS functionality to a
programming language. whereas ORDBMSs try to
add richer data types to RDBMS.
OODBMS aim to achieve seamless integration with a
programming language
s.a. Java,C++ etc.Such integration is not an important
goal for ORDBMS. SQL:1999, like SQL-92, allows us to
embed SQL commands in a host language, but the
interface is very evident to the SQL programmer
An
OODBMS is aimed at applications where an object-
centric view-
point is appropriate; a typical user session consists of
retrieving a few objects and working on them for long
periods, with related objects. Transactions are likely
to be of long duration. Objects may be extremely
large may have to be fetched in piece.
AN ORDBMS is optimized for applications in which
large data collections are the focus even though
objects may have rich structure and be fairly large.
Transactions are assumed to be relatively short.
OODBMS Vs. ORDBMS : Differences
The query facilities of OQL are not supported
efficiently in most OODBMSs , whereas the query
facilities are the centerpiece of an ORDBMS . To
some extent, this selection is the result of different
concentrations of effort in the development of these
systems. To a significant extent, it is also a
consequence of the systems being optimized for
very different kinds of applications