MaxwellPaper.doc - Kennesaw State University

mexicanmorningData Management

Dec 16, 2012 (4 years and 6 months ago)

235 views



KENNESAW STATE UNIVERSITY




DEPARTMENT OF COMPUTER SCIENCE AND
INFORMATION SYSTEMS

MASTER OF SCIENCE IN APPLIED
COMPUTER SCIENCE

CS 8
630

D
ATABASE ADMINISTRATION

TERM PAPER
:

Object Oriented Database and
Object Relational Databases


AUTHOR:
MAXWELL K NGAN
GA


JULY
2
2, 2004




TABLE OF CONTENTS



PAGE

PART 1
CHAPTER 24
………………………………….………2


1.1
A
DVANCED
D
ATABASE

APPLICATIONS
…………..…………..
2

Computer Aided Design (CAD
)

Computer Aided Manufacturing (CAM)

Network Management System

Office information System (ois) and Multimedia systems

Digital Publishing

Geographic information Systems (GIS)

Intera
ctive and Dynamic Web sites


1.2 WEAKNESSES OF RDBMSs
…………………………...………..3

1.3 OBJECT
-
ORIENTED CONCEPTS
…………………..…………..3

Abstraction
,
Encapsulation
,
Information hiding


Objects and Attributes

Classes

Polymorphism and Dynamic Binding


1.4
STORING OBJECTS IN A
RELATIONAL DATABASE
…..………5

Mapping Classes to Relations

Accessing Objects in the Relational Database


1.5 NEXT GENERATION DATABASE
SYSTEMS

………..…………
5

Semantic Data Model [Hammer and McLeod, 1981]

Functional Data Model [Shipman, 1981]

Semantic Association M
odel [Su, 1983]



PART 2
CHAPTER.
…………….……………………………….6


OBJECT
-
ORIENTED DBMSs
………………………………….6


1.1

CONCEPTS AND DESIGN
………………………………………6

Introduction to OO Data Models and OODBMSs

Persistent programming Languages

Data programming languages

Alternative Strategies f
or Developing an OODBMS

-

Extend an existing Object
-
Oriented

programming language with database
capabilities

-

Provide extensible object
-
oriented DBMS libraries

-

Embed Object
-
Oriented Database language constructs in a conventional host
language

-

Extend an existi
ng database language with Object
-
Oriented capabilities

-

Develop a novel database data model/data language


1.2

OODBMS PERSPECTIVES
……………………………………...6


Point Swizzling techniques

Accessing an Object


1.3

PERSISTENCE
………………………………………………….7

Persistence schemes

Checkpoint
ing

Serialization

Explicit paging

Orthogonal persistence

Persistence independence

Data type Orthogonality

Transitive persistence

Advantages and
Disadvantages

of Orthogonal Persistence

What Objects do queries apply to?

What objects are part of transaction s
emantics?


1.4

ISSUES IN OODBMS
…………………………………………..11

Transactions

Versions

Schema evolution

Architecture

-

Clint
-
Server


-
object server


-
page server


-
Database server


-

Storing and executing methods



-

It eliminates redundant code


-

It simplifies modifications


-

Methods are more secure


-

Improve integrity


Benchmarking

-

Wisconsin benchmark

-

TPC
-
A and TPC
-
B benchmarks

-

TPC
-
C ben
chmark

-

001 benchmark

-

007 benchmark


1.5

OBJECT
-
ORIENTED DATABASE SYSTEM MANIFESTO
……..12

1.6

ADVANTAGES AND DISADVANTAGES OF OODBMSs
……….14

1.7

OBJECT
-
ORIENTED DATABASE DESIGN
……………………15

Comparison of Object
-
Oriented data modeling and Conceptual Data Modeling

Relationshi
ps and Refe
re
ntial Integrity

Behavioral Design



PART 3 CHAPTER 26……………………………………….16


OBJECT
-
ORIENTED DBMSs STANDARDS AND SYSTEMS


1.1
OBJECT MANAGEMENT GROUP
…………………………….16

Background

Common object request Broker Architecture


1.2
OBJECT DATA STANDARD OD
MG 3.0, 1999
.............................
16

Object data Management Group

Object Model

Object Definition language

Object Query language

Other parts of the ODMG Standard



Object Interchange Format



ODMG language bindings


1.3
OBJECTSTORE
.......................
..................................................
17

Architecture

Data
Definition

in ObjectStore

Data Manipulation in ObjectStore


PART 4
CHAPTER 27
………………………………………18


OBJECT
-
RELATIONAL DBMSs
…………………………………18


INTRODUCTION
…………………………………………………18


1.2 THE TH
IRD GENERATION DATABASE MANIFESTOS

The Third Manifesto
…………………………………………………18


1.3 POSTGRES


AN EARLY ORDBMS
……………………..…….19


1.4 SQL3
………………………………………………………….20


1.5 QUERY PROCESSING AND OPTIMIZATION
...........................21


1.6 OBJECT
-
ORIENTED EXTENSION
S IN ORACLE
……………..22


1.7 COMPARISON OF ORDBMS AND OODBMS
………………….22


Reference:
………………………………………………………22


















PART 1
CHAPTER 24



INTRODUCTION TO OBJE
CT DBMS


Object

orientation is an approach to software construction that shows considera
ble
promise for solving some of the classic problems of software development. The
underlying concept is that all software should be constructed out of standard, reusable
components wherever possible. The emergences of Object
-
Relational DBMS and object
-
Rela
tional DBMS have been combined to allow the concurrent modeling of both data and
the processes acting upon the data.


1.1 ADVANCED DATABASE APPLICATIONS


Computer Aided Design (CAD)

A CAD database stores data relating to mechanical and electrical design
co
vering, for

example, buildings
, aircraft, and integrated circuit chips. Designs of this type have some
common characteristics

Computer Aided Manufacturing (CAM)

Computer Aided Manufacturing (CAM) is the use of computers to assist the
manufacturing process.

CAD and CAM are combined CAD/CAM so that the output of
the CAD module is fed to the CAM system. The design can be converted into a sequence
of processes (drilling, turning, milling etc) for manufacture on a Numerically Controlled
(NC) milling machine, for

example.

Computer
-
Aided Software Engineering (CASE)

To speed up the software system building process, a new concept of designing software
was introduced in the '70s, called
Computer Aided Software Engineering (CASE).

This
term is used for a new generation

of tools that applies rigorous engineering principles to
the development and analysis of software specifications. Simply, computers develop
software for other computers in a fast way by using specific tools

Network Management System

Enables network admini
strators to identify and resolve problems and performance
bottlenecks before they impact network services. ONMS is essential for maintaining user
quality of experience in multi
-
cast video, IP Telephony, and other business
-
critical
applications

Office infor
mation System (
OIS
) and Multimedia systems

An OIS database stores data relating to the computer control of information in a business,
including electronic mail, documents, and invoices and so on.

Digital Publishing

Digital publishing is the digitization of

the professional publishing process, coupled with
the commerce and distribution powers of the Internet. Digital publishing takes place after
the copy is written and includes the digital preparation and automated production,
delivery and distribution of yo
ur content. By harnessing powerful XML technology, each
of these functions is tied together through a common infrastructure to facilitate the
sharing of data and process information between and among them. The result is a Web
-
based publishing solution that

can economically produce one or thousands of copies, as
they are needed, through an elegant publishing platform, with zero inventory.

Geographic information Systems (GIS)

A GIS combines layers of information about a place

to give you a better understandin
g of that
place. What layers of information you combine depends on your purpose

finding the
best location for a new store, analyzing environmental damage, viewing similar crimes in
a city to detect a pattern, and so on.

Interactive and Dynamic Web sites

We
b

sites

that allows us to do business online, with
interactive

displays
and

database
interactivity.


1.2 WEAKNESSES OF RDBMSs



Representation of ‘real world’ entities: The process of normalization generally
leads to the creation of relations that do not co
rrespond to entities in the ‘real
world’.



Semantic overloading: The relational model has only one construct for
representing data and data relationships: the relation.



Homogeneous data: The relational model assumes both horizontal and vertical
homogeneit
y. Also, intersection of a row and column must be an atomic value =>
this structure is restrictive for many ‘real world’ objects with a complex structure.



Limited operations: The relational model has a fixed set of operations (provided
in SQL). => does not

allow new operations to be specified.



Recursive queries: It is extremely difficult to produce recursive queries (queries
about relationships that a relation has with itself).



Impedance mismatch: Result of mixing different programming paradigms (e.g.,
SQ
L is a declarative language that handles rows of data whereas a high
-
level
language such as ‘C’ is a procedural language that can handle only one row at a
time).


1.3 OBJECT
-
ORIENTED CONCEPTS

Abstraction

is the
Process of picking out (
abstracting
) common f
eatures of objects and
procedures. A programmer would use abstraction, for example, to note that two functions
perform almost the same task and can be combined into a single function. Abstraction is
one of the most important techniques in software engineer
ing

Encapsulation

is
the process of combining elements to create a new entity. For example,
a procedure is a type of encapsulation because it combines a series of computer
instructions. Likewise, a complex data type, such as a record or class, relies on
en
capsulation. Object
-
oriented programming languages rely heavily on encapsulation to
create high
-
level objects

Information hiding

the process of hiding details of an
object

or
function
. Information
hiding is a powerful programming technique because it reduc
es complexity. One of the
chief mechanisms for hiding information is
encapsulation

--

combining elements to
create a larger entity. The programmer can then focus on the new object without
worrying about the hidden details. In a sense, the entire
hierarchy

of
programming

languages

--

from
machine languages

to
high
-
level languages

--

can be seen as a form of
information hiding.

Information hiding is also used to prevent
programmers

from changing
---

intentionally
or unintentionally
--

parts of a program


Att
ributes

(instance variables)
describe the current state of an object

Objects

are the physical and conceptual things we find in the universe around us.
Hardware, software, documents, human beings, and even concepts are all examples of
objects.

Aggregation

is either: the process of creating a new object from two or more other
objects, or an object that is composed of two or more other objects.

A
monolithic object
is an object that has no externally
-
discernible structure. Said
another way, a monolithic objec
t does not appear to have been constructed from two or
more other objects. Specifically, a monolithic object can only be treated as a cohesive
whole

Composite objects

are objects that have an externally
-
discernible structure, and the
structure can be addre
ssed via the public interface of the composite object. The objects
that comprise a composite object are referred to as
component objects

The
state

of an object is the condition of the object, or a set of circumstances describing
the object

Classes

A
class

is a thing that consists of both a pattern and a mechanism for creating items based
on that pattern. This is the "class as an `instance factory'" view;
instances

are the
individual items that are "manufactured" (created) using the class's creation mechanis
m.

A
metaclass

is a class whose instances themselves are classes

A
parameterized class

is a template for a class wherein specific items have been
identified as being required to create non
-
parameterized classes based on the template

The term
polymorphism
,
originates from the Greek word 'poly morph' meaning many
forms.
P
olymorphism concept allows different objects to react to the same stimuli (i.e.
message) differently
[
Hymes, 1995Polymorphism and Dynamic Binding
]

Inheritance

allows

o
ne class to be defined
as a special case of a more general class.
These special cases are known as
subclasses

and the more general cases are known as
super classes
. The process of forming a superclass is referred to as
generalization
;
forming a subclass is specialization. A subc
lass inherits all the properties of its superclass
and additionally defines its own unique properties (attributes and methods).

Overloading
allows the name of the method to be reused within a class definition or
across definitions.

Overriding
is a special
case of overloading, allows the name of a property to be
redefined in a subclass.

Dynamic binding

allows the determination of an object‘s type and methods to be
deferred until runtime


1.4
STORING OBJECTS IN A RELATIONAL DATABASE

Mapping Classes to Relatio
ns

Accessing Objects in the Relational Database


1.5 NEXT GENERATION DATABASE SYSTEMS

Semantic Data Model [Hammer and McLeod, 1981]

Functional Data Model [Shipman, 1981]

Semantic Association Model [Su, 1983]




















PART 2
CHAPTER 25


O
BJECT
-
ORIENTED DBMSs


1.8

CONCEPTS AND DESIGN

Introduction to OO Data Models and OODBMSs

Object
-
Oriented Data Models

is a logical data model that captures the semantics of
object supported in object
-
oriented programming.

Object
-
Oriented Database

is a persisten
t and sharable collection of objects defined by
an OODM

OODBMS

is the manager of an OODB


Persistent programming Languages

This is a language that provides its users with the ability to (transparently) preserve data
across successive executions of a progr
am, and even allows such data to be used by many
different programs


Data programming languages

This is a language that integrates some ideas from the database programming model with
traditional programming language features

Alternative Strategies for Dev
eloping an OODBMS

-

Extend an existing Object
-
Oriented programming language with database
capabilities

-

Provide extensible object
-
oriented DBMS libraries

-

Embed Object
-
Oriented Database language constructs in a conventional host
language

-

Extend an existing dat
abase language with Object
-
Oriented capabilities

-

Develop a novel database data model/data language


1.9

OODBMS PERSPECTIVES


The object
-
oriented database management system (OODBMS) has gained considerable
popularity in the last few years due to its flexibility

and compatibility


Point Sizzling techniques

Pointer Sizzling. The action of converting object identifiers to main memory pointers and
back again. The aim of point sizzling is to optimize access to objects. There are various
techniques used.

a)

No sizzling

The easiest implementation of faulting objects into and out of memory is to do any
sizzling at all. In this case objects are faulted into memory by the underlying object
manager, and a handle is passed back to the application containing the objects OID.

b)

Ob
ject Referencing

To be able to swizzle a persistent object’s OID to virtual memory pointer, a
mechanism is required to distinguish between resident and non
-
resident objects. Most
techniques are variations of either edge marking or node marking.

c)

Hardware
-
ba
sed schemes

Hardware based swizzling uses virtual memory access protection violations to detect
accesses of non
-
resident objects. These schemes are the standard virtual memory
hardware to trigger the transfer of persistent data from disk to main memory


Cl
assification of pointer swizzling

Pointer swizzling techniques can be classified according to the following three
dimensions

a)

copy versus in
-
place swizzling

When faulting objects in, the data can either be copied into the application‘s local
object cache or

it can be accessed in place within the object manager’s database
cache. Copy swizzling may be more efficient as, in the worst case; only modified
objects have to be swizzled back to their OIDs, whereas an in
-
place technique may
have to unswizzle an entire

page of objects if one object on the page is modified. On
the other hand, with the copy approach, every object must be explicitly copied into
the local object cache.

b)

Eager Versus Lazy Swizzling

Moss and Elliot [1990] defined eager swizzling as the swizzli
ng of all OIDs for
persistent objects on all data pages used by the application before any object can be
accessed.

c)

Direct versus indirect swizzling

This is an issue only when it is possible for a swizzled pointer to refer to an object
that is no longer in
virtual memory. With direct swizzling, the virtual memory pointer
of the referenced object is placed directly in the swizzled pointer; with indirect
swizzling, the virtual memory pointer is placed in an intermediate object, which acts
as a placeholder for
the actual object.


Accessing an Object

How an object is accessed on secondary storage is another important aspect that can have
a significant impact on OODBMS performance. Now, If we look at the approach taken in
a conventional relational DBMS with a two
-
level storage model. The following steps
apply



The DBMS determines the page on secondary storage that contains the required
record using indexes or table scans, as appropriate. The DBMS then reads that
page from secondary storage and copies its cache.



The
DBMS subsequently transfers the required parts of the record from the cache
into the applications memory space. Conversions may be necessary to convert the
SQL data types into the applications data types



The application can then update the record’s fields
in its own memory space.



The application transfers the modified fields back to the DBMS cache using SQL,
again requiring conversions between data types.



Finally, at an appropriate point the DBMS writes the updated page of the cache
back to the secondary st
orage.


1.10

PERSISTENCE

Since most application programs need to deal with persistent data, adding persistence to
objects is essential to making object
-
oriented applications useful in practice. There are
three classes of solutions for implementing persistence i
n object
-
oriented applications:
the gateway
-
based object persistence approach, which involves adding object
-
oriented
programming access to persistent data stored using traditional non
-
object
-
oriented data
stores, the object
-
relational database management s
ystem (DBMS) approach, which
involves enhancing the extremely popular relational data model by adding object
-
oriented
modeling features, and the object
-
oriented DBMS approach (also called the persistent
programming language approach), which involves adding

persistence support to objects
in an object
-
oriented programming language


Persistence schemes

Database Management Systems
Classical database management systems (DBMS)
support persistent (long term) data as quite distinct from transient (short
-
term) data.

Long
term data is described in a schema or data definition language (DDL) and is manipulated
using a query or data manipulation language (DML). An application system typically
consists of application programs written in a general purpose programming langu
age,
together with the DDL schemas for the database. The application programs typically
access the database by queries expressed as embedded DML statements. In 4GL's, the
general purpose language is replaced by a domain specific language with the DBMS's
DD
L and DML as partially integrated sublanguages.

The key problem with the classical DBMS approach is that the DDL defines a type/value
space that is distinct from, and not directly compatible with the type/value space defined
by the host programming langua
ge. Bridging the gap between the two spaces typically
adds complexity to the application system design and requires extra application code that
would be absent if the long term data structures were entirely memory resident. In some
application domains, typ
ical database schema and query languages are simply not
suitable for describing and managing the data structures.

Check pointing
.

Some systems implement persistence by copying part or all of a
program's address space to disc. In cases where the entire add
ress space is saved, the
computation can be restarted from the checkpoint. In other cases, only the contents of the
program's heap are saved. Checkpoint systems tend to have two major problems. First, a
checkpoint or saved heap file can typically only be u
sed by the application program that
created it. Even a small change to the application can lead to incompatibilities which
render the checkpoint useless. Second, a typical checkpoint contains a large amount of
information that is of no use in later executi
ons.

Data Structure Copying

There are many examples of persistence mechanisms that
work by copying the closure of a data structure to an external medium [27
, 38
]. The
application typically invokes a write operation on a data value which traverses the gra
ph
of objects reachable from the value, and writes it to disc in a flattened form. At a later
stage, the flattened data structure can be read in, giving a new copy of the data structure.
Depending on the implementation of the mechanism, the application may

need to provide
hooks to assist in the data structure traversal process; e.g. [43]. This style of persistence is
often called pickling, or in the distributed computing context, marshalling.

Persistence by data structure copying has two inherent problems.

First, it does not
preserve object identity; e.g. if two graphs that share a common subgraph are separately
copied to disc and then restored, the subgraph will no longer be shared in the restored
copies. Second, data structure copying is not incremental,
and is therefore not an efficient
way to save small changes to large data structures.

Explicit Data Structure Paging

Some persistence mechanisms work by "paging"
objects between the application's heap and a persistent database [29, 42]. Object pointers
typically exist in two forms; machine addresses and persistent identifiers (PIDs). When
an application wants to access an object referred to by a PID, it makes an explicit call to
the persistence manager to obtain the corresponding address. If the object i
n question is
not in memory, the persistence manager reads it in from disc and records the object's PID
to address mapping. Finally, the object's machine address is returned to the caller. In
effect, objects are "demand paged" into memory.

There are two c
ommon schemes for creating and updating persistent objects. The first
scheme requires the caller to allocate the object using a persistent heap allocator. In the
absence of pervasive garbage collection, an object will exist in the persistent store until it

is explicitly free'ed by the application. This leads inevitably to storage leak and dangling
pointer problems.

The second scheme makes objects persistent depending on their reachability from the
"root" of the persistent store. This presupposes that the p
ersistence manager has the
structural information needed to trace the reachable nodes, but it also allows automatic
garbage collection of the persistent store.

Apart from the storage management issue already noted, the main problem with explicit
data stru
cture paging is that the application needs to handle the two different kinds of
object pointer. This is a burden for the programmer, and reduces the reliability and
maintainability of applications. These problems are avoided if the persistence mechanism
is

fully integrated with the application programming language.

Orthogonal Persistence

The most sophisticated form of persistence is known as orthogonal persistence. In an
orthogonal persistence mechanism, the lifetime of a first
-
class data value is independ
ent
of other static and dynamic properties of the value. A persistent value does not have a
special type, and in created or used by the application in the same way as a non
-
persistent
value. Loading and saving of values does not alter their semantics, and
the process is
transparent to the application program. If the base language supports first
-
class function
values and task values, these should persist along with other values.

Most examples of orthogonal persistence use "root" reachability to determine th
e lifetime
of objects. The persistent store contains a distinguished object called the "root" object.
When the store is
stabilized
, the persistence mechanism finds all objects that can be
reached from the root object and ensures that their current values a
re saved to the
persistent store. A subsequent program execution can access persistent values by first
calling a built
-
in function to obtain the store's root object, and then traversing a path from
the root to the required values.

Orthogonal persistence's

main advantages over other methods of managing long
-
term
data are as follows:



there is no need to define long
-
term data in a separate schema language,



no special application code is required to access or update persistent data, and



There is no limit to

the complexity of the data structures that can be made
persistent.

This makes languages that support orthogonal persistence particularly good for
applications that have to maintain complex long
-
term state.

Unfortunately, current implementations of orthog
onal persistence have some important
drawbacks:



Current generation persistence technology is inefficient compared with more
mature languages and data management systems. Few, if any, compilers for
persistent languages generate native machine code. Persist
ent stores do not
support bulk data well, and their performance tends to degrade due to data locality
effects.



Most current generation persistent stores are only serially shareable.



Current generation persistence systems do not support concurrency or
dis
tribution.



Current generation persistence systems do not interface well with the non
-
persistent world; e.g. access to traditional database systems is typically not
supported.

We can expect most, if not all, of these problems to be largely solved in the ne
xt 5 to 10
years. Current research into orthogonal persistence includes the following:



Compilers: production of native code compilers is largely a matter of resources.



Concurrency and distribution support: initial work has been done on concurrency
and di
stribution in persistent languages [35
, 36, 54
], though some important
semantic problems are still to be solved. Current effort is mainly focused on
implementation issues [52
, 53
].



Persistent stores: developments in persistent store technology should give

better
support for bulk data.



Persistent programming environments: current research into configuration
management of persistent programs and novel binding schemes [24] could
revolutionize persistent programming environments.



Meta
-
programming: current wo
rk on linguistic [44] and other forms of reflection
[24] should lead to better application support for meta
-
programming.

Finally, there has been a tendency in the persistence research community not to make the
tools available outside of restricted circles.

We believe that this has inhibited both
research into orthogonal persistence and the use of persistence technology for
applications programming. This has tended to limit orthogonal persistence's visibility in
the wider software engineering community.

1.11

ISSU
ES IN OODBMS

Three issues are defined in this document.



Long
-
duration transactions



Versions



Schema evolution

Transactions

A transaction is a logical unit of work, which should always transform the database from
one consistent state to another. The type of
transaction found in business application is
typically of short duration. In contrast, transactions involving complex objects, such as
those found in engineering and design applications, can continue for several days. Clearly
to support long

duration tran
sactions we need to use different protocols from those used
for traditional database applications in which transactions are typically of a very short
duration.

Versions

The process of maintaining the evolution of objects is known as Version Management.
An
Object Version represents an identifiable state of an object; a version history
represents the evolution of an
object. Versioning

should allow changes to the
properties
of

objects to be managed in such a way that object references always point to the corre
ct
version of an object.

Schema evolution

Design is an incremental process and evolves with time. To support this process,
applications require considerable flexibility in dynamically defining and modifying the
database schema. For example, it should be po
ssible to modify class
definitions
, the
inheritance structure, and the specifications of attributes and methods without requiring
system shutdown.

Architecture

Here are going to discuss two architectural issues: how best to apply the client
-
server
architec
ture to the OODBMS environment, and the storage of methods.


Clint
-
Server

The three basic architectures for a client
-
server DBMS that vary in the functionality
assigned to each component.

Object server

this method attempts to distribute the processing betw
een the two
components.

Page server

most of the database processing is performed by the client.


Database server

Most of the database processing is performed by the server.

Storing and executing methods

There are two approaches to handling methods:
store the methods in external
files, and

store the methods in the database .The second approach offers several benefits:


-

It eliminates redundant code


-

It simplifies modifications


-

Methods are more secure


-

Improve in
tegrity


Benchmarking

Over the years, various database benchmarks have been developed as a tool for
comparing the performance of DBMS and are frequently
referred

to in academic,
technical, and commercial literature

-

Wisconsin benchmark

-

TPC
-
A and TPC
-
B bench
marks

-

TPC
-
C benchmark

-

001 benchmark

-

007 benchmark


1.12

OBJECT
-
ORIENTED DATABASE SYSTEM MANIFESTO

The Object
-
oriented Database System Manifesto proposes 13 mandatory features for an
OODBMS, based on two criteria: it should be an object
-
oriented system and it sh
ould be
a DBMS. The first eight rules apply to the object

oriented characteristics


1. Complex objects

Thou shalt support complex objects.

Databases based on the Relational Model only consist of tables with tuples and atomic
values. The requirement for o
bject
-
oriented databases is to offer constructors to build
user
-
defined complex objects of any kind. Constructors are: tuples, sets, bags, lists and
arrays. All object constructors should be orthogonal; the designer should be able to mix
the constructors i
n any way (a list of sets, an array of bags or a list of lists).


2. Object identity

Thou shalt support object identity.

In relational databases each tuple has a unique set of values called primary key. We can
say: the identification of any tuple is based

on values of the tuple. It is part of its
philosophy not to have any hidden information which can be used to identify a tuple. This
situation makes it hard to guarantee integrity of the database. Object
-
oriented databases
should have an object identity, w
hich is independent from the values of the object. In
most cases the object identity is a hidden value (and not part of the user
-
designed data
structure).

Example: The DBMS POET uses object identifiers (O
-
IDs) like the following:
(0
-
772#15)
.


3. Encapsula
tion

Thou shalt encapsulate thine objects.

Like abstract data structures, objects shall encapsulate state and behavior (attributes and
operations). Objects should be handled by using the public operations. Access to (private)
attributes should be impossib
le. This situation creates a problem concerning the use of
ad
-
hoc query systems: These systems need the direct access to all attributes without using
predefined access operations. In this case the encapsulation mechanisms should not be
strict.


4. Types an
d Classes

Thou shalt support types and classes.

Each object
-
oriented DBMS in the sense of

the Manifesto has to be able to produce
objects. This means:



It could use
types

as the abstract construction plan for objects of a special
kind. Systems as C++ or T
urbo
-
Pascal belong to this category.



It could deal with
classes

while using a so
-
called object factory and an
object warehouse. It is strongly run
-
time oriented. Systems as Smalltalk or
Lisp belong to this category.

5. Class or Type
Hierarchies

Thine cla
sses or types shalt inherit from
their ancestors.

Classes or types of the database structure could be arranged in an inheritance tree
structure.

Example: A
Person

could be a
Student

or a
Member of Staff

(or even just a person).
Student

and
Member of Staf
f
are derived classes/types of the basic classes/type
Person
.


6. Overriding, overloading and late
binding

Thou shalt not bind
prematurely.

The topics of this chapter cover well
-
known mechanisms which came up with object
-
oriented programming:



Overriding

and
overloading
of operations (i.e. giving

the same name to
operations of similar behavior although they are part of different
types/classes). The concrete operation doesn't depend on the referred name
but on the type/class of the object it is invoked.



La
te binding
of operations (i.e. during run
-
time the appropriate operation
will be selected).

7. Computational
completeness

Thou shalt be computationally
complete.

A programming language should offer the programmer features to express any algorithm.
If so
we call the programming language computational complete. SQL for instance is not
computational complete.


8. Extensibility

Thou shalt be extensible.

Each database system has a set of predefined (system defined) types. This set can be
extended; system defi
ned and user defined types should be treated in the same way.


9. Persistence

Thou shalt remember thy data.

Unnecessary to say, that an object
-
oriented DBMS should be able to store data. But in the
sense of the Manifesto it means, that each object (system

or user defined) is allowed to
become persistent. And: The process of storing an object should be implicit
-

no need for
an explicit store or move of data.


10. Secondary storage
management

Thou shalt manage very large
databases.

Each DBMS must offer fea
tures for efficient storage management, an object
-
oriented
DBMS as well. This must include index management, data clustering, data buffering,
access path selection and query optimization. And: All these feature have to be invisible
for the application prog
rammer.


11. Concurrency

Thou shalt accept concurrent users.

Again a feature of each DBMS: each object
-
oriented DBMS has to offer mechanisms to
synchronize access of more than one user at the same time.


12.
Recovery

Thou shalt recover from hardware and s
oftware
failures.

An object
-
oriented DBMS should provide the usual level of services in case of software
or hardware failures.


13. Ad Hoc Query
Facility

Thou shalt have a simple way of querying
data.

An object
-
oriented DBMS should provide an Ad Hoc Quer
y Facility which matches the
following criteria



It should be declarative (WHAT instead of HOW) and of high level.



It should be efficient. The Query Facility must contain a query
optimizer
.



It should work on any database structure (even on such based on
user
defined types/classes).




ADVANTAGES AND DISADVANTAGES OF OODBMSs

Advantages of OODBMS



More semantic information



Support for complex objects



Extensibility of data types



May improve performance with efficient caching



Versioning



Reusability



Inhe
ritance speeds development and application



Potential to integrate DBMSs into single environment

Disadvantages

OODBMS



Strong opposition from the established RDBMSs



Lack of theoretical foundation



Throwback to old pointer systems



Lack of standard
ad hoc

query language



Lack of business data design and management tools



Steep learning curve



Low market presence



Lack of compatibility between different OODBMSs



1.13

OBJECT
-
ORIENTED DATABASE DESIGN

Comparison of Object
-
Oriented data modeling and Conceptual Data
Modeling


OODM

CDM

DIFFERENCES


Object Entity Object includes behavior

Attribute Attribute Non
e

Association Relationship Association are the same but inheritance


in OODM includes both state and



behavior

Message No corresponding concept in CDM

Class Entity type/Supertype None

Instance Entity

None

Encapsulation No corresponding concept in CDM


Relationships and Referen
tial Integrity



Do not allow the user to explicitly delete objects



Allow the user to delet
e objects when they are no longer required.



Allow the user to modify and delete objects and relationships when they are no
longer required


Behavioral Design

In Object
-
oriented analysis, the processing requirements are mapped onto a set of
methods that are

unique for each class. The methods that are visible to the user or to the
other objects (
public methods
)

must be distinguished from methods that are purely
internal to a class (
private methods
)
. There are different types of public and private
methods



Cons
tructors



Access methods



Transform methods





















PART 3
CHAPTER 26


OBJECT
-
ORIENTED DBMSs STANDARDS AND SYSTEMS


1.1
OBJECT MANAGEMENT GROUP


Background

OMG is an international non
-
profit

making industry consortium founded in 1989 to
a
ddress the issues of object standards. The aims of the group are promotion of object
-
oriented approach to software engineering and the development of standards in which the
location, environment language, and other characteristics of objects are completely

transparent to other objects. The structure of Object Management Architecture (OMA)
guide is as follows.


a)

The Object Model…This is a design
-
portable abstract model for
communicating with OMG
-
compliant object
-
oriented systems.

b)

The object request broker…Thi
s handles distribution of messages between
application objects in a highly interoperable manner.

c)

The Object Services…This provide the main functions for realizing basic
object functionality.

d)

The Common Facilities…Comprise a set of tasks that many applicati
ons
must perform but are traditionally duplicated with each one , such as
printing and electronic mail facilities




The
Common object request Broker Architecture

The Common Object Request Broker Architecture (CORBA) is a
specification

of a
standard archi
tecture for object request brokers (ORBs). A standard architecture allows
vendors to develop ORB products that support application
portability

and
interoperability

across different programming languages, hardware platforms, operating systems, and
ORB imple
mentations


1.2 OBJECT DATA STANDARD ODMG 3.0, 1999


Object data Management Group

An independent consortium that specifies universal
object

storage
standards
. ODMG's
members include
object
-
oriented database

management system (ODBMS) vendors and
other inter
ested parties. They aim to increase portability of customer software across
products. On 1998
-
04
-
27 ODMG changed its name from the Object Database
Management Group to reflect the expansion of its efforts beyond merely setting storage
standards for object d
atabases.


Object Model

The Object Model package is a combination of data model and a procedural API for
manipulating application objects within an ACS instance. The OM allows developers to
describe a hierarchical system of
object types

that store metadat
a on application objects.
The object type system supports subtyping with inheritance, so new object types can be
defined in terms of existing object types.

The OM data model forms the main part of the
ACS 4 Kernel data model. The other parts of the Kernel
data model include:

Parties and Groups

Permissions

Object Definition language

The Object Definition Language (ODL) allows objects to be described in a fashion
compatible with Interface Definition Language (IDL) used in COM and CORBA object
systems. ODL all
ows objects to be described as well as serialized for transport across
networks.

Object Query language

The object database language for querying and manipulating object databases which
conform to the Object Data Model, defined as part of the ODMG standard
s Other parts of
the ODMG Standard



Object Interchange Format



ODMG language bindings


1.3
OBJECTSTORE

Architecture

ObjectStore[TM] is a high performance ODBMS designed for ease of use in

development
of sophisticated applications using object
-
oriented

develo
pment techniques. It offers a
tightly
-
integrated language

interface to a complete set of traditional DBMS features
including

persistence, transaction management (concurrency control and

recovery),
distributed access, associative queries over large amounts

of data, and database
administration utilities.
ObjectStore's data

management facilities combined with popular
development tools create a

high productivity development environment for implementing

Object
-
oriented applications.

Key Features:



T
ransparent in
terface designed for popular C and C++ programming

environments.



Concurrent access to large amounts of persistent data.



Distribution of objects over networks using a variety of popular

network
protocols.



Access to persistent data at the same speed as tra
nsient data.



Extensible data modeling capabilities for applications requiring

complex data
structures.



Easy migration path for existing C and C++ applications.



Class libraries for version and configuration management.



Class libraries for managing collectio
ns of objects.



A fully distributed (multi
-
server/multi
-
database) ad hoc query

capability.



An interactive Browser to inspect objects and object

descriptions.



Interoperable with ObjectStore servers running on other operating

systems and

hardware environ
ments.



Complete schema evolution for an application's metadata and

existing object
instances.



Full online backup for continuous processing environments.



Meta objects protocol with programmatic access to schema

information.



Dynamic Type creation for extend
ing existing class definitions

during program
execution.





















PART 4
CHAPTER 27


OBJECT
-
RELATIONAL DBMSs


INTRODUCTION

Object
-
Relational database management systems

(ORDBMS) are an evolutionary
extension of
relational

DBMS

products. T
he term is also sometimes used to describe
external software products running over traditional DBMSs to provide similar features.
These systems are more correctly referred to as
object
-
relational mapping
.

goal of
ORDBMS technology is to allow developers to

raise the level of abstraction at which
they view the problem domain.

Advantages of ORDBMS



Ability to query complex applications and ability to handle large and complex
applications



Reduced Network Traffic…queries and complex instructions can be executed
on
the server (as opposed to clients)



Application and Query Performance
…..
.Parallel server technology can be
employed Software Maintenance…data and methods are stored on the server and
makes maintenance easier



Integrated Data and Transaction Management

.Th
e database engine handles all
transaction integrity, backup, etc., issues


Disadvantages of ORDBMS



Modeling and processing support of complex objects and their versions, large
objects, semantic
-
rich relationships, etc. is only rudimentary or even missing i
n
current ORDBMSs



ORDBMSs have to be complemented by adequate client
-
side data management
and long
-
running design transactions encapsulating the client processing model,
in order to provide satisfactory support for technical applications



Low performance in

web applications


1.2 THE THIRD GENERATION DATABASE MANIFESTOS

The Third Manifesto

(1995) is
Christopher J. Date
's and
Hugh Darwen
's proposal for
future
relational database management systems

that would avoid '
impedance mismatch
'
between
object
-
oriented p
rogramming languages

and
RDBMSs

by fully supporting all
the capabilities of the
relational model
.

The main objective of The Third Manifesto, besides being theoretically sound and
avoiding arbitrary restrictions and pragmatic debasement of the relational mo
del, is to
make a simple, restricted and precise definition of the role of object orientation in
Database Management systems emphasising the few valid ideas from
object modelling

that are orthogonal to relational modelling.


1.3 POSTGRES


AN EARLY ORDBMS

PostGre is an open
-
source object relational DBMS (ORDBMS) that traces its roots back
to Academia. It traces its roots back to a database called Postgres (developed at UC
Berkley in the early 80's). It was officially known as PostGreSQL around 1996 mostly t
o
reflect the added on ANSI SQL compliant translator. It is perhaps the most feature
-
rich
robust open
-
source database around and perhaps the most feature rich even among non
-
open source databases.


Objectives of Postgres

Support for Numerous languages
Th
e Postgres architecture allows to define new PL
languages by providng PL handlers. This feature makes Postgres very extensible
-

for
example one can imagine creating a specialized rules language and then providing this as
a PL extension to Postgres

Inherit
ance of Table Structures

Table inheritance is a feature that is not found in a
mere RDBMS, but is one of the hallmarks of an ORDBMS. This feature provides a
compromise for those looking for an object orientated database, but who wish to also
have the simpl
icity and speed that a relational database system provides

Built
-
in complex data types and ability to define new
..
Postgre comes with quite a few
complex data

types; one can define new ones or get extensions to PostgreSQL that

extend

these.

One such produ
ct we've found is a product called
PostGIS

which is an open source
spatial engine that spatially enables Postgre. Although PostgreSQL comes with some
simple geometry data types, PostGIS defines new

ones and provides an OpenGIS SFSQL
interface to these.


Makes a Great Web Database
….
Postgre is a fairly fast database with ample support in
web languages such as PHP, Perl and the ODBC and JDBC drivers make it easily usable
in other languages such as ASP,

ASP.Net , ColdFusion and Java. It is often compared
with MySQL
-

one of the fastest databases on the web (open source or non). Its querying
speed is in line with MySQL and in fact studies have shown that it scales better with
more users than MySQL. In ter
ms of features, it is leagues above MySQL
-

but the new
version of MySQL coming out which will provide transactional support and trigger
support, and subselects will change some of that.


1.4 SQL3

ANSI (X3H2) and ISO (ISO/IEC JTC1/SC21/WG3) SQL standardiza
tion committees
have for some time been adding features to the SQL specification to support object
-
oriented data management. The current version of SQL in progress including these
extensions is often referred to as "SQL3" [ISO96a
, b
].

The parts of SQL3 tha
t provide the primary basis for supporting object
-
oriented

s
tructures

are:



user
-
defined types

(
ADT
s,
named row types
, and
distinct types
)



type constructors for
row types

and
reference types



type constructors for
collection types

(sets, lists, and multis
ets)



user
-
defined functions and procedures




support for
large objects

(BLOBs and CLOBs)



Polymorphism



Subtypes and Supertypes



Creating Tables



Querying Data



Persistent Stored Modules



Triggers



Recursion


1.5 QUERY PROCESSING AND OPTIMIZATION

New Index Types


1.6 OBJECT
-
ORIENTED EXTENSIONS IN ORACLE


User Defined Data Types

Oracle’s support of user
-
defined data types (sometimes called abstract data types, or
ADTs) has profound implications for database design and implementation. User
-
defined
data types will a
llow the database designer to:



Create aggregate data types.

These are data types that contain other data types. For
example a type called
full address
could

contain all of the subfields necessary for a
complete mailing address.



Create nested data structur
es.

Designers can place data types within other data
types to create data structures that
can
easily

be reused within Oracle. For example, a
designer could define a data type called customer that contains a data type called
customer demographics
, which in
turn contains a data type called
job history
, and so
on.


Pointers

One of the new user
-
defined data types in the object/relational model is the pointer.
Basically, a pointer is a unique reference to a row in a relational table. Pointer data types
allow yo
u to:



Reference sets of related rows in other
tables.

It is possible to violate first
normal form and have a cell in a table that contains a pointer to repeating table
values. For example, an employee table could contain a pointer called
job_history_set, w
hich in turn contains pointers to all the relevant rows in a job
history table. This would also allow for aggregate objects to be prebuilt so that all
the specific rows in the aggregate table could be predefined.



Include pointers to non

database objects i
n a flat file.

For example, a table cell
could contain a pointer to a flat file that contains an object such as a picture in
GIF or JPEG format.



Establish pointers to repeating groups.

Database designers can violate first
normal form and create a table co
lumn that has pointers to an array of row
pointers. For example, you might create a column called order history in a
customer table. The column could contain a pointer to a reference table containing
pointers to the specific rows that represent prior order
s for that customer.



Establish one
-
to
-
many and many
-
to
-
many data relationships without
relational foreign keys.

This capability alleviates the need for relational JOIN
operations, since table columns can contain references to rows in other tables. By
de
-
r
eferencing these pointers, rows from other tables can be retrieved without
ever using the expensive SQL JOIN operator.


Polymorphism potential

Polymorphism is a situation where the same method call will result in the invocation of a
different process, dep
ending upon the target object. Oracle does not yet support true
polymorphism because identical member method names are not yet supported, but we
may expect to see these features in a future release




1.7 COMPARISON OF ORDBMS AND OODBMS


Object Relational
Database Management

Systems Object relational database management systems (ORDBMS) are an attempt to
meet the demands of more complex data representation through extending relational
database systems with object oriented technology. The main contribution
of the
ORDBMS is its handling of complex object
-
centric, persistent data while maintaining the
RDBMS querying methods (SQL) to operate on that data. Not only are more complex
data types supported, but user
-
defined types are supported as well, greatly incre
asing the
application domains to which an ORDBMS can be applied. ORDBMSs are often
considered the bridge between RDBMSs and OODBMSs.


Object Oriented Database Management Systems

Object oriented database management systems (OODBMS), rather than attempting t
o
extend relational systems as ORDBMSs do, are viewed as an alternative approach to
meeting the demands of more complex (and persistent) data types. The need to handle
complex object
-
centric data as the main data element is the driving force behind
OODBMSs
. These systems attempt to extend object oriented programming languages,
techniques, and tools to provide a means to support data management tasks. Whereas
ORDBMSs take the approach of starting from where RDBMSs leave off, OODBMSs
approach from the opposit
e direction (a programming language itself) to solve the
problem of handling complex data types







References:


Thomas Connolly, Carolyn Begg;
DATABASE SYSTEMS

A Practical Approach to
Design, Implementation, and management, Third Edition


Wikipedia, the

free encyclopedia

Michael Stonebreaker, Dorothy Moore;
Object
-
Relational DBMSs, The Next Great
Wave
; Morgan Kaufman, Inc. 1996

C.J. Date, Hugh Darwen;
Foundation for Object/Relational Databases, The Third
Manifesto
; Addison Wesley, Inc. 1998

Raghu Ramakri
shnan;
Database Management Systems
; McGraw
-
Hill, Inc. 1998

Jeffrey D. Ullman, Jennifer Widom;
A First Course in Database Systems
; Prentice Hall,
Inc. 1997