CS

Indexing

for

Data

Models

with

Constraints

and

Classes

Paris

Kanellakis

Sridhar

Ramaswamy

Darren

Vengroff

Jeffrey

Scott

Vitter

Department

of

Computer

Science

Duke

University

Durham

North

Carolina

June

Indexing

for

Data

Models

with

Constraints

and

Classes

Paris

Kanellakis

Sridhar

Ramaswamyy

Darren

Vengroffz

Jeffrey

Vitterx

Abstract

We

examine

I/O-efficient

data

structures

that

provide

indexing

support

for

new

data

models

The

database

languages

of

these

models

include

concepts

from

constraint

programming

-LRB-

e.g.

relational

tuples

are

generalized

to

conjunctions

of

constraints

-RRB-

and

from

object-oriented

programming

-LRB-

e.g.

objects

are

organized

in

class

hierarchies

-RRB-

Let

n

be

the

size

of

the

database

c

the

number

of

classes

B

the

page

size

on

secondary

storage

and

t

the

size

of

the

output

of

a

query

-LRB-

-RRB-

Indexing

by

one

attribute

in

many

constraint

data

models

is

equivalent

to

external

dynamic

interval

management

which

is

a

special

case

of

external

dynamic

range

searching

We

present

a

semi-dynamic

data

structure

for

this

problem

that

has

worst-case

space

O

-LRB-

n

B

-RRB-

pages

query

I/O

time

O

-LRB-

logB

n

t

B

-RRB-

and

O

-LRB-

logB

n

-LRB-

logB

n

-RRB-

B

-RRB-

amortized

insert

I/O

time

Note

that

for

the

static

version

of

this

problem

this

is

the

first

worst-case

optimal

solution

-LRB-

-RRB-

Indexing

by

one

attribute

and

by

class

name

in

an

object-oriented

model

where

objects

are

organized

as

a

forest

hierarchy

of

classes

is

also

a

special

case

of

external

dynamic

range

searching

Based

on

this

observation

we

first

identify

a

simple

algorithm

with

good

worst-case

performance

query

I/O

time

O

-LRB-

c

logB

n

t

B

-RRB-

update

I/O

time

O

-LRB-

c

logB

n

-RRB-

and

space

O

-LRB-

-LRB-

n

B

-RRB-

c

-RRB-

pages

for

the

class

indexing

problem

Using

the

forest

structure

of

the

class

hierarchy

and

techniques

from

the

constraint

indexing

problem

we

improve

its

query

I/O

time

to

O

-LRB-

logB

n

t

B

B

-RRB-

Introduction

Motivation

The

successful

realization

of

any

data

model

requires

supporting

its

language

features

with

efficient

secondary

storage

manipulation

For

example

the

relational

data

model

-LSB-

-RSB-

includes

declarative

Address

Dept.

of

Computer

Science

Brown

University

Box

Providence

RI

Email

pck@cs.brown.edu

Research

supported

by

ONR

Contract

-LCB-

-LCB-

J

-LCB-

ARPA

Order

yAddress

Dept.

of

Computer

Science

Brown

University

Box

Providence

RI

Email

sr@cs.brown.edu

Research

supported

by

ONR

Contract

-LCB-

-LCB-

J

-LCB-

ARPA

Order

zAddress

Dept.

of

Computer

Science

Duke

University

Box

Durham

NC

-LCB-

Email

dev@cs.duke.edu

Also

affiliated

with

Brown

University

Support

was

provided

in

part

by

National

Science

Foundation

research

grant

CCR

-LCB-

and

by

Army

Research

Office

grant

-LCB-

-LCB-

G

-LCB-

xAddress

Dept.

of

Computer

Science

Duke

University

Box

Durham

NC

-LCB-

Email

jsv@cs.duke.edu

Support

was

provided

in

part

by

National

Science

Foundation

research

grant

CCR

-LCB-

and

by

Army

Research

Office

grant

-LCB-

-LCB-

G

-LCB-

programming

in

the

form

of

relational

calculus

and

algebra

and

expresses

queries

of

low

data

complexity

because

every

fixed

relational

calculus

query

is

evaluable

in

LOGSPACE

and

PTIME

in

the

size

of

the

input

database

More

importantly

these

language

features

can

be

supported

by

data

structures

for

searching

and

updating

that

make

optimal

use

of

secondary

storage

B

trees

and

their

variants

B

trees

-LSB-

-RSB-

are

examples

of

such

data

structures

They

have

been

an

unqualified

success

in

supporting

external

dynamic

range

searching

in

relational

database

systems

The

general

data

structure

problem

underlying

efficient

secondary

storage

manipulation

for

many

data

models

is

external

dynamic

k-dimensional

range

searching

The

problem

of

k-dimensional

range

searching

in

both

main

memory

and

secondary

memory

has

been

the

subject

of

much

research

To

date

solutions

approaching

the

worst-case

performance

of

B-trees

for

searching

have

not

been

found

for

even

the

simplest

cases

of

external

k-dimensional

range

searching

In

this

paper

we

examine

new

I/O-efficient

data

structures

for

special

cases

of

the

general

problem

of

k-dimensional

range

searching

These

special

cases

are

important

for

supporting

new

language

features

such

as

constraint

query

languages

-LSB-

-RSB-

and

class

hierarchies

in

object-oriented

databases

-LSB-

-RSB-

We

make

the

standard

assumption

that

each

secondary

memory

access

transmits

one

page

or

B

units

of

data

and

we

count

this

as

one

I/O

-LRB-

We

will

use

the

terms

page

and

disk

block

interchangeably

as

also

the

terms

in-core

and

main

memory

-RRB-

We

also

assume

that

at

least

O

-LRB-

-RRB-

words

of

main

memory

are

available

This

is

not

an

assumption

that

is

normally

made

but

it

is

entirely

reasonable

given

that

B

is

typically

on

the

order

of

to

and

today

's

machines

have

main

memories

of

many

megabytes

Let

R

be

a

relation

with

n

tuples

and

let

the

output

to

a

query

on

R

have

t

tuples

We

will

also

use

n

for

the

number

of

objects

in

a

class

hierarchy

with

c

classes

and

t

for

the

output

size

of

a

query

on

this

hierarchy

The

performance

of

our

algorithms

will

be

measured

in

terms

of

the

number

of

I/O

's

that

they

need

for

querying

and

updating

and

the

number

of

disk

blocks

they

require

for

storage

The

I/O

bounds

will

be

expressed

in

terms

of

n

c

t

and

B

i.e.

all

constants

will

be

independent

of

these

four

parameters

-LRB-

For

a

survey

of

state

of

the

art

I/O

complexity

see

-LSB-

-RSB-

-RRB-

We

will

first

review

B

tree

performance

since

we

will

use

that

as

our

point

of

reference

A

B

tree

on

attribute

x

of

the

n-tuple

relation

R

uses

O

-LRB-

n

B

-RRB-

pages

of

secondary

storage

The

following

operations

define

the

problem

of

external

dynamic

range

searching

on

relational

database

attribute

x

with

the

corresponding

I/O

time

performance

bounds

using

the

B

tree

on

x

-LRB-

-RRB-

Find

all

tuples

such

that

for

their

x

attribute

-LRB-

x

-RRB-

If

the

output

size

is

t

tuples

then

this

range

searching

is

in

worst-case

O

-LRB-

logB

n

t

B

-RRB-

secondary

memory

accesses

If

and

x

is

a

key

i.e.

it

uniquely

identifies

the

tuple

then

this

is

key-based

searching

-LRB-

-RRB-

Insert

or

delete

a

given

tuple

are

in

worst-case

O

-LRB-

logB

n

-RRB-

secondary

memory

accesses

The

problem

of

external

dynamic

k-dimensional

range

searching

on

relational

database

attributes

xk

generalizes

range

searching

to

k

attributes

with

range

searching

on

kdimensional

intervals

If

there

are

no

deletes

we

say

that

the

problem

is

semi-dynamic

If

there

are

no

inserts

or

deletes

we

say

that

the

problem

is

static

In

this

paper

we

will

be

concerned

with

external

range

searching

dynamic

-LRB-

Section

-RRB-

semi-dynamic

and

static

-LRB-

Sections

and

-RRB-

We

are

concerned

with

algorithms

which

have

provably

good

worst-case

I/O

bounds

In

order

to

put

our

contributions

into

perspective

we

point

out

-LRB-

from

the

literature

by

us

ing

standard

mappings

of

in-core

data

structures

to

external

ones

-RRB-

that

external

dynamic

dimensional

range

searching

and

thus

the

problems

examined

here

can

be

solved

using

worst-case

O

-LRB-

-LRB-

n

B

-RRB-

n

-RRB-

pages

static

query

I/O

time

O

-LRB-

n

t

B

-RRB-

using

fractional

cascading

dynamic

query

I/O

time

O

-LRB-

n

logB

n

t

B

-RRB-

and

amortized

update

I/O

time

O

-LRB-

n

logB

n

-RRB-

-LRB-

Note

that

n

-LRB-

B

-RRB-

-LRB-

logB

n

-RRB-

is

asymptotically

much

larger

than

logB

n.

-RRB-

Based

on

the

special

structure

of

the

indexing

problems

of

interest

we

improve

on

the

above

bounds

Contributions

to

Indexing

Constraints

Constraint

programming

paradigms

are

inherently

declarative

since

they

describe

computations

by

specifying

how

these

computations

are

constrained

A

general

constraint

programming

framework

for

database

query

languages

called

Constraint

Query

Languages

or

CQLs

was

presented

in

-LSB-

-RSB-

This

framework

adapts

ideas

of

Constraint

Logic

Programming

e.g.

from

-LSB-

-RSB-

to

databases

provides

a

calculus

and

algebra

guarantees

low

data

complexity

and

is

applicable

to

managing

spatial

data

It

is

of

course

important

to

index

constraints

and

thus

support

these

new

language

features

with

efficient

secondary

storage

manipulation

-LRB-

see

Section

for

a

detailed

exposition

of

the

problem

-RRB-

Fortunately

it

is

possible

to

do

this

by

combining

CQLs

with

existing

range

searching

data

structures

-LSB-

-RSB-

The

basis

of

this

observation

is

a

reduction

of

indexing

constraints

for

a

fairly

general

class

of

constraints

to

dynamic

interval

management

on

secondary

storage

Given

a

set

of

input

intervals

dynamic

interval

management

involves

being

able

to

perform

the

following

operations

efficiently

-LRB-

-RRB-

Answer

interval

intersection

queries

That

is

to

report

all

the

input

intervals

which

intersect

a

query

interval

-LRB-

-RRB-

Delete

or

insert

intervals

from

the

interval

collection

Dynamic

interval

management

can

be

shown

to

be

a

special

case

of

external

dynamic

range

searching

Dynamic

interval

management

is

interesting

because

it

can

be

solved

optimally

in-core

using

the

Priority

Search

Tree

of

Mccreight

-LSB-

-RSB-

in

query

time

O

-LRB-

n

t

-RRB-

update

time

O

-LRB-

n

-RRB-

and

space

O

-LRB-

n

-RRB-

which

are

all

optimal

Achieving

analogous

I/O

bounds

is

much

harder

In

Section

we

reduce

indexing

constraints

to

a

special

case

of

external

dynamic

range

searching

that

involves

diagonal

corner

queries

and

updates

A

diagonal

corner

query

is

a

two

sided

range

query

whose

corner

must

lie

on

the

line

x

y

and

whose

query

region

is

the

quarter

plane

above

and

to

the

left

of

the

corner

-LRB-

See

figure

-RRB-

In

Section

we

propose

a

new

data

structure

which

we

call

the

metablock

tree

for

this

problem

Our

data

structure

has

optimal

worst-case

space

O

-LRB-

n

B

-RRB-

pages

optimal

query

I/O

time

O

-LRB-

logB

n

t

B

-RRB-

and

has

O

-LRB-

logB

n

-LRB-

logB

n

-RRB-

B

-RRB-

amortized

insert

I/O

time

This

performance

is

optimal

for

the

static

case

and

nearly

optimal

for

the

semi-dynamic

case

where

only

insertions

are

allowed

-LRB-

modulo

amortization

-RRB-

Contributions

to

Indexing

Classes

Indexing

by

one

attribute

and

by

class

name

in

an

object-oriented

model

where

objects

are

organized

as

a

static

forest

hierarchy

of

classes

is

also

a

special

case

of

external

dynamic

range

searching

Together

with

the

different

problem

of

indexing

nested

objects

as

in

-LSB-

-RSB-

it

constitutes

the

basis

for

indexing

in

object-oriented

databases

Indexing

classes

has

been

examined

Diagonal

corner

queryDiagonal

corner

query

query

general

query

Figure

Diagonal

corner

queries

and

general

range

queries

in

-LSB-

-RSB-

and

more

recently

in

-LSB-

-RSB-

but

the

solutions

offered

there

are

largely

heuristic

with

poor

worst-case

performance

In

Section

we

reduce

indexing

classes

to

a

special

case

of

external

dynamic

range

searching

called

searching

range

queries

are

a

special

case

of

range

queries

In

range

queries

one

of

the

four

sides

defining

the

query

rectangle

is

always

one

of

the

coordinate

axes

or

at

We

also

assume

that

the

class-subclass

relationship

is

static

although

objects

can

be

inserted

or

deleted

from

classes

Under

this

reasonable

assumption

for

a

class

hierarchy

with

c

classes

having

a

total

of

n

objects

we

identify

a

simple

algorithm

with

worst-case

space

O

-LRB-

-LRB-

n

B

-RRB-

c

-RRB-

pages

query

I/O

time

O

-LRB-

c

logB

n

t

B

-RRB-

and

update

I/O

time

O

-LRB-

c

logB

n

-RRB-

Even

with

the

additional

assumption

of

a

static

class-subclass

relationship

the

problem

is

a

nontrivial

case

of

range

searching

We

show

in

Section

that

it

is

impossible

to

achieve

optimal

query

time

for

this

problem

-LRB-

O

-LRB-

logB

n

t

B

-RRB-

disk

I/O

's

-RRB-

with

only

one

copy

of

each

object

in

secondary

storage

-LRB-

For

lower

bounds

on

range

searching

in

main

memory

see

-LSB-

-RSB-

and

-LSB-

-RSB-

-RRB-

In

Section

analyzing

the

hierarchy

using

the

hierarchical

decomposition

of

-LSB-

-RSB-

and

using

techniques

from

the

constraint

indexing

problem

we

improve

query

I/O

time

to

O

-LRB-

logB

n

t

B

B

-RRB-

using

space

O

-LRB-

-LRB-

n

B

-RRB-

c

-RRB-

pages

Amortized

update

I/O

time

for

the

semi-dynamic

problem

with

inserts

is

O

-LRB-

c

-LRB-

logB

n

-LRB-

logB

n

-RRB-

B

-RRB-

-RRB-

Related

Research

A

large

literature

exists

for

in-core

algorithms

for

range

searching

The

range

tree

-LSB-

-RSB-

can

be

used

to

solve

the

problem

in

O

-LRB-

n

n

-RRB-

space

and

static

worst-case

query

time

O

-LRB-

n

t

-RRB-

By

using

fractional

cascading

we

can

achieve

a

worst-case

dynamic

query

time

O

-LRB-

n

n

t

-RRB-

and

update

time

O

-LRB-

n

n

-RRB-

using

the

same

space

We

refer

the

reader

to

-LSB-

-RSB-

for

a

detailed

survey

of

the

topic

The

ideal

worst-case

I/O

bounds

would

involve

making

all

the

above

logarithms

have

base

B

and

compacting

the

output

term

to

t

B

any

other

improvements

would

of

course

imply

improvements

to

the

in-core

bounds

Unfortunately

the

various

in-core

algorithms

do

not

map

to

secondary

storage

in

as

smooth

a

fashion

as

balanced

binary

trees

map

to

B

trees

For

example

-LSB-

-RSB-

examine

mappings

which

maintain

the

logarithmic

overheads

and

make

the

logarithms

base

B

however

their

algorithms

do

not

compact

the

t-sized

output

on

t

B

pages

that

diagonal

corner

queries

are

a

special

case

of

queries

and

queries

are

a

special

case

of

queries

See

Figure

The

practical

need

for

general

I/O

support

has

led

to

the

development

of

a

large

number

of

data

structures

for

external

k-dimensional

searching

These

data

structures

do

not

have

good

theoretical

worst-case

bounds

but

have

good

average-case

behavior

for

common

spatial

database

problems

Examples

are

the

grid-file

various

quad-trees

z-orders

and

other

space

filling

curves

k-d-B-trees

hB-trees

cell-trees

and

various

R-trees

For

these

external

data

structures

there

has

been

a

lot

of

experimentation

but

relatively

little

algorithmic

analysis

Their

average-case

performance

-LRB-

e.g.

some

achieve

the

desirable

static

query

I/O

time

of

O

-LRB-

logB

n

t

B

-RRB-

on

average

inputs

-RRB-

is

heuristic

and

usually

validated

through

experimentation

Moreover

their

worst-case

performance

is

much

worse

than

the

optimal

bounds

achievable

for

dynamic

external

range

searching

using

B

trees

We

present

here

a

brief

survey

of

general

purpose

data

structures

to

solve

external

range

searching

General

purpose

external

k-dimensional

range

searching

techniques

can

be

broadly

divided

into

two

categories

those

that

organize

the

embedding

space

from

which

the

input

data

is

drawn

and

those

that

organize

the

input

data

We

will

first

consider

data

structures

that

organize

the

embedding

space

with

reference

to

our

problem

Quad

trees

-LSB-

-RSB-

were

designed

to

organize

data

They

work

by

recursively

subdividing

each

region

into

four

equal

pieces

until

the

number

of

points

in

each

region

fits

into

a

disk

block

Because

they

do

not

adapt

to

the

input

data

they

can

have

very

bad

worst-case

times

The

grid

file

-LSB-

-RSB-

was

proposed

as

a

data

structure

that

treats

all

dimensions

symmetrically

unlike

many

other

data

structures

like

the

inverted

file

which

distinguish

between

primary

and

secondary

keys

The

grid

file

works

by

dividing

each

dimension

into

ranges

and

maintaining

a

grid

directory

that

provides

a

mapping

between

regions

in

the

search

space

and

disk

blocks

The

paper

-LSB-

-RSB-

does

not

provide

analysis

for

worst-case

query

times

They

do

mention

that

range

queries

become

very

efficient

when

queries

return

many

records

If

we

assume

a

uniform

of

points

-LRB-

with

a

point

on

each

location

with

integral

x

and

y

coordinates

-RRB-

as

input

the

grid

file

would

produce

regions

which

are

of

size

O

-LRB-

pB

-RRB-

O

-LRB-

pB

-RRB-

The

time

to

report

answers

to

a

range

query

would

then

be

-LRB-

in

the

worst-case

-RRB-

O

-LRB-

t

pB

-RRB-

where

t

is

the

number

of

points

in

the

query

result

This

is

higher

than

the

optimal

time

of

O

-LRB-

t

B

-RRB-

In

fact

it

turns

out

that

most

data

structures

in

the

literature

fail

to

give

optimal

performance

for

this

very

simple

example

The

second

class

of

general

purpose

external

k-dimensional

range

searching

data

structures

that

have

been

proposed

for

multi-attribute

indexing

are

based

on

the

principle

of

building

a

search

structure

based

on

the

recursive

decomposition

of

input

data

Many

of

them

are

based

on

a

B-tree-like

organization

We

will

consider

several

of

them

with

reference

to

our

problems

Two

related

data

structures

that

have

been

proposed

for

multi-attribute

indexing

are

the

k-dB-tree

-LSB-

-RSB-

and

the

hB-tree

-LSB-

-RSB-

k-d-B-trees

combine

properties

of

balanced

k-d-trees

in

a

B-tree-like

organization

In

the

dimensional

case

-LRB-

these

ideas

generalize

readily

to

higher

dimensions

-RRB-

the

k-d-B-tree

works

by

subdividing

space

into

rectangular

regions

Such

subdivisions

are

stored

in

the

interior

nodes

of

the

k-d-B-tree

If

a

subdivision

has

more

points

than

can

be

stored

in

a

disk

block

further

subdivision

occurs

until

each

region

in

the

lowest

level

of

the

tree

contains

no

more

points

than

can

be

stored

in

a

disk

block

Insertion

and

deletion

algorithms

for

the

k-d-B-tree

are

also

outlined

in

-LSB-

-RSB-

This

work

does

not

offer

any

worst-case

analysis

for

range

search

As

mentioned

before

the

k-d-B-tree

works

by

subdividing

space

into

rectangular

regions

With

a

uniform

grid

of

points

as

input

we

would

read

O

-LRB-

t

pB

-RRB-

disk

blocks

to

report

t

points

on

a

straight

line

The

hB-tree

is

based

on

the

k-d-B-tree

Instead

of

organizing

space

as

rectangles

they

organize

space

into

rectangles

from

which

-LRB-

possibly

-RRB-

other

rectangles

have

been

removed

This

helps

bring

down

the

cost

of

managing

insertions

and

deletions

This

paper

also

does

not

provide

a

formal

analysis

of

the

cost

of

range

searching

Although

range

searching

in

hB-trees

is

similar

to

range

searching

in

B-trees

the

crucial

difference

is

that

with

B-trees

it

is

possible

to

totally

order

data

This

is

because

B-trees

index

data

along

only

one

attribute

In

fact

almost

all

implementations

of

B-trees

recognize

this

and

keep

data

only

in

their

leaves

and

chain

the

leaves

from

left

to

right

-LRB-

Such

B-trees

are

called

B

trees

-RRB-

This

makes

range

searching

extremely

simple

and

efficient

In

order

to

find

elements

in

a

range

-LSB-

a

b

-RSB-

we

locate

a

in

the

B

tree

and

follows

pointers

to

the

right

until

the

value

b

is

crossed

Such

a

total

ordering

is

not

possible

for

k-dimensional

data

The

problem

that

we

had

with

k-d-B-trees

with

respect

to

the

question

at

hand

remains

Given

a

uniform

grid

hB-trees

still

produce

rectangles

of

size

O

-LRB-

pB

-RRB-

O

-LRB-

pB

-RRB-

and

range

searching

is

inefficient

That

is

we

would

read

O

-LRB-

t

pB

-RRB-

disk

blocks

to

report

t

points

on

a

straight

line

Several

data

structures

have

been

proposed

in

the

literature

to

handle

region

data

These

include

the

R-tree

-LSB-

-RSB-

the

R

tree

-LSB-

-RSB-

the

cell

tree

-LSB-

-RSB-

and

many

others

These

data

structures

are

not

directly

applicable

to

point

data

However

they

can

deal

with

range

data

and

hence

are

relevant

to

our

problem

All

of

them

are

based

on

the

recursive

decomposition

of

space

using

heuristics

and

can

not

offer

the

worst-case

guarantees

in

space

and

time

that

we

seek

An

interesting

idea

based

on

the

use

of

space-filling

curves

is

proposed

in

-LSB-

-RSB-

This

paper

identifies

a

space-filling

curve

to

order

points

in

k-dimensional

space

This

curve

has

the

desirable

property

that

points

that

are

close

by

in

the

input

will

with

high

probability

be

close

by

in

the

resulting

ordering

This

helps

in

making

range

searching

efficient

because

it

is

desirable

to

keep

nearby

points

in

the

same

disk

block

This

paper

also

does

not

offer

any

worst-case

analysis

for

range

searching

Specifically

this

method

will

not

have

optimal

reporting

time

with

our

standard

case

i.e.

the

uniform

grid

of

points

Dynamic

interval

management

has

been

examined

extensively

in

the

literature

-LRB-

see

-LSB-

-RSB-

-RRB-

As

mentioned

before

the

best

in-core

bounds

have

been

achieved

using

the

priority

search

tree

of

-LSB-

-RSB-

yielding

O

-LRB-

n

-RRB-

space

dynamic

query

time

O

-LRB-

n

t

-RRB-

and

update

time

O

-LRB-

n

-RRB-

which

are

all

optimal

Other

data

structures

like

the

Interval

Tree

-LSB-

-RSB-

and

Segment

Tree

-LSB-

-RSB-

can

also

solve

the

interval

management

problem

optimally

in-core

with

respect

to

the

query

time

Among

these

the

priority

search

tree

does

the

best

because

it

solves

the

interval

management

problem

in

optimal

time

and

space

and

provides

an

optimal

worst-case

update

time

as

well

There

have

been

several

pieces

of

work

done

by

researchers

to

implement

these

data

structures

in

secondary

memory

These

works

include

-LSB-

-RSB-

-LSB-

-RSB-

-LSB-

-RSB-

-LSB-

-RSB-

contains

a

claimed

optimal

solution

for

implementing

static

priority

search

trees

in

secondary

memory

Unfortunately

the

-LSB-

-RSB-

static

solution

has

static

query

time

O

-LRB-

n

t

B

-RRB-

instead

of

O

-LRB-

logB

n

t

B

-RRB-

and

the

claimed

optimal

solution

is

incorrect

of

the

other

approaches

solve

the

problem

of

interval

management

in

secondary

memory

in

the

optimal

time

of

O

-LRB-

logB

n

t

B

-RRB-

either

Overview

To

summarize

we

present

I/O-efficient

data

structures

with

provably

good

worst

case

bounds

that

provide

indexing

support

for

new

data

models

Section

explains

the

constraint

data

model

in

detail

and

shows

that

indexing

constraints

can

be

reduced

to

dynamic

interval

management

in

secondary

storage

which

in

turn

reduces

to

answering

diagonal

corner

queries

In

Section

we

propose

a

new

data

structure

optimal

for

the

static

case

for

this

problem

Section

discusses

the

problem

of

indexing

classes

in

more

detail

and

presents

a

simple

algorithm

for

this

problem

with

good

worst-case

bounds

We

improve

on

these

bounds

in

Section

using

the

techniques

developed

for

indexing

constraints

Section

has

the

conclusions

and

open

problems

The

Problems

and

Initial

Approaches

Indexing

Constraints

To

illustrate

indexing

constraints

in

CQLs

consider

the

domain

of

rational

numbers

and

a

language

whose

syntax

consists

of

the

theory

of

rational

order

with

constants

the

relational

calculus

-LRB-

See

-LSB-

-RSB-

for

details

-RRB-

In

this

context

a

generalized

k-tuple

is

a

quantifier-free

conjunction

of

constraints

on

k

variables

which

range

over

the

domain

-LRB-

rational

numbers

-RRB-

For

example

in

the

relational

database

model

R

-LRB-

-RRB-

is

a

tuple

of

arity

It

can

be

thought

of

as

a

single

point

in

space

and

also

as

R

-LRB-

x

y

-RRB-

with

x

and

y

where

x

y

range

over

some

finite

domain

In

our

framework

R

-LRB-

x

y

-RRB-

with

-LRB-

x

y

x

-RRB-

is

a

generalized

tuple

of

arity

where

x

y

range

over

the

rational

numbers

Hence

a

generalized

tuple

of

arity

k

is

a

finite

representation

of

a

possibly

infinite

set

of

tuples

of

arity

k

A

generalized

relation

of

arity

k

is

a

finite

set

of

generalized

k-tuples

with

each

k-tuple

over

the

same

variables

It

is

a

disjunction

of

conjunctions

-LRB-

i.e.

in

disjunctive

normal

form

DNF

-RRB-

of

constraints

which

uses

at

most

k

variables

ranging

over

domain

D

A

generalized

database

is

a

finite

set

of

generalized

relations

Each

generalized

relation

of

arity

k

is

a

quantifier-free

DNF

formula

of

the

logical

theory

of

constraints

used

It

contains

at

most

k

distinct

variables

and

describes

a

possibly

infinite

set

of

arity

k

tuples

-LRB-

or

points

in

k-dimensional

space

Dk

-RRB-

The

syntax

of

a

CQL

is

the

union

of

an

existing

database

query

language

and

a

decidable

logical

theory

-LRB-

theory

of

rational

order

the

relational

calculus

here

-RRB-

The

semantics

of

the

CQL

is

based

on

that

of

the

decidable

logical

theory

by

interpreting

database

atoms

as

shorthands

for

formulas

of

the

theory

For

each

input

generalized

database

the

queries

can

be

evaluated

in

closed

form

bottom-up

and

efficiently

in

the

input

size

Let

us

motivate

this

theory

with

an

example

Example

The

database

consists

of

a

set

of

rectangles

in

the

plane

and

we

want

to

compute

all

pairs

of

distinct

intersecting

rectangles

-LRB-

See

Figure

-RRB-

This

query

is

expressible

in

a

relational

data

model

that

has

a

interpreted

predicate

One

possibility

is

to

store

the

data

in

a

relation

named

R

This

relation

will

contain

tuples

of

the

form

-LRB-

n

a

b

c

d

-RRB-

and

such

a

tuple

will

mean

that

n

is

the

name

of

the

rectangle

with

corners

at

r

-LRB-

-RRB-

r

-LRB-

-RRB-

r

-LRB-

-RRB-

r

-LRB-

-RRB-

r

-LRB-

-RRB-

r

-LRB-

-RRB-

r

-LRB-

-RRB-

r

-LRB-

-RRB-

r

-LRB-

-RRB-

r

-LRB-

-RRB-

r

-LRB-

-RRB-

r

-LRB-

-RRB-

r

-LRB-

-RRB-

r

-LRB-

-RRB-

r

-LRB-

-RRB-

r

-LRB-

-RRB-

Figure

Rectangle

intersection

-LRB-

a

b

-RRB-

-LRB-

a

d

-RRB-

-LRB-

c

b

-RRB-

and

-LRB-

c

d

-RRB-

We

can

express

the

intersection

query

as

f

-LRB-

-RRB-

j

-LRB-

-RRB-

-LRB-

R

-LRB-

-RRB-

R

-LRB-

-RRB-

-LRB-

y

-RRB-

-LRB-

x

y

x

y

-RRB-

-RRB-

g

To

see

that

this

query

expresses

rectangle

intersection

note

the

following

the

two

rectangles

and

share

a

point

if

and

only

if

they

share

a

point

whose

coordinates

belong

to

the

set

This

can

be

shown

by

exhaustively

examining

all

possible

intersecting

configurations

Thus

we

can

eliminate

the

-LRB-

y

-RRB-

quantification

altogether

and

replace

it

by

a

boolean

combination

of

atomic

formulas

involving

the

various

cases

of

intersecting

rectangles

The

above

query

program

is

particular

to

rectangles

and

does

not

work

for

triangles

or

for

interiors

of

rectangles

Recall

that

in

the

relational

data

model

quantification

is

over

constants

that

appear

in

the

database

By

contrast

if

we

use

generalized

relations

the

query

can

be

expressed

very

simply

-LRB-

without

case

analysis

-RRB-

and

applies

to

more

general

shapes

Let

R

-LRB-

z

x

y

-RRB-

be

a

ternary

relation

We

interpret

R

-LRB-

z

x

y

-RRB-

to

mean

that

-LRB-

x

y

-RRB-

is

a

point

in

the

rectangle

with

name

z

The

rectangle

that

was

stored

above

by

-LRB-

n

a

b

c

d

-RRB-

would

now

be

stored

as

the

generalized

tuple

-LRB-

z

n

-RRB-

-LRB-

a

x

c

-RRB-

-LRB-

b

y

d

-RRB-

The

set

of

all

intersecting

rectangles

can

now

be

expressed

as

f

-LRB-

-RRB-

-LRB-

y

-RRB-

-LRB-

R

-LRB-

x

y

-RRB-

R

-LRB-

x

y

-RRB-

g

The

simplicity

of

this

program

is

due

to

the

ability

in

CQL

to

describe

and

name

point-sets

using

constraints

The

same

program

can

be

used

for

intersecting

triangles

This

simplicity

of

expression

can

be

combined

with

efficient

evaluation

techniques

even

if

quantification

is

over

the

infinite

domain

of

rationals

For

more

examples

and

details

please

see

-LSB-

-RSB-

The

CQL

model

for

rational

order

relational

calculus

has

low

data

complexity

because

every

fixed

query

is

evaluable

in

LOGSPACE

That

alone

is

not

enough

to

make

it

a

suitable

model

for

implementation

This

situation

is

similar

to

that

in

the

relational

model

where

the

language

framework

does

have

low

data

complexity

but

does

not

account

for

searches

that

are

logarithmic

or

faster

in

the

sizes

of

input

relations

Without

the

ability

to

perform

such

searches

relational

databases

would

have

been

impractical

Very

efficient

use

of

secondary

storage

is

an

additional

requirement

beyond

low

data

complexity

whose

satisfaction

greatly

contributes

to

any

database

technology

In

the

above

example

the

domain

of

database

attribute

x

is

infinite

How

can

we

index

on

it

For

CQLs

we

can

define

indexing

constraints

as

the

problem

of

external

dynamic

range

searching

on

generalized

database

attribute

x

using

the

following

operations

-LRB-

i

-RRB-

Find

a

generalized

database

that

represents

all

tuples

of

the

input

generalized

database

such

that

their

x

attribute

satisfies

x

-LRB-

ii

-RRB-

Insert

or

delete

a

given

generalized

tuple

If

-LRB-

x

-RRB-

is

a

constraint

of

our

CQL

then

there

is

a

trivial

but

inefficient

solution

to

the

problem

of

searching

on

generalized

database

attribute

x

We

can

add

the

constraint

-LRB-

x

-RRB-

to

every

generalized

tuple

-LRB-

i.e.

conjunction

of

constraints

-RRB-

and

naively

insert

or

delete

generalized

tuples

in

a

table

This

involves

a

linear

scan

of

the

generalized

relation

and

introduces

a

lot

of

redundancy

in

the

representation

In

many

cases

the

projection

of

any

generalized

tuple

on

x

is

one

interval

-LRB-

a

x

-RRB-

This

is

true

for

Example

for

relational

calculus

with

linear

inequalities

over

the

reals

and

in

general

when

a

generalized

tuple

represents

a

convex

set

-LRB-

We

call

such

CQLs

convex

CQLs

-RRB-

Under

such

natural

assumptions

there

is

a

better

solution

for

searching

on

generalized

database

attribute

x.

ffl

A

generalized

index

is

a

set

of

intervals

where

each

interval

is

associated

with

a

generalized

tuple

Each

interval

-LRB-

a

x

-RRB-

in

the

index

is

the

projection

on

x

of

its

associated

generalized

tuple

The

two

endpoint

a

representation

of

an

interval

is

a

fixed

length

generalized

key

ffl

Finding

a

generalized

database

that

represents

all

tuples

of

the

input

generalized

database

such

that

their

x

attribute

satisfies

-LRB-

x

-RRB-

can

be

performed

by

adding

constraint

-LRB-

x

-RRB-

to

only

those

generalized

tuples

whose

generalized

keys

have

a

non-empty

intersection

with

it

ffl

Inserting

or

deleting

a

given

generalized

tuple

is

performed

by

computing

its

projection

and

inserting

or

deleting

an

interval

from

the

set

of

intervals

By

the

above

discussion

the

use

of

generalized

indexes

reduces

redundancy

of

representation

and

transforms

searching

on

generalized

database

attribute

x

into

the

problem

of

external

dynamic

interval

management

In

this

paper

we

examine

solutions

for

this

problem

with

good

I/O

performance

Remember

that

a

diagonal

corner

query

is

a

two

sided

range

query

whose

corner

must

lie

on

the

line

x

y

and

whose

query

region

is

the

quarter

plane

above

and

to

the

left

of

the

corner

as

shown

in

Figure

We

now

can

show

the

following

proposition

Proposition

Indexing

constraints

for

convex

CQLs

reduces

to

external

dynamic

interval

management

which

reduces

to

external

dynamic

range

searching

with

diagonal

corner

queries

and

updates

Proof

As

remarked

before

indexing

constraints

means

solving

the

problem

of

interval

intersection

in

secondary

memory

Given

a

set

of

input

intervals

we

would

like

to

find

all

intervals

that

intersect

t

oe

-LRB-

-RRB-

Stabbing

Query

Query

Interval

Data

Intervals

Stabbing

Query

Figure

Reducing

Interval

Intersection

to

Stabbing

Queries

and

Stabbing

Queries

to

Diagonal

Corner

Queries

a

query

interval

Intervals

that

intersect

a

query

interval

-LSB-

-RSB-

can

be

divided

into

four

categories

as

shown

in

Figure

Types

and

can

be

reported

by

sorting

all

the

intervals

on

the

basis

of

their

first

endpoint

and

reporting

those

intervals

whose

first

endpoint

lies

between

and

This

can

be

done

efficiently

using

a

B

tree

Types

and

can

be

reported

by

performing

what

is

called

a

stabbing

query

at

-LRB-

A

stabbing

query

at

on

a

set

of

intervals

returns

those

intervals

that

contain

the

point

See

Figure

-RRB-

It

is

also

clear

that

no

interval

gets

reported

twice

by

this

process

Therefore

we

will

be

able

to

index

constraints

if

we

can

answer

stabbing

queries

efficiently

An

interval

contains

a

point

q

if

and

only

if

its

first

endpoint

is

less

than

or

equal

to

q

and

its

second

endpoint

is

greater

than

or

equal

to

q.

Let

us

map

an

interval

-LSB-

-RSB-

to

the

point

-LRB-

-RRB-

in

space

Clearly

the

stabbing

query

now

translates

into

a

query

That

is

an

interval

-LSB-

-RSB-

belongs

to

a

stabbing

query

at

q

if

and

only

if

the

corresponding

point

-LRB-

-RRB-

is

inside

the

box

generated

by

the

lines

x

x

q

y

q

and

y

Since

the

second

endpoint

of

an

interval

is

always

greater

than

or

equal

to

the

first

endpoint

all

points

that

we

generate

are

above

the

line

x

y

One

of

the

corners

of

any

query

-LRB-

corresponding

to

a

stabbing

query

-RRB-

is

anchored

on

this

line

as

well

-LRB-

See

Figure

-RRB-

The

proposition

follows

Indexing

Classes

To

illustrate

the

problem

of

indexing

classes

consider

an

object-oriented

database

The

objects

in

the

database

are

classified

in

a

forest

class

hierarchy

Each

object

is

in

exactly

one

of

the

classes

of

this

hierarchy

This

partitions

the

set

of

objects

and

the

block

of

the

partition

corresponding

to

a

class

C

is

called

C

's

extent

The

union

of

the

extent

of

a

class

C

with

all

the

extents

of

all

its

descendants

in

this

hierarchy

is

called

the

full

extent

of

C.

Let

us

illustrate

these

ideas

with

an

example

Example

Consider

a

database

that

contains

information

about

people

such

as

names

and

incomes

Let

the

people

objects

be

organized

in

a

class

hierarchy

which

is

a

tree

with

root

Person

two

children

of

Person

called

Professor

Student

and

a

child

of

Professor

called

Assistant-Professor

-LRB-

See

Figure

-RRB-

We

can

read

this

as

follows

Assistant-Professor

isa

Professor

Professor

isa

Person

Student

isa

Person

People

get

partitioned

in

these

classes

For

example

the

full

extent

of

Person

is

the

set

of

all

people

whereas

the

extent

of

Person

is

the

set

of

people

who

are

not

in

the

Professor

Assistant-Professor

and

Student

extents

Indexing

classes

means

being

able

to

perform

external

dynamic

range

searching

on

some

attribute

of

the

objects

but

for

the

full

extent

of

each

class

in

the

hierarchy

Example

Consider

the

class

hierarchy

in

Example

Indexing

classes

for

this

hierarchy

means

being

able

to

find

all

people

in

-LRB-

the

full

extent

of

-RRB-

class

Professor

with

income

between

and

or

to

find

all

people

in

-LRB-

the

full

extent

of

-RRB-

class

Person

with

income

between

and

or

to

insert

a

new

person

with

income

in

the

Student

class

Let

c

be

the

number

of

classes

n

the

number

of

objects

and

B

the

page

size

We

use

the

term

index

a

collection

when

we

build

a

B

tree

on

a

collection

of

objects

-LRB-

This

B

tree

will

be

built

over

some

attribute

which

will

always

be

clear

from

context

In

Example

the

attribute

was

the

salary

attribute

-RRB-

One

way

of

indexing

classes

is

to

create

a

single

B

tree

for

all

objects

-LRB-

i.e.

index

the

collection

of

all

objects

-RRB-

and

answer

a

query

by

looking

at

this

B

tree

and

filtering

out

the

objects

in

the

class

of

interest

This

solution

can

not

compact

a

t-sized

output

into

t

B

pages

because

the

algorithm

has

no

control

over

how

the

objects

of

interest

are

interspersed

with

other

objects

Another

way

is

to

keep

a

B

tree

per

class

-LRB-

i.e.

index

the

full

extent

of

each

class

-RRB-

but

this

uses

O

-LRB-

-LRB-

n

B

-RRB-

c

-RRB-

pages

has

query

I/O

time

O

-LRB-

logB

n

t

B

-RRB-

and

update

I/O

time

O

-LRB-

c

logB

n

-RRB-

The

indexing

classes

problem

has

the

following

special

structure

-LRB-

-RRB-

The

class

hierarchy

is

a

forest

and

thus

it

can

be

mapped

in

one

dimension

where

subtrees

correspond

to

intervals

-LRB-

-RRB-

The

class

hierarchy

is

static

unlike

the

objects

in

it

which

are

dynamic

Based

on

this

structure

we

show

that

indexing

classes

is

a

special

case

of

external

dynamic

range

searching

on

some

attribute

of

the

objects

We

then

use

the

idea

of

the

dimensional

range

tree

-LRB-

see

-LSB-

-RSB-

-RRB-

with

classes

as

the

primary

dimension

and

the

object

attribute

as

a

secondary

dimension

to

devise

an

efficient

storage

and

query

strategy

These

ideas

are

formalized

in

the

proposition

and

theorem

to

follow

Proposition

Indexing

classes

reduces

to

external

dynamic

range

searching

with

one

dimension

being

static

Proof

We

write

a

simple

algorithm

which

attaches

a

new

attribute

called

class

to

every

object

This

attribute

has

a

value

corresponding

to

the

class

to

which

the

object

belongs

Further

we

associate

a

range

with

each

class

such

that

it

includes

all

the

class

attribute

values

of

each

one

of

its

subclasses

-LRB-

The

class

attribute

and

ranges

are

for

the

purposes

of

this

reduction

only

In

an

actual

implementation

these

are

computed

once

and

stored

separately

-RRB-

We

start

out

by

associating

the

half-open

range

-LSB-

-RRB-

with

the

root

of

the

class

hierarchy

We

then

make

a

call

to

the

procedure

label-class

shown

in

Figure

with

the

root

and

the

range

as

parameters

-LRB-

If

the

hierarchy

is

a

forest

of

k

trees

we

simply

divide

the

range

-LSB-

-RRB-

into

k

equal

parts

associate

every

root

with

a

distinct

range

and

call

label-class

once

for

each

root

-RRB-

At

the

end

of

the

procedure

every

class

is

associated

with

a

range

and

every

object

has

a

procedure

label-class

-LRB-

node

-LSB-

a

b

-RRB-

-RRB-

Associate

-LSB-

a

b

-RRB-

with

node

Let

a

be

the

value

of

attribute

class

for

every

object

in

class

node

Let

S

-LRB-

The

number

of

children

of

node

-RRB-

if

node

has

no

children

terminate

Divide

-LSB-

a

b

-RRB-

into

S

equal

parts

of

size

K

Recursively

call

label-class

for

each

child

with

ranges

-LSB-

a

K

a

-RRB-

-LSB-

a

a

-RRB-

etc.

Figure

The

procedure

label-class

used

in

the

proof

of

Proposition

bbbbbbbb

Salary

Student

Person

Asst.

Prof.

Professor

-LSB-

-RRB-

-LSB-

-RRB-

-LSB-

-RRB-

-LSB-

-RSB-

Person

Student

Professor

Asst.

Prof.

Figure

Using

label-class

to

reduce

indexing

classes

to

range

search

class

value

associated

with

it

If

we

apply

label-class

to

the

class

hierarchy

in

Example

the

root

Person

class

is

associated

with

the

range

-LSB-

-RRB-

and

all

the

objects

in

its

extent

have

their

class

attribute

set

to

Similarly

the

Student

Professor

and

Asst.

Prof.

classes

are

associated

with

ranges

-LSB-

-RRB-

-LSB-

-RRB-

and

-LSB-

-RRB-

respectively

The

objects

in

the

Student

Professor

and

Asst.

Prof.

classes

have

their

class

attributes

set

to

and

respectively

It

is

easy

to

see

how

querying

some

class

over

some

particular

attribute

corresponds

to

dimensional

range

searching

The

first

dimension

of

this

search

is

the

class

attribute

and

the

second

dimension

is

the

attribute

over

which

the

search

is

specified

The

range

in

the

class

dimension

is

the

range

that

we

associate

with

the

query

class

in

our

label-class

algorithm

Since

we

assume

that

the

class

hierarchy

is

static

the

proposition

follows

See

Figure

for

an

example

of

the

results

of

applying

label-class

to

a

class

hierarchy

Theorem

Indexing

classes

can

be

solved

in

dynamic

query

I/O

time

O

-LRB-

c

logB

n

t

B

-RRB-

procedure

index-classes

Let

the

individual

extents

of

the

classes

be

the

initial

set

of

collections

for

i

from

to

ce

do

Index

each

collection

at

current

level

if

i

ce

terminate

Merge

with

to

get

Ci

with

to

get

Ci

etc.

If

there

are

odd

number

of

collections

let

Cili

the

last

collection

at

round

i

be

Ci

li

the

last

collection

at

round

i

Number

of

collections

goes

down

by

two

at

each

iteration

li

c

endfor

Figure

The

procedure

index-classes

used

in

the

proof

of

Theorem

and

update

I/O

time

O

-LRB-

c

logB

n

-RRB-

using

O

-LRB-

-LRB-

n

B

-RRB-

c

-RRB-

pages

Here

n

is

the

number

of

objects

in

the

input

database

c

the

size

of

the

class

hierarchy

t

the

number

of

objects

in

the

output

of

a

query

and

B

the

size

of

a

disk

block

Proof

We

know

from

the

previous

proposition

that

by

treating

the

class

value

as

a

dimension

we

can

reduce

indexing

classes

to

range

searching

with

the

values

in

the

class

dimension

being

static

We

use

the

idea

of

the

range

tree

in

procedure

index-classes

shown

in

Figure

to

create

and

index

certain

collections

of

objects

-LRB-

Remember

that

indexing

a

collection

means

building

a

B

tree

on

the

query

attribute

-RRB-

Our

initial

set

of

collections

is

the

set

of

the

individual

extents

of

each

class

Our

final

collection

consists

of

the

full

extent

of

the

root

class

We

will

assume

here

without

loss

of

generality

that

the

class

hierarchy

is

a

tree

If

it

is

a

forest

we

simply

have

to

run

index-classes

on

each

tree

in

the

forest

Our

bounds

will

not

change

From

the

previous

proposition

we

know

that

every

class

query

can

be

represented

as

a

dimensional

range

query

What

label-class

essentially

does

is

to

build

a

binary

search

tree

on

the

class

attribute

values

It

is

easy

to

show

that

the

range

corresponding

to

each

class

can

be

covered

by

no

more

than

ce

nodes

in

this

search

tree

That

is

one

can

answer

class

indexing

queries

on

any

class

by

looking

at

no

more

than

O

-LRB-

c

-RRB-

collections

-LRB-

or

B

trees

-RRB-

This

gives

us

the

query

bound

We

establish

the

space

and

update

bounds

by

noting

that

the

number

of

levels

in

the

class

binary

search

tree

is

no

more

than

ce

This

automatically

implies

that

no

object

is

replicated

more

than

ce

times

and

the

storage

bound

follows

This

also

implies

that

in

order

to

insert/delete

an

object

we

have

to

access

no

more

than

ce

B

trees

The

theorem

follows

Theorem

offers

a

practical

solution

to

class

indexing

It

does

not

have

the

disadvantages

of

indexing

each

class

individual

extent

separately

-LRB-

high

query

overhead

-RRB-

nor

that

of

indexing

each

class

full

extent

separately

-LRB-

high

storage

overhead

-RRB-

nor

that

of

maintaining

only

one

index

containing

all

the

objects

-LRB-

loss

of

query

efficiency

-RRB-

The

query

update

and

storage

overheads

are

Figure

Showing

that

tessellating

a

grid

optimally

is

hard

all

low

-LRB-

a

factor

of

c

-RRB-

and

the

algorithm

outlined

in

the

proof

of

Theorem

is

extremely

simple

This

makes

this

method

an

ideal

choice

for

implementation

Noticing

the

absence

of

data

structures

to

perform

external

range

searching

with

performance

comparable

to

that

of

B-trees

we

might

try

to

prove

that

the

problem

is

inherently

harder

than

external

range

search

Such

bounds

have

been

established

for

range

searching

in

main

memory

by

-LSB-

-RSB-

The

following

lemma

is

a

preliminary

result

that

shows

that

B-tree-like

performance

is

probably

not

possible

for

range

search

We

consider

a

simple

grid

of

points

and

try

to

see

if

it

is

possible

to

place

rectangles

on

this

grid

of

points

-LRB-

i.e.

tessellate

the

points

-RRB-

so

that

all

range

queries

can

be

answered

efficiently

The

idea

behind

the

lemma

is

that

these

rectangles

correspond

to

disk

blocks

We

make

the

simplifying

assumption

that

there

is

only

one

copy

of

each

data

item

which

means

that

the

rectangles

can

not

intersect

We

are

only

concerned

with

reporting

time

in

this

lemma

Even

if

it

is

possible

to

produce

partitions

to

answer

range

queries

efficiently

it

is

far

from

clear

that

they

can

be

located

in

optimal

time

Lemma

Consider

a

grid

of

p?p

points

on

the

plane

It

is

not

possible

to

tessellate

these

points

with

rectangles

of

size

B

-LRB-

which

do

not

intersect

one

another

-RRB-

such

that

range

queries

are

answered

in

optimal

time

That

is

it

is

not

possible

to

answer

all

range

queries

such

that

for

a

range

query

with

q

points

in

the

output

the

points

are

covered

by

only

kq

B

rectangles

where

k

is

a

constant

independent

of

p

q

and

B.

Proof

Figure

shows

an

example

of

the

kinds

of

tessellations

considered

by

this

proof

The

grid

is

of

size

and

B

This

proof

is

by

contradiction

Let

us

assume

that

an

optimal

tessellation

is

possible

for

a

particular

constant

k

We

assume

without

loss

of

generality

that

p

is

a

multiple

of

B.

Let

a

grid

of

p

p

points

be

tessellated

with

rectangles

of

size

B

There

will

be

B

rectangles

tessellating

the

grid

We

will

use

wi

and

hi

to

indicate

the

width

and

height

of

the

i

th

rectangle

Consider

range

queries

that

retrieve

p

points

along

horizontal

straight

lines

There

are

p

such

queries

one

for

each

row

of

the

p

p

grid

By

our

assumption

the

number

of

rectangles

the

j'

th

such

horizontal

query

intersects

will

be

kjp

B

for

some

constant

kj

k

We

observe

that

the

height

of

each

rectangle

in

our

blocking

is

equal

to

the

number

of

horizontal

queries

that

intersect

it

Thus

if

we

sum

up

the

heights

of

all

the

rectangles

we

will

get

the

same

value

that

we

get

when

we

sum

kjp

B

over

all

j

This

gives

us

B

X

i

hi

pX

j

kj

p

B

pX

j

k

p

B

B

-LRB-

-RRB-

Symmetrically

we

can

consider

vertical

queries

and

get

B

X

i

wi

B

-LRB-

-RRB-

Recall

that

for

each

rectangle

hiwi

B.

Thus

the

bounds

on

the

sums

of

the

heights

of

the

rectangles

given

in

-LRB-

-RRB-

can

be

rewritten

as

B

X

i

B

wi

B

Dividing

through

by

B

gives

us

B

X

i

wi

k

-LRB-

-RRB-

Now

we

use

the

fact

that

the

harmonic

mean

of

a

set

of

numbers

is

at

most

their

arithmetic

mean

which

tells

us

that

B

B

X

i

wi

B

X

i

wi

B

If

we

substitute

for

the

denominator

of

the

left

hand

side

then

by

-LRB-

-RRB-

the

value

of

the

left

hand

side

will

either

decrease

or

remain

the

same

Thus

B

B

X

i

wi

B

B

k

B

X

i

wi

B

Now

by

-LRB-

-RRB-

we

can

replace

the

numerator

of

the

right

hand

side

by

B

and

it

will

either

increase

or

remain

the

same

Thus

B

k

B

B

k

and

thus

B

This

produces

our

contradiction

since

we

were

assuming

that

k

was

a

constant

independent

of

B.

Two

intriguing

open

questions

are

whether

or

not

B-tree-like

performance

is

possible

for

arbitrary

partitions

of

the

plane

not

just

rectangular

tessellations

and

whether

or

not

performance

can

be

improved

by

allowing

a

small

constant

number

of

copies

of

each

data

item

From

the

previous

lemma

we

can

infer

that

the

problem

of

indexing

classes

despite

its

structure

is

nontrivial

Consider

a

class

hierarchy

with

c

leaves

all

of

which

are

children

of

the

root

We

can

map

the

class

indexing

problem

to

range

searching

as

before

Now

we

can

use

the

previous

lemma

Instead

of

having

a

grid

of

p?p

points

we

have

a

grid

of

c?p

points

The

following

theorem

then

follows

easily

Theorem

Consider

the

fully

static

problem

of

indexing

classes

where

the

hierarchy

has

c

leaves

which

are

children

of

the

root

We

allow

our

disk

blocks

to

cover

only

rectangular

regions

and

only

one

copy

of

each

object

on

secondary

storage

-LRB-

i.e.

no

two

disk

blocks

will

contain

the

same

objects

-RRB-

For

any

fixed

k

-LRB-

independent

of

q

and

B

-RRB-

there

will

be

class

indexing

queries

whose

q

items

of

output

can

not

be

covered

by

only

kq

B

disk

blocks

An

Algorithm

for

External

Semi-Dynamic

Interval

Manage

ment

As

was

shown

by

Proposition

an

efficient

data

structure

for

external

dynamic

range

searching

with

diagonal

corner

queries

can

be

used

to

efficiently

solve

the

external

dynamic

interval

maintenance

problem

In

this

section

we

describe

the

metablock

tree

an

optimal

data

structure

for

this

problem

Initially

we

describe

the

metablock

tree

for

the

static

case

where

all

data

is

given

and

can

be

preprocessed

before

any

queries

are

processed

Once

this

is

done

we

describe

methods

whereby

the

data

structure

can

be

made

semi-dynamic

xy

Figure

A

metablock

tree

for

B

and

n

All

data

points

lie

above

the

line

y

x.

Each

region

represents

a

metablock

The

root

is

at

the

top

Note

that

each

non-leaf

metablock

contains

data

points

An

I/O

Optimal

Static

Data

Structure

for

Diagonal

Corner

Queries

At

the

outermost

level

a

metablock

tree

whether

static

or

dynamic

is

a

B-ary

tree

of

metablocks

each

of

which

represents

data

points

The

root

represents

the

data

points

with

the

largest

y

values

The

remaining

n

data

points

are

divided

into

B

groups

of

-LRB-

n

-RRB-

B

data

points

each

based

on

their

x

coordinates

The

first

group

contains

the

-LRB-

-RRB-

B

data

points

with

the

smallest

x

values

the

second

contains

those

with

the

next

-LRB-

-RRB-

B

smallest

x

values

and

so

on

A

recursive

tree

of

the

exact

same

type

is

constructed

for

each

such

group

of

data

points

This

process

continues

until

a

group

has

at

most

data

points

and

can

fit

into

a

single

metablock

This

is

illustrated

in

Figure

Now

let

us

consider

how

we

can

store

a

set

of

k

data

points

belonging

to

a

metablock

in

blocks

of

size

B

One

very

simple

scheme

is

to

put

the

data

points

into

horizontally

oriented

blocks

by

putting

the

B

data

points

with

the

largest

y

values

into

the

first

block

the

B

data

points

with

the

next

largest

y

values

into

the

next

block

and

so

on

Similarly

we

can

put

the

data

points

into

vertically

oriented

blocks

by

discriminating

on

the

x

coordinates

These

techniques

are

illustrated

in

Figure

Each

metablock

in

our

tree

is

divided

into

both

horizontally

and

vertically

oriented

blocks

This

means

that

each

data

point

is

represented

more

than

once

but

the

overall

size

of

our

data

structure

remains

O

-LRB-

n

B

-RRB-

In

addition

to

the

horizontally

and

vertically

oriented

blocks

each

metablock

contains

pointers

to

each

of

its

B

children

as

well

as

a

location

of

each

child

's

bounding

box

Finally

each

metablock

M

contains

pointers

to

B

blocks

that

represent

in

horizontal

orientation

the

set

TS

-LRB-

M

-RRB-

TS

-LRB-

M

-RRB-

is

the

set

obtained

by

examining

the

set

of

data

points

stored

in

the

left

siblings

of

M

and

taking

the

such

points

with

the

largest

y

values

This

is

illustrated

in

Figure

Note

that

each

-LRB-

a

-RRB-

Vertically

oriented

-LRB-

b

-RRB-

Horizontally

oriented

Figure

Vertically

and

horizontally

oriented

blockings

of

data

points

Each

thin

rectangle

represents

a

block

MTS

-LRB-

M

-RRB-

Figure

A

metablock

M

and

the

set

TS

-LRB-

M

-RRB-

Note

that

TS

-LRB-

M

-RRB-

spans

all

of

M

's

left

siblings

in

the

metablock

tree

Though

it

is

not

explicitly

shown

here

TS

-LRB-

M

-RRB-

will

be

represented

as

a

set

of

B

horizontally

oriented

blocks

metablock

already

requires

O

-LRB-

B

-RRB-

blocks

of

storage

space

so

storing

TS

-LRB-

M

-RRB-

for

each

metablock

does

nothing

to

the

asymptotic

space

usage

of

the

metablock

tree

The

final

bit

of

organization

left

is

used

only

for

those

metablocks

that

can

possibly

contain

the

corner

of

a

query

These

are

the

leaf

metablocks

the

root

metablocks

and

all

metablocks

that

lie

along

the

path

from

the

root

to

the

rightmost

leaf

-LRB-

See

the

metablocks

on

the

diagonal

in

Figure

-RRB-

These

blocks

will

be

organized

as

prescribed

by

the

following

lemma

Lemma

A

set

S

of

k

data

points

can

be

represented

using

O

-LRB-

k

B

-RRB-

blocks

of

size

B

so

that

a

diagonal

corner

query

on

S

can

be

answered

using

at

most

B

I/O

operations

where

t

is

the

number

of

data

points

in

S

that

lie

within

the

query

region

Proof

Initially

we

divide

S

into

a

vertically

oriented

blocking

of

k

B

blocks

Let

C

be

the

set

of

points

at

which

right

boundaries

of

the

regions

corresponding

to

the

vertically

oriented

blocks

intersect

the

line

y

x

Now

we

choose

a

subset

C

C

of

these

points

and

use

one

or

more

blocks

to

explicitly

represent

the

answer

to

each

query

that

happens

to

have

a

corner

c

C

This

is

illustrated

in

Figure

In

order

to

decide

which

elements

of

C

will

become

elements

of

C

we

use

an

iterative

process

The

first

element

of

C

is

chosen

to

be

at

the

intersection

of

the

left

boundary

of

the

rightmost

block

in

the

vertically

oriented

blocking

We

will

call

this

point

c

To

decide

which

other

elements

Figure

The

sets

C

and

C

used

in

the

proof

of

Lemma

The

marked

points

lying

along

the

diagonal

line

y

x

are

the

points

in

the

set

C.

Those

that

are

small

and

dark

are

points

in

C

n

C

The

larger

open

points

are

in

the

set

C

The

dark

lines

represent

the

boundaries

of

queries

whose

corners

are

at

points

c

C

One

such

query

is

shaded

to

demonstrate

what

they

look

like

of

C

should

be

elements

of

C

we

proceed

along

the

line

y

x

from

the

upper

right

-LRB-

large

x

and

y

-RRB-

to

the

lower

left

-LRB-

small

x

and

y

-RRB-

considering

each

element

of

C

we

encounter

in

turn

Let

c?j

be

the

element

of

C

most

recently

added

to

C

initially

this

is

c

We

now

move

down

the

line

y

x

considering

each

ci

C

until

we

find

one

to

add

to

C

In

considering

ci

C

we

define

the

sets

i

i

i

and

i

to

be

subsets

of

S

as

shown

in

Figure

Let

i

i

-LSB-

i

Let

S?j

i

-LSB-

i

be

the

answer

to

a

query

whose

corner

is

c?j

This

was

the

last

set

of

points

that

was

explicitly

blocked

Let

Si

i

-LSB-

i

be

the

answer

to

a

query

whose

corner

is

ci

We

decide

to

add

ci

to

C

and

thus

explicitly

store

Si

if

and

only

if

j

i

j

j

i

j

jSij

Intuitively

we

do

not

add

ci

to

C

when

we

can

efficiently

amortize

the

cost

of

a

query

cornered

at

ci

over

a

number

of

blocks

that

have

already

been

constructed

Having

constructed

C

we

now

explicitly

block

the

set

S?i

answering

a

diagonal

corner

query

for

each

element

c?i

C

Clearly

the

space

used

for

each

such

set

is

djS?i

j

Be

blocks

An

obvious

concern

is

that

by

explicitly

blocking

these

sets

we

may

already

be

using

more

space

than

the

lemma

we

are

trying

to

prove

allows

This

however

is

not

the

case

We

can

prove

this

by

amortization

Each

time

we

add

a

ci

to

C

we

will

charge

jSij

credits

to

the

set

i

-LSB-

i

The

charge

is

divided

equally

among

the

elements

of

the

set

being

charged

Once

we

add

ci

to

C

no

element

of

i

can

ever

be

in

another

i

for

a

larger

value

of

i

as

the

iteration

continues

The

same

holds

for

elements

of

i

which

can

never

appear

as

elements

of

i

again

for

larger

i.

Thus

no

element

of

S

can

be

a

part

of

a

set

that

is

charged

for

the

insertion

of

a

ci

into

C

more

than

twice

Since

the

size

of

the

set

being

charged

is

at

least

the

size

of

the

set

being

inserted

the

total

cost

charged

to

any

point

is

at

most

Thus

the

total

size

of

all

the

sets

in

C

is

at

most

which

we

can

clearly

represent

within

O

-LRB-

k

B

-RRB-

blocks

The

only

possible

concern

is

that

almost

a

full

block

can

be

wasted

for

each

set

in

C

due

to

roundoff

This

is

not

a

problem

however

since

jC?j

jCj

k

B

so

the

number

of

blocks

wasted

is

at

most

of

the

same

order

as

the

number

used

Now

that

we

have

a

bound

on

the

space

used

by

our

data

structure

we

have

only

to

show

that

it

can

be

used

to

answer

queries

in

B

I/Os

To

answer

a

query

whose

corner

is

at

i

i

i

i

c?j

ci

Figure

The

sets

i

i

i

and

i

as

constructed

in

the

proof

of

Lemma

c?j

is

the

last

point

that

was

added

to

C

and

ci

is

the

point

being

considered

for

inclusion

The

sets

consist

of

subsets

of

S

falling

within

the

labeled

regions

some

c?i

C

we

simply

read

the

blocks

that

explicitly

store

the

answer

to

the

query

This

takes

dt

Be

t

B

I/Os

which

is

clearly

within

the

required

bounds

The

more

complicated

case

is

when

the

query

point

c

lies

between

two

consecutive

elements

c?j

and

c?j

in

C

Let

T

be

the

subset

of

S

that

is

the

answer

to

the

query

whose

corner

is

c

We

find

T

in

two

stages

In

the

first

stage

we

read

blocks

from

S?j

which

we

assume

is

horizontally

blocked

starting

at

the

top

and

continuing

until

we

reach

the

bottom

of

the

query

This

is

illustrated

in

Figure

-LRB-

a

-RRB-

At

most

one

block

is

wasted

in

this

process

In

the

second

stage

we

return

to

our

original

vertical

blocking

of

S

-LRB-

into

k

B

blocks

-RRB-

and

read

blocks

from

left

to

right

starting

with

the

one

directly

to

the

right

of

c?j

and

continuing

until

we

reach

the

block

containing

c

This

is

illustrated

in

Figure

-LRB-

b

-RRB-

To

show

that

we

are

still

within

the

I/O

bounds

we

are

trying

to

prove

we

consider

two

cases

In

the

first

case

there

is

no

ci

C

between

c

and

c?j

This

is

illustrated

in

Figure

-LRB-

a

-RRB-

In

this

case

we

only

have

to

read

one

block

from

the

vertical

blocking

namely

the

one

immediately

to

the

right

of

c?j

and

the

proof

is

done

In

the

second

case

there

is

at

least

one

ci

C

between

c

and

c?j

Let

us

consider

the

leftmost

such

ci

Since

c?j

and

c?j

are

consecutive

elements

of

C

it

must

be

the

case

that

ci

was

not

chosen

in

the

iterative

process

that

constructed

C

This

means

that

j

i

j

j

i

j

jSij

otherwise

ci

would

have

been

added

to

C

Subtracting

j

i

j

from

both

sides

we

get

j

i

j

j?ij

since

i

and

i

are

disjoint

but

their

union

is

Si

Referring

to

Figure

-LRB-

b

-RRB-

we

see

that

i

is

a

c

c?j

c?j

-LRB-

a

-RRB-

The

first

phase

of

the

algorithm

to

answer

a

query

whose

corner

is

c

The

shaded

blocks

correspond

to

blocks

of

the

explicitly

blocked

set

S?j

that

are

read

in

this

phase

c

c?j

c?j

-LRB-

b

-RRB-

The

second

phase

of

the

algorithm

to

answer

a

query

In

this

phase

the

shaded

vertical

blocks

are

examined

Figure

The

two

phases

of

the

algorithm

to

answer

a

query

whose

corner

is

c

as

used

in

the

proof

of

Lemma

c?j

and

c?j

are

consecutive

elements

of

the

set

C

an

thus

answers

to

queries

having

them

as

corners

are

explicitly

blocked

subset

of

T

the

answer

to

the

query

whose

corner

is

c.

Thus

j

i

j

j?ij

jT

j

We

also

see

that

except

for

the

leftmost

block

all

the

vertical

blocks

examined

in

the

second

phase

in

Figure

-LRB-

b

-RRB-

are

fully

contained

in

i

This

means

that

in

the

worst

case

we

will

have

to

examine

all

of

i

plus

one

additional

block

But

since

j

i

j

jT

j

the

number

of

blocks

examined

is

at

most

equal

to

the

number

of

blocks

needed

to

represent

the

output

of

our

query

Even

if

all

these

blocks

are

wasted

because

the

points

they

contain

lie

in

the

region

below

c

no

more

than

dt

Be

blocks

are

wasted

If

we

add

these

to

the

blocks

used

in

the

first

stage

and

the

vertical

block

just

to

the

right

of

c?j

the

total

number

of

blocks

used

is

no

more

than

B

The

final

step

of

the

proof

is

to

show

how

we

can

determine

where

to

begin

looking

for

a

query

given

a

query

point

c

Since

k

the

size

of

C

is

at

most

B

We

can

thus

use

a

single

block

to

store

an

index

with

pointers

to

the

appropriate

locations

to

begin

the

two

stages

of

the

search

for

any

query

value

falling

between

two

consecutive

elements

of

C

This

gives

us

our

overall

result

of

B

I/Os

The

only

cases

we

have

not

considered

occur

when

c

does

not

fall

between

two

elements

of

C

but

rather

completely

to

either

the

left

or

right

of

them

These

special

cases

can

be

handled

by

c?j

c?j

c

-LRB-

a

-RRB-

In

the

first

case

c

is

in

the

vertical

block

immediately

to

the

right

of

c?j

i

i

i

i

c?j

c?j

ci

c

-LRB-

b

-RRB-

In

the

second

case

there

is

at

least

one

element

of

C

between

c

and

c?j

ci

is

the

leftmost

such

element

Figure

Two

cases

of

the

second

phase

of

the

algorithm

-LRB-

Figure

-LRB-

b

-RRB-

-RRB-

used

in

the

proof

of

Lemma

minor

variations

of

the

arguments

given

above

Now

that

we

know

how

to

structure

the

corner

blocks

of

a

metablock

tree

so

that

the

portion

of

a

query

that

falls

within

that

metablock

can

be

reported

efficiently

we

need

only

show

that

the

portions

of

the

query

residing

in

the

rest

of

the

metablocks

can

also

be

reported

efficiently

We

do

this

with

the

following

theorem

Theorem

If

a

set

of

n

data

points

-LRB-

x

y

-RRB-

in

the

planar

region

y

x

and

y

is

organized

into

a

metablock

tree

with

blocks

of

size

B

then

a

diagonal

corner

query

with

t

data

points

in

its

query

region

can

be

performed

in

O

-LRB-

logB

n

t

B

-RRB-

I/O

operations

The

size

of

the

data

structure

is

O

-LRB-

n

B

-RRB-

blocks

of

size

B

each

Proof

First

we

consider

the

space

used

by

the

tree

In

Lemma

we

showed

that

the

number

of

blocks

used

by

each

corner

metablock

containing

k

points

is

O

-LRB-

k

B

-RRB-

All

other

metablocks

in

the

tree

must

be

internal

and

thus

contain

points

Each

such

metablock

occupies

O

-LRB-

B

-RRB-

blocks

as

was

shown

in

the

discussion

of

their

construction

This

includes

the

associated

TS

data

structures

In

addition

we

will

use

a

constant

number

of

disk

blocks

per

metablock

to

store

control

information

for

that

metablock

This

will

include

split

values

and

pointers

to

its

children

boundary

values

and

pointers

to

the

horizontal

organization

etc.

This

control

information

uses

O

-LRB-

n

-RRB-

disk

blocks

since

there

are

only

O

-LRB-

n

-RRB-

metablocks

Thus

a

total

of

O

-LRB-

n

B

-RRB-

blocks

are

used

Queries

are

answered

using

the

procedure

diagonal-query

in

Figure

-LRB-

by

invoking

diagonal

-LRB-

-RRB-

procedure

diagonal-query

-LRB-

query

q

node

M

-RRB-

-LRB-

-RRB-

if

M

contains

the

corner

of

query

q

then

-LRB-

-RRB-

use

the

corner

structure

for

M

to

answer

the

query

return

-LRB-

-RRB-

else

M

does

not

contain

the

corner

of

query

q

-LRB-

-RRB-

use

M

's

vertically

oriented

blocks

to

report

points

of

M

that

lie

inside

q

-LRB-

-RRB-

let

Mc

be

the

child

of

M

containing

the

vertical

side

of

the

query

-LRB-

-RRB-

if

Mc

has

siblings

to

its

left

that

fall

inside

the

query

use

the

bottom

boundary

of

TS

-LRB-

Mc

-RRB-

to

determine

if

TS

-LRB-

Mc

-RRB-

falls

completely

inside

the

query

-LRB-

-RRB-

If

TS

-LRB-

Mc

-RRB-

does

not

fall

completely

inside

the

query

report

the

points

in

TS

-LRB-

Mc

-RRB-

that

lie

inside

the

query

-LRB-

-RRB-

If

TS

-LRB-

Mc

-RRB-

falls

completely

inside

the

query

examine

the

siblings

one

by

one

using

their

horizontally

oriented

blocks

-LRB-

-RRB-

If

any

sibling

is

completely

contained

inside

the

query

look

at

its

children

using

their

-LRB-

the

children

's

-RRB-

horizontally

oriented

organizations

and

continue

downwards

until

the

bottom

boundary

of

the

query

is

reached

for

every

metablock

so

examined

-LRB-

-RRB-

invoke

diagonal-query

-LRB-

q

Mc

-RRB-

Figure

Procedure

diagonal-query

to

answer

diagonal

corner

queries

using

a

metablock

tree

query

-LRB-

query

q

root

of

metablock

tree

-RRB-

-RRB-

We

associate

every

metablock

with

the

minimum

bounding

rectangle

of

the

points

inside

it

Call

this

the

metablock

's

region

Also

a

diagonal

corner

query

q

is

completely

specified

by

the

point

at

which

it

is

anchored

on

the

line

x

y

We

will

use

phrases

like

if

metablock

M

contains

the

corner

of

query

q

etc.

with

the

understanding

that

these

are

really

short

procedures

that

can

be

implemented

easily

by

considering

intersections

of

the

appropriate

regions

To

prove

the

bound

on

the

query

time

we

consider

the

fact

that

once

we

know

the

query

region

each

block

that

has

a

non-empty

intersection

with

it

falls

into

one

of

four

categories

based

on

how

it

interacts

with

the

boundary

of

the

query

These

four

types

are

illustrated

in

Figure

To

complete

the

proof

we

simply

look

at

the

contributions

of

each

type

of

metablock

to

the

total

number

of

I/Os

required

ffl

There

are

at

most

O

-LRB-

n

-RRB-

O

-LRB-

logB

n

-RRB-

Type

I

nodes

each

of

which

can

be

queried

using

its

vertically

oriented

blocks

so

as

to

visit

at

most

one

block

that

is

not

completely

full

These

potentially

wasted

blocks

are

accounted

for

in

the

O

-LRB-

logB

n

-RRB-

term

ffl

Only

one

Type

II

node

can

exist

Let

tc

be

the

number

of

data

points

stored

in

the

metablock

at

this

node

that

are

within

the

query

region

By

Lemma

the

tc

points

can

be

found

using

only

O

-LRB-

tc

B

-RRB-

I/O

operations

This

gets

absorbed

into

the

O

-LRB-

t

B

-RRB-

term

ffl

A

Type

III

metablock

returns

data

points

and

uses

O

-LRB-

B

-RRB-

I/O

operations

These

are

accounted

for

in

the

O

-LRB-

t

B

-RRB-

term

ffl

The

set

of

all

Type

IV

children

of

a

Type

III

node

can

be

queried

using

their

horizontally

Type

I

Type

II

Type

III

Type

IV

Figure

The

four

types

of

metablocks

The

shaded

rectangles

represent

metablock

boundaries

and

the

thick

lines

are

the

boundaries

of

queries

The

four

types

appear

in

processing

diagonal

corner

queries

as

described

in

Section

and

are

used

in

the

proof

of

Theorem

oriented

blocks

so

as

to

examine

at

most

O

-LRB-

B

-RRB-

blocks

that

are

not

entirely

full

-LRB-

one

per

child

-RRB-

Since

we

used

O

-LRB-

B

-RRB-

I/O

operations

for

the

output

from

the

Type

III

block

the

extra

Type

IV

I/O

operations

can

be

absorbed

into

the

Type

III

I/O

and

added

to

the

O

-LRB-

t

B

-RRB-

term

ffl

The

last

type

of

block

that

has

to

be

considered

is

a

Type

IV

child

of

a

Type

I

node

Up

to

B

Type

IV

nodes

can

be

children

of

a

single

Type

I

node

M

Let

Mr

be

the

rightmost

Type

IV

child

of

M

We

can

determine

whether

or

not

to

examine

the

Type

IV

siblings

of

Mr

by

first

examining

TS

-LRB-

Mr

-RRB-

If

the

bottom

boundary

of

TS

-LRB-

Mr

-RRB-

is

below

the

bottom

boundary

of

the

query

we

load

the

blocks

that

make

up

TS

-LRB-

Mr

-RRB-

one

at

a

time

from

top

to

bottom

until

we

cross

the

bottom

boundary

of

the

query

If

the

bottom

boundary

of

TS

-LRB-

Mr

-RRB-

is

above

the

bottom

boundary

of

the

query

then

we

know

that

the

siblings

contain

at

least

points

that

are

inside

the

query

Thus

we

can

afford

to

examine

each

of

Mr

's

Type

IV

siblings

individually

This

process

may

result

in

one

block

of

overshoot

for

each

such

sibling

but

we

will

get

at

least

points

overall

so

we

can

afford

this

This

case

is

illustrated

in

Figure

-LRB-

a

-RRB-

If

we

hit

the

boundary

of

the

query

first

we

can

simply

report

all

the

points

we

saw

as

part

of

the

output

and

we

have

no

need

to

examine

any

of

Mr

's

Type

IV

siblings

at

all

This

case

is

illustrated

in

Figure

-LRB-

b

-RRB-

In

both

cases

all

the

blocks

examined

can

be

charged

to

the

O

-LRB-

t

B

-RRB-

term

Theorem

gives

us

an

upper

bound

for

handling

diagonal

corner

queries

The

following

proposition

provides

a

matching

lower

bound

which

proves

that

the

metablock

tree

technique

is

optimal

Proposition

Any

method

that

performs

diagonal

corner

queries

on

sets

of

n

data

points

-LRB-

x

y

-RRB-

in

the

planar

region

y

x

and

y

must

use

-LRB-

logB

n

t

B

-RRB-

I/O

operations

where

t

is

the

number

of

items

in

the

answer

to

the

query

Furthermore

the

data

structure

it

uses

must

occupy

-LRB-

n

B

-RRB-

blocks

Proof

Consider

the

set

of

points

S

f

-LRB-

x

x

-RRB-

x

Z

n

g

and

the

set

of

n

queries

whose

corners

are

the

elements

of

the

set

Q

f

-LRB-

x

x

-RRB-

x

Z

n

g.

Each

of

these

queries

contains

exactly

one

Mr

M

TS

-LRB-

Mr

-RRB-

-LRB-

a

-RRB-

In

this

case

the

entire

TS

-LRB-

Mr

-RRB-

structure

lies

above

the

bottom

of

the

query

region

implying

that

we

can

individually

examine

all

Type

IV

right

siblings

of

Mr.

M

Mr

TS

-LRB-

Mr

-RRB-

-LRB-

b

-RRB-

In

this

case

the

TS

-LRB-

Mr

-RRB-

structure

intersects

the

bottom

boundary

of

the

query

region

thus

all

points

in

the

query

that

appear

in

Type

IV

siblings

of

Mr

will

be

located

when

TS

-LRB-

Mr

-RRB-

is

examined

Figure

Use

of

the

TS

structure

to

search

Type

IV

metablocks

as

used

in

the

proof

of

Theorem

point

in

the

set

S

This

is

illustrated

in

Figure

Since

there

are

n

distinct

subsets

of

S

that

can

be

reported

as

answers

to

queries

we

must

have

some

means

of

deciding

which

if

any

answer

our

question

Each

time

we

read

a

block

we

can

make

a

decision

between

at

most

O

-LRB-

B

-RRB-

alternatives

This

means

that

if

we

view

our

algorithm

as

a

decision

tree

with

a

block

read

at

each

node

it

must

have

depth

-LRB-

logB

n

-RRB-

in

order

to

have

n

leaves

This

gives

us

the

first

term

of

our

lower

bound

The

second

term

of

the

lower

bound

comes

from

the

fact

that

in

general

we

must

report

the

answer

to

any

query

of

size

t

n

and

therefore

at

least

t

B

block

reads

will

be

required

The

space

utilization

follows

since

every

element

of

S

may

appear

in

the

answer

to

some

query

and

thus

it

must

be

represented

somewhere

in

the

data

structure

Dynamization

of

Insertions

The

data

structure

described

in

Section

can

be

made

semi-dynamic

in

the

sense

that

it

will

support

the

efficient

insertion

of

points

Because

of

the

complexity

of

the

internal

organization

of

a

metablock

it

will

not

be

possible

for

us

to

reorganize

the

data

structure

immediately

after

the

insertion

of

a

point

Our

strategy

will

be

to

defer

reorganization

until

sufficient

inserts

have

occurred

for

us

to

be

able

to

pay

for

the

reorganizations

that

we

perform

Thus

the

bounds

we

get

are

amortized

The

general

strategy

will

be

to

collect

inserts

that

go

into

a

metablock

in

an

update

block

Figure

The

set

of

points

S

and

a

query

whose

corner

is

an

element

of

the

set

of

Q

as

described

in

the

lower

bound

proof

of

Theorem

that

is

associated

with

that

metablock

When

that

update

block

fills

up

we

will

perform

certain

reorganizations

on

the

associated

metablock

In

order

to

keep

the

size

of

a

metablock

itself

under

limits

we

will

peform

certain

other

reorganizations

when

the

size

of

a

metablock

reaches

from

the

initial

size

of

This

will

eventually

cause

the

branching

factors

of

the

nodes

in

the

metablock

tree

to

go

up

We

will

let

branching

factors

increase

from

the

initial

value

of

B

to

after

which

will

perform

certain

other

reorganizations

that

will

restore

the

branching

factor

back

to

B

The

precise

details

are

below

To

start

with

we

first

enumerate

the

different

positions

at

which

a

point

can

be

stored

in

a

metablock

tree

a.

in

the

vertically

oriented

organization

of

a

metablock

b.

in

the

horizontally

oriented

organization

of

a

metablock

c.

in

the

corner

structure

of

a

metablock

-LRB-

if

the

metablock

intersects

the

diagonal

line

-RRB-

and

d.

in

the

TS

structures

of

the

right

siblings

of

the

metablock

It

is

relatively

easy

to

handle

the

reorganization

of

the

-LRB-

a

-RRB-

-LRB-

b

-RRB-

and

-LRB-

c

-RRB-

-LRB-

where

it

exists

-RRB-

components

of

a

metablock

when

insertions

are

allowed

Note

however

that

immediate

reorganization

after

the

insertion

of

a

point

is

still

not

possible

because

it

takes

O

-LRB-

B

-RRB-

I/O

's

to

reorganize

components

-LRB-

a

-RRB-

-LRB-

b

-RRB-

and

-LRB-

b

-RRB-

of

a

metablock

Our

strategy

will

be

to

associate

an

additional

update

block

in

the

control

information

of

a

metablock

When

this

update

block

fills

up

we

have

had

B

inserts

into

the

metablock

At

this

point

we

reorganize

the

vertically

and

horizontally

oriented

components

of

the

metablock

and

rebuild

the

corner

structure

-LRB-

if

it

exists

for

the

metablock

-RRB-

optimally

as

described

in

Lemma

This

costs

O

-LRB-

B

-RRB-

I/O

's

This

implies

that

we

spend

only

O

-LRB-

-RRB-

I/O

's

amortized

per

point

for

this

reorganization

Let

us

call

this

reorganization

of

a

metablock

M

a

level

I

reorganization

of

M

Note

that

we

will

peform

a

level

I

reorganization

once

in

every

B

inserts

When

the

size

of

a

metablock

reaches

we

will

perform

other

reorganizations

that

are

outlined

below

Updating

the

TS

structures

of

the

siblings

of

a

metablock

when

points

are

inserted

into

it

is

much

more

difficult

because

a

point

potentially

can

belong

in

the

TS

structures

of

B

siblings

Since

rebuilding

these

TS

structures

-LRB-

of

total

size

O

-LRB-

-RRB-

blocks

-RRB-

takes

O

-LRB-

-RRB-

I/O

's

we

can

not

afford

to

rebuild

the

TS

structures

even

once

in

B

inserts

In

order

to

circumvent

this

problem

we

use

the

following

crucial

observation

Consider

an

internal

-LRB-

non-leaf

-RRB-

metablock

M

Take

the

points

that

are

inserted

into

its

children

and

build

a

corner

structure

for

these

points

as

prescribed

by

Lemma

A

diagonal

corner

query

on

the

whole

metablock

tree

is

also

a

diagonal

corner

query

on

this

new

corner

structure

and

can

be

answered

optimally

as

long

as

the

number

of

points

in

it

is

less

than

O

-LRB-

-RRB-

We

call

this

corner

structure

the

TD

corner

structure

for

M

As

in

the

case

of

a

metablock

this

TD

corner

structure

will

have

an

update

block

and

will

be

rebuilt

once

in

B

insertions

into

it

When

the

size

of

the

TD

structure

of

a

metablock

M

becomes

points

we

discard

the

TD

corner

structure

and

rebuild

the

TS

structures

of

all

the

children

of

M

-LRB-

taking

into

account

the

points

that

were

in

the

TD

corner

structure

-RRB-

Call

this

reorganization

a

TS

reorganization

of

the

children

of

M

We

can

not

let

the

size

of

a

metablock

increase

indefinitely

Our

bounds

hold

only

when

the

number

of

points

in

a

metablock

is

O

-LRB-

-RRB-

Therefore

when

the

number

of

points

in

a

metablock

reaches

we

perform

the

following

actions

-LRB-

if

the

metablock

is

a

non-leaf

metablock

-RRB-

select

the

top

points

-LRB-

with

the

largest

y

values

-RRB-

of

the

metablock

and

build

the

vertical

horizontal

and

corner

-LRB-

if

necessary

-RRB-

organizations

of

the

metablock

-LRB-

this

takes

O

-LRB-

B

-RRB-

I/O

's

-RRB-

insert

the

bottom

points

of

the

metablock

into

the

appropriate

children

depending

on

the

x

values

of

the

points

perform

a

TS

reorganization

of

M

and

its

siblings

-LRB-

this

takes

O

-LRB-

-RRB-

I/O

's

-RRB-

We

call

such

a

reorganization

a

level

II

reorganization

of

a

metablock

Obviously

this

scheme

will

not

work

if

the

metablock

M

is

a

leaf

because

there

are

no

children

to

insert

into

In

that

case

we

perform

the

following

actions

split

the

metablock

into

two

children

containing

points

each

and

update

the

control

information

of

the

metablock

's

parents

and

perform

a

TS

reorganization

of

the

two

new

metablocks

and

its

siblings

We

call

this

reorganization

a

level

II

reorganization

of

a

leaf

The

final

detail

has

to

do

with

the

branching

factor

of

the

parent

of

a

leaf

that

just

split

We

will

let

this

grow

from

the

initial

value

of

B

to

Once

it

reaches

we

split

the

parent

itself

into

two

by

reorganizing

the

entire

metablock

tree

rooted

at

the

parent

One

subtree

will

contain

the

leftmost

B

leaves

and

the

other

will

contain

the

rightmost

B

leaves

We

insert

the

two

new

roots

-LRB-

-RRB-

procedure

insert-point

-LRB-

p

-RRB-

-LRB-

-RRB-

M

the

metablock

p

falls

in

-LRB-

-RRB-

P

M

's

parent

-LRB-

-RRB-

Add

p

to

M

's

update

block

-LRB-

-RRB-

Add

p

to

P

's

TD

update

block

-LRB-

-RRB-

If

M

's

update

block

is

full

then

perform

a

level

I

restructuring

of

M

-LRB-

-RRB-

If

P

's

TD

update

block

is

full

then

rebuild

the

TD

corner

structure

-LRB-

-RRB-

If

the

size

of

P

's

TD

corner

structure

is

then

discard

the

points

in

the

structure

and

perform

a

TS

reorganization

of

the

children

of

P

-LRB-

-RRB-

If

M

is

a

non-leaf

metablock

and

contains

points

then

perform

a

level

II

reorganization

of

M

-LRB-

-RRB-

If

M

is

a

leaf

and

contains

points

then

perform

a

level

II

reorganization

of

the

leaf

and

call

propagate-branching-factor

-LRB-

P

-RRB-

-LRB-

-RRB-

procedure

propagate-branching-factor

-LRB-

M

-RRB-

-LRB-

-RRB-

P

M

's

parent

-LRB-

-RRB-

If

the

branching

factor

of

M

is

then

reorganize

M

into

two

equal

subtrees

rooted

at

metablocks

ML

and

MR

and

insert

these

into

P

in

place

of

M

Perform

a

TS

reorganization

of

ML

MR

and

their

siblings

Recursively

call

propagate-branching-factor

-LRB-

P

-RRB-

-LRB-

-RRB-

If

-LRB-

-RRB-

can

not

be

done

because

M

is

the

root

create

a

new

root

with

two

children

ML

and

MR

Figure

An

algorithm

for

inserting

a

point

into

an

augmented

metablock

tree

insert-point

-LRB-

-RRB-

is

the

main

procedure

for

inserting

a

point

It

inserts

a

point

and

propagates

insertions

down

the

tree

as

needed

propagate-branching-factor

-LRB-

-RRB-

is

a

subroutine

which

splits

metablocks

and

propagates

changes

up

the

tree

of

these

subtrees

above

in

place

of

the

parent

This

procedure

has

to

be

continued

up

recursively

as

necessary

We

show

that

this

will

not

take

too

much

time

by

showing

that

such

reorganizations

can

not

happen

too

often

Figure

is

an

algorithm

for

performing

updates

in

an

augmented

metablock

tree

that

presents

concisely

the

steps

that

we

have

discussed

so

far

Lemma

The

space

used

by

an

augmented

metablock

tree

containing

n

points

is

O

-LRB-

n

B

-RRB-

blocks

of

size

B.

Proof

The

additional

structures

that

we

have

added

to

the

metablock

tree

are

as

follows

ffl

the

update

block

for

every

metablock

and

ffl

the

TD

corner

structure

and

its

update

block

for

every

non-leaf

node

Every

metablock

contains

O

-LRB-

-RRB-

points

and

having

one

update

block

per

metablock

obviously

does

not

add

to

the

asymptotic

complexity

of

the

storage

used

A

TD

corner

structure

for

a

nonleaf

block

contains

at

most

points

and

therefore

occupies

no

more

than

O

-LRB-

B

-RRB-

blocks

as

per

Lemma

Since

every

metablock

contains

at

least

O

-LRB-

-RRB-

points

we

can

charge

the

cost

of

the

TD

corner

structure

to

it

This

implies

that

the

total

storage

used

by

the

augmented

metablock

tree

is

O

-LRB-

n

B

-RRB-

disk

blocks

Lemma

An

augmented

metablock

tree

containing

n

points

can

answer

diagonal

corner

queries

in

optimal

O

-LRB-

logB

n

t

B

-RRB-

I/O

operations

Proof

The

search

procedure

for

an

augmented

metablock

tree

is

very

similar

to

that

of

a

normal

metablock

tree

The

differences

are

as

follows

ffl

Every

time

a

horizontal

organization

or

a

vertical

organization

or

a

corner

structure

of

a

metablock

is

to

be

examined

we

will

examine

the

update

block

of

the

metablock

as

well

This

obviously

will

not

add

to

the

asymptotic

complexity

of

the

querying

because

examining

any

of

these

organizations

imposes

an

overhead

of

at

least

one

disk

I/O

and

the

update

block

increases

it

by

at

most

one

ffl

Every

time

a

TS

structure

of

a

metablock

needs

to

be

examined

we

will

examine

the

TD

corner

structure

of

the

parent

This

does

not

change

the

asymptotic

complexity

of

the

query

because

the

TD

corner

structure

imposes

only

a

constant

overhead

for

a

search

-LRB-

outside

of

the

reporting

which

pays

for

itself

-RRB-

and

this

overhead

is

imposed

by

the

TS

structure

anyway

Modulo

these

changes

the

query

procedure

remains

exactly

the

same

The

lemma

follows

from

the

previous

proof

for

Theorem

Lemma

Insertions

into

an

augmented

metablock

tree

containing

n

points

can

be

performed

in

O

-LRB-

logB

n

-LRB-

logB

n

-RRB-

B

-RRB-

amortized

I/O

operations

Proof

Finding

and

inserting

a

point

into

the

appropriate

metablock

involves

O

-LRB-

logB

n

-RRB-

disk

I/O

's

Let

us

consider

the

different

reorganizations

that

the

insertion

of

a

point

into

a

metablock

M

can

lead

to

and

list

the

amortized

costs

of

each

of

these

reorganizations

The

insertion

of

a

point

can

cause

a

level

I

reorganization

of

the

metablock

M

into

which

it

is

inserted

Since

this

happens

only

once

per

B

inserts

the

amortized

cost

for

this

is

O

-LRB-

-RRB-

The

insertion

of

a

point

can

cause

a

reorganization

of

the

TD

corner

structure

of

M

's

parent

metablock

Since

this

happens

only

once

per

B

inserts

the

amortized

cost

for

this

is

O

-LRB-

-RRB-

The

insertion

of

a

point

can

cause

a

TS

reorganization

of

M

and

its

siblings

This

happens

once

in

O

-LRB-

-RRB-

inserts

and

costs

O

-LRB-

-RRB-

I/O

's

The

amortized

cost

is

O

-LRB-

-RRB-

The

insertion

of

a

point

can

cause

a

level

II

reorganization

of

the

metablock

into

which

it

is

inserted

The

amortized

cost

of

this

is

also

O

-LRB-

-RRB-

because

this

happens

once

in

insertions

and

costs

O

-LRB-

-RRB-

disk

I/O

's

Note

that

we

do

n't

count

the

cost

of

inserting

the

points

further

down

in

the

tree

nor

the

cost

of

keeping

the

branching

factor

within

here

They

are

discussed

separately

below

At

the

end

of

a

level

II

reorganization

-LRB-

which

must

eventually

happen

as

points

are

continuously

being

inserted

into

M

-RRB-

the

inserted

point

has

been

either

inserted

into

a

child

of

M

or

has

forced

some

other

point

to

be

inserted

there

This

is

because

after

M

reaches

a

size

of

the

bottom

points

are

inserted

into

M

's

children

This

means

that

an

inserted

point

can

cause

these

reorganizations

all

the

way

down

to

the

leaf

This

gives

us

a

total

amortized

cost

of

O

-LRB-

logB

n

-RRB-

for

these

reorganizations

At

the

end

of

the

situation

described

above

the

inserted

points

have

trickled

down

to

the

bottom

of

the

metablock

tree

or

have

caused

other

points

to

get

trickled

down

The

final

cost

for

the

insertion

comes

from

the

fact

that

we

have

to

reorganize

subtrees

once

the

branching

factor

of

a

node

reaches

The

following

statements

are

easily

proved

by

induction

ffl

If

a

subtree

rooted

at

M

has

k

points

to

start

with

and

no

branching

factor

in

the

subtree

exceeds

B

we

have

to

insert

at

least

k

points

into

it

before

the

branching

factor

of

M

becomes

ffl

It

costs

O

-LRB-

-LRB-

k

B

-RRB-

logB

k

-RRB-

disk

I/O

's

to

build

a

perfectly

balanced

metablock

tree

with

k

points

The

amortized

cost

per

point

for

this

building

is

-LRB-

-LRB-

logB

k

-RRB-

B

-RRB-

An

inserted

point

contributes

to

the

cost

of

these

rebuilds

from

the

leaf

level

all

the

way

upto

the

root

The

amortized

cost

per

point

is

x

logB

n

X

x

x

B

O

-LRB-

-LRB-

logB

n

-RRB-

B

-RRB-

The

lemma

follows

when

we

add

up

the

costs

for

the

trickling

down

and

the

rebuilding

We

put

everything

together

in

the

following

theorem

Theorem

A

set

of

n

data

points

-LRB-

x

y

-RRB-

in

the

planar

region

y

x

and

y

can

be

organized

into

an

augmented

metablock

tree

with

blocks

of

size

B

such

that

a

diagonal

corner

query

with

t

data

points

in

its

query

region

can

be

performed

in

O

-LRB-

logB

n

t

B

-RRB-

I/O

operations

and

points

can

be

inserted

into

this

data

structure

at

an

amortized

cost

of

O

-LRB-

logB

n

-LRB-

logB

n

-RRB-

B

-RRB-

disk

I/O

's

The

size

of

the

data

structure

is

O

-LRB-

n

B

-RRB-

blocks

of

size

B

each

A

Class

Indexing

Algorithm

Using

Hierarchy

Decomposition

In

Section

we

showed

how

to

solve

the

class

indexing

problem

such

that

the

worst-case

query

time

is

O

-LRB-

c

logBn

t

B

-RRB-

the

worst-case

update

time

is

O

-LRB-

c

logBn

-RRB-

and

the

storage

used

is

O

-LRB-

-LRB-

n

B

-RRB-

-LRB-

c

-RRB-

-RRB-

disk

blocks

Here

c

is

the

size

of

the

class

hierarchy

n

is

the

size

of

the

problem

and

B

is

the

disk

block

size

In

this

section

we

have

a

preliminary

lemma

concerning

our

ability

to

answer

queries

We

then

consider

two

extremes

of

the

class

indexing

problem

and

show

that

they

both

have

efficient

solutions

We

call

a

class

hierarchy

degenerate

when

it

consists

of

a

tree

where

every

node

has

only

one

child

We

give

efficient

solutions

to

the

class

indexing

problem

when

the

hierarchy

is

degenerate

and

when

the

hierarchy

has

constant

depth

Combining

these

techniques

we

give

an

efficient

solution

to

the

whole

problem

Lemma

-LSB-

-RSB-

There

exists

a

data

structure

that

can

answer

any

query

on

a

set

of

n

points

on

the

plane

in

O

-LRB-

n

t

B

-RRB-

disk

I/O

's

This

data

structure

occupies

O

-LRB-

n

B

-RRB-

disk

blocks

and

can

be

built

in

O

-LRB-

-LRB-

n

B

-RRB-

logB

n

-RRB-

disk

I/O

's

A

data

structure

to

achieve

these

bounds

was

presented

in

-LSB-

-RSB-

The

data

structure

is

essentially

a

priority

search

tree

where

each

node

contains

B

points

A

simple

recursive

algorithm

can

build

this

tree

in

O

-LRB-

-LRB-

n

B

-RRB-

logB

n

-RRB-

disk

I/O

's

Lemma

Consider

an

instance

of

the

class

indexing

problem

where

k

is

the

maximum

depth

of

the

class

hierarchy

and

n

is

the

size

of

the

problem

instance

We

can

index

the

class

hierarchy

so

that

the

worst-case

query

time

is

O

-LRB-

logBn

t

B

-RRB-

the

worst-case

update

time

is

O

-LRB-

k

logBn

-RRB-

and

the

scheme

uses

O

-LRB-

-LRB-

n

B

-RRB-

k

-RRB-

storage

This

is

optimal

when

k

is

constant

Proof

We

simply

keep

the

full

extent

of

a

class

in

a

collection

associated

with

that

class

and

build

an

index

for

this

collection

This

might

entail

copying

an

item

at

most

k

times

since

k

is

the

maximum

depth

of

the

hierarchy

The

bounds

for

the

query

and

update

times

and

the

storage

space

follow

And

clearly

this

is

optimal

when

k

is

a

constant

It

should

be

pointed

out

that

this

lemma

does

not

contradict

Theorem

which

applies

when

we

have

only

one

copy

of

the

objects

in

the

database

Lemma

uses

k

copies

to

index

efficiently

Lemma

When

the

hierarchy

is

degenerate

the

class

indexing

problem

reduces

to

answering

queries

in

secondary

memory

and

can

be

solved

using

a

variant

of

the

metablock

tree

such

that

the

worst-case

query

time

is

O

-LRB-

logB

n

B

t

B

-RRB-

Proof

In

Section

we

reduced

the

class

indexing

problem

to

range

searching

in

secondary

memory

To

see

why

this

reduces

to

answering

queries

if

the

hierarchy

is

degenerate

consider

the

behavior

of

procedure

label-class

in

Figure

on

a

degenerate

hierarchy

The

root

of

this

hierarchy

will

be

associated

with

the

range

-LSB-

-RRB-

its

child

with

-LSB-

-RRB-

the

grandchild

Case

Case

Case

Case

Figure

Problems

with

using

the

metablock

tree

for

queries

with

-LSB-

-RRB-

and

so

on

Each

successive

range

is

completely

contained

in

its

previous

range

From

this

we

can

infer

that

a

query

on

the

full

extent

of

a

class

is

precisely

a

query

We

will

try

to

modify

the

metablock

tree

to

solve

this

problem

The

metablock

tree

solves

range

queries

in

secondary

memory

where

the

corner

always

lies

on

the

diagonal

queries

are

different

for

the

following

reasons

-LRB-

-RRB-

the

corners

need

not

lie

on

the

diagonal

of

a

metablock

-LRB-

-RRB-

both

corners

may

lie

on

the

same

metablock

for

this

problem

forcing

us

to

answer

a

query

on

a

metablock

-LRB-

-RRB-

both

the

vertical

sides

of

a

query

may

pass

through

the

same

metablock

-LRB-

remember

that

a

query

has

only

one

vertical

side

-RRB-

-LRB-

-RRB-

the

two

vertical

sides

of

the

query

may

lie

on

metablocks

which

are

children

of

the

same

metablock

-LRB-

This

makes

the

TS

structures

useless

for

this

case

because

they

contain

points

from

all

the

siblings

to

the

left

We

now

are

interested

in

only

a

subset

of

them

-RRB-

and

-LRB-

-RRB-

in

the

construction

of

the

TS

structures

in

the

metablock

tree

we

build

them

assuming

that

the

query

will

always

contain

the

left

siblings

never

the

right

siblings

With

queries

this

assumption

is

no

longer

true

See

Figure

illustrating

these

cases

We

deal

with

these

problems

one

by

one

To

handle

-LRB-

-RRB-

and

-LRB-

-RRB-

we

build

for

the

points

in

each

metablock

a

data

structure

to

answer

queries

as

prescribed

in

Lemma

Since

that

data

structure

uses

optimal

storage

our

asymptotic

storage

does

not

change

Also

since

queries

are

generalizations

of

diagonal

queries

we

dispense

with

the

corner

structures

we

used

for

the

metablock

tree

Case

-LRB-

-RRB-

requires

no

special

handling

because

we

can

determine

the

points

of

a

metablock

that

lie

in

between

two

vertical

lines

by

looking

at

the

vertical

organization

for

the

metablock

We

handle

-LRB-

-RRB-

by

building

two

TS

structures

for

every

metablock

One

will

contain

points

from

left

siblings

and

the

other

from

right

siblings

The

most

difficult

problem

is

that

of

case

-LRB-

-RRB-

In

order

to

handle

cases

like

this

where

the

two

vertical

sides

of

the

query

lie

on

metablocks

that

are

siblings

we

perform

the

following

action

for

every

interior

-LRB-

non-leaf

-RRB-

metablock

M

we

combine

the

points

of

the

children

of

M

-LRB-

to

get

a

total

of

O

-LRB-

-RRB-

points

-RRB-

and

build

a

data

structure

to

answer

queries

as

prescribed

in

Lemma

The

understanding

is

that

this

structure

will

be

used

whenever

case

-LRB-

-RRB-

occurs

This

structure

will

be

called

the

structure

for

the

children

of

M

Figure

gives

a

modified

version

of

procedure

diagonal-query

to

handle

queries

The

time

bound

analysis

is

very

similar

to

the

one

in

Theorem

While

answering

a

sided

query

no

more

than

three

strucures

have

to

be

accessed

one

each

for

the

two

corners

of

the

query

and

one

for

the

case

where

the

vertical

sides

of

the

query

fall

on

sibling

-LRB-

-RRB-

procedure

-LRB-

query

q

node

M

-RRB-

-LRB-

-RRB-

if

query

q

is

then

-LRB-

-RRB-

if

M

contains

both

the

corners

of

q

-LRB-

-RRB-

use

the

structure

for

M

to

answer

the

query

return

-LRB-

-RRB-

else

if

both

the

vertical

sides

of

query

q

fall

inside

one

child

of

M

-LRB-

-RRB-

let

this

child

be

Mc

-LRB-

-RRB-

use

M

's

vertically

oriented

blocks

to

report

points

that

lie

in

between

the

vertical

sides

of

the

query

q

-LRB-

-RRB-

invoke

-LRB-

q

Mc

-RRB-

-LRB-

-RRB-

else

the

two

vertical

sides

fall

on

different

children

-LRB-

-RRB-

use

M

's

vertically

oriented

blocks

to

report

points

that

lie

in

between

the

vertical

lines

of

q

-LRB-

-RRB-

let

Ml

and

Mr

be

the

children

of

M

containing

the

left

and

right

sides

of

q

resp

-LRB-

-RRB-

let

Mk

be

the

children

of

M

in

between

Ml

and

Mr

-LRB-

-RRB-

use

the

structure

for

M

's

children

to

determine

points

of

Mk

that

fall

inside

the

query

-LRB-

-RRB-

if

any

of

Mk

fall

completely

inside

the

query

examine

its

children

using

the

horizontally

oriented

blocks

and

continue

downwards

until

the

boundary

of

the

query

is

reached

for

every

metablock

so

examined

-LRB-

-RRB-

invoke

-LRB-

left

side

of

q

Ml

-RRB-

-LRB-

-RRB-

invoke

-LRB-

right

side

of

q

Mr

-RRB-

-LRB-

-RRB-

else

query

q

is

-LRB-

-RRB-

if

M

contains

the

corner

of

query

q

-LRB-

-RRB-

use

the

structure

for

M

to

answer

the

query

return

-LRB-

-RRB-

else

corner

of

q

does

not

fall

inside

M

-LRB-

-RRB-

use

M

's

vertically

oriented

blocks

to

report

points

of

M

that

lie

inside

q

-LRB-

-RRB-

let

Ml

be

the

child

of

M

containing

the

vertical

side

of

q

-LRB-

-RRB-

let

Mk

be

the

other

children

of

M

intersecting

q

-LRB-

-RRB-

use

the

appropriate

TS

structure

of

Ml

to

determine

the

points

of

Mk

and

their

descendants

that

fall

inside

the

query

-LRB-

as

above

-RRB-

-LRB-

-RRB-

invoke

-LRB-

q

Ml

-RRB-

Figure

Procedure

to

answer

queries

metablocks

-LRB-

i.e.

case

-LRB-

-RRB-

-RRB-

All

these

structures

have

or

less

points

in

them

and

by

the

bounds

of

Lemma

can

be

used

to

answer

queries

in

O

-LRB-

B

t

B

-RRB-

disk

I/O

's

Combining

this

with

the

bounds

of

Theorem

we

get

this

lemma

Lemma

There

exists

a

data

structure

that

can

answer

any

query

on

a

set

of

n

points

in

O

-LRB-

logB

n

B

t

B

-RRB-

disk

I/O

's

Points

can

be

inserted

to

this

data

structure

at

an

amortized

cost

of

O

-LRB-

logB

n

-LRB-

n

-RRB-

B

-RRB-

per

operation

and

the

storage

space

required

is

O

-LRB-

n

B

-RRB-

Proof

The

proof

of

this

lemma

parallels

that

of

Lemma

The

corner

structures

that

we

build

-LRB-

-RRB-

procedure

label-edges

-LRB-

root

-RRB-

-LRB-

-RRB-

S

f

children

of

root

g

-LRB-

-RRB-

Max

element

of

S

with

the

maximum

number

of

descendants

Break

ties

arbitrarily

-LRB-

-RRB-

Label

edge

between

Max

and

root

as

thick

-LRB-

-RRB-

Label

edges

between

other

children

and

root

as

thin

-LRB-

-RRB-

Apply

procedure

label-edges

recursively

to

each

child

of

root

order

irrevelant

Figure

An

algorithm

for

labeling

a

tree

with

thick

and

thin

edges

as

used

in

Lemma

for

that

proof

become

structures

In

particular

the

TD

corner

structure

for

an

internal

node

M

becomes

a

structure

also

This

will

have

an

update

block

as

the

TD

corner

structure

did

before

and

will

be

rebuilt

once

in

B

insertions

When

its

size

reaches

the

structure

for

the

children

of

M

will

be

rebuilt

as

will

the

TS

structures

for

the

children

of

M

As

before

a

level

I

reorganization

of

a

metablock

involves

the

rebuilding

of

the

vertical

horizontal

and

organizations

of

a

metablock

A

level

II

reorganization

-LRB-

remember

that

a

level

II

reorganization

is

done

when

the

number

of

points

in

a

metablock

reaches

-RRB-

of

a

non-leaf

metablock

M

involves

-LRB-

-RRB-

the

rebuilding

of

the

vertical

horizontal

and

organizations

for

the

top

points

in

it

-LRB-

-RRB-

the

insertion

of

the

bottom

points

into

the

children

of

M

-LRB-

-RRB-

a

TS

reorganization

of

M

and

its

siblings

and

-LRB-

-RRB-

a

rebuilding

of

the

structure

built

for

M

and

its

siblings

Similarly

a

level

II

reorganization

of

a

leaf

metablock

M

involves

-LRB-

-RRB-

the

splitting

of

the

leaf

into

two

-LRB-

-RRB-

a

TS

reorganization

of

the

siblings

of

M

and

-LRB-

-RRB-

a

rebuilding

of

the

structures

for

the

siblings

of

M

Procedure

insert-point

in

Figure

with

minor

modifications

that

take

into

account

the

structures

can

be

used

to

perform

inserts

To

get

the

bounds

for

the

number

of

I/O

's

for

an

insert

we

note

that

a

structure

with

-LRB-

respectively

-RRB-

points

can

be

rebuilt

in

O

-LRB-

B

-RRB-

-LRB-

O

-LRB-

-RRB-

-RRB-

disk

I/O

's

as

per

Lemma

The

analysis

for

Lemma

applies

here

and

gives

us

the

required

bounds

We

now

show

how

to

combine

the

two

lemmas

above

so

that

we

can

deal

with

any

class

hierarchy

We

restrict

our

attention

to

hierarchies

that

are

trees

The

procedure

trivially

extends

to

forest

hierarchies

Before

that

we

need

an

algorithm

that

enables

us

to

decide

which

of

the

two

lemmas

to

apply

on

which

part

of

the

hierarchy

The

idea

for

the

hierarchy

tree

labeling

algorithm

is

from

a

dynamic

tree

algorithm

of

-LSB-

-RSB-

The

following

lemma

is

easily

proven

by

induction

Lemma

Let

the

procedure

label-edges

shown

in

Figure

be

applied

to

an

arbitrary

hierarchy

tree

of

size

c

The

number

of

thin

edges

from

a

leaf

of

this

hierarchy

tree

to

the

root

is

no

more

than

c

We

are

now

ready

to

prove

the

key

lemma

The

procedure

rake-and-contract

shown

in

Figure

takes

as

input

a

hierarchy

processed

by

label-edges

and

applies

procedures

outlined

in

the

proofs

-LRB-

-RRB-

procedure

rake-and-contract

-LRB-

root

-RRB-

-LRB-

-RRB-

repeat

-LRB-

-RRB-

for

each

leaf

L

connected

by

means

of

a

thin

edge

to

the

tree

do

-LRB-

-RRB-

index

collection

associated

with

L

-LRB-

-RRB-

copy

items

in

L

's

collection

to

its

parent

's

collection

-LRB-

-RRB-

delete

L

from

the

tree

and

mark

L

as

indexed

-LRB-

-RRB-

endfor

-LRB-

-RRB-

for

each

path

in

the

hierarchy

tree

composed

entirely

of

thick

edges

whose

sole

connection

to

the

rest

of

the

tree

is

by

means

of

a

thin

edge

-LRB-

or

ends

in

the

root

-RRB-

do

-LRB-

-RRB-

build

a

structure

for

the

path

-LRB-

as

described

in

Lemma

-RRB-

-LRB-

-RRB-

copy

all

the

collections

associated

with

the

nodes

of

the

path

into

the

collection

of

the

parent

of

the

topmost

node

in

the

path

-LRB-

-RRB-

mark

all

the

nodes

in

the

path

as

indexed

-LRB-

-RRB-

delete

all

the

nodes

in

the

path

from

the

hierarchy

tree

-LRB-

-RRB-

endfor

-LRB-

-RRB-

until

hierarchy

tree

is

made

up

of

one

node

only

Figure

The

rake

and

contract

algorithm

for

reducing

an

arbitrary

hierarchy

tree

of

Lemmas

and

appropriately

to

parts

of

the

hierarchy

Initially

we

associate

a

unique

collection

with

each

class

This

collection

will

contain

the

extent

-LRB-

not

the

full

extent

-RRB-

of

the

class

Lemma

Let

an

instance

of

the

class

indexing

problem

have

class

hierarchy

size

c

problem

size

n.

Let

us

index

the

collections

as

per

the

procedure

rake-and-contract

Then

we

have

No

extent

of

any

class

is

duplicated

more

than

c

times

Every

class

in

the

input

class

hierarchy

gets

indexed

in

the

sense

that

either

an

explicit

index

is

built

for

its

full

extent

-LRB-

which

means

that

a

query

on

this

class

is

simply

a

query

on

a

B

tree

-RRB-

or

a

structure

is

built

for

it

as

per

Lemma

-LRB-

which

means

that

a

query

on

this

class

can

be

answered

by

performing

a

query

on

the

structure

-RRB-

Proof

Consider

the

first

part

of

the

lemma

In

procedure

rake-and-contract

we

copy

the

extent

of

a

class

as

many

times

as

there

are

thin

edges

from

it

to

the

root

of

the

hierarchy

We

know

from

Lemma

that

there

are

no

more

than

c

thin

edges

from

any

leaf

to

the

root

Part

of

the

lemma

follows

It

is

easy

to

see

that

one

of

the

two

for

loops

in

procedure

rake-and-contract

runs

at

least

once

unless

the

hierarchy

has

size

one

This

is

a

simple

proof

-LRB-

-RRB-

In

the

beginning

there

are

leaves

attached

by

means

of

thin

edges

to

their

parents

and

-LRB-

-RRB-

if

the

nodes

attached

by

means

of

thin

edges

are

removed

there

are

path

-LRB-

s

-RRB-

composed

entirely

of

thick

edges

-LRB-

these

paths

exist

because

every

interior

node

has

at

least

one

thick

edge

coming

out

of

it

-RRB-

whose

sole

connection

to

the

rest

of

the

tree

is

a

thin

edge

Once

the

nodes

in

a

thick

path

are

deleted

case

-LRB-

-RRB-

has

to

apply

again

Figure

An

example

class

hierarchy

decomposition

for

the

same

reason

This

implies

that

every

iteration

of

the

repeat

loop

reduces

the

size

of

the

hierarchy

which

implies

that

the

algorithm

will

terminate

To

prove

part

we

first

claim

that

if

a

node

is

deleted

from

the

hierarchy

in

the

first

for

loop

in

procedure

rake-and-contract

its

collection

must

have

contained

the

full

extent

of

the

class

that

the

node

corresponds

to

This

trivially

follows

because

only

leaves

get

deleted

in

the

first

for

loop

-LRB-

because

every

interior

node

has

a

thick

path

coming

out

of

it

and

therefore

will

be

deleted

only

in

the

second

for

loop

-RRB-

We

now

claim

that

if

a

node

is

deleted

from

the

hierarchy

in

the

second

for

loop

in

procedure

rake-and-contract

its

collection

contains

the

extents

of

all

the

classes

in

its

descendants

except

for

the

ones

attached

to

it

by

means

of

a

thick

path

This

is

easily

proved

by

noting

that

whenever

we

delete

nodes

we

copy

their

collections

to

the

parent

upwards

in

the

tree

It

is

easy

to

show

Part

of

the

lemma

now

If

a

node

is

deleted

in

the

first

for

loop

a

class

indexing

query

on

the

corresponding

class

is

simply

a

query

on

the

index

built

for

it

since

this

index

contains

the

complete

extent

of

the

class

If

a

node

is

deleted

in

the

second

for

loop

it

must

have

been

part

of

a

path

consisting

entirely

of

thick

edges

Further

we

know

from

our

previous

claim

that

every

node

in

this

path

contains

its

complete

extent

except

for

the

nodes

in

the

thick

path

below

it

In

other

words

the

class

corresponding

to

the

node

can

be

thought

of

as

belonging

to

a

degenerate

hierarchy

Lemma

applies

here

and

therefore

an

indexing

query

on

the

class

can

be

answered

by

looking

at

the

query

structure

built

in

rake-and-contract

The

lemma

follows

See

Figure

for

an

example

of

how

a

hierarchy

is

processed

We

put

everything

together

in

the

following

theorem

Note

that

the

bounds

for

insertion

come

from

the

fact

that

an

object

can

be

represented

no

more

than

c

times

in

the

indexes

built

by

procedure

rake-and-contract

Theorem

An

instance

of

the

class

indexing

problem

where

c

is

the

size

of

the

input

class

hierarchy

n

is

the

size

of

the

problem

and

B

is

the

disk

block

size

can

be

solved

such

that

the

worst-case

query

time

is

O

-LRB-

logB

n

t

B

B

-RRB-

the

amortized

insertion

time

is

O

-LRB-

-LRB-

c

-RRB-

-LRB-

logB

n

-LRB-

n

-RRB-

B

-RRB-

per

operation

and

the

storage

space

required

is

O

-LRB-

-LRB-

n

B

-RRB-

c

-RRB-

Conclusions

and

Open

Problems

We

have

examined

I/O-efficient

data

structures

which

provide

indexing

support

for

data

models

with

constraint

programming

and

object-oriented

programming

features

Our

algorithms

for

in

dexing

constraints

have

optimal

storage

and

query

time

and

log-suboptimal

insert

performance

Our

algorithms

for

indexing

constraints

have

improved

space

and

query

performance

and

polylogsuboptimal

insert

performance

-LRB-

modulo

amortization

-RRB-

The

data

structures

in

Sections

and

should

be

viewed

as

existence

proofs

that

for

these

practical

cases

of

range

searching

close

to

optimal

I/O

performance

is

achievable

Our

new

data

structures

have

provably

good

performance

but

are

somewhat

complex

One

direction

to

focus

on

is

whether

simpler

data

structures

can

achieve

the

same

bounds

For

example

we

believe

that

the

class

indexing

algorithm

in

Section

is

practical

even

if

suboptimal

We

believe

that

it

should

be

possible

using

standard

data

structure

techniques

to

transform

our

insertion

bounds

from

amortized

to

worst-case

-LRB-

although

we

have

not

done

so

here

-RRB-

Whether

they

can

be

asymptotically

improved

is

an

open

question

The

performance

for

the

case

of

deletions

is

open

We

should

note

that

using

the

techniques

in

this

paper

to

dynamize

the

static

structure

of

-LSB-

-RSB-

it

is

possible

to

achieve

the

following

dynamic

bounds

-LRB-

-RRB-

indexing

constraints

in

O

-LRB-

n

B

-RRB-

pages

dynamic

query

I/O

time

O

-LRB-

n

t

B

-RRB-

and

amortized

update

time

O

-LRB-

n

-LRB-

n

-RRB-

B

-RRB-

and

-LRB-

-RRB-

indexing

classes

in

O

-LRB-

c

-LRB-

n

B

-RRB-

-RRB-

pages

dynamic

query

I/O

time

O

-LRB-

n

t

B

-RRB-

and

amortized

update

time

O

-LRB-

-LRB-

c

-RRB-

-LRB-

n

-LRB-

n

-RRB-

B

-RRB-

-RRB-

Some

progress

has

been

made

in

the

case

where

our

goal

is

to

handle

a

very

large

number

of

queries

in

a

batch

-LSB-

-RSB-

In

this

case

queries

can

be

answered

in

O

-LRB-

-LRB-

n

B

k

B

-RRB-

-LRB-

logM

B

-LRB-

n

B

-RRB-

-RRB-

t

B

-RRB-

I/Os

where

k

is

the

number

of

queries

being

processed

and

M

is

the

amount

of

main

memory

available

Recently

a

new

technique

called

path

caching

was

presented

in

-LSB-

-RSB-

to

convert

many

mainmemory

data

structures

like

the

priority

search

trees

segments

trees

etc.

into

efficient

secondary

storage

structures

For

example

it

is

shown

in

-LSB-

-RSB-

that

it

is

possible

to

implement

priority

search

trees

in

secondary

memory

so

that

queries

can

be

answered

in

optimal

O

-LRB-

logB

n

t

B

-RRB-

disk

I/O

's

while

using

a

storage

of

O

-LRB-

-LRB-

n

B

-RRB-

B

-RRB-

Both

inserts

and

deletes

can

be

made

to

this

data

structure

The

amortized

cost

of

an

update

is

O

-LRB-

logB

n

-RRB-

We

close

with

the

most

elegant

open

question

can

dynamic

interval

management

on

secondary

storage

be

achieved

optimally

in

O

-LRB-

n

B

-RRB-

pages

query

I/O

time

O

-LRB-

logB

n

t

B

-RRB-

and

update

time

O

-LRB-

logB

n

-RRB-

References

-LSB-

-RSB-

R.

Bayer

and

E.

McCreight

Organization

of

Large

Ordered

Indexes

Acta

Informatica

-LRB-

-RRB-

-LCB-

-LSB-

-RSB-

J.

L.

Bentley

Algorithms

for

Klee

's

Rectangle

Problems

Dept.

of

Computer

Science

Carnegie

Mellon

Univ.

unpublished

notes

-LSB-

-RSB-

J.

L.

Bentley

Multidimensional

divide

and

conquer

CACM

-LRB-

-RRB-

-LRB-

-RRB-

-LCB-

-LSB-

-RSB-

G.

Blankenagel

and

R.

H.

G?uting

External

Segment

Trees

FernUniversit?at

Hagen

Informatik

-LCB-

Bericht

-LSB-

-RSB-

G.

Blankenagel

and

R.

H.

G?uting

XP-Trees

External

Priority

Search

Trees

FernUniversit?at

Hagen

Informatik

-LCB-

Bericht

Nr

-LSB-

-RSB-

B.

Chazelle

Lower

Bounds

for

Orthogonal

Range

Searching

I

The

Reporting

Case

J.

ACM

-LRB-

-RRB-

-LRB-

-RRB-

-LCB-

-LSB-

-RSB-

Y.-J

Chiang

and

R.

Tamassia

Dynamic

Algorithms

in

Computational

Geometry

Proceedings

of

IEEE

Special

Issue

on

Computational

Geometry

-LRB-

-RRB-

-LRB-

-RRB-

-LCB-

-LSB-

-RSB-

E.

F.

Codd

A

Relational

Model

for

Large

Shared

Data

Banks

CACM

-LRB-

-RRB-

-LRB-

-RRB-

-LCB-

-LSB-

-RSB-

D.

Comer

The

Ubiquitous

B-tree

Computing

Surveys

-LRB-

-RRB-

-LRB-

-RRB-

-LCB-

-LSB-

-RSB-

H.

Edelsbrunner

A

new

Approach

to

Rectangle

Intersections

Part

II

Int

J.

Computer

Mathematics

-LRB-

-RRB-

-LCB-

-LSB-

-RSB-

H.

Edelsbrunner

A

new

Approach

to

Rectangle

Intersections

Part

I

Int

J.

Computer

Mathematics

-LRB-

-RRB-

-LCB-

-LSB-

-RSB-

M.

L.

Fredman

A

Lower

Bound

on

the

Complexity

of

Orthogonal

Range

Queries

J.

ACM

-LRB-

-RRB-

-LCB-

-LSB-

-RSB-

M.

T.

Goodrich

J.-J

Tsay

D.

E.

Vengroff

and

J.

S.

Vitter

External-Memory

Computational

Geometry

Proc

Annual

IEEE

Symposium

on

Foundations

of

Computer

Science

-LRB-

-RRB-

-LCB-

-LSB-

-RSB-

O.

G?unther

The

Design

of

the

Cell

Tree

An

Object-Oriented

Index

Structure

for

Geometric

Databases

Proc

of

the

fifth

Int

Conf

on

Data

Engineering

-LRB-

-RRB-

-LCB-

-LSB-

-RSB-

Antonin

Guttman

R-Trees

A

Dynamic

Index

Structure

for

Spatial

Searching

Proc

ACM-SIGMOD

Conference

on

Management

of

Data

-LRB-

-RRB-

-LCB-

-LSB-

-RSB-

C.

Icking

R.

Klein

and

T.

Ottmann

Priority

Search

Trees

in

Secondary

Memory

-LRB-

Extended

Abstract

-RRB-

Lecture

Notes

In

Computer

Science

Springer-Verlag

-LSB-

-RSB-

J.

Jaffar

and

J.

L.

Lassez

Constraint

Logic

Programming

Proc

ACM

POPL

-LRB-

-RRB-

-LCB-

-LSB-

-RSB-

P.

C.

Kanellakis

G.

M.

Kuper

and

P.

Z.

Revesz

Constraint

Query

Languages

Proc

ACM

PODS

-LRB-

-RRB-

-LCB-

Invited

to

the

special

issue

of

JCSS

on

Principles

of

Database

Systems

-LRB-

to

appear

-RRB-

A

complete

version

of

the

paper

appears

in

Technical

Report

Brown

University

-LSB-

-RSB-

W.

Kim

K.

C.

Kim

and

A.

Dale

Indexing

Techniques

for

Object-Oriented

Databases

in

Object-Oriented

Concepts

Databases

and

Applications

W.

Kim

and

F.

H.

Lochovsky

eds.

Addison-Wesley

-LCB-

-LSB-

-RSB-

W.

Kim

and

F.

H.

Lochovsky

eds.

Object-Oriented

Concepts

Databases

and

Applications

Addison-Wesley

-LSB-

-RSB-

D.

B.

Lomet

and

B.

Salzberg

The

hB-Tree

A

Multiattribute

Indexing

Method

with

Good

Guaranteed

Performance

ACM

Transactions

on

Database

Systems

-LRB-

-RRB-

-LRB-

-RRB-

-LCB-

-LSB-

-RSB-

C.

C.

Low

B.

C.

Ooi

and

H.

Lu

H-trees

A

Dynamic

Associative

Search

Index

for

OODB

Proc

ACM

SIGMOD

-LRB-

-RRB-

-LCB-

-LSB-

-RSB-

D.

Maier

and

J.

Stein

Indexing

in

an

Object-Oriented

DBMS

IEEE

Proc

International

Workshop

on

Object-Oriented

Database

Systems

-LRB-

-RRB-

-LCB-

-LSB-

-RSB-

E.

M.

McCreight

Priority

Search

Trees

SIAM

Journal

of

Computing

-LRB-

-RRB-

-LRB-

-RRB-

-LCB-

-LSB-

-RSB-

J.

Nievergelt

H.

Hinterberger

and

K.

C.

Sevcik

The

Grid

File

An

Adaptable

Symmetric

Multikey

File

Structure

ACM

Transactions

on

Database

Systems

-LRB-

-RRB-

-LRB-

-RRB-

-LCB-

-LSB-

-RSB-

J.

A.

Orenstein

Spatial

Query

Processing

in

an

Object-Oriented

Database

System

Proc

ACM

SIGMOD

-LRB-

-RRB-

-LCB-

-LSB-

-RSB-

M.

H.

Overmars

M.

H.

M.

Smid

M.

T.

de

Berg

and

M.

J.

van

Kreveld

Maintaining

Range

Trees

in

Secondary

Memory

Part

I

Partitions

Acta

Informatica

-LRB-

-RRB-

-LCB-

-LSB-

-RSB-

S.

Ramaswamy

and

S.

Subramanian

Path

Caching

A

Technique

for

Optimal

External

Searching

-LRB-

to

appear

in

the

-RRB-

Proc

ACM

PODS

-LRB-

-RRB-

-LSB-

-RSB-

J.

T.

Robinson

The

K-D-B

Tree

A

Search

Structure

for

Large

Multidimensional

Dynamic

Indexes

Proc

ACM

SIGMOD

-LRB-

-RRB-

-LCB-

-LSB-

-RSB-

H.

Samet

Applications

of

Spatial

Data

Structures

Computer

Graphics

Image

Processing

and

GIS

Addison-Wesley

-LSB-

-RSB-

H.

Samet

The

Design

and

Analysis

of

Spatial

Data

Structures

Addison-Wesley

-LSB-

-RSB-

T.

Sellis

N.

Roussopoulos

and

C.

Faloutsos

The

R

Tree

A

Dynamic

Index

for

MultiDimensional

Objects

Proc

VLDB

Conference

Brighton

England

-LRB-

-RRB-

-LSB-

-RSB-

D.

D.

Sleator

and

R.

E.

Tarjan

A

Data

Structure

for

Dynamic

Trees

J.

Computer

and

System

Sciences

-LRB-

-RRB-

-LCB-

-LSB-

-RSB-

M.

H.

M.

Smid

and

M.

H.

Overmars

Maintaining

Range

Trees

in

Secondary

Memory

Part

II

Lower

Bounds

Acta

Informatica

-LRB-

-RRB-

-LCB-

-LSB-

-RSB-

J.

S.

Vitter

Efficient

Memory

Access

in

Large-Scale

Computation

Symposium

on

Theoretical

Aspects

of

Computer

Science

-LRB-

STACS

-RRB-

Lecture

Notes

in

Computer

Science

-LRB-

-RRB-

invited

paper

-LSB-

-RSB-

S.

Zdonik

and

D.

Maier

Readings

in

Object-Oriented

Database

Systems

Morgan

Kaufmann

constraint and object-oriented databases

external dynamic k-dimensional range searching