Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

The Object Oriented Database System Manifesto


Published on

Presentation given at the GlobIS research seminar

Published in: Technology

The Object Oriented Database System Manifesto

  1. 1. The Object Oriented Database System
  2. 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. 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. 4. OODBMS History First Generation OODBMS: • 1986  G-Base (Graphael, F) • 1987  GemStone (Servio Corporation, USA) • 1988  Vbase (Ontologic)  Statice (Symbolics)
  5. 5. OODBMS History... Second Generation OODBMS: • 1989  Ontos (Ontos)  ObjectStore (Object Design)  Objectivity (Objectivity)  Versant ODBMS (Versant Object Technology)
  6. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 22. Concurrency "Thou shalt accept concurrent users" • Support standard notion of atomicity of a sequence of operations and of controlled sharing
  23. 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. 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. 25. Optional Features (The Goodies) • Multiple Inheritance • Type checking and type inferencing • Distribution • Design transactions • Versions
  26. 26. Open Features • Programming Paradigm • Representation System • Type System  generic types, type generator,... • Uniformity  are types and methods objects?
  27. 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"