The

Object-Slicing

Technique

A

Flexible

Object

Representation

and

Its

Evaluation

Harumi

A.

Kuno

Young-Gook

Ra

and

Elke

A.

Rundensteiner

Dept.

of

Elect

Engineering

and

Computer

Science

Software

Systems

Research

Laboratory

The

University

of

Michigan

Beal

Avenue

Ann

Arbor

MI

e-mail

kuno@umich.edu,

ygra@umich.edu,

rundenst@umich.edu

fax

-LRB-313-RRB- 763-1503

phone

-LRB-313-RRB- 936-2971

Abstract

Recently

much

work

has

been

done

towards

extending

object-oriented

database

systems

-LRB-

OODBs

-RRB-

with

advanced

tools

such

as

view

technology

advanced

schema

evolution

support

and

role

modeling

systems

These

extensions

all

require

that

the

underlying

database

system

supports

more

powerful

and

flexible

modeling

constructs

than

are

currently

supported

by

existing

OODB

systems

In

this

paper

we

identify

these

features

as

multiple

classification

dynamic

reclassification

and

dynamic

restructuring

We

then

describe

a

methodology

known

as

object-slicing

that

is

capable

of

extending

data

models

to

support

these

required

features

We

have

successfully

implemented

an

object-slicing

software

layer

using

the

GemStone

system

which

while

still

providing

full

access

to

all

GemStone

DBMS

functions

now

also

offers

all

required

modeling

features

In

this

paper

we

describe

our

experimental

results

evaluating

the

relative

costs

and

benefits

of

adopting

the

object-slicing

technique

This

includes

an

analytical

assessment

of

the

storage

overhead

of

the

object-slicing

representation

and

its

comparison

against

the

conventional

representational

models

As

clustering

is

critical

to

optimizing

queries

on

such

models

we

present

the

results

of

using

benchmark

test

suites

evaluating

various

clustering

strategies

for

the

object-slicing

model

We

find

that

for

certain

types

of

queries

-LRB-

e.g.

those

that

benefit

from

the

superior

blocking

factor

at

the

local

attribute

level

resulting

from

clustering

object-slices

together

by

class

-RRB-

the

object-slicing

model

outperforms

the

conventional

approach

in

spite

of

its

storage

overhead

while

queries

involving

inherited

attributes

with

low

selectivity

are

better

serviced

using

a

conventional

object-clustering

approach

This

work

was

supported

in

part

by

the

NSF

RIA

grant

#IRI

the

NSF

NYI

grant

#IRI

and

the

University

of

Michigan

Faculty

Award

Program

Harumi

Kuno

is

also

grateful

for

support

from

the

NASA

Graduate

Student

Researchers

Program

Introduction

Recently

much

work

has

been

done

towards

extending

object-oriented

database

systems

-LRB-

OODBs

-RRB-

with

advanced

tools

such

as

view

technology

advanced

schema

evolution

tools

and

role

modeling

systems

-LSB-

-RSB-

These

extensions

all

require

that

the

underlying

database

system

supports

flexible

and

powerful

modeling

constructs

that

are

currently

not

supported

by

most

existing

OODB

systems

-LSB-

-RSB-

As

we

will

describe

in

Section

such

features

include

multiple

classification

-LRB-

allowing

an

object

to

be

an

instance

of

multiple

classes

-RRB-

dynamic

reclassification

-LRB-

allowing

an

object

to

gain

and

lose

class

memberships

throughout

the

object

's

lifetime

-RRB-

and

dynamic

restructuring

-LRB-

allowing

an

object

's

structure

to

change

dynamically

throughout

the

object

's

lifetime

-RRB-

Unfortunately

this

common

need

of

view

management

transparent

schema

evolution

role

modeling

systems

as

well

as

of

many

knowledge-based

systems

for

flexible

and

fundamental

data

model

characteristics

is

not

met

by

current

OODB

technology

In

fact

the

object

representation

assumptions

underlying

most

commercial

OODB

systems

namely

one

most-specific

type

per

object

object

type

determined

at

objectcreation

time

fixed

typing

and

upwards

inheritance

conflict

with

the

requirements

of

such

systems

The

object-slicing

technique

-LSB-

-RSB-

is

one

particularly

promising

approach

of

extending

an

existing

OODB

system

to

support

the

identified

required

features

In

object-slicing

a

real-world

object

corresponds

to

a

hierarchy

of

implementation

objects

-LRB-

one

for

each

class

whose

type

the

object

possesses

-RRB-

linked

to

a

conceptual

object

-LRB-

used

to

represent

the

objectitself

-RRB-

rather

than

associating

a

single

implementation

with

each

real-world

object

as

is

commonly

assumed

in

conventional

OODB

systems

-LSB-

-RSB-

This

technique

of

using

implementation

objects

to

represent

an

object

's

membership

in

multiple

classes

is

extremely

flexible

and

provides

a

solution

that

extends

an

OODB

system

to

support

capacity-augmenting

virtual

classes

multiple

classification

dynamic

reclassification

and

dynamic

restructuring

of

objects

and

classes

For

example

an

object-slicing

system

can

dynamically

reclassify

an

object

from

being

the

instance

of

one

class

-LRB-

-RRB-

to

becoming

that

of

another

class

-LRB-

-RRB-

by

linking

the

object

instance

to

an

implementation

object

of

and

discarding

that

of

In

addition

object-slicing

facilitates

the

maintenance

of

materialized

views

in

that

-LRB-

-RRB-

it

elegantly

avoids

the

need

to

duplicate

data

for

materialized

classes

and

-LRB-

-RRB-

any

update

to

an

object

will

take

place

at

a

unique

location

determined

by

the

property

involved

regardless

of

the

source

of

the

update

request

-LSB-

-RSB-

Similarly

the

flexibility

offered

by

the

object-slicing

approach

naturally

lends

itself

to

implementing

role

systems

object-slicing

's

implementation

objects

can

easily

be

adapted

to

represent

the

various

roles

of

objects

in

a

role

system

-LSB-

-RSB-

We

examine

the

object-slicing

representation

in

the

context

of

the

University

of

Michigan

's

MultiView

project

an

on-going

NSF-funded

view

management

system

capable

of

supporting

updatable

materialized

views

and

transparent

schema

evolution

In

order

to

support

the

features

required

by

views

and

schema

evolution

we

have

successfully

implemented

an

object-slicing

layer

-LSB-

-RSB-

on

top

of

the

GemStone

OODB

system

Based

on

this

flexible

foundation

we

have

been

able

to

rapidly

prototype

the

MultiView

system

providing

capacity-augmenting

virtual

classes

updatable

materialized

virtual

classes

and

view

schemata

Because

the

object-slicing

implementation

could

be

cleanly

built

on

top

of

an

existing

DBMS

system

the

question

of

how

the

addition

of

an

object-slicing

mechanism

impacts

performance

now

arises

It

is

to

be

expected

that

extending

an

existing

system

with

object-slicing

techniques

involves

the

potential

overhead

of

additional

data

structures

maintenance

costs

and

processing

time

Although

object-slicing

is

a

known

technique

that

is

being

utilized

for

view

systems

-LSB-

-RSB-

schema

evolution

-LSB-

-RSB-

and

role

systems

-LSB-

-RSB-

to

the

best

of

our

knowledge

no

work

has

been

done

evaluating

the

costs

of

object-slicing

The

purpose

of

this

paper

is

to

provide

such

an

evaluation

In

this

paper

we

present

experimental

results

of

utilizing

our

MultiView

implementation

to

perform

benchmark

tests

for

evaluating

the

costs

and

benefits

of

the

object-slicing

paradigm

In

the

remainder

of

this

paper

we

will

ffl

Discuss

data

modeling

requirements

that

can

be

addressed

by

an

object-slicing

solution

-LRB-

Section

-RRB-

ffl

Compare

object-slicing

with

the

conventional

intersection

class

alternative

-LRB-

Section

-RRB-

ffl

Describe

the

object-slicing

data

model

and

its

implementation

-LRB-

Section

-RRB-

ffl

Analyze

the

storage

costs

of

our

object-slicing

representation

-LRB-

Section

-RRB-

ffl

Present

the

findings

of

experiments

evaluating

the

object-slicing

model

compared

to

the

conventional

architecture

-LRB-

Section

-RRB-

is

a

registered

trademark

of

Servio

Corporation

ffl

Present

the

experimental

results

of

optimizing

query

types

from

the

benchmark

on

the

objectslicing

model

using

clustering

-LRB-

Section

-RRB-

This

is

followed

by

a

discussion

of

related

work

as

well

as

some

concluding

remarks

Data

Model

Requirements

of

Advanced

OODB

Tools

As

we

will

detail

below

view

management

transparent

schema

evolution

role

modeling

systems

as

well

as

many

knowledge-based

systems

share

a

common

need

for

the

powerful

data

model

characteristics

of

multiple

classification

dynamic

reclassification

and

dynamic

restructuring

which

typically

are

not

provided

in

current

OODB

systems

View

System

Needs

In

recent

years

object-oriented

view

technology

has

been

touted

as

an

important

technique

for

integrating

heterogeneous

and

distributed

systems

for

achieving

interoperability

by

hiding

idiosyncrasies

of

component

systems

to

be

integrated

into

one

unified

yet

federated

system

and

for

security

-LSB-

-RSB-

View

mechanisms

typically

provide

the

functionality

to

restructure

a

base

schema

by

hiding

classes

by

adding

classes

by

customizing

the

behavior

or

extent

of

classes

and

by

rearranging

the

generalization

hierarchy

The

introduction

of

virtual

classes

and

schemata

requires

the

underlying

data

model

to

support

certain

features

For

example

if

an

object

instance

qualifies

for

membership

in

two

virtual

classes

then

it

should

belong

to

both

even

if

no

subsumption

relationship

exists

between

the

virtual

classes

For

this

reason

the

data

model

must

provide

multiple

classification

which

means

that

an

object

can

belong

to

the

local

extents

of

multiple

classes

and

can

thus

be

associated

with

the

types

of

multiple

classes

Furthermore

an

object

instance

should

dynamically

gain

-LRB-

or

lose

-RRB-

the

type

of

a

select

virtual

class

if

its

data

values

change

so

that

it

fulfills

-LRB-

or

ceases

to

fulfill

-RRB-

the

class

's

selection

predicate

Thus

a

view

system

must

also

support

the

dynamic

reclassification

and

dynamic

restructuring

of

object

instances

allowing

objects

to

flexibly

gain

and

lose

types

during

their

lifetimes

-LRB-

including

both

the

data

stored

in

their

state

as

well

as

the

set

of

methods

to

which

they

can

respond

-RRB-

Extending

Views

for

Schema

Evolution

The

use

of

view

mechanisms

to

achieve

schema

evolution

has

been

advocated

by

a

number

of

researchers

-LSB-

-RSB-

The

basic

principle

is

that

given

a

schema

change

request

on

a

view

schema

the

system

rather

than

modifying

the

view

schema

in

place

computes

a

new

view

that

reflects

the

semantics

of

the

schema

change

This

approach

provides

several

advantages

over

direct

modification

First

it

lends

itself

naturally

to

a

schema

versioning

system

in

which

a

new

schema

can

be

generated

using

views

without

destroying

the

old

schema

Without

schema

versioning

updates

to

the

shared

database

schema

are

almost

always

prohibited

because

of

the

risk

of

incompatibility

between

existing

application

programs

and

the

modified

schema

Second

the

underlying

instances

are

directly

shared

by

different

schema

versions

which

facilitates

interoperability

and

ensures

that

old

versions

will

always

be

kept

up-to-date

In

spite

of

these

advantages

to

the

best

of

our

knowledge

an

implementation

of

view

mechanisms

to

achieve

transparent

schema

evolution

has

not

yet

been

realized

We

suspect

that

one

reason

for

this

is

that

because

views

correspond

to

derived

data

they

by

definition

do

not

support

the

addition

of

new

stored

information

to

the

database

Views

therefore

can

not

simulate

capacity-augmenting

schema

changes

such

as

the

add-attribute

operator

In

order

to

use

view

technology

to

support

schema

evolution

the

traditional

view

management

system

must

be

extended

to

support

the

creation

of

capacity-augmenting

virtual

classes

A

capacity-augmenting

virtual

class

is

a

virtual

class

that

includes

for

example

instance

variables

that

are

not

derivable

from

the

source

classes

of

the

virtual

class

Thus

the

underlying

view

system

providing

such

capacity-augmenting

views

does

require

the

dynamic

restructuring

of

objects

in

addition

to

the

features

of

multiple

classification

and

dynamic

reclassification

Role

Modeling

System

Needs

Finally

role

modeling

approaches

have

become

increasingly

popular

-LSB-

-RSB-

Role

systems

strive

to

increase

the

flexibility

of

the

model

by

enabling

objects

to

dynamically

change

types

and

class

membership

In

role

modeling

systems

objects

dynamically

gain

and

lose

multiple

interfaces

-LRB-

a.k.a.

roles

-RRB-

throughout

their

lifetimes

hence

the

need

for

multiple

classification

Such

changes

are

done

explicitly

by

user

request

and

on

an

object-by-object

basis

Because

role

systems

must

reflect

the

evolution

of

an

object

as

it

dynamically

gains

and

loses

roles

throughout

its

lifetime

the

properties

of

dynamic

reclassification

and

dynamic

restructuring

must

also

be

supported

by

the

data

model

underlying

a

role

system

Object-Slicing

v.s.

Intersection-Class

Creation

An

Introduction

of

Two

Multiple-Classification

Techniques

In

Section

we

identified

the

following

object

model

requirements

-LRB-

-RRB-

efficient

dynamic

restructuring

of

object

representations

-LRB-

-RRB-

multiple

classification

and

-LRB-

-RRB-

dynamic

reclassification

in

addition

to

the

wellestablished

object-oriented

features

such

as

encapsulation

generalization

hierarchy

etc.

To

the

best

of

our

knowledge

no

current

OODB

system

supports

all

of

these

features

Furthermore

with

the

exception

of

the

IRIS

functional

database

system

-LSB-

-RSB-

which

uses

a

relational

database

as

storage

structure

and

stores

data

from

one

object

across

many

relations

most

OODBs

represent

each

database

object

as

a

chunk

of

contiguous

storage

determined

at

object

creation

time

Thus

they

adhere

to

the

invariant

that

an

object

belongs

to

exactly

one

class

at

a

time

as

well

as

indirectly

to

all

of

that

class

's

superclasses

-LSB-

-RSB-

Car

-LRB-

a

-RRB-

ImportedJeepcolorfuelnation

Example

Imported

Jeep

Imported

belongs

toObject-Slicing

ApproachIntersection-Class

-LRB-

c

-RRB-

-LRB-

b

-RRB-

Figure

Two

Approaches

For

Implementing

Multiple

Classification

Object-slicing

as

introduced

in

Section

is

one

way

to

extend

an

existing

OODB

system

to

provide

the

required

features

The

intersection-class

approach

is

another

The

intersection-class

approach

simulates

multiple

classification

and

dynamic

restructuring

in

existing

systems

by

creating

intersection

classes

to

reflect

the

structure

of

a

multiply-classified

object

For

example

suppose

that

given

the

schema

in

Figure

-LRB-

a

-RRB-

we

want

to

create

a

new

car

object

that

is

both

of

type

Jeep

and

of

type

Imported

We

can

not

find

a

class

in

which

to

store

without

violating

the

invariant

that

an

object

belongs

to

exactly

one

class

To

resolve

this

dilemma

the

intersection-class

approach

would

create

a

new

intersection

class

Jeep

Imported

that

is

a

subclass

of

both

the

Jeep

and

Imported

classes

It

then

would

create

as

member

of

the

new

class

-LRB-

Figure

-LRB-

b

-RRB-

-RRB-

Alternatively

given

the

same

schema

suppose

that

were

a

member

of

the

Jeep

class

and

that

we

wanted

to

dynamically

reclassify

it

to

be

a

member

of

the

Imported

class

In

this

case

the

intersection-class

approach

would

require

us

to

create

a

new

object

as

member

of

the

Imported

class

to

copy

all

attribute

values

from

to

and

finally

to

swap

the

object

identities

of

these

two

objects

If

should

not

lose

its

membership

in

the

Jeep

class

then

this

dynamic

reclassification

of

the

object

would

again

cause

the

creation

of

a

Jeep

Imported

intersection

class

The

object-slicing

approach

-LRB-

Figure

-LRB-

c

-RRB-

-RRB-

would

implement

the

required

multiple

classification

by

manipulating

the

implementation

objects

representing

the

object

As

shown

in

the

figure

the

conceptual

object

corresponds

to

a

hierarchy

consisting

of

the

and

implementation

objects

Each

implementation

object

acts

as

its

class

's

interface

to

the

object

For

example

when

the

current

class

of

the

object

is

Jeep

the

object

represents

the

object

The

object-slicing

approach

also

enables

efficient

dynamic

restructuring

of

object

representations

to

account

for

the

addition

of

new

instance

variables

Suppose

that

we

were

to

extend

our

schema

which

originally

contains

the

Car

and

the

Jeep

classes

with

a

new

class

named

Imported

that

refines

the

Car

class

by

adding

the

stored

attribute

nation

Each

Car

object

-LRB-

as

well

as

each

Jeep

object

-RRB-

can

potentially

acquire

object-slicing

intersection-class

casting

change

representative

implement

obj

need

additional

mechanism

#oids

for

one

object

Nimpl

one

storage

for

-LRB-

Nimpl

-RRB-

sizeOf

-LRB-

oid

-RRB-

sizeOf

-LRB-

oid

-RRB-

managerial

purposes

Nimpl

sizeOf

-LRB-

pointer

-RRB-

storage

for

no

redundancy

no

redundancy

data

values

#classes

#user

defined

classes

#user

defined

classes

#intersection

classes

-LRB-

exponential

-RRB-

performance

good

access

to

local

attributes

fast

access

to

inherited

attributes

for

queries

dynamic

by

creating

and

destroying

by

creating

new

classes

another

object

classification

implementation

object

and

copying

values

and

removing

old

one

multiple

inheritance

has

flexibility

must

be

resolution

to

dynamically

resolve

determined

statically

Nimpl

the

number

of

implementation

objects

for

each

object

Table

Comparison

of

Two

Multiple

Classification

Approaches

the

type

of

the

Imported

class

This

means

that

the

Car

object

representation

should

be

restructured

so

that

it

can

store

the

data

for

the

new

attribute

This

can

be

accomplished

simply

by

creating

implementation

objects

of

the

Imported

class

and

adding

them

to

each

Car

object

Thus

the

restructuring

the

object

representation

in

the

object-slicing

paradigm

is

relatively

efficient

and

simple

when

compared

with

the

conventional

architecture

of

having

each

object

carry

all

of

its

state

information

in

a

contiguous

fashion

and

permitting

objects

to

belong

to

only

one

most

specific

class

Comparing

the

Two

Approaches

Each

approach

has

its

own

advantages

and

disadvantages

A

summary

of

the

following

comparison

is

also

presented

in

Table

ffl

Casting

an

object

to

a

type

is

readily

provided

by

switching

between

the

representative

implementation

objects

in

the

object-slicing

approach

However

in

the

intersection-class

approach

we

need

an

additional

mechanism

-LRB-

possibly

implemented

by

the

compiler

-RRB-

to

implement

the

casting

facility

ffl

In

the

object-slicing

approach

a

single

database

object

is

represented

by

as

many

implementation

objects

as

the

number

of

types

the

object

possesses

plus

one

conceptual

object

Thus

the

number

of

object

identifiers

needed

to

implement

a

single

object

is

equal

to

Nimpl

where

Nimpl

denotes

the

number

of

implementation

objects

needed

by

the

object

The

intersection-class

approach

requires

only

one

object

identifier

per

conceptual

object

ffl

OODBs

use

storage

for

purposes

other

than

storing

data

values

e.g.

for

indices

and

object

identifiers

The

object-slicing

approach

requires

additional

storage

for

the

internal

object

identifiers

described

above

-LRB-

Nimpl

sizeOf

-LRB-

oid

-RRB-

-RRB-

and

pointers

to

link

the

implementation

and

conceptual

objects

-LRB-

Nimpl

sizeOf

-LRB-

pointer

-RRB-

-RRB-

On

the

other

hand

the

intersection-class

approach

requires

no

additional

storage

other

than

that

required

to

create

the

intersection-class

itself

ffl

Neither

approach

requires

duplication

of

data

values

and

thus

they

are

non-redundant

in

terms

of

the

storage

for

data

values

-LRB-

Note

that

the

designer

is

still

able

to

duplicate

data

for

performance

reasons

in

both

approaches

-RRB-

ffl

The

object-slicing

approach

does

not

require

the

creation

of

any

hidden

classes

all

classes

in

the

global

schema

are

user-defined

classes

However

the

intersection-class

approach

requires

intersection

classes

in

order

to

accomplish

multiple

classification

For

each

object

that

takes

two

types

we

must

create

identifiers

are

necessary

for

one

conceptual

object

and

Nimpl

implementation

objects

implementation

object

keeps

the

pointer

to

its

conceptual

object

and

vice

versa

a

class

to

hold

the

combination

of

the

two

types

if

it

does

not

yet

exist

The

number

of

intersection

classes

may

increase

to

where

Nclass

is

the

number

of

user-defined

classes

of

the

global

schema

In

the

worst

case

the

number

of

intersection

classes

could

grow

exponentially

with

respect

to

the

number

of

user-defined

classes

Also

as

demonstrated

above

dynamic

classification

may

require

the

creation

and/or

removal

of

intersection-classes

on

the

fly

The

intersection-class

approach

thus

requires

dynamic

schema

evolution

support

ffl

The

state

of

a

given

object

in

the

object-slicing

approach

is

separated

by

class

and

distributed

over

a

number

of

implementation

objects

Because

each

implementation

object

is

smaller

than

a

complete

object

the

blocking

factor

of

the

implementation

objects

of

a

given

class

under

the

object-slicing

model

should

be

significantly

better

than

the

blocking

factor

of

complete

objects

of

the

same

class

under

a

conventional

architecture

such

as

that

of

the

intersection-class

model

Sequential

access

of

clustered

implementation

objects

should

therefore

be

faster

than

sequential

access

to

the

same

number

of

complete

objects

However

access

to

an

inherited

attributes

in

the

object-slicing

approach

can

involve

the

random

access

retrieval

of

conceptual

object

and

multiple

implementation

objects

The

intersection-class

approach

may

therefore

be

faster

in

accessing

an

inherited

attribute

because

the

values

of

all

attributes

of

an

object

reside

in

the

same

location

We

present

detailed

comparison

studies

by

benchmark

experiments

and

simulations

that

confirm

this

hypothesis

in

Section

ffl

Changing

an

object

from

being

an

instance

of

one

class

-LRB-

-RRB-

to

being

an

instance

of

another

class

-LRB-

-RRB-

is

called

dynamic

classification

-LSB-

-RSB-

In

the

object-slicing

approach

when

an

object

is

dynamically

reclassified

to

be

an

instance

of

the

class

rather

than

one

of

class

the

object

instance

takes

an

implementation

object

of

the

class

and

discards

that

of

the

class

By

combining

the

operators

for

adding

and

removing

class

membership

we

can

easily

achieve

this

functionality

In

the

intersectionclass

approach

we

first

must

identify

the

proper

class

for

the

new

classification

and

if

it

does

not

exist

create

the

class

This

requires

schema

evolution

support

with

classification

capability

Second

we

need

to

create

an

object

of

this

new

class

and

copy

the

values

of

the

object

to

be

reclassified

into

this

newly

created

object

To

preserve

object

identity

we

must

copy

the

object

identity

of

the

old

object

to

the

new

object

by

utilizing

a

swap

mechanism

In

conclusion

on

most

fronts

the

object-slicing

approach

promises

comparable

performance

to

the

more

conventional

intersection-class

method

and

in

some

cases

even

improves

performance

Furthermore

because

object-slicing

avoids

the

creation

of

cumbersome

intersection

classes

and

offers

flexible

restructuring

of

both

state

and

behavior

it

appears

to

be

a

cleaner

method

for

extending

existing

OODBs

However

the

additional

overhead

required

for

the

object-slicing

structures

and

the

random

accesses

needed

to

retrieve

the

inherited

state

from

implementation

objects

are

disadvantages

associated

with

the

object-slicing

methodology

In

the

remainder

of

this

paper

we

thus

describe

our

experimental

results

in

evaluating

these

two

approaches

In

Sections

and

we

perform

a

closer

examination

of

the

benefit

provided

by

object-slicing

's

larger

blocking

factor

at

the

class

the

cost

of

the

additional

random

accesses

and

the

potential

of

clustering

to

alleviate

that

cost

The

Object-Slicing

Model

We

formalize

the

object-slicing

paradigm

used

in

our

implementation

of

MultiView

below

Let

Oi

O

be

a

user-defined

object

In

the

object-slicing

model

Oi

is

represented

using

two

kinds

of

objects

a

single

conceptual

object

Oiconc

and

one

implementation

object

for

each

class

Cj

C

to

which

the

object

belongs

OiimplCj

A

conceptual

object

consists

of

a

tuple

implObjects

OID

where

OID

is

the

unique

system-generated

object-identifier

of

the

conceptual

object

and

implObjects

is

the

set

of

implementation

objects

that

are

linked

to

the

conceptual

object

An

implementation

object

is

a

tuple

OID

oid

class

state

where

OID

is

the

object-identifier

of

the

linked

conceptual

object

oid

is

the

object-identifier

of

the

implementation

object

itself

class

is

the

class

of

which

the

implementation

object

is

a

direct

instance

and

state

corresponds

to

the

values

of

the

local

instance

variables

stored

for

the

given

implementation

object

by

default

possesses

its

own

object

identifier

However

because

the

implementation

object

serves

as

an

interface

for

a

specific

conceptual

object

the

object-identifier

of

the

conceptual

object

supersedes

that

of

the

implementation

object

for

most

practical

purposes

such

as

determining

object-equality

object

Each

implementation

object

OiimplCj

is

an

object

instance

of

the

database

class

Cj

C

it

repre

sents

Conceptual

objects

are

object

instances

of

a

special

system

class

ConceptualObject

rather

than

of

a

user-defined

class

Because

a

single

real-world

object

is

now

represented

using

multiple

database

objects

we

define

a

number

of

functions

to

operate

on

objects

in

the

model

including

object

creation

equality

comparison

etc.

For

example

we

say

that

two

objects

are

equal

if

and

only

if

they

are

linked

to

the

same

conceptual

object

Similarly

given

an

object

Oi

O

and

a

class

Cj

C

we

define

functions

MakeImpl

-LRB-

Oiconc

Cj

-RRB-

and

DeleteImpl

-LRB-

Oiconc

Cj

-RRB-

to

create

and

destroy

implementation

objects

of

class

Cj

for

object

Oiconc

If

an

object

Oi

possesses

an

implementation

object

OiimplCj

for

some

Cj

C

then

Oi

must

also

possess

implementation

objects

for

all

classes

Ck

s.t.

Cj

is-a

Ck

Thus

the

set

of

implementation

objects

associated

with

a

given

conceptual

object

mirrors

the

structure

of

the

class

hierarchy

Object-slicing

intrinsically

includes

its

own

inheritance

mechanism

Let

there

be

an

implementation

object

OiimplCj

Oi

O

Cj

C

If

the

method

mk

M

were

to

be

invoked

upon

object

OiimplCj

and

mk

is

not

defined

locally

in

type

-LRB-

Cj

-RRB-

then

OiimplCj

will

delegate

the

method

mk

to

Oiconc

It

will

in

turn

conduct

a

search

upwards

through

Cj

's

superclasses

If

method

mk

is

not

found

in

the

type

of

a

superclass

Cl

of

Cj

then

an

error

is

returned

otherwise

the

method

is

invoked

upon

the

object

OiimplCl

Figure

illustrates

this

idea

using

an

example

Root

color

Cat

Pedigreed

color

conceptual

object

Cat

Cat

Show

Cat

House

name

breed

pedigree

name

Kitty-breed

Burmese

pedigree

color

brown

-LRB-

a

-RRB-

An

implementation

object

from

the

PedigreedCat

class

receives

a

message

color

color

conceptual

object

pedigree

color

brown

breed

Burmese

name

Kitty

color

conceptual

object

pedigree

color

brown

breed

Burmese

name

Kitty

color

brown

-LRB-

b

-RRB-

belonging

to

the

superclasses

of

Each

of

the

implementation

objects

the

method

color

the

PedigreedCat

class

is

queried

for

-LRB-

c

-RRB-

The

implementation

object

of

belonging

The

method

color

is

found

at

the

Cat

class

to

the

Cat

class

returns

the

value

of

the

color

instance

variable

brown

Figure

Object-Slicing

Example

Because

objects

in

the

object-slicing

model

can

dynamically

add

and

lose

implementation

objects

and

because

the

object-slicing

model

includes

its

own

inheritance

mechanism

the

object-slicing

technique

can

be

used

to

extend

object-oriented

data

models

to

provide

the

features

of

multiple

classification

dynamic

reclassification

and

dynamic

restructuring

It

is

relatively

straightforward

to

see

how

one

could

implement

the

object-slicing

model

on

top

of

an

existing

OODB

In

our

technical

report

-LSB-

-RSB-

we

describe

our

solution

of

realizing

the

model

using

a

Smalltalk-based

OODB

GemStone

system

Due

to

space

limitations

a

discussion

of

these

implementation

issues

is

not

repeated

here

Object-Slicing

Storage

Costs

In

evaluating

the

performance

of

databases

I/O

operation

time

typically

dominates

CPU

operation

time

Consequently

an

evaluation

of

object-slicing

must

consider

the

effect

of

object-slicing

on

I/O

time

methods

used

to

set

or

retrieve

an

instance

variable

's

value

are

called

accessing

methods

Accessing

methods

are

always

located

at

the

same

class

as

the

instance

variables

for

which

they

are

defined

and

thus

when

an

instance

variable

migrates

from

one

class

to

another

that

instance

variable

's

accessing

methods

must

make

the

same

migration

a

method

with

selector

mi

is

found

in

more

than

one

class

in

the

superclass

hierarchy

of

Cj

then

the

user

is

prompted

to

cast

Oi

into

a

non-ambiguous

implementation

object

One

major

variable

for

calculating

I/O

time

is

the

number

of

objects

that

can

be

stored

in

a

disk

block

known

as

the

blocking

factor

-LRB-

bf

-RRB-

namely

d

disk

block

size

object

size

e

In

traditional

-LRB-

non-object-slicing

-RRB-

architectures

the

size

of

an

object

is

calculated

to

be

the

total

amount

of

storage

needed

to

store

the

state

of

the

object

-LRB-

data

size

-RRB-

oid

size

and

pointer

size

-LRB-

to

reference

the

object

's

class

-RRB-

and

some

fields

for

the

system

use

Because

the

object-slicing

model

represents

any

given

object

using

a

conceptual

object

and

some

number

of

implementation

objects

objects

in

the

object-slicing

architecture

inherently

require

more

storage

space

than

their

counterparts

in

traditional

architectures

Like

a

traditional

object

an

object

under

the

object-slicing

architecture

contains

data

an

oid

and

a

pointer

to

its

class

In

addition

an

object-slicing

object

that

belongs

to

l

classes

also

requires

l

implementation

objects

-LRB-

each

with

a

reference

to

its

class

and

to

the

object

's

conceptual

object

-RRB-

the

conceptual

object

-LRB-

which

has

a

dictionary

of

references

to

its

implementation

objects

respectively

indexed

by

the

class

the

implementation

object

belongs

to

-RRB-

and

the

system

fields

That

is

while

in

a

conventional

architecture

we

would

have

obj

size

data

size

oid

size

pointer

size

system

fields

in

the

object-slicing

architecture

we

now

have

obj

size

data

size

-LRB-

l

-RRB-

oid

size

-LRB-

-RRB-

pointer

size

system

fields

To

simplify

we

assume

that

oid

size

is

equal

to

pointer

size

The

ratio

of

the

sizes

is

now

SizeRatio

-LRB-

SR

-RRB-

datasize

-LRB-

-RRB-

pointersize

systemfields

datasize

pointersize

systemf

ields

Ignoring

the

size

of

the

system

fields

for

simplicity

and

assuming

that

oid

size

pointer

size

the

ratio

becomes

SR

DS

-LRB-

-RRB-

pointersize

DS

pointersize

where

SR

is

the

size

ratio

and

DS

is

data

size

When

the

size

of

the

pointer

is

bytes

which

is

a

reasonable

assumption

for

current

systems

this

becomes

SR

DS

-LRB-

-RRB-

DS

Given

these

assumptions

Figure

shows

the

blocking

factor

ratio

for

the

fixed

data

size

values

of

and

bytes

while

increasing

l

the

number

of

implementation

objects

required

from

to

On

the

other

hand

Figure

shows

the

blocking

factor

ratio

by

fixing

the

number

of

implementation

objects

and

varying

data

size

In

general

the

ratio

increases

as

the

value

of

l

increases

and

decreases

as

the

data

size

increases

This

means

that

the

disadvantage

of

the

object-slicing

architecture

's

storage

overhead

is

ameliorated

by

an

increased

object

size/decreased

schema

size

-LRB-

depth

of

schema

-RRB-

ratio

Evaluation

of

Object-Slicing

Approach

Using

the

Benchmark

In

order

to

determine

the

base

cost

of

implementing

the

object-slicing

representation

paradigm

we

have

run

several

test

queries

from

the

University

of

Wisconsin

's

benchmark

suite

-LSB-

-RSB-

with

the

intention

of

comparing

GemStone

's

native

implementation

versus

our

object-slicing

extension

to

GemStone

GemStone

is

a

Smalltalk-based

system

while

the

four

systems

compared

in

the

benchmark

paper

-LSB-

-RSB-

are

all

C++

based

Because

GemStone

thus

supports

dynamic

method

resolution

run-time

augmentation

of

the

schema

with

new

methods

etc.

we

did

not

compare

GemStone

against

other

systems

and

instead

limited

our

study

to

comparing

pure

GemStone

with

MultiView

For

this

study

we

used

GemStone

version

Opal

and

created

a

randomly

populated

database

of

the

parts-assembly

benchmark

example

with

Atomic

Parts

First

we

compare

results

for

navigation-type

queries

e.g.

for

the

Traversal

query

The

Traversal

query

tests

raw

pointer

traversal

speed

with

a

high

degree

of

locality

-LSB-

-RSB-

The

query

requires

a

traversal

of

this

storage

of

references

linking

conceptual

to

implementation

objects

and

back

could

be

reduced

we

've

chosen

this

representation

for

reason

of

efficiency

bf-ratio

number

of

implementation

objects

-LRB-

k

-RRB-

blocking

factor

ratio

ds

ds

ds

ds

ds

ds

Figure

Blocking

Factor

Ratio

with

Fixed

Data

Size

10 100 1000

bf-ratio

data

size

of

the

object

-LRB-

DS

-RRB-

blocking

factor

ratio

k

k

k

k

k

Figure

Blocking

Factor

Ratio

with

Fixed

Number

of

Implementation

Object

the

assembly

hierarchy

shown

in

Figure

and

performs

a

depth-first

search

on

each

part

's

graph

of

atomic

parts

MultiView

's

performance

slightly

improved

upon

GemStone

's

time

-LRB-

by

ss

-RRB-

despite

the

fact

that

MultiView

is

built

on

top

of

GemStone

rather

than

directly

into

the

GemStone

kernel

thus

adding

an

extra

layer

of

indirection

The

improved

performance

can

be

explained

as

follows

First

the

navigation

was

limited

to

access

of

local

instance

variables

-LRB-

rather

than

inherited

ones

-RRB-

Thus

there

is

no

overhead

of

finding

appropriate

implementation

objects

for

MultiView

Consequently

only

one

implementation

object

has

to

be

retrieved

per

queried

object

The

query

avoids

having

to

perform

random

accesses

to

retrieve

additional

implementation

objects

Not

only

was

retrieval

of

the

single

implementation

objects

sequential

but

also

these

navigated

implementation

objects

are

much

smaller

in

size

-LRB-

containing

only

local

instance

variables

-RRB-

compared

to

GemStone

's

native

objects

-LRB-

containing

both

local

and

inherited

instance

variables

in

one

contiguous

allocation

-RRB-

and

thus

offered

a

higher

blocking

factor

-LRB-

See

Section

for

a

more

formal

analysis

of

these

factors

-RRB-

DesignObj

idtypebuildDate

AssemblyAtomicPart

lengthConnection

typexydocIdMNis-a

Base

Assembly

Composite

Part

PartsComponent

Shared

Figure

A

Portion

of

Benchmark

Database

Next

we

tested

the

Query

Search

benchmark

which

performs

a

random

lookup

of

an

atomic

part

based

on

the

inherited

property

id

as

shown

in

Figure

For

this

lookup

MultiView

performed

times

slower

than

GemStone

The

major

overhead

stems

from

the

fact

that

for

each

of

the

lookups

we

must

traverse

from

each

Atomic

Part

's

implementation

objects

to

the

corresponding

conceptual

object

and

then

to

its

corresponding

DesignObj

's

implementation

object

in

order

to

retrieve

the

id

data

value

Accessing

an

inherited

attribute

in

MultiView

requires

two

additional

traversals

one

to

traverse

the

do

not

have

access

to

the

GemStone

code

to

override

the

kernel

with

MultiView

conceptualLink

to

get

from

the

implementation

object

to

its

conceptual

object

and

the

other

to

traverse

the

implementationLink

to

get

from

the

conceptual

object

to

the

correct

implementation

object

holding

the

desired

data

value

As

demonstrated

in

this

paper

these

two

links

improve

the

flexibility

of

our

object

model

greatly

but

it

also

causes

the

observed

performance

degradation

In

short

there

are

two

possible

causes

for

the

degradation

in

performance

associated

with

object-slicing

First

the

storage

overhead

to

store

the

conceptual

object

the

oids

of

the

implementation

objects

and

those

two

extra

links

may

require

a

larger

number

of

blocks

and

result

in

more

page

faults

Second

because

the

implementation

objects

belonging

to

the

same

class

are

by

default

clustered

together

each

traversal

to

an

implementation

object

for

getting

an

inherited

value

requires

a

partial

random

block

access

which

can

result

in

a

page

fault

In

the

next

section

we

investigate

the

impact

of

the

object-slicing

mechanism

upon

an

implementation

's

storage

overhead

in

terms

of

the

blocking

factor

of

various

objects

and

also

in

terms

of

the

page

faults

incurred

by

the

retrieval

of

object-slicing

implementation

objects

We

also

evaluate

the

ability

of

clustering

strategies

to

alleviate

these

object-slicing

penalties

Evaluating

and

Optimizing

Object-Slicing

Using

the

Benchmark

Clustering

Strategies

for

Object-Slicing

By

specifying

that

certain

categories

of

objects

be

placed

in

contiguous

storage

on

the

disk

-LRB-

thereby

clustering

them

-RRB-

database

designers

try

to

match

the

traversal

patterns

of

objects

in

a

database

to

storage

sequences

of

objects

to

minimize

disk

I/O

costs

In

traditional

-LRB-

non-object-slicing

-RRB-

environments

the

granularity

of

this

optimization

is

often

restricted

to

the

clustering

of

objects

A

MultiView

object

's

state

is

distributed

among

multiple

object-slicing

implementation

objects

however

which

lends

itself

to

clustering

strategies

that

resemble

the

vertical

partitioning

of

the

relational

model

In

order

to

determine

under

which

circumstances

it

is

preferable

to

cluster

the

implementation

objects

by

class

-LRB-

which

we

call

class

clustering

-RRB-

and

under

which

circumstances

it

is

better

to

cluster

all

the

components

of

a

MultiView

object

together

-LRB-

which

we

term

object

clustering

-RRB-

we

designed

and

carried

out

an

extensive

experimental

study

evaluating

both

clustering

techniques

partOf

-LRB-

bytes

-RRB-

to

-LRB-

bytes

-RRB-

from

-LRB-

bytes

-RRB-

x

-LRB-

bytes

-RRB-

y

-LRB-

bytes

-RRB-

docId

-LRB-

bytes

-RRB-

CompositePart

AtomicPart

documentation

-LRB-

bytes

-RRB-

usedInPriv

-LRB-

bytes

-RRB-

usedInShar

-LRB-

bytes

-RRB-

parts

-LRB-

bytes

-RRB-

rootPart

-LRB-

bytes

-RRB-

DesignObj

id

-LRB-

bytes

-RRB-

type

-LRB-

bytes

-RRB-

buildDate

-LRB-

bytes

-RRB-

-LRB-

objects

-RRB-

-LRB-

objects

-RRB-

-LRB-

objects

-RRB-

is-a

is-a

Figure

Subschema

of

Database

For

our

evaluation

we

again

use

a

subsection

of

the

Benchmark

's

example

database

-LRB-

Figure

-RRB-

Figure

shows

the

three

class

subschema

that

is

central

to

our

test

queries

Figure

illustrates

clustering

options

of

object

versus

class

clustering

using

an

example

In

this

example

there

are

three

objects

that

are

instances

of

the

AtomicPart

class

from

the

schema

shown

in

Figure

Figure

-LRB-

a

-RRB-

depicts

the

initial

object

relationships

in

which

there

are

three

objects

and

each

of

which

has

two

implementation

objects

-LRB-

one

for

the

DesignObj

class

and

one

for

AtomicPart

-RRB-

If

we

were

to

cluster

the

database

objects

by

class

as

shown

in

Figure

-LRB-

b

-RRB-

then

we

would

cluster

the

implementation

objects

of

each

class

and

the

conceptual

objects

separately

If

however

we

were

to

cluster

by

objects

then

all

the

data

associated

with

each

individual

object

would

be

clustered

together

as

shown

in

Figure

-LRB-

c

-RRB-

The

second

option

resembles

clustering

at

the

granularity

of

complete

objects

Tables

and

compare

the

relative

object

sizes

and

blocking

factors

involved

with

the

object

clustering

and

class

clustering

strategies

The

classes

in

the

schema

are

listed

as

the

rows

of

each

table

The

columns

of

Table

indicate

respectively

the

number

of

objects

that

initially

exist

in

each

class

's

extent

-LRB-

#impls

-RRB-

the

number

of

objects

that

have

the

given

class

as

a

most-specific

type

-LRB-

#objs

-RRB-

the

average

size

of

an

object

in

the

class

's

extent

using

the

class

clustering

methodology

-LRB-

CC

size

-RRB-

the

blocking

factor

of

the

class

using

the

CC

strategy

-LRB-

CC

BF

-RRB-

the

number

of

blocks

that

would

be

needed

to

store

the

extent

of

Subclass

Of

Instance

Of

Cluster

DesignObj

AtomicPart

id

-LRB-

a

-RRB-

-LRB-

b

-RRB-

Class

Clustering

KEY

-LRB-

c

-RRB-

Object

Clustering

a

a

c

e

b

d

f

Implementation

object

c

d

fe

Conceptual

Object

DesignObj

AtomicPart

DesignObj

AtomicPart

DesignObj

AtomicPart

a

b

f

e

c

d

b

Figure

Example

of

Object

Clustering

v.s.

Class

Clustering

#impl

#objs

CC

size

CC

BF

#CC

OC

size

OC

BF

#OC

DesignObj

Assembly

BaseAssembly

ComplexAssembly

AtomicPart

CompositePart

Connection

Module

Table

Data

sizes

with

byte

blocks

Objects

Conc

Obj

Size

Conc

Obj

BF

Conc

Obj

Blocks

DesignObj

Assembly

BaseAssembly

ComplexAssembly

AtomicPart

CompositePart

Connection

Module

Table

Conceptual

Object

sizes

for

ClassClusterDictionary

with

a

blocksize

of

bytes

the

class

using

the

CC

strategy

-LRB-

#CC

-RRB-

the

average

size

of

an

object

in

the

class

's

extent

using

the

object

clustering

-LRB-

OC

-RRB-

methodology

-LRB-

OC

size

-RRB-

the

blocking

factor

of

the

class

using

OC

-LRB-

OC

BF

-RRB-

and

the

number

of

blocks

that

would

be

needed

to

store

the

extent

of

the

class

using

OC

-LRB-

#OC

-RRB-

The

columns

of

Table

indicate

respectively

the

number

of

objects

that

have

that

class

as

most

specific

type

the

size

of

a

conceptual

object

that

has

that

class

as

most

specific

type

the

blocking

factor

of

such

a

conceptual

object

and

the

number

of

blocks

needed

to

store

the

conceptual

objects

of

that

class

's

extent

For

example

we

can

see

from

Table

that

there

are

instances

of

the

AtomicPart

class

If

we

were

to

cluster

implementation

objects

according

to

their

classes

then

the

blocking

factor

of

the

AtomicPart

class

's

extent

would

be

sixteen

objects

per

byte

block

If

on

the

other

hand

we

were

to

cluster

all

of

an

object

's

conceptual

object

plus

all

of

its

implementation

objects

together

then

the

AtomicPart

class

's

extent

would

have

a

blocking

factor

of

only

six

objects

per

byte

block

We

ran

several

benchmark

queries

adopted

from

the

benchmark

test

suite

on

MultiView

to

compare

the

performance

of

the

class

clustering

and

object

clustering

strategies

We

modified

the

accessing

methods

of

all

objects

in

MultiView

so

as

to

log

all

object

accesses

and

method

invocations

We

used

the

resulting

logs

as

input

to

trace-driven

simulations

of

a

least-recently-used

-LRB-

LRU

-RRB-

buffering

policy

The

simulator

takes

as

input

the

trace

data

a

clustering

policy

and

the

amount

of

memory

in

the

simulated

machine

and

performs

the

following

tasks

Uses

the

specified

clustering

policy

to

map

each

data

item

in

the

trace

data

to

a

simulated

block

Simulates

the

effect

of

the

clustering

policy

given

the

specified

amount

of

memory

and

the

access

patterns

contained

in

the

trace

data

Returns

the

total

number

of

block

misses

incurred

by

the

simulation

-LRB-

A

block

miss

occurs

when

an

object

that

does

not

reside

in

main

memory

is

accessed

-RRB-

We

use

this

simulator

to

compare

the

number

of

block

misses

that

are

incurred

under

the

class

clustering

and

object

clustering

strategies

to

the

number

of

block

misses

that

would

occur

if

we

did

not

use

an

objectslicing

mechanism

Thus

each

of

the

following

graphs

plots

three

lines

The

block

misses

incurred

by

an

object-clustering

policy

The

block

misses

incurred

by

an

class-clustering

policy

The

block

misses

incurred

by

a

non-object-slicing

implementation

From

these

graphs

we

should

be

able

to

identify

the

degree

to

which

either

the

object-clustering

or

classclustering

strategy

approaches

the

memory

size

blocks

missed

ratio

of

a

non-object-slicing

implementation

Retrieving

Local

Attributes

Class

clustering

and

object

clustering

are

each

associated

with

inherent

strengths

and

weaknesses

The

chief

advantage

of

class

clustering

is

that

it

greatly

increases

the

blocking

factor

of

the

objects

in

each

class

's

extent

thereby

facilitating

the

retrieval

of

local

attributes

A

comparison

of

the

blocking

factors

of

the

two

strategies

for

the

various

classes

is

presented

in

Tables

and

From

these

tables

we

can

see

that

the

number

of

blocks

needed

to

store

the

extent

of

the

classes

in

our

example

schema

using

the

class

clustering

strategy

is

between

one

half

and

one

third

the

number

of

blocks

that

would

be

needed

if

an

object-clustering

strategy

were

used

This

ratio

clearly

depends

on

other

factors

such

as

the

datasize

and

the

number

of

implementation

objects

as

indicated

by

the

blocking

factor

ratios

depicted

in

Tables

and

In

Test

we

compare

the

performance

of

object

clustering

and

class

clustering

regarding

the

retrieval

of

objects

local

attributes

In

this

test

we

generate

random

numbers

n

then

search

the

extent

of

the

AtomicPart

class

looking

for

a

part

that

has

a

Document

Id

equal

to

the

random

number

n.

Note

that

docIdArray

is

an

attribute

defined

by

the

AtomicPart

class

and

is

thus

an

attribute

local

to

the

AtomicPart

implementation

objects

Query

index

-LRB-

Rand

RandomNumberLessThan

-LRB-

docIdArray

size

-RRB-

-RRB-

document

docIdArray

at

index

-LRB-

AtomicPart

extent

-RRB-

select

-LSB-

elem

elem

docId

document

-RSB-

This

test

is

equivalent

to

performing

ten

sequential

searches

of

the

objects

in

the

extent

of

the

AtomicPart

class

while

retrieving

a

locally

defined

attribute

The

class

clustering

strategy

produces

a

blocking

factor

of

sixteen

objects

per

block

for

the

AtomicPart

class

versus

only

six

objects

per

block

using

the

object

clustering

strategy

We

thus

would

expect

the

class

clustering

strategy

to

produce

about

of

the

block

misses

of

the

object

clustering

strategy

Our

experiments

confirm

these

expectations

Namely

Figure

shows

a

decrease

in

block

misses

between

the

object

clustering

and

class

clustering

strategies

200 400 600 800

1000 1200 1400 1600

Number

of

Block

Misses

Memory

Size

in

Blocks

clustering

by

class

clustering

by

object

non-object-slicing

Figure

Block

Misses

for

Retrieving

Local

Attribute

The

vertical

axis

of

Figure

indicates

the

number

of

block

misses

while

the

horizontal

axis

indicates

the

memory

size

in

blocks

Because

the

AtomicPart

class

's

extent

is

stored

on

contiguous

blocks

under

the

class

clustering

strategy

and

contiguous

blocks

under

the

object

clustering

strategy

even

with

an

infinite

amount

of

memory

there

will

be

a

minimum

of

block

misses

in

the

object-clustering

case

and

block

misses

in

the

class-clustering

scenario

The

third

line

shows

the

blocks

misses

that

would

be

incurred

if

we

did

not

use

object-slicing

In

that

case

the

AtomicPart

class

's

extent

would

be

stored

on

contiguous

blocks

and

the

first

query

would

result

in

a

minimum

block

misses

As

the

number

of

blocks

in

memory

decreases

the

number

of

block

misses

should

naturally

increase

Because

accesses

are

sequential

both

class

clustering

and

object

clustering

object

layouts

are

optimal

for

this

query

in

that

every

object

will

be

accessed

exactly

once

and

no

object

will

be

accessed

after

any

of

the

objects

that

succeeds

it

in

storage

has

been

accessed

Therefore

independent

from

the

number

of

blocks

in

memory

the

class

clustering

strategy

will

result

in

block

misses

and

the

object

clustering

strategy

will

result

in

block

misses

The

class

clustering

strategy

is

the

clear

winner

for

these

types

of

queries

It

improves

upon

a

non-object-slicing

implementation

and

is

superior

to

the

object-clustering

strategy

for

the

retrieval

of

local

attributes

Sequential

Retrieval

of

Inherited

Attributes

In

the

case

of

queries

that

retrieve

inherited

attributes

we

might

expect

object

clustering

to

outperform

class

clustering

While

the

object

clustering

strategy

can

access

methods

in

a

sequential

manner

in

the

class

clustering

scenario

each

retrieval

of

an

inherited

attribute

requires

a

semi-random

access

to

retrieve

the

object

's

conceptual

object

and

a

semi-random

access

to

retrieve

the

implementation

object

associated

with

the

inherited

property

Our

second

test

Test

iterates

through

the

extent

of

the

AtomicPart

class

comparing

each

object

's

inherited

buildDate

instance

variable

to

a

randomly

generated

date

Query

because

the

sets

of

implementation

objects

and

conceptual

objects

are

themselves

clustered

sequentially

aDate

RandomNumber

-LRB-

AtomicPart

extent

-RRB-

select

-LSB-

elem

elem

buildDate

aDate

-RSB-

Test

measures

the

impact

of

semi-random

accesses

caused

by

retrieving

an

inherited

attribute

from

the

objects

in

the

AtomicPart

extent

In

this

test

the

buildDate

of

each

object

in

the

AtomicPart

extent

was

compared

to

a

randomly

generated

number

Test

is

equivalent

to

performing

a

sequential

search

of

the

objects

in

the

extent

of

AtomicPart

class

and

retrieving

a

property

inherited

from

the

DesignObj

class

from

each

of

them

Recall

from

Section

that

whenever

an

inherited

instance

variable

of

an

implementationobject

is

accessed

three

objects

must

be

accessed

in

order

to

retrieve

the

inherited

instance

variable

-LCB-

the

recipient

object

-LRB-

the

object

that

is

initially

accessed

-RRB-

the

recipient

's

conceptual

object

and

the

implementation

object

where

the

inherited

instance

variable

is

defined

For

example

if

we

were

to

apply

this

query

to

the

example

scenario

shown

in

Figure

the

sequence

of

objects

we

retrieve

might

be

as

follows

Obj

b

-LRB-

's

AtomicPart

object

accessed

when

it

receives

buildDate

-RRB-

Obj

-LRB-

's

conceptual

object

accessed

when

Obj

b

does

not

understand

buildDate

-RRB-

Obj

a

-LRB-

's

DesignObj

impl

object

accessed

because

buildDate

is

defined

at

DesignObj

-RRB-

Obj

d

-LRB-

's

AtomicPart

impl

object

accessed

when

it

receives

buildDate

-RRB-

Obj

-LRB-

's

conceptual

object

accessed

when

Obj

d

does

not

understand

buildDate

-RRB-

Obj

c

-LRB-

's

DesignObj

impl

object

accessed

because

buildDate

is

defined

at

DesignObj

-RRB-

Obj

f

-LRB-

's

AtomicPart

impl

object

accessed

when

it

receives

buildDate

-RRB-

Obj

-LRB-

's

conceptual

object

accessed

when

Obj

f

does

not

understand

buildDate

-RRB-

Obj

e

-LRB-

's

DesignObj

impl

object

accessed

because

buildDate

is

defined

at

DesignObj

-RRB-

200 400 600 800

1000 1200 1400 1600

Number

of

Block

Misses

Memory

Size

in

Blocks

clustering

by

class

clustering

by

object

non-object-slicing

Figure

Block

Misses

Involved

in

the

Sequential

Retrieval

of

an

Inherited

Attribute

The

results

of

this

test

-LRB-

Figure

-RRB-

show

that

the

cost

of

semi-random

access

to

inherited

attributes

needed

by

the

class

clustering

strategy

is

counterbalanced

by

the

superior

blocking

factors

at

both

the

DesignObj

and

AtomicPart

classes

Although

for

small

memory

sizes

object-clustering

causes

fewer

faults

than

class

clustering

for

larger

memory

sizes

class

clustering

out-performs

object

clustering

and

more

closely

approaches

the

baseline

of

a

non-object-slicing

implementation

Note

that

the

number

of

object-clustering

misses

remains

constant

regardless

of

the

number

of

blocks

in

memory

This

is

because

from

the

objectclustering

perspective

we

are

simply

performing

a

sequential

search

of

the

AtomicPart

class

On

the

other

hand

because

the

class

clustering

approach

automatically

references

three

different

blocks

for

every

object

processed

when

the

number

of

blocks

in

memory

dips

below

three

class

clustering

results

in

block

misses

-LRB-

one

for

each

implementation

or

conceptual

object

accessed

-RRB-

In

order

to

refine

the

results

from

Test

we

next

set

out

to

vary

two

parameters

that

affect

the

performance

of

object

clustering

and

class

clustering

First

Test

involved

only

a

single

inherited

attribute

Since

the

block

miss

gap

between

class

and

object

clustering

was

reduced

by

the

presence

of

a

single

inherited

attribute

we

designed

Test

to

measure

the

effect

of

an

increased

number

of

inherited

attributes

-LRB-

each

inherited

from

a

different

class

-RRB-

Next

note

that

the

implementation

objects

associated

with

AtomicPart

objects

make

up

a

significant

percentage

of

the

implementation

objects

in

the

extent

of

the

DesignObj

class

In

Test

we

compare

class

and

object

clustering

performance

in

a

scenario

where

the

inherited

attribute

is

inherited

from

a

class

where

the

queried

objects

make

up

only

a

small

portion

of

the

class

's

extent

that

is

where

a

condition

of

low

selectivity

exists

between

the

original

and

inheritance

class

Retrieval

of

Multiple

Inherited

Attributes

In

Test

inherited

attributes

are

retrieved

with

semi-random

accesses

Because

object

clustering

permits

a

given

object

's

state

to

be

retrieved

in

a

sequential

manner

-LRB-

whereas

class

clustering

requires

at

best

semirandom

accesses

for

inherited

attributes

-RRB-

we

designed

Test

to

increase

the

number

of

classes

involved

in

the

access

pattern

Test

traverses

the

assembly

hierarchy

of

the

root

Module

object

visiting

all

components

and

their

sub-components

in

a

recursive

fashion

Query

method

Assembly

TraverseAH

-LRB-

self

isInstanceOf

BaseAssembly

-RRB-

ifTrue

-LSB-

-LRB-

-LRB-

-LRB-

self

asClassOf

BaseAssembly

-RRB-

componentsPriv

-RRB-

do

-LSB-

elem

visitedNode

at

nodeNumber

put

nodeCount

-RSB-

-RRB-

-RSB-

ifFalse

-LSB-

-LRB-

-LRB-

self

asClassOf

ComplexAssembly

-RRB-

subAssemblies

-RRB-

do

-LSB-

elem

elem

TraverseAH

-RSB-

-RSB-

run

aModule

-LRB-

Module

extent

-RRB-

at

aModule

designRoot

TraverseAH

50 100 150 200

Number

of

Block

Misses

Memory

Size

in

Blocks

clustering

by

class

clustering

by

object

no-object-slicing

Figure

Random

Access

on

Inherited

Attribute

Graph

compares

the

block

misses

that

are

incurred

by

the

object

and

class

clustering

layouts

Because

this

query

does

not

use

all

of

the

state

of

the

accessed

objects

we

benefit

from

the

superior

blocking

factor

at

the

implementation

object

level

offered

by

the

class

clustering

approach

Under

the

object

clustering

scenario

the

accessed

objects

reside

on

unique

blocks

whereas

under

the

class

clustering

scenario

only

unique

blocks

are

retrieved

during

Test

The

graph

shows

that

object

clustering

is

better

for

small

amounts

of

memory

but

that

class

clustering

's

performance

more

successfully

approaches

non-object-slicing

performance

as

the

number

of

blocks

in

main

memory

increases

Class

clustering

is

better

for

larger

amounts

of

main

memory

due

to

the

inherently

higher

blocking

factors

of

class

clustering

Under

the

object

clustering

when

an

instance

is

brought

into

main

memory

all

the

constituent

implementation

objects

residing

in

the

same

block

must

also

be

brought

into

the

memory

including

implementation

objects

that

are

not

needed

by

the

query

being

performed

Object

clustering

thus

accesses

a

number

of

unnecessary

blocks

However

because

the

implementation

objects

of

an

object

under

the

class

clustering

scenario

inhabit

separate

blocks

class

clustering

requires

cross-block

references

to

access

the

values

of

the

inherited

attribute

Thus

when

only

an

extremely

small

number

of

blocks

can

be

stored

in

memory

some

of

the

necessary

blocks

will

be

swapped

out

from

memory

before

they

are

re-referenced

by

the

query

Retrieval

of

Inherited

Attributes

with

Low

Selectivity

In

Test

we

compare

class

and

object

clustering

performance

in

a

scenario

where

the

inherited

attribute

is

inherited

from

a

class

where

the

queried

objects

make

up

only

a

small

portion

of

the

class

's

extent

Test

's

query

iterates

over

the

extent

of

the

CompositePart

class

retrieving

each

object

's

DesignObj

implementation

object

Query

-LRB-

CompositePart

extent

-RRB-

select

-LSB-

elem

elem

buildDate

RandomNumber

-RSB-

Since

CompositePart

objects

make

up

about

of

the

DesignObj

class

's

extent

the

retrieval

of

each

CompositePart

instance

's

buildDate

requires

a

random

access

into

the

extent

of

the

DesignObj

class

's

extent

Graph

contrasts

the

impact

of

the

two

clustering

strategies

on

the

block

misses

incurred

by

query

The

graph

shows

that

under

conditions

of

low

selectivity

object

clustering

is

far

better

than

class

clustering

50 100 150 200

250 300 350 400

Number

of

Block

Misses

Memory

Size

in

Blocks

clustering

by

class

clustering

by

object

no-object-slicing

Figure

Query

on

Inherited

Attribute

with

Low

Selectivity

When

a

given

implementation

object

receives

a

reference

to

a

local

attribute

the

local

attribute

is

stored

in

the

receiver

and

thus

no

additional

blocks

must

be

retrieved

The

retrieval

of

an

inherited

attribute

in

the

object-slicing

architecture

also

involves

additional

accesses

to

the

receiver

's

conceptual

object

and

to

the

implementation

object

that

stores

the

inherited

attribute

value

If

an

object-clustering

strategy

is

in

effect

then

both

implementation

objects

will

be

stored

in

the

same

block

as

the

conceptual

object

and

thus

all

three

objects

can

be

accessed

with

the

retrieval

of

a

single

block

If

however

a

class-clustering

strategy

is

being

used

then

the

reference

to

the

implementation

object

will

require

a

random

access

to

retrieve

the

receiver

's

conceptual

object

from

the

store

of

conceptual

objects

as

well

as

a

random

access

to

retrieve

the

appropriate

implementation

object

from

the

extent

of

whichever

of

the

receiver

's

superclasses

defines

the

referenced

property

Thus

under

object

clustering

the

number

of

blocks

that

must

be

randomly

accessed

is

not

affected

by

the

size

of

the

extent

of

the

DesignObject

superclass

because

the

DesignObject

implementation

objects

of

objects

belonging

to

both

the

DesignObject

and

CompositePart

classes

will

be

clustered

together

with

the

extent

of

the

CompositePart

class

However

the

class

clustering

strategy

does

not

differentiate

between

the

implementation

objects

belonging

to

different

classes

when

storing

the

implementation

objects

that

make

up

a

class

's

extent

Thus

under

class

clustering

the

DesignObject

implementation

objects

of

objects

that

belong

to

both

the

DesignObject

and

CompositePart

classes

will

be

intermingled

with

all

other

DesignObject

implementation

objects

in

the

extent

of

the

DesignObject

class

As

shown

in

Figure

the

number

of

AutomicPart

instances

CompositePart

instances

and

DesignObject

instances

are

and

respectively

Thus

under

class

clustering

the

DesignObject

class

indiscriminately

stores

the

implementation

objects

that

belong

to

DesignObject

AtomicPart

or

CompositePart

instances

Because

these

implementation

objects

are

intermixed

most

of

the

blocks

to

store

implementation

objects

of

DesignObject

could

be

brought

into

memory

in

order

to

retrieve

the

buildDate

values

of

the

CompositePart

instances

This

means

that

under

the

class

clustering

strategy

the

execution

of

query

could

require

the

retrieval

of

all

blocks

of

the

DesignObject

implementation

objects

whereas

for

object

clustering

the

query

only

needs

to

bring

the

portion

of

blocks

that

contain

the

implementation

objects

belonging

to

the

CompositePart

instances

This

difference

causes

the

performance

gap

between

class

clustering

and

object

clustering

as

shown

in

Graph

This

gap

is

quite

dramatic

and

indicates

that

if

an

application

heavily

uses

this

kind

of

queries

-LRB-

queries

on

inherited

attribute

with

low

selectively

-RRB-

object-clustering

is

superior

to

class-clustering

for

the

sake

of

average

performance

Related

Work

In

this

paper

we

identified

data

modeling

requirements

that

should

be

met

by

an

OODB

model

in

order

to

support

advanced

tools

such

as

view

mechanisms

schema

evolution

and

role

systems

Identified

features

include

multiple

classification

dynamic

reclassification

and

dynamic

restructuring

We

are

not

the

first

who

have

identified

the

utility

of

such

flexible

modeling

constructs

One

example

of

this

is

the

work

by

Scholl

et

al.

on

object-oriented

views

-LSB-

-RSB-

Other

examples

are

recently

emerging

role

modeling

approaches

-LSB-

-RSB-

In

role

modeling

systems

objects

dynamically

gain

and

lose

multiple

interfaces

-LRB-

aka

roles

-RRB-

throughout

their

lifetimes

These

roles

can

be

compared

to

the

implementation

objects

of

an

object-slicing

implementation

in

that

both

permit

objects

to

belong

to

multiple

classes

and

change

types

dynamically

In

some

sense

accessing

an

object

through

one

of

its

implementation

objects

is

like

accessing

an

object

while

it

is

playing

one

of

its

roles

In

-LSB-

-RSB-

Sciore

proposed

an

object

specialization

approach

in

which

a

real

world

entity

is

modeled

by

multiple

objects

arranged

in

an

object

hierarchy

These

object

hierarchy

objects

inherit

from

each

other

enabling

each

individual

entity

object

to

decide

its

own

inheritance

hierarchy

Although

our

implementation

objects

resemble

object

hierarchy

objects

in

that

they

inherit

from

each

other

objects

in

our

implementation

always

conform

to

the

existing

global

class

hierarchy

The

role

system

proposed

by

Gottlob

et

al.

-LSB-

-RSB-

was

implemented

using

techniques

similar

to

object-slicing

This

system

like

ours

is

implemented

in

Smalltalk

by

overriding

the

doesNotUnderstand

method

Unlike

many

role

systems

which

allow

object

hierarchies

to

exist

independently

from

class

hierarchies

-LSB-

-RSB-

objects

in

our

model

always

conform

to

the

existing

global

class

hierarchy

To

recap

if

an

object

possesses

an

implementation

object

of

a

given

class

's

type

it

must

also

possess

an

implementation

object

for

every

class

that

is

a

superclass

of

that

given

type

This

achieves

an

efficient

and

uniform

inheritance

scheme

Also

unlike

many

role

systems

in

our

implementation

conceptual

objects

can

be

associated

with

at

most

one

implementation

object

of

a

given

type

-LSB-

-RSB-

Our

proposed

object-slicing

approach

is

thus

a

compromise

between

extremely

flexible

role

models

on

the

one

side

and

rigid

class-based

data

models

on

the

other

side

In

short

variations

of

the

object-slicing

technique

have

been

repeatedly

recognized

as

a

powerful

and

flexible

method

for

extending

an

existing

OODB

system

to

support

the

identified

required

features

In

spite

of

this

work

the

object

representation

assumptions

underlying

most

OODB

systems

are

of

a

different

nature

Current

OODB

systems

allow

only

one

most-specific

type

per

object

and

the

object

type

is

determined

and

fixed

at

object-creation

time

-LSB-

-RSB-

The

Iris

functional

database

system

is

the

most

well-known

exception

to

this

i.e.

it

is

a

DBMS

system

that

supports

multiple

classification

However

IRIS

being

built

on

top

of

a

relational

engine

distributes

its

data

over

several

relational

tables

-LSB-

-RSB-

and

hence

can

support

multiple

states

per

object

There

are

however

several

significant

differences

between

our

work

and

IRIS

For

one

our

object-slicing

representation

is

built

on

top

of

a

pure

object-oriented

kernel

rather

than

a

relational

system

Consequently

our

system

supports

inheritance

of

both

instance

variable

and

methods

IRIS

however

does

not

provide

for

any

encapsulation

Instead

foreign

functions

written

in

other

programming

languages

can

be

imported

In

our

system

each

implementation

object

is

still

a

fully

functioning

object

in

the

sense

of

the

object-oriented

paradigm

and

thus

is

encapsulated

and

can

respond

to

methods

such

as

typeof

-LRB-

-RRB-

etc.

In

short

in

this

paper

we

examine

the

impact

of

an

object-oriented

realization

of

object-slicing

rather

than

a

horizontal

partitioning

type

of

an

approach

Extending

an

existing

DBMS

with

object-slicing

techniques

necessarily

involves

the

overhead

of

additional

data

structures

maintenance

costs

and

processing

time

To

our

knowledge

no

work

has

been

done

evaluating

the

costs

of

object-slicing

In

this

paper

we

address

this

issue

More

precisely

we

present

results

from

our

evaluation

of

the

performance

costs

incurred

by

object-slicing

and

examine

the

potential

of

various

clustering

techniques

to

alleviate

this

cost

Unlike

previous

work

on

the

clustering

and

partitioning

of

OODBs

-LSB-

-RSB-

our

goals

are

not

to

invent

new

clustering

strategies

to

dynamically

adapt

to

various

access

patterns

Instead

we

are

interested

in

understanding

what

the

innate

differences

are

between

the

conventional

and

the

object-slicing

representation

and

whether

the

flexibility

gained

comes

with

an

added

cost

Furthermore

previous

work

in

the

area

of

clustering

such

as

-LSB-

-RSB-

is

still

applicable

in

our

representation

model

In

fact

we

expect

that

objectslicing

is

amendable

to

horizontal

and

vertical

partitioning

techniques

since

conceptual

objects

are

already

naturally

partitioned

into

smaller

self-maintained

chunks

Conclusions

In

this

paper

we

identify

extensions

required

from

an

OODB

system

in

order

to

support

advanced

tools

such

as

view

technology

advanced

schema

evolution

support

and

role

modeling

systems

These

features

include

multiple

classification

dynamic

reclassification

and

dynamic

restructuring

While

we

are

not

the

first

to

identify

the

need

for

such

flexible

data

modeling

support

we

point

out

that

the

majority

of

currently

available

OODB

systems

do

not

provide

such

support

Instead

they

support

comparatively

poor

data

models

requiring

an

object

to

belong

to

exactly

one

most

specific

type

and

not

allowing

an

object

to

dynamically

migrate

to

new

types

over

the

lifetime

of

the

object

In

this

paper

we

describe

a

methodology

known

as

object-slicing

that

is

capable

of

extending

existing

OODB

systems

to

support

these

required

features

We

have

successfully

implemented

an

object-slicing

representational

layer

on

the

GemStone

OODBMS

system

which

while

still

providing

full

access

to

all

GemStone

DBMS

functions

now

also

offers

these

flexible

modeling

features

Our

experience

with

building

this

object-slicing

paradigm

should

be

valuable

to

other

researchers

or

OODB

system

builders

that

are

exploring

the

extension

of

OODB

systems

with

more

flexible

constructions

Extending

an

existing

DBMS

with

object-slicing

techniques

necessarily

involves

the

overhead

of

additional

data

structures

maintenance

costs

and

processing

time

However

although

object-slicing

is

a

known

technique

that

is

being

utilized

for

view

systems

-LSB-

-RSB-

schema

evolution

-LSB-

-RSB-

and

role

systems

-LSB-

-RSB-

to

our

knowledge

no

work

has

been

done

evaluating

the

costs

of

object-slicing

In

this

paper

we

therefore

provide

an

in

depth

evaluation

of

the

object-slicing

technique

We

describe

our

experimental

results

evaluating

the

relative

costs

and

benefits

of

adopting

the

objectslicing

techniques

First

we

compare

object-slicing

with

the

conventional

intersection

class

alternative

by

contrasting

their

capabilities

We

back

up

our

experimental

results

with

an

analytical

storage

cost

model

of

our

object-slicing

implementation

which

confirms

the

expected

improvement

of

performance

for

access

of

local

attributes

and

the

additional

cost

associated

with

accessing

inherited

objects

with

low

selectivity

As

clustering

is

critical

to

optimizing

queries

on

such

models

we

present

results

gathered

using

benchmarks

queries

to

evaluate

the

object-slicing

model

using

two

of

the

more

standard

clustering

strategies

In

particular

we

report

our

experimental

results

of

both

class-clustering

and

object-clustering

strategies

Based

on

these

results

we

conclude

that

clustering

can

be

utilized

to

effectively

reduce

the

overhead

associated

with

objectslicing

and

that

as

in

a

conventional

architecture

various

types

of

access

patterns

can

best

be

optimized

by

providing

distinct

types

of

clustering

techniques

References

-LSB-

-RSB-

S.

Abiteboul

and

A.

Bonner

Objects

and

views

SIGMOD

pages

-LCB-

-LSB-

-RSB-

M.

Atkinson

F.

Bancilhon

D.

DeWitt

K.

Dittrich

D.

Maier

and

S.

Zdonic

The

object-oriented

database

system

manifesto

In

F.

Bancilhon

C.

Delobel

and

P.

Kanellakis

editors

Building

an

ObjectOriented

Database

System

The

Story

of

chapter

pages

-LCB-

Morgan

Kaufmann

Pub.

-LSB-

-RSB-

J.

Banerjee

H.

Chou

J.

F.

Garza

W.

Kim

D.

Woelk

N.

Ballou

and

H.

J.

Kim

Data

model

issues

for

object-oriented

applications

In

S.

B.

Zdonik

and

D.

Maier

editors

Readings

in

Object-Oriented

Database

Systems

pages

-LCB-

Morgan

Kaufmann

Pub.

-LSB-

-RSB-

E.

Bertino

A

view

mechanism

for

object-oriented

databases

In

International

Conference

on

Extending

Database

Technology

pages

-LCB-

March

-LSB-

-RSB-

P.

Butterworth

A.

Otis

and

J.

Stein

The

gemstone

object

database

management

system

Communications

of

the

ACM

-LRB-

-RRB-

-LCB-

October

-LSB-

-RSB-

M.

J.

Carey

D.

J.

DeWitt

and

J.

F.

Naughton

The

benchmark

SIGMOD

-LSB-

-RSB-

C.

Souza

dos

Santos

S.

Abiteboul

and

C.

Delobel

Virtual

schemas

and

bases

International

Conference

on

Extending

Database

Technology

-LRB-

EDBT

-RRB-

-LSB-

-RSB-

D.H.

Fishman

Iris

An

object

oriented

database

management

system

In

ACM

Transactions

on

Office

Information

Systems

volume

pages

-LCB-

January

-LSB-

-RSB-

C.

Gerlhof

A.

Kemper

C.

Kilger

and

G.

Moerkotte

Partition-based

clustering

in

object

bases

From

theory

to

practice

In

Foundations

of

Data

Organization

and

Algorithms

International

Conference

pages

-LCB-

October

-LSB-

-RSB-

G.

Gottlob

P.

Paolini

and

R.

Zicari

Properties

and

Update

Semantics

of

Consistent

Views

ACM

Trans

on

Database

Systems

vol

-LRB-

-RRB-

-LCB-

December

-LSB-

-RSB-

G.

Gottlob

M.

Schrefl

and

B.

Rock

Extending

object-oriented

systems

with

roles

manuscript

-LSB-

-RSB-

W.

Kim

J.

F.

Garza

N.

Ballou

and

D.

Woelk

Architecture

of

the

orion

next-generation

database

system

IEEE

Transactions

on

Knowledge

and

Data

Engineering

-LRB-

-RRB-

March

-LSB-

-RSB-

H.

A.

Kuno

and

E.

A.

Rundensteiner

Implementation

experience

with

building

an

object-oriented

view

management

system

Technical

Report

University

of

Michigan

Ann

Arbor

August

-LSB-

-RSB-

H.

A.

Kuno

and

E.

A.

Rundensteiner

Materialized

object-oriented

views

in

MultiView

In

ACM

Research

Issues

in

Data

Engineering

March

-LSB-

-RSB-

C.

Lecluse

P.

Richard

and

F.

Velez

an

object-oriented

data

model

SIGMOD

pages

-LCB-

-LSB-

-RSB-

J.

Martin

and

J.

Odell

Object-Oriented

Analysis

and

Design

Prentice-Hall

Inc.

-LSB-

-RSB-

S.

Navathe

S.

Ceri

G.

Wiederhold

and

J.

Dou

Vertical

partitioning

algorithms

for

database

design

ACM

Transactions

on

Database

Systems

-LRB-

-RRB-

-LCB-

December

-LSB-

-RSB-

Technology

Views

User

Manual

version

edition

December

-LSB-

-RSB-

M.

P.

Papazoglou

Roles

A

methodology

for

representing

multifaceted

objects

In

International

Conference

on

Database

and

Expert

Systems

Applications

pages

-LCB-

Springer-Verlag

-LSB-

-RSB-

Y.

G.

Ra

H.

A.

Kuno

and

E.

A.

Rundensteiner

A

flexible

object-oriented

database

model

and

implementation

for

capacity-augmenting

views

Technical

Report

University

of

Michigan

-LSB-

-RSB-

Y.

G.

Ra

and

E.

A.

Rundensteiner

A

transparent

object-oriented

schema

change

approach

using

view

schema

evolution

In

IEEE

International

Conference

on

Data

Engineering

March

-LSB-

-RSB-

E.

A.

Rundensteiner

MultiView

A

methodology

for

supporting

multiple

views

in

object-oriented

databases

In

VLDB

Conference

pages

-LCB-

-LSB-

-RSB-

M.

H.

Scholl

C.

Laasch

and

M.

Tresch

Updatable

views

in

object-oriented

databases

In

Proceedings

of

the

Second

DOOD

Conference

December

-LSB-

-RSB-

E.

Sciore

Object

specialization

ACM

Transactions

on

Information

Systems

pages

-LCB-

April

-LSB-

-RSB-

M.

Tresch

and

M.

H.

Scholl

Schema

Transformation

without

Database

Reorganization

In

SIGMOD

RECORD

pages

-LCB-

-LSB-

-RSB-

M.

M.

Tsangaris

and

J.

F.

Naughton

A

stochastic

approach

to

clustering

in

object

bases

SIGMOD

pages

-LCB-

-LSB-

-RSB-

M.

M.

Tsangaris

and

J.

F.

Naughton

On

the

performance

of

object

clustering

techniques

SIGMOD

pages

-LCB-

multiple classification
object clustering

benchmarking
object-oriented database models
performance evaluation