Critique%20of%20Relational%20Database%20Models

1
Critique of Relational Database Models

• Why relational?
• Relational, network and CODASYL DBs
• Advantages of RDBs classified

2
Orientation for module

• Wk 2 Basic ideas of databases
• Wk 3-7 Relational database theory
• Wk 8 SQL and object-relational DBs
• Wks 9-10 Comparative study, reflection on DBs
• Timetable wk 9-10
• wk 9 Why relational?
• wk 10 Why not relational?
• Is there no alternative?
• The future of DBs

3
Orientation / schedule for module 2005

• Wk 1-2 Generalities on databases 3
• Wk 2-6 Relational database theory 13
• Wk 7 Evaluating relational databases 3
• Wk 8 SQL and object-relational DBs 4
• Wk 9 Temporal Relational Databases 4
• Wk 10 Reflection on DBs 3
• Hugh Darwen in weeks 8 and 9
• Week 8 - Monday 2pm 5pm, Thursday 2pm 5pm
• Week 9 - Monday 2pm 5pm, Thursday 2pm 5pm

4
Why relational? C.J. Date

• Relational Database Writings 1985-1989
• Purpose of the paper ...
• ... a succint and reasonably comprehensive
  summary of the main advantages of the relational
  approach
• concerned with technical not business
  advantages
• to evaluate relational models in DBs fully we
  must also consider the most fundamental issues

5
The agenda for reading Why Relational?

• Where is Date coming from? what is his bias?
• How do we classify Date's perceived virtues of
  relational
• models? Some virtues differ in nature from
  others ...
• To what extent are the qualities of relational
  databases fundamentally to do with relations?
• What is the future for databases as a concept?

6
Orientation on the issues raised by Date

• Paper has a rationale behind it - to defend
  relational
• models from emerging new technologies (c. 1989)
• Date has a long history as a relational DB
  champion
• Even the initial claim of the paper is contested
  (by 1989)
• First and primary advantage of RDB model
  simplicity
• Issue is SQL and ORACLE simple ... ?
• but with what is it being compared?

7
Context candidate abstract data models

• 3 classical models
• hierarchical
• e.g. Information Management System (IMS)
• developed late 1960s for Apollo mission
• network
• Conference on Data Systems Languages
• CODASYL standardised COBOL
• CODASYL Database Task Group (DBTG)
• Official CODASYL reports 1971-1978

8
Context candidate abstract data models (cont.)

• 3 classical models
• hierarchical, network, ...
• relational
• proposed by E.F. Codd in 1970
• E.F. Codd was at IBM San Jose RL
• Examples
• System R Sequel -gt SQL,
• Ingres Quel, QBE, PRTV ISBL
• Commercial Relational Systems in 1980s

9
Context Other Candidate Models

• Clear that relational database are good for many
  commercial enterprises involved in data
  processing
• What about other applications? need different
  models?
• interactive design
• human interaction intervention essential in
  design
• real-time applications
• need fast response, no encoding overheads
• integrated project support environments
• need to store pieces of code, diagrams etc.

10
Context Other Candidate Models

• Possible alternative approaches
• Extensions to relational e.g. deductive dbs
• Datalog (proper subset of Prolog)
• logic language
• cf. Kowalski Logic for Problem Solving
• object-oriented databases
• application of OOP to DBs dates from late 1980s
  e.g. Orion, Kim, Cactis, Gemstone, O2, Iris

11
Putting Date's view in context ....

• is Date biased?
• list of advantages could go on for ever, or at
  least for a very long time (p3)
• anywhere from 5-fold to 20-fold increases in
  productivity (p5) cf. quotes from other sources
  ...
• tables are sufficient, in the sense that there
  is no known data that cannot be represented in
  tabular form (p5) (what about the Mona Lisa", or
  "the sound of the last act of Marriage of
  Figaro?)

12
Useful to put Date's view in historical context

• Brief history establishes the historical context
  .
• CODASYL databases on the network model
• Outline of a network model for the HVFC
• MEMBERS (NAME, ADDRESS, BALANCE)
• ORDERS (ORDER_NO, NAME, ITEM, QUANTITY)
• SUPPLIERS (SNAME, SADDR, ITEM, PRICE)
• Develop an entity-relationship diagram ...

13
CODASYL databases on the network model 1

• Network model for the HVFC
• MEMBERS (NAME, ADDRESS, BALANCE)
• ORDERS (ORDER_NO, NAME, ITEM, QUANTITY)
• SUPPLIERS (SNAME, SADDR, ITEM, PRICE)
• Develop an entity-relationship diagram have two
• many-many relationships
• SUPPLIES (SUPPLIERS, ITEMS)
• ORDERS (MEMBERS, ITEMS)
• Principle of querying in a CODASYL model
• replace many-many relationships by functions
• navigate around sets of records via functions

14
CODASYL databases on the network model 2

• A many-many relationship XY can be expressed as
• a-1b where a RX b RY are many-one functions
• Example to factorise many-many relationship in
  HVFC
• ORDERS (MEMBERS, ITEMS)
• Introduce a set of records to represent ORDERS
• Typical record is (m_name, i_name, quantity)

15
CODASYL databases on the network model 3

• A many-many relationship XY can be expressed as
• a-1b where a RX b RY are many-one functions
• Factorise ORDERS into two projection maps
• MEMBORD ORDERS MEMBERS
• ITEMORD ORDERS ITEMS
• where
• MEMBORD (m_name, i_name, quantity) m_name
• ITEMORD (m_name, i_name, quantity) i_name
• Represent many-many ORDERS relationship by
• MEMBORD-1 . ITEMORD
• by combining the two projections thus
• MEMBERS ORDERS ITEMS

16
A Sample CODASYL query

• "Find how much Granola Brooks has ordered"
• NAME "Brooks"
• FIND MEMBERS RECORD USING CALC-KEY
• LOOP repeat forever
• FIND NEXT ORDERS RECORD IN CURRENT MEMBORD SET
• if FAIL then break LOOP
• FIND OWNER OF CURRENT ITEMORD SET
• GET ITEMS INAME
• if ITEMS.INAME "Granola" then do
• FIND CURRENT OF ORDERS RECORD
• GET ORDERS QUANTITY
• print QUANTITY
• break LOOP
• end
• end LOOP

17
Commentary on the CODASYL query 1

• NAME "Brooks"
• gt find the MEMBERS record associated with Brooks
• gt assume stored by CALC_key (hash-code) NAME
• FIND MEMBERS RECORD USING CALC-KEY
• LOOP repeat forever
• FIND NEXT ORDERS RECORD
• IN CURRENT MEMBORD SET
• gt traverse link º MEMBORD ORDERS MEMBERS
• gt current MEMBERS record is Brookss
• gt Þ link to his orders
• if FAIL then break LOOP
• FIND OWNER OF CURRENT ITEMORD SET
• gt apply link º ITEMORD ORDERS ITEMS
• gt to determine what item was ordered

18
Commentary on the CODASYL query (cont.)

• ...
• gt apply link º ITEMORD ORDERS ITEMS
• gt to determine what item was ordered
• GET ITEMS INAME
• gt access name of the item ordered
• if ITEMS.INAME "Granola" then do
• gt check to see if item ordered is Granola
• FIND CURRENT OF ORDERS RECORD
• gt current orders record is order by Brooks of
  Granola
• GET ORDERS QUANTITY
• gt access quantity of Granola ordered by Brooks
• print QUANTITY
• break LOOP
• end
• end LOOP

19
About the CODASYL environment

• Issue is SQL and ORACLE simple ... ?
• The sheer range of FIND commands and their
  almost Byzantine intricacy is one of the reasons
  why DBTG databases are programmed by experts
• The efficiency of CODASYL implementations for
  performing access and update has been a very
  large factor in their widespread use. This
  efficiency has been purchased at the cost of
  using a baffling variety of storage strategies
  and DML commands
• Peter Gray Logic, Algebra and Databases

20
SQL is simple - relative to CODASYL

• ORDERS (ORDER_NO, NAME, ITEM, QUANTITY)
• "Find how much Granola Brooks has ordered
• select QUANTITY
• from ORDERS
• where NAMEBrooks and ITEMGranola
• The SQL-CODASYL comparison highlights reason for
• Date-Darwen concern about back-to-the-future in
  DBs

21
Why relational? 1

• CODASYL is bad, but is relational good?
• also beware! CODASYL is bad, but is network
  bad?
• ... first try to understand Date's claims by
  comparing the two models ....
• Areas of usefulness for relational model
• data manipulation
• database design
• database definition
• database installation
• ....

22
Why relational? 2

• Advantages of relational technology
• usability
• productivity
• ... promotes end-user programming
• Evident in relation to the CODASYL alternative!
• cf Korth and Silberchatz file system vs DBMS

23
Why relational? 3

• Perceived advantages of relational DBs
• simple data structure
• simple operators
• no frivolous distinctions
• SQL support
• the view mechanism
• sound theoretical base
• small number of concepts
• the dual-mode principle
• physical data independence
• logical data independence

24
Why relational? 4

• Perceived advantages of relational DBs (cont.)
• ease of application development
• dynamic data definition
• ease of installation and ease of operations
• simplified database design
• integrated dictionary
• distributed database support
• performance
• extendability
• all evident in relation to CODASYL comparison

25
A brief elaboration of Date's concerns 1

• simple data structure
• table is the basis of the relational model
• simple operators
• 5 relational operators for completeness
• set-level operations / closure / declarative
• no frivolous distinctions
• uniform methods of interaction with DB
• e.g. for update relation, or impose constraint
• SQL support
• high-level queries / widespread use, acceptance
• the view mechanism
• means to customise the DB without new concepts
• sound theoretical base
• relational model is mathematically rigorous

26
A brief elaboration of Date's concerns 2

• small number of concepts
• single mode of representation uniform update
• cf multi-mode proliferation of mechanisms
• the dual-mode principle
• embedded DML to access the DB from programs
• autonomous activity resembles user interaction
• physical data independence
• separate conceptual model / physical database
• logical data independence
• separate conceptual model / user views
• ease of application development
• makes application generators possible
• makes high-level prototyping easy
• dynamic data definition
• can modify a relational DB design incrementally

27
A brief elaboration of Date's concerns 3

• ease of installation and ease of operations
• robust, easy to manage by few personnel
• simplified database design
• have principles for database design
• integrated dictionary
• consistent interface for meta-level access
• metadata-driven programs can be written
• distributed database support
• high semantic content of queries, declarative
  nature
• cf. problems of breaking up procedural chains
• performance
• down to optimiser, not applications programmer
• extendability
• can easily build on relational database models

28
Date's concerns and CODASYL 1

• simple data structure?
• cf complexity of DBTG sets and pointers
• simple operators?
• no high-level operators, nothing at the
  set-level
• have to record state, pointers create modes
• no frivolous distinctions?
• complex methods of interaction with DB
• e.g. update relation and impose constraint would
  be dealt with in entirely separate ways
• SQL support?
• no concept of high-level query, was widespread!
• the view mechanism?
• has no analogue for CODASYL
• sound theoretical base?
• no discernible theory in CODASYL framework

29
Date's concerns and CODASYL 2

• small number of concepts?
• multi-mode proliferation of mechanisms
• representation? ways to select, insert, delete,
  update
• the dual-mode principle?
• no clear distinction between high-level queries
  and application programmer's mode of access
• physical data independence?
• conceptual model mixed with physical database
• logical data independence?
• no provision for user views
• ease of application development?
• CODASYL doesn't make data access much easier
• dynamic data definition?
• DB design has to be carefully preconceived and
  can't easily be adapted

30
Date's concerns and CODASYL 3

• ease of installation and ease of operations?
• CODASYL probably keeps program surgery busy
• simplified database design?
• principles for database design more suspect
• integrated dictionary?
• meta-level issues not addressed within model
• distributed database support?
• who'd like to parallelise CODASYL updates?
• performance?
• was traditionally better than relational models!
• extendability?
• CODASYL not something to be built on ...

31
Interpreting Dates defence of relational models

• Date s arguments in defence of relational models
  are
• very powerful when seen in the context of
  CODASYL
• Need to understand them in relation what might be
  the
• best data modelling practices for today and the
  future
• Important for this purpose to classify the
  defences
• defence from theory ? is the theory adequate
• defence from practice ? will the practice change
• special qualities exhibited by the relational
  model
• ? are they particular to RDBs, or generalisable

32
Classifying the advantages cited by Date 1

• Will classify Dates list of advantages into
• THEORY, PRINCIPLES and CONSEQUENCES
• and further subdivide
• PRINCIPLES into PRACTICAL FOUNDATIONAL
• THEORY
• simple data structure
• simple operators
• no frivolous distinctions
• sound theoretical base
• small number of concepts

33
Classifying the advantages cited by Date 2

• PRINCIPLES - PRACTICAL ASPECT
• SQL support
• the view mechanism
• the dual-mode principle
• physical data independence
• logical data independence
• dynamic data definition
• PRINCIPLES - FOUNDATIONAL ASPECT
• simplified database design
• integrated dictionary metadata-driven
• distributed database support atomicity

34
Classifying the advantages cited by Date 3

• CONSEQUENCES
• ease of application development
• ease of installation and ease of operations
• performance
• extendability
• The status of these advantages is relevant when
  we
• come to consider what is really siginificant
  about the
• relational model in comparison with other
  alternatives ...

35

• will return to express personal views
  concerning the defence of the relational position
  later turn next to the issue of Why not
  Relational?
• ? whynotrel.ppt

36
What are the virtues of the relational model? 1

• Certain features of relational models wish to
  retain ...
• The defence from theory
• simple data structure
• want elegant and consistent structures
• simple operators
• want high-level operators
• need techniques at the set-level
• don't want to have to record state
• don't want to maintain pointers

37
What are the virtues of the relational model? 2

• Certain features of relational models wish to
  retain ...
• The defence from theory
• small number of concepts
• want a unified view for representation
• uniform ways to manipulate
• sound theoretical base
• want to be able to apply mathematical techniques
• ... but all these attributes apply to Miranda,
  for example, and this hasn't made it widely /
  wildly successful

38
What are the virtues of the relational model? 3

• The defence from practice ...
• SQL support
• need concept of high-level query
• the view mechanism
• must be able to represent different user views
• the dual-mode principle
• invoking user commands automatically is a
  powerful principle for program development and
  debugging
• physical and logical data independence
• must be possible to separate concerns
• at high and low levels of abstraction
• ... but do these qualities fit into a general
  scheme or are they specific to the relational
  framework?

39
What are the virtues of the relational model? 4

• Evidence of special suitability for real-world
  modelling ...
• simplified database design
• have principles for database design
• contrast the messiness of CODASYL
• integrated dictionary
• can write metadata-driven programs
• no chance to take high-level view in CODASYL
• distributed database support
• high semantic content of queries, atomicity of
  action
• queries in CODASYL not much about the real-world

40
What are the virtues of the relational model? 5

• Evidence of special suitability for real-world
  modelling ...
• ... database design reveals very direct
  connections between dependencies amongst
  attributes of real-world objects and forms for
  their representation in relation schemes
• content real-world meaning
• dictating form structure of the
  representation
• Fundamental conflict between theory and practice
• over the relationship between form and content

41
What are the virtues of the relational model? 6

• Important aspects of relational DBs (in WMBs
  view)
• THEORY aspect underlying algebraic model
• provides basis for unambiguous evaluation
• closure properties
• potential for optimisation axiomatisation
• PRINCIPLES represented in
• views application generators spreadsheets

42
What are the virtues of the relational model? 7

• Important aspects of relational DBs (in WMBs
  view)
• PRACTICAL aspect
• involve state essentially, so not purely
  declarative
• good for expressing agent actions / views
• good for representing levels of abstraction
• cf ACE A Small Matter of Programming, Bonnie
  Nardi
• Represents a framework for managing state cleaner
• than procedural programming, more expressive than
  FP

43
What are the virtues of the relational model? 8

• Important aspects of relational DBs (in WMBs
  view)
• FOUNDATIONAL aspect
• concerned with metaphor not symbolic
  representation
• invokes form and content in combination
• Notes on these respective issues
• metaphor the form reflects the content
• as is true to some degree of relational models
• cf logicism debate in AI
• A Critique of Pure Reason McDermott et seq

44
Issues for database development 1

• 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 / replace the form-content
  relationships that relational DB design theory
  introduces

45
Issues for database development 2

• 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 between direct (human) and
  programmed (computer) data access
• support for modern data abstractions objects,
  inheritance, aggregation
• applicability to design environment needs
  incremental intensional change