1 / 10

The Object-Oriented Database System Manifesto

The Object-Oriented Database System Manifesto. M. Atkinson, F. Bancilhon, D. DeWitt, K. Dittrich, D. Maier & S. Zdonik DOOD’89 Kyoto Japan. Motivation for paper. ”Proposition” paper Establish common ground for further development in Object-Oriented Database Systems (OODBS).

jziegler
Download Presentation

The Object-Oriented Database System Manifesto

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The Object-Oriented Database System Manifesto M. Atkinson, F. Bancilhon, D. DeWitt, K. Dittrich, D. Maier & S. Zdonik DOOD’89 Kyoto Japan

  2. Motivation for paper • ”Proposition” paper • Establish common ground for further development in Object-Oriented Database Systems (OODBS). • Establish guidelines for separating object oriented databases and non-object oriented databases. • The paper were meant to function as a roadmap for those doing OODBS research.

  3. Paper outline:What is needed in an OODBS? • Mandatory – Functionality necessary for an OODBS • Optional – Interesting functionality able to expand the usability of the OODBS • Open – Design issues; Few right and / or wrong answers exists.

  4. Mandatory properties (1) • Complex objects • Minimum: Set, list and tuples • Orthogonal constructors • Unique object identity • Equal or the same object? • Update and sharing issues • Encapsulation • Only operations should be visible • Methods for overriding encapsulation is necessary.

  5. Mandatory properties (2) • Types and classes • Types or classes are meant to replace database schemas. • Class or type hierarchies • Type or class hierarchy must be supported. • Overriding, overloading and late binding • A method is defined at the most general level (overriding) and can be redefined for subclasses (overloading). • Which version of method to be used is determined at runtime (late binding). • Computational completeness • Any computational function can be expressed using the DML of the database.

  6. Mandatory properties (3) • Extensibility • Possibility for defining new types. • New types must be handled as predefined types. • Persistence • Any object can become persistent.

  7. Mandatory properties (4) • Secondary storage management • Invisible database mechanisms to allow for reasonable performance. • Concurrency • Serializability must be offered. • Recovery • Must be able to recover for hardware and software failure. • Ad Hoc Query Facility • Must be high level, efficient and application independent.

  8. Optional properties • Multiple inheritance • Type checking and type inferencing • Distribution • Design transactions • Versions

  9. Open choices • Programming paradigm • Representation system • Type system • Uniformity

  10. Conclusion • The authors invite to further discussion based on the suggested requirements for OODBS.

More Related