• Save
The Object Oriented Database System Manifesto
Upcoming SlideShare
Loading in...5
×
 

The Object Oriented Database System Manifesto

on

  • 3,055 views

Presentation given at the GlobIS research seminar

Presentation given at the GlobIS research seminar

Statistics

Views

Total Views
3,055
Views on SlideShare
3,043
Embed Views
12

Actions

Likes
4
Downloads
0
Comments
0

1 Embed 12

http://www.slideshare.net 12

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

The Object Oriented Database System Manifesto The Object Oriented Database System Manifesto Presentation 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 "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)
  • 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)
  • 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
  • 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)
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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)
  • 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
  • Concurrency "Thou shalt accept concurrent users" • Support standard notion of atomicity of a sequence of operations and of controlled sharing
  • 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
  • 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
  • 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"