Extensibility & Object-Relational Systems

DBMS vs. OS Extensibility

OS extensibility raises the frightening question "what is an operating system" In the end, OS extensibility is hard to pin down because OSes have no functional spec.

By contrast, relational databases had a clear functional spec, SQL.  After its initial success, there was interest in bringing the functionality to new apps not met by the current spec.  This all got tied up in a war about object-orientedness (the DB community's history of models and languages became necessarily intwined with the system issues; OOness was hot back then.)  Resulted in two research thrusts:

Extensibility: The Ultimate API Design Challenge

Elegance of extensibility API drives both Performance and Functionality

Q: What's the difference between an API and a language?

Program as Proof, API as axioms

Note the top-down design philosophy! Basic engineering tension in extensible systems: flexibility vs. elegance Why isn't extensibility more popular in industry?

What's Wrong with Relational?

In the early 80ís, it became clear that Relational systems were not powerful enough for non-administrative data-intensive applications of the day: Can roll the logic in the app, but two key problems:


The relational data model (as implemented!) is "semantically impoverished":

Instead, people want a "semantically rich" data model Much vision & politics ensued: Systems were built, companies started, etc.

By now, the dust of battle has cleared:

Or has it?  XML looks kind of like a (sloppy, embarrassing) nested object representation, and XPath/XSL looks like the declarative features in some of the OODBs.  ObjectStore (Excelon) and Poet now trying to sell XML engines!

Systems History

Influential research systems: Today: focus on POSTGRES, discuss Starburst briefly.
 

Object-Relational Systems

Informix's buzzphrase for extensible relational systems (courtesy Roger Sippl).  Didn't patent the name!

Query-based, extensible systems with some OO features like ADTs, inheritance, complex types, OIDs.

SQL99 is very much like this.

Stonebrakerís application matrix:
 

Query  RDBMS ORDBMS 
No Query File Sys.  OODBMS 
  Simple Data Complex Data

Argues that the upper right is growing, and will engulf upper left and lower right.

Some Major Research Challenges in Obj-Rel Extensibility

ADTs and efficient declarative queries -- suddenly the semantics are encapsulated even to the DBMS!  Major theme of Postgres.  Many characteristic extensible API issues -- what MUST you know, what can you generalize without knowledge of specifics?

Complex Objects and efficiency.  A mix of extensibility features with "more hard problems in query optimization and indexing".
  • How to teach optimizer about new operators and their legal transformations.  (Exodus/Volcano, Starburst).
  • How to efficiently process queries on nested sets, arrays, etc.
  • How to do data modeling in this world.

  • Applications:

    Players:

    Stonebraker: Extensible ADTs

    Seminal paper.

    Idea: you should be able to add new atomic types to the system, along with methods for the types, and new access methods.

    Type is defined by:

    Then you could do standard relational processing over those types.

    Example: add 2d spatial operators to RDBMS

    Engineering issues (some from the paper, some not):

     Note: Extensible ADTs do not fundamentally change a relational system

    POSTGRES

    Stonebraker, Rowe, a few staff and many students, 1986-1994. Post-INGRES.

     The Postgres Data Model

    1. Co-opt the OO terminology
    2. Support extensible ADTs
    3. Support type constructors
    4. added class inheritance (gives method inheritance and collection hierarchies)
    Implementation Details Postgres Rule System: Active Database support. Other Postgres stuff Editorial Comments

    Starburst

    Original goal: build a nice playpen for whatever comes next.

    Extensible "in-house". Not by users!

    No one survey paper seems to capture the work they did. Best bet: "Starburst Mid-Flight: As The Dust Clears", Haas, et al., TKDE 1990

    Extensibility features:

    "Proofs" of Extensibility: Many of the Starburst folks took a "vacation" from research, and merged Starburst technology into DB2 UDB.