the object oriented database system manifesto
TRANSCRIPT
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"