ThirdGeneration Database System Manifesto

1
Third-Generation Database System Manifesto

• The Committee for Advanced DBMS Systems
• Michael Stonebraker, Lawrence A. Rowe, Bruce
  Lindsay, James Gray, Michael Carey, Michael
  Brodie, Philip Bernstein, David Beech
• ACM SIGMOD Record, Sep'1990

2
First generation database systems

• The network and hierarchical databases of the
  1970s
• The first systems to offer DBMS function in a
  unified system
• e.g. CODASYL, IMS

3
Second generation database systems

• relational databases of the 1980s
• data independence and non procedural data
  manipulation language
• e.g. DB2, INGRES, NON-STOP SQL, ORACLE, Rdb/VMS
• Focused on business data processing

4
Third generation database systems

• Problems with 2nd generation DBS
• inadequate for a broader class of applications
  (than business data processing)
• e.g. CAD, CASE, Hypertext,
• storing text segments, graphics, etc is usually
  difficult in 2nd gen. systems
• Does not support complex data (folders)
• Most vendors are working on functional
  enhancements on their 2nd gen. systems
• Surprising degree of consensus on these features
• 3rd gen systems includes the desired capabilities
  of next generation database systems

5
The tenets of third generation DBMS Tenet 1

• Besides traditional data management services,
  third generation DBMS will provide support for
  richer object structures and rules
• richer object structures characterize the
  capabilities to store and manipulate e.g. text
  and spatial data
• designer should be given the capability to
  specify a set of rules about data elements,
  records and collections

6
The tenets of third generation DBMS Tenet 2

• Third generation DBMSs must subsume second
  generation DBMSs
• The major contribution of 2nd gen. DBMS
• non procedural access
• data independence
• A query language is an absolute requirement
• Data independence have dramatically lowered the
  amount of program maintenance that must be done
  by applications and should not be abandoned

7
The tenets of third generation DBMS Tenet 3

• Third generation DBMSs must be open to other
  subsystems
• Must have
• fourth generation language
• various decision support tools
• friendly access from many programming languages
• interfaces to business graphics packages
• the ability to run the application on a different
  machine than the DBMS
• ......
• Third generation DBMS must be open
• Must be willing to participate in future
  distributed DBMS systems

8
Propositions concerning object and rule management

• A third generation DBMS must have a rich type
  system (se list in article)
• Inheritance is a good idea
• Functions including database procedures and
  methods, and encapsulation are a good idea
• Unique identifiers for records should be assigned
  by the DBMS only if a user defined primary key is
  not available
• Rules (triggers, constraints) will become a major
  feature in future systems. They should not be
  associated with a specific function or collection

9
Propositions concerning increasing DBMS function

• Essentially all programmatic access to a database
  should be through a non.procedural, high-level
  access language
• There should be at least two ways to specify
  collections, one using enumeration of members and
  one using the query language to specify
  membership
• Updateable views are essential
• performance indicators have almost nothing to do
  with data models and must not appear in them

10
Propositions that results from the necessity of
an open system

• Third generation DBMS must be accessible form
  multiple HLLs
• Persistent X for variety of Xs is a good idea.
  They will be supported on top of a single DBMS by
  compiler extensions and a (more or less) complex
  run time system
• For better or worse, SQL is intergalactic
  dataspeak
• Queries and their resulting answers should be the
  lowest level of communication between a client
  and a server

11
Summary

• Agree with OODB enthusiast on
• rich type system, functions, inheritance,
  encapsulation
• Disagree
• to narrowly focused on object management issues
• non-SQL, single language systems appealing to a
  fairly narrow market

12
Summary cont.

• DMBS access should only occur through a query
  language (20 years of history is convincing)
• Physical navigation by user programs and
  functions should be avoided
• Automatic collections should be encouraged
• Persistence should be added to a variety of
  programming languages (this has little to do with
  the data model)
• Unique identifiers should be user defined or
  system defined

13
Summary cont.

• A natural evolution from current RDBS to the ones
  with the capabilities discussed in this paper
• Many of the features are already supported by
  aggressive RDBS vendors
• inheritance, additional type constructors,
  persistent programming languages must be
  supported
• Current ODBS are not faithful to any of the
  tenets and some of the propositions
• query languages, rule system, SQL client/server
  support, views, persistent programming languages
  must be supported
• must undo hard coded requirements for UID and
  discourage navigation
• must build 4GL, support distributed databases,
  tune systems to perform efficient data management

14
Research and development challenges

• The design of persistent programming languages
  for existing HLL
• The inclusion of pleasing query language
  constructs
• Logical and physical database design will get
  more difficult with richer type systems and rules
• Optimisation of the execution of rules
• Tools to allow users to visualize and debug rule
  oriented applications