The Object Oriented Database System Manifesto
7 likes3,300 views
This document outlines the key features that an object-oriented database system should have according to a 1989 paper. It defines mandatory "golden rules" including supporting complex objects, object identity, encapsulation, types/classes, inheritance, late binding, extensibility, persistence, storage management, concurrency, recovery and querying. Optional features and open topics for debate are also discussed.
![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...'](https://image.slidesharecdn.com/oodbmsmanifesto-091103135540-phpapp02/85/The-Object-Oriented-Database-System-Manifesto-3-320.jpg)
The Object Oriented Database System Manifesto
- 2. 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
- 3. 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...'
- 4. OODBMS History First Generation OODBMS: • 1986 G-Base (Graphael, F) • 1987 GemStone (Servio Corporation, USA) • 1988 Vbase (Ontologic) Statice (Symbolics)
- 5. OODBMS History... Second Generation OODBMS: • 1989 Ontos (Ontos) ObjectStore (Object Design) Objectivity (Objectivity) Versant ODBMS (Versant Object Technology)
- 6. 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)
- 7. 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
- 8. 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
- 9. 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
- 10. Complex Objects "Thou shalt support 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)
- 11. Object Identity "Thou shalt support 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)
- 12. Encapsulation "Thou shalt encapsulate thine objects" • 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
- 13. Encapsulation... "Thou shalt encapsulate thine objects" • Proper encapsulation is obtained when only the operations are visible and the data is hidden (may be violated under certain conditions)
- 14. Types and Classes "Thou shalt support types or 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
- 15. Types and Classes... "Thou shalt support types or 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
- 16. Class or Type Hierarchies "Thine classes or types shalt inherit from their ancestors" • Helps code reusability • At least four types of inheritance; substitution inheritance, inclusion inheritance, constraint inheritance and specialization inheritance
- 17. Overriding/loading, late binding "Thou shalt not bind prematurely" • A single name denotes different implementations → overloading • Redefinition of the implementation for different types → overriding • Operation names are resolved at run-time → late binding
- 18. Computational Completeness "Thou shalt be computationally complete" • 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
- 19. Extensibility "Thou shalt be extensible" • 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
- 20. Persistence "Thou shalt remember thy data" • 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)
- 21. Secondary Storage Management "Thou shalt manage very large databases" • 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
- 22. Concurrency "Thou shalt accept concurrent users" • Support standard notion of atomicity of a sequence of operations and of controlled sharing
- 23. Recovery "Thou shalt recover from hardware and software failures" • In case of hardware or software failures, the system should recover, i.e. bring itself back to a coherent state of the data
- 24. Ad Hoc Query Facility "Thou shalt have a simple way of querying data" • Provide functionality of an ad hoc query language (graphical browser could be sufficient) • High level (declarative) • Application independent
- 25. Optional Features (The Goodies) • Multiple Inheritance • Type checking and type inferencing • Distribution • Design transactions • Versions
- 26. Open Features • Programming Paradigm • Representation System • Type System generic types, type generator,... • Uniformity are types and methods objects?
- 27. 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"