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 1970’s
The first systems to offer DBMS function in a unified system
e.g. CODASYL, IMS

3. Second generation database systems
relational databases of the 1980’s
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: Disagree
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