270 likes | 466 Views
The Object-Oriented Database System Manifesto. by Engin Deveci. Three Points Characterize. Lack of a common data model Lack of formal foundations Strong experimental activity. Must Satisfy Three Criteria. Should be a DBMS Should be an object oriented system
E N D
The Object-Oriented Database System Manifesto by Engin Deveci
Three Points Characterize • Lack of a common data model • Lack of formal foundations • Strong experimental activity
Must Satisfy Three Criteria • Should be a DBMS • Should be an object oriented system • Should be consistent with object oriented languages
Main Features and Characteristics of OODBMS • Mandatory Features • Optional Features • Open Features
Mandatory Features • Features for general databases • Features for object oriented databases
Features for General Databases • Persistence • Secondary storage management • Concurrency • Recovery • Ad-Hoc query facility
Overriding combined with late binding Extensibility Computational completeness Features for Object Oriented Databases • Complex objects • Object identity • Encapsulation • Types and classes • Inheritance
Thou shalt support complex objects Complex Objects • Simple objects • Integer, characters, byte string, boolean, float, vs. • Complex objects • Tuples, sets, bags, lists, arrays
Thou shalt support complex objects Complex Objects Cont’d • Object constructers must be orthogonal • Appropriate operators must be provided
Thou shalt support object identity Object Identity • Object sharing • Object updates
Thou shalt encapsulate thine objects Encapsulation • Interface and implementation • Modularity
Thou shalt support types and classes Types and Classes • Supporting the notion of class • Supporting the notion of type
Thine classes or types shalt inherit from their ancestors Class or Type Hierarchies • Substitution inheritance • Inclusion inheritance • Constraint inheritance • Specialization inheritance
Thou shalt not bind prematurely Late Binding • Overriding • Overloading • Late binding
Thou shalt be computationally complete Computational Completeness • SQL is not computationally complete • Reasonable connection to existing programming languages
Thou shalt be extensible Extensibility • System defined types • User defined types • No distinction in usage • Distinction in low level support
Thou shalt remember thy data Persistence • Data survival • Should be orthogonal • Should be implicit
Thou shalt manage very large databases Secondary Storage Management • Index management • Data management • Data clustering • Data buffering • Access path selection • Query optimization
Thou shalt accept concurrent users Concurrency • Same level of service • Harmonious coexistence • Atomicity of a sequence of operations • Controlled sharing • Serializability of operations
Thou shalt recover from hardware and software failures Recovery • Back to coherant state of data • Processor failures • Disk failures
Thou shalt have a simple way of querying data Ad Hoc Query Facility • Should be high level • Should be efficient • Should be application independent
No Consensus • View definition and derived data • Database administration utilities • Integrity constraints • Schema evolution facility
Optional Features • Multiple inheritance • Type checking and type inferencing • Distribution • Design transactions • Versions
Open Features • Programming paradigm • Representation system • Type system • Uniformity
Conclusion • Thou shalt question the golden rules Q&A