Highlights of Object-Database Systems

1. Highlights of Object-Database Systems Chapter 21 Plus a few words about Deductive Databases (Chapter 20)

2. Limitations of the Relational Model • limited constraints expressible • limited types of relationships • normalization leads to atomization, inefficiency • Limited built-in data types • No support for complex objects, user-defined types • BLOBs (binary large objects) are one workaround

3. Pressures on Traditional RDBMSs • From end-users: desire to store and retrieve non-traditional data • From SW development community: desire to integrate today’s languages with DB By lucky coincidence, both parties converge on OO as a solution to many problems

4. Evolving End-User Needs • Complex objects: pictures, video, X-Rays, CAD drawings, sound files, time series, etc. • Unstructured data from heterogeneous sources: document scans, commercial data services, the Web, etc. • Historical data • to "mine" for unsuspected value • versions (for change control)

5. SW Development Community • SW Development community has come to expect C++/Java environment • class libraries, inheritance • GUI, event-based programming • Want to develop DB in the same environment • COBOL and DB grew up together • COBOL pioneered the "record" construct • character-based types • Poor fit to today's languages like C++

6. A Look Back • Before we look ahead... • Hierarchical and Network (CODASYL) models were popular before relational • Network had extremely rich semantics • Complex relationships directly expressed (no joins) • Primarily "navigational" • Custom programs locate data via knowledge of schema, following pointers • No standardized query languages

7. Object-Oriented Trends • Trends in OO Programming seem promising for databases • Rich, user-defined data types • support of new media • lift 1NF restriction • Inheritance (important type of relationship) • Encapsulation of data and functions • Increasing emphasis on components and reusability; cross-platform operation • Tighter integration with C++, Java

8. ORDBMS vs OODBMS • Object-relational DBMS (ORDBMS): relational system with some object features added in • Approach taken by major DB vendors (in different forms) • Approach taken by SQL evolution • Object-oriented DBMS (OODBMS) • More radical rethinking of DBMS • Tight fit to C++ or Java

9. Strict OO Viewpoint • Where possible: model the behavior and relationships of the real world • Everything is an object • Objects communicate only by passing messages • In practice, a message is a function name plus a set of arguments • Types can be determined at run-time • Smalltalk is the model: untyped; interpreted; interactive

10. Object Identifiers (OIDs) • Unique (database-wide) identifier for each object • similar in concept to a pointer, but is permanent • independent of key • One object can reference another via OID • Allows complex embedding without data duplication • somewhat similar to use of a foreign key • Increases referential integrity problems

11. Hybrids and Compromises I • Coming from a traditional RDBM • Will retain relational facilities • Add support for user-defined types • type constructors • support for methods • maybe support for specialized indexes • Add OIDs and reference objects • Add inheritance • Modify existing query language • SQL3/SQL4 will have OO features

12. Hybrids and Compromises II • Coming from C++/Java • Add "persistence”: class objects automatically saved on disk • Add TP support • Add a query language

13. Persistence • The idea: it's easy for a program to work with a complex data structure in memory, but hard to flatten it into a file. • It would be convenient if some variables were persistent, i.e., could exist on disk between executions of the program, i.e., be part of the DB. • Not strictly on OO concept • One challenge: mapping OIDs between in-memory pointers and disk addresses • "pointer swizzling"

14. Challenges for Query Languages • DDL: coordinating PL with QL • Encapsulation issues • how much is visible? • must all operations be predefined? • Multimedia • what does "query" mean? • how to display results? • Typical: user must “register” methods with DBMS

15. OO Wrapup • Commercial DBMSs are evolving into ORDBMSs • User-defined ADTs • Inheritance • All the old reliable stuff (TP) • Also coming: Web as a DB source

16. Deductive Databases I • See chapter 20 • Another (non-OO) approach to relieving relational limitations • Admits recursive queries such as transitive closures: “Give me all of John’s ancestors” • Excellent at expressing complex constraints, making deductions and discoveries, etc. • DB viewed as a set of facts and rules • a row can be viewed as a fact which satisfies a predicate

17. Deductive Databases II • Query languages • Datalog: DB extension of Prolog • Logic-based • vastly different from SQL • but curiously, both are non-procedural • “fixpoint”: v is a fixpoint of a function f if f(v)= v • recognizing and computing fixpoints efficiently is the heart of recursive query processing • Thorny problem: negation • What part of “not” don’t you understand?