1. 1 Object Databases: Introduction

2. 2 Why OO? v Relational Systems are limited: –Structural restrictions on data –Missing semantics (value-based relationships) –Linguistic limitations (SQL and Algebra) v PL community’s OO work is appealing: –More “realistic” data structures –Explicit relationships and behavior modeling –“Tighter” interface between DBMS and PL v New applications: –CAD, OIS, hypertext, geograph. data, multimedia, medical data, music, hierarchical data,...

3. 3 OODBMS Features v Complex Objects (set, tuple, list) v OID (value-independent, permanent) –Allows explicit (vs. value-based) relationships v Encapsulation (overriding it?) –Methods (behavior) model ICs as part of data model v Classes/Types (maintain extents?) v Subclasses (multiple superclasses?) v Late binding for overridden methods v Turing-complete host language

4. 4 OODBMS Features (cont.) v Seamless type extensibility v Persistence enforced by system v Handle large DBs (indexing, buffering, etc.) v Concurrency support v Recovery support v Must provide a simple (declarative, optimizable) query language v Separate constraint mechanisms? v Views?

5. 5 Solution 1: Object-Oriented DBMS v Idea: Take an OO language like C++, add persistence, collections, queries, …. v class frame { int frameno; jpeg *image; int category; } persistent set frames; foreach (frame *f, frames) return f->image->thumbnail(); v Shut down the program. Start it up again. Persistent vars (e.g. frames) retain values!

6. 6 OODBMS applications v OODBMSs good for: – complex data –easier integration with application code –integrated modeling of behavior and structure v Problems: –lack of backward compatibility –some argue it’s back to the network data model –standards still emerging (ODMG, OQL) v Many built from ground up, vs. C++ plus... v A modest success in the marketplace

7. 7 Solution 2: Object-Relational v Idea: Add OO features to the type system of SQL. I.e., “plain old SQL”, but... –columns can be of new types (ADTs) –user-defined methods on ADTs –columns can be of complex types –reference types and “deref” –inheritance –old SQL schemas still work! (backwards compatibility) v Many relational vendors moving this way (SQL3). Big business!

8. 8 Stonebraker’s Application Matrix No Query Query Complex Data Simple Data File System OODBMS RDBMS ORDBMS Thesis: Most applications will move to the upper right.

9. 9 Summary v OO/ORDBMS offers many new features. –But not clear how to use them! –Schema design techniques not well understood –Query processing techniques still in research phase. u A moving target for OO/OR DBAs! v Prediction: You will use an OO/ORDBMS in the future.

10. 10 Current Products v Some OR features supported in: –Oracle 8 –IBM DB2 –Informix UDS –UniSQL v Some OODBMS products: –O2 –ObjectStore –Objectivity –Versant, Jasmine, Titanium, Poet, …