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 object- oriented 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