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

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 1/16/2019

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 1/16/2019

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) 1/16/2019

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++ 1/16/2019

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 1/16/2019

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 1/16/2019

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 1/16/2019

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 1/16/2019

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 1/16/2019

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 1/16/2019

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

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" 1/16/2019

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 1/16/2019

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 1/16/2019

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 1/16/2019

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? 1/16/2019