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

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

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

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

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

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

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

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

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

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

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

12. 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

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

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

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

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

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