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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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