Why not Relational?

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

2. Modern context for general data modelling Programs 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 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? 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? 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? 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? 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? 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? 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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. 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. 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. 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 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”) 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 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 CS319 Theory of Databases