1. Why not Relational? Critique of Why Relational? The OODB Manifesto
The 3rd Generation DB Manifesto
11/15/2018
CS319 Theory of Databases

2. Modern context for general data modelling
Programs
11/15/2018
CS319 Theory of Databases

3. Perceived advantages of relational DBs 1
THEORY
simple data structure BUT
is a table really what we need?
simple operators BUT
sometimes want complicated operators?
set-level operators good, but also need local update?
no frivolous distinctions BUT
are things really just the same?
is the distinction between defining a view
and giving access rights frivolous?
different agent, action, and significance
11/15/2018
CS319 Theory of Databases

4. Perceived advantages of relational DBs 2
THEORY
sound theoretical base BUT
does theory really fit the real-world needs well?
e.g. in 4NF, are we tabulating functions?
how do we cope with design DB, animation, graphics, modes of interaction?
small number of concepts BUT
are there sufficient concepts?
are relations enough: problems with nulls etc, tension over 1NF?
11/15/2018
CS319 Theory of Databases

5. Perceived advantages of relational DBs 3
PRINCIPLES: PRACTICAL ASPECT …
SQL support BUT
what's intrinsically good about SQL?
to what extent is this pragmatism?
the view mechanism BUT
is the view mechanism general enough?
do we want to see tables, even if they are maintained automatically?
the dual-mode principle BUT
is there “an impedance mismatch”
are procedural programs the future?
11/15/2018
CS319 Theory of Databases

6. Perceived advantages of relational DBs 4
PRINCIPLES: PRACTICAL ASPECT …
physical data independence BUT
can we achieve in other ways e.g. info hiding?
do we pay too high a price in efficiency?
logical data independence BUT
to what extent do we need it?
are there other ways to meet demands?
would we like greater flexibility to access or not to access? how do we resolve issues of view update?
11/15/2018
CS319 Theory of Databases

7. Perceived advantages of relational DBs 5
PRINCIPLES: PRACTICAL ASPECT ...
dynamic data definition BUT
too narrow a perception of extendable? aren't objects extensible?
dynamism is only within the terms of reference of the relational model?
how about broader range of concerns, such as alternative visualisations?
11/15/2018
CS319 Theory of Databases

8. Perceived advantages of relational DBs 6
PRINCIPLES: FOUNDATIONAL ASPECT
simplified database design BUT
is the world really defined by dependency relations that can be captured in tables?
integrated dictionary: metadata-driven BUT
are integrity / security / privileges to access concepts well-represented by tables?
what about privileges determined by DB content?
why not use objects for management of OODB?
distributed database support: atomicity BUT
is this merely to do with maturity of DBs?
aren't objects good basis for distribution?
11/15/2018
CS319 Theory of Databases

9. Perceived advantages of relational DBs 7
CONSEQUENCES
ease of application development BUT
isn't this claimed for other technologies?
is this really to do with a relational data model?
ease of installation and ease of operations BUT
increasingly aspects of full system are outside the scope of the model: other overheads in setting up DB
e.g. in getting suitable interfaces to user / data
¥ performance BUT
is it really so good? isn't navigation faster?
¥ extendability BUT
is this to say that relational DBs are good because they are a good platform for better systems?
11/15/2018
CS319 Theory of Databases

10. Issues for database development
How to avoid "back to the future"?
need theoretical foundation
need qualities of declarative query
need principles to handle abstraction at many levels: data independence
need to support interaction of agents at high-levels of abstraction
need to retain/enhance the form-content relationships that relational DB design theory introduces
11/15/2018
CS319 Theory of Databases

11. Issues for database development
Modern database demands
enormous volumes of data
high-performance e.g. for multi-media, real-time
support for metaphor e.g. visual image not table
concurrent access, distributed data
closer integration of data access and programming
support for modern data abstractions:
objects, inheritance, aggregation
applicability to design environment needs: incremental intensional change
11/15/2018
CS319 Theory of Databases

12. Some Database manifestos
Classical applications for databases presume
uniformity: many data items of similar format
record orientation: fixed length records are the basic data item
fields are atomic: assume "1NF "
short transactions: typically fraction of a second, no human interaction
static conceptual schemes: infrequent change of DB scheme, mode of change is restricted
11/15/2018
CS319 Theory of Databases

13. Issues that emerged in the 80s ...
In context of new applications:
CAD, CASE, multi-media, GIS, expert DBs
had the development of new features:
rule-based integrity, triggers, knowledge emphasis
complex objects
complex data structured hierarchically
Þ OODBs + nested relational models
behavioural data
interdependent deletion of tuples
store behavioural info in DB
Þ methods and rule-based approaches
11/15/2018
CS319 Theory of Databases

14. Issues that emerged in the 80s
behavioural data
interdependent deletion of tuples
store behavioural information in DB
Þ methods and rule-based approaches
meta-knowledge
application data obeys complex rules
"a/c's pay interest only if balance > X"
Þ rule-based approaches
long transactions
need for undo, as in exploratory design
conflicts amongst transactions
11/15/2018
CS319 Theory of Databases

15. The Object-Oriented DB Manifesto 1
Atkinson et al 1989
Introduction motivates the manifesto with reference to
Characteristics of current OODB research:
(i) lack of common data model
(ii) lack of formal foundations
(iii) strong experimental activity
Mandatory features: The Golden Rules
Controversial, Optional and Open features
11/15/2018
CS319 Theory of Databases

16. The Object-Oriented DB Manifesto 2
Mandatory features: The Golden Rules
2.1. Thou shalt support complex objects
2.2. Thou shalt support object identity
2.3. Thou shalt encapsulate thine objects
2.4. Thou shalt support types or classes
2.5. Thine classes or types shalt inherit from their
ancestors
2.6. Thou shalt not bind prematurely
2.7. Thou shalt be computationally complete
2.8. Thou shalt be extensible
11/15/2018
CS319 Theory of Databases

17. The Object-Oriented DB Manifesto 3
Mandatory rules (cont.)
2.9. Thou shalt remember thy data
2.10. Thou shalt manage very large databases
2.11. Thou shalt accept concurrent users
2.12. Thou shalt recover from h/w & s/w failures
2.13. Thou shalt have a simple way to query data
Relational DBs don't satisfy Rules 1-8
CODASYL DBs partially satisfy rules 1&2
don't satisfy rules 3,5,6,8,13
11/15/2018
CS319 Theory of Databases

18. The Object-Oriented DB Manifesto 4
Controversial features: should be mandatory?
are views needed?
DBA utilities
integrity constraints
schema evolution facility
Optional features
Multiple inheritance
Type checking and inferencing
Distribution
Design transactions
Versions
11/15/2018
CS319 Theory of Databases

19. The Object-Oriented DB Manifesto 5
Open features
Programming paradigm
Representation system
Type system
Uniformity
Conclusions
OODBMS = DBMS with an underlying OO data model
Thou shalt question the golden rules
11/15/2018
CS319 Theory of Databases

20. The Third-Generation Database Manifesto 1
First generation DBMS:
Hierarchical and Network Systems
IMS and CODASYL
Second generation DBMS:
Relational Systems
dBase2, INGRES, ORACLE
non-procedural + data independence
11/15/2018
CS319 Theory of Databases

21. The Third-Generation Database Manifesto 2
Third generation DBMS ... ????
Preliminary note re neutral terminology
data element is atomic data value
every element has a data type
data elements can be assembled into records
a collection is a named set of records, each with same number and type of data elements
11/15/2018
CS319 Theory of Databases

22. The Third-Generation Database Manifesto 3
1. Introduction
Limitations of 2G DBMS ...
business data processing applications main strength
even here not entirely satisfactory e.g. insurance co.
insurance data: photos, facsimile of claim form
information for claim in a folder
11/15/2018
CS319 Theory of Databases

23. The Third-Generation Database Manifesto 4
1. Introduction (cont.)
Limitations of 2G DBMS
CAD, CASE, hypertext
e.g. publishing application
store text segments, graphics, icons,
hypertext data elements
Þ need for better DBMSs
some consensus on features required of 3G DBMSs
11/15/2018
CS319 Theory of Databases

24. The Third-Generation Database Manifesto 5
2. Tenets of 3G DBMSs
TENET 1:
Besides traditional data management services, 3G DBMSs will provide support for richer object structures and rules
TENET 2:
3G DBMSs must subsume 2G DBMSs
TENET 3:
3G DBMSs must be open to other subsystems
11/15/2018
CS319 Theory of Databases

25. The Third-Generation Database Manifesto 6
3. The Thirteen Propositions
3.1. Propositions concerning object & rule management
Prop. 1.1: A 3G DBMS must have a rich type system
Prop. 1.2: Inheritance is a good idea
Prop. 1.3: Functions, including database procedures and methods, and encapsulation are a good idea
Prop. 1.4: Unique Identifiers (UIDs) for records should be assigned by the DBMS only if a user-defined primary key is not available
Prop. 1.5: Rules (triggers, constraints) will become a major feature in future systems. They should not be associated with a specific function or collection.
11/15/2018
CS319 Theory of Databases

26. The Third-Generation Database Manifesto 7
3.2. Propositions concerning increasing DBMS function
Prop. 2.1: Essentially all pragmatic access to a database should be through a non-procedural, high-level access language.
Prop. 2.2: There should be at least two ways to specify collections, one using enumeration of members, and one using the query language to specify membership.
Prop. 2.3: Updatable views are essential.
Prop. 2.4: Performance indicators have almost nothing to do with data models and must not appear in them.
11/15/2018
CS319 Theory of Databases

27. The Third-Generation Database Manifesto 8
3.3. Propositions implied by need for an open system
Prop. 3.1: 3G DBMSs must be accessible from multiple HLLs.
Prop. 3.2: Persistent X for a variety of Xs is a good idea. They will all be supported on top of a single DBMS by compiler extensions and a (more or less) complex run-time system.
Prop. 3.3: For better or worse, SQL is intergalactic dataspeak.
Prop. 3.4: Queries and their resulting answers should be the lowest level of communication between client and a server.
11/15/2018
CS319 Theory of Databases

28. The Third-Generation Database Manifesto 9
Summary
Agree with OODB proposals over
rich type system, functions, inheritance, encapsulation
Disagree with OODB proposals over
1. narrow proposals: single language base + object management emphasis
propose instead data + rule + object management
complete toolkit, including integration of DBMS and query language into multilingual environment
11/15/2018
CS319 Theory of Databases

29. The Third-Generation Database Manifesto 10
Summary (cont.) Disagree with OODB proposals because ...
2. physical navigation is to be avoided by user programs and within functions (“no pointers to be used in data traversal”)
3. use of automatic collections is encouraged, not just those that are explicitly maintained (“no need to program triggers”)
4. persistence should be added to many PLs: choice of language has little to do with the data model, persistence is an orthogonal concept (“needn’t restrict the choice of PL”)
11/15/2018
CS319 Theory of Databases

30. The Third-Generation Database Manifesto 11
Major change in emphasis
relational models can get & are getting there through extension
object-oriented models aren't anywhere near satisfying requirements e.g. no query language, no optimiser, no rules, no SQL client/server support, no support for views
also need 4GLs, distributed DB support, better tuned performance.
both OO & relational models need interfaces to persistent PLs
11/15/2018
CS319 Theory of Databases

31. The Third-Generation Database Manifesto 12
Future challenges
persistent PLs for variety of existing PLs
query languages to be included in such languages
database design principles for DBs with richer types & rules
optimisation techniques for rule execution
visualisation and debugging aids for rule-based applications
11/15/2018
CS319 Theory of Databases