Transcript d03-atkinson

The Object-Oriented Database
System Manifesto
Malcolm Atkinson, François
Bancilhon, David deWitt, Klaus
Dittrich, David Maier, Stanley Zdonik
DOOD'89, Dec'89, Kyoto
Introduction
• The paper attempts to define an objectoriented database system, by the features
and characteristics a system must have to
qualify as an oodbs
Summary
• Mandatory
– Complex objects, object identity, encapsulation, types
of classes, inheritance, overriding combined with late
binding, extensibility, computational completeness,
persistence, secondary storage management,
concurrency, recovery, ad hoc query facility
• Optional
– Multiple inheritance, type checking, inferencing,
distribution, design transactions, versions
• Open
– Programming paradigm, representation system, type
system, uniformity
Characteristics of the field of
OODBMS (1989)
• Lack of a common data model
– No consensus on a formal model
• Lack of formal foundations
– No solid underlying theory is obvious
• Strong experimental activity
– Darwinian approach
Complex objects
• Built from simpler ones by applying
constructors to them
– E.g. tuples, sets, bags, lists, and arrays
• Minimal : sets, tuples, lists, and arrays
• Object constructors must be orthogonal
• Appropriate operators must be provided for
dealing with complex objects
Object identity
• Implicit object identity
• An object has existence independent on its value
• Object equivalence can be either
– Objects can be identical
– Objects can be equal
• Allows for
– Object sharing
– Object update
Encapsulation
• Objects have both a data part and an operation part
• Both data and operations are stored in the database
• No operations, outside those specified in the
interface, can be performed
• Proper encapsulation is only obtained when only
the operations are visible
• Encapsulations mechanism must be provided by
an OODBS, but there appear to be cases where its
enforcement is not appropriate
Types or Classes
• Type
– A type summarizes the common features of a set of
objects with the same characteristics
– A type is mainly used at compile time to check the
correctness of the program
• Class
–
–
–
–
The same specification as a type
A run-time notion
Object factory used to create new objects
Object warehouse is the extension attached to the class
• A set of types or classes will replace the database
schema
Class or Type Hierarchies
• Inheritance helps code reusability
• Different types of inheritance
–
–
–
–
substitution
inclusion
constraint
specialization
• No specific style of inheritance is
prescribed
Overriding, overloading and late
binding
• An operation is defined at the most general
level and redefine the implementation for
each type of object (overriding)
• The result is a single name denoting
different programs (overloading)
• Operation names must be resolved at run
time (late binding)
Computational completeness
• One can express any computational function
using the DML of the database
• Does not necessarily mean that OODBS
must define new programming languages
• Computational completeness can be
supported by a connection to existing
programming languages
Extensibility
• There must be a means to define new types
• No distinction in usage between system
defined and user defined types
Persistence
• A novelty from a programming language
point of view
• The ability for data to survive the execution
of a process
• Persistence should be orthogonal
– each object is allowed to become persistence
– should be implicit
Secondary storage management
• Usually supported by
– index management, data clustering, data
buffering, access path selection, query
optimization
• Performance features invisible to the user
• Not a task for the application programmer
• There should be a clear independence
between the logical and physical level
Concurrency, Recovery
• The system should support the same level of
service as current database systems provide
Ad hoc query facility
• provide the functionality of an ad hoc query
language (e.g. graphical rather than trad.
query language)
• Should satisfy the following
– be high level (what and not how)
– be efficient (query optimisation)
– application independence (should work on any
database)
Additional ?
• No consensus on whether the following are
mandatory or optional features
–
–
–
–
view definitions and derived data
database administration utilities
integrity constraints
schema evolution facility
Optional features
•
•
•
•
Multiple inheritance
Type checking and type inferencing
Distribution
Design transaction (long or nested
transactions)
• Versions
Open choices
• Programming paradigm
– choice of programming paradigm, independent on
programming paradigm and support multiple, syntax
• Representation system (set of atomic types and
constructors)
• Type system (type formers)
– only encapsulation is required
• Uniformity within a system
– implementation, programming, interface level
Conclusion
• The approach is in accordance with the
view that an OODBS is an DBMS with an
underlying object oriented data model
• This is a concrete proposal for a definition
of a OODBS to be debated, critiqued and
analysed