U-1

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 todays 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 Johns 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 dont you understand?