The Object Oriented Database System Manifesto

The

Object

Oriented

Database

System

Paper Facts

• 1989

The Object-Oriented Database System Manifesto(246 citations)

M. Atkinson, F. Bancilhon, D. DeWitt, K. Dittrich,D. Maier, S. Zdonik

• 1990

Third-Generation Database System Manifesto(19 citations)

M. Stonebraker, L. Rowe, B. Lindsay, M. Carey,M. Brodie, P. Bernstein, D. Beech

Paper Facts...

• 1995

The Third Manifesto (9 citations)

H. Darwen, C. Date

'We believe that [object oriented] features are

orthogonal to the Relational Model, and therefore that

the Relational Model needs no extension, no

correction, no subsumption, and, above all, no

perversion, in order for them to be accommodated...'

OODBMS History

First Generation OODBMS:

• 1986

G-Base (Graphael, F)

• 1987

GemStone (Servio Corporation, USA)

• 1988

Vbase (Ontologic)

Statice (Symbolics)

OODBMS History...

Second Generation OODBMS:

• 1989

Ontos (Ontos)

ObjectStore (Object Design)

Objectivity (Objectivity)

Versant ODBMS (Versant Object Technology)

OODBMS History...

Third Generation OODBMS:

• 1990

Orion/Itasca (Microelectronics and Computer

Technology Cooperation, USA)

O2 (Altaïr, F)

Zeitgeist (Texas Instruments)

• 1991

ODMG formed (first standard released in 1993)

Overview

• Paper attemps to define an object-oriented database system

• Describes the main features and characteristics that a system must have to qualify as an object-oriented database system

• OODBMSs at the beginning of the 90s

lack of a common data model

lack of strong theoretical framework

strong experimental activity

Overview...

• Darwinian approach → hope that, out of the set of

experimental prototypes being built, a fit model will

emerge → risk of de facto standard

• Paper is separated into mandatory, optional and

open features

Mandatory Features (Golden Rules)

• An object-oriented database system must be a

DBMS and an object-oriented system

• DBMS

persistence, secondary storage management,

concurrency, recovery and ad hoc query facility

• Object-oriented system

complex objects, object identity, encapsulation, types

or classes, inheritance, overriding combined with late

binding, extensibility and computational completeness

Complex Objects

• Complex objects are built from simpler ones by

applying constructors to them

• The minimal set of constructors that the system

should have are set, tuple and list

• Constructors must be orthogonal

• Operations on a complex object must propagate

transitively to all its components (e.g. deep copy)

"Thou shalt support complex objects"

Object Identity

• Two notions of object equivalence: two objects

can be identical (same object) or equal (same

value)

• Object identity has impact on object sharing and

object updates

• Object identity "can be simulated" in a value-

based system by introducing explicit object

identifiers (places burden on the user)

"Thou shalt support object identity"

Encapsulation

• Distinguish between specification and

implementation and support for modularity

• Two views of encapsulation: programming

language view and the database adaption of that

view

• In the database world, it is not clear whether the

structural part of the type is part of the interface

"Thou shalt encapsulate thine objects"

Encapsulation...

• Proper encapsulation is obtained when only the

operations are visible and the data is hidden (may

be violated under certain conditions)

"Thou shalt encapsulate thine objects"

Types and Classes

• Type in an object-oriented system defines common features of a set of objects → type checking at compile time

• In general types can not be modified at run-time

• Classes (run-time notion) contains two aspects: object factory and object warehouse

Object Factory → create new objects

Object warehouse → extension (objects) attached to the class

"Thou shalt support types or classes"

Types and Classes...

• Classes can be manipulated at run-time

• Choice between types or classes should be left to

the designer of the system

• Not necessary for the system to automatically

maintain the extent of a type

"Thou shalt support types or classes"

Class or Type Hierarchies

• Helps code reusability

• At least four types of inheritance; substitution

inheritance, inclusion inheritance, constraint

inheritance and specialization inheritance

"Thine classes or types shalt inherit from their ancestors"

Overriding/loading, late binding

• A single name denotes different implementations

→ overloading

• Redefinition of the implementation for different

types → overriding

• Operation names are resolved at run-time → late

binding

"Thou shalt not bind prematurely"

Computational Completeness

• Should be possibe to express any computable

function, using the DML of the DB system

• Can be introduced through a reasonable

connection to existing programming languages

"Thou shalt be computationally complete"

Extensibility

• Set of predefined types

• Should be possible to define new types with no

distinction in usage between system defined and

user defined types

• Type constructors (tuples, sets, lists, etc.) don't

have to be extensible

"Thou shalt be extensible"

Persistence

• Evident from a database point of view but novelty

from a programming language point of view

• Persistence should be orthogonal (each object,

independent of its type, is persistence capable)

• User should not have to explicitly move or copy

data to make it persistent (implicit persistence)

"Thou shalt remember thy data"

Secondary Storage Management

• Supported through a set of mechansims: index

management, data clustering, data buffering,

access path selection and query optimization

• Should be invisible for the application programmer

"Thou shalt manage very large databases"

Concurrency

• Support standard notion of atomicity of a

sequence of operations and of controlled sharing

"Thou shalt accept concurrent users"

Recovery

• In case of hardware or software failures, the

system should recover, i.e. bring itself back to a

coherent state of the data

"Thou shalt recover from hardware and software failures"

Ad Hoc Query Facility

• Provide functionality of an ad hoc query language

(graphical browser could be sufficient)

• High level (declarative)

• Application independent

"Thou shalt have a simple way of querying data"

Optional Features (The Goodies)

• Multiple Inheritance

• Type checking and type inferencing

• Distribution

• Design transactions

• Versions

Open Features

• Programming Paradigm

• Representation System

• Type System

generic types, type generator,...

• Uniformity

are types and methods objects?

Conclusions

• Golden rules should be the definition of an object-

oriented database management system

• Paper is a proposal to be debatted

"Thou shalt question the golden rules"