Follow @DBDebunk Follow @ThePostWest


Revised: 12/2017

Interviewed about his Turing Award, Michael Stonebraker is "modest" about his jointly-with-others contribution:

"... the Ingres database [sic] brought Codd’s lofty relational ideas into the realm of ordinary individuals ... turned [them] into constructs that could be manipulated by ordinary people ... it was argued at the time that RDBMS couldn’t perform, but we showed it could be efficient."

and gives most of the credit to "Ted" Codd:

"What Ted proposed was radical ... a complete change from how things were being done in database [sic] ... he turned the problem of data management into one of relations. That dramatically simplified things ... The conventional wisdom was that you should build for the particulars of how the data is stored. He saw that made no sense ... he [moved] the actual manipulation of data away from assembly language programming of the time to higher levels of abstraction that would later become structured query language, or SQL ... He brought principles of encapsulation and abstraction to programming databases, like with a high-level-language in programming."

Quite. Except that Ted was vehemently critical of SQL as a botched concretization of the RDM which, as it turned out, ensured that his ideas would never be truly and fully implemented (one of which, incidentally, was a relational declarative data sublanguage that would replace programming for data management DBMS functions). On the one hand SQL, whatever its flaws, was much superior to the database technologies that preceded it; on the other it has been forever identified with the RDM, to the point where the chance for true RDBMSs was lost (the assembly language statement is not quite accurate -- COBOL, FORTRAN and special purpose languages were used at the time -- assembly language was used for writing access methods at the I/O level, but even that wasn't pure).

Follow @DBDebunk Follow @ThePostWest

1. Quote of the Week

To clarify my point further, although M doesn't care about how it's implemented, the implementation has a strong influence on the logical structures that it's trying to implement. In a normalized or demoralized [sic] debate, a fully normalized physical schema is always good, when implemented on an infinite performance hardware. --LinkedIn.com

2. To Laugh or Cry?
I recently attended a presentation on Azure DocumentDB, Microsoft's NoSQL cloud product. I made the following notes:

• Polyglot persistence: Wasn't this what the RDM was supposed to substitute? 
• Hierarchy: Didn't we get rid of HDM decades ago?
• NoSQL: No SQL, but a "SQL-like" language (it's barely relational and now it's used for documents?)
• No integrity, data independence: Nothing learned from the past.
• Cloud: At least mainframes were under each company's control.

Progress.

3. Online Debunkings

Comments on "Michael Stonebraker Explains Oracle’s Obsolescence, Facebook’s Enormous Challenge"

4. Interesting Elsewhere

Unskilled and Unaware of It

5. And now for something completely different

Follow @DBDebunk Follow @ThePostWest

My April post @All Analytics.

Aside from domain constraints, every R-table designed to represent a single class of entities is also subject to table constraints that approximate in the database class business rules in the real world. If the rules are not documented, for the conscientious analyst who wants to guarantee sensible data manipulation and result interpretation they are the next best thing.

Read it All. (Please comment there, not here)



 

Follow @DBDebunk Follow @ThePostWest

DBDebunk readers should know of David McGoveran (see his bibliography under FUNDAMENTALS), whose work on relational theory and practice has appeared or been discussed on the old site and here over the years. On more than one occasion I mentioned the Principle of Orthogonal Design (POOD) identified by David, who had published several years ago work he did on the subject with Chris Date. The POOD has relevance to updating relations and particularly views and led to Date's VIEW UPDATING AND RELATIONAL THEORY book .

I recently mentioned that David's and Date's understandings on POOD have diverged since their joint effort--currently Date and Darwen reject the POOD as formulated then and David has problems with Date's understanding of it and with their THE THIRD MANIFESTO (TTM) book.

David is working on a book tentatively titled LOGIC FOR SERIOUS DATABASE FOLKS where he will detail his views on RDM in general and POOD and view updating in particular, but in the meantime I asked him to publish an early draft of a chapter on the latter subject, which he did-- Can All Relations Be Updated?--and which he has just revised.

He has asked me to post a clarification on the nature of the differences with Date and Darwen (see next) and I used the opportunity to interview him about his impressive career, which covers much more than database management. David provided written answers to questions.

Follow @DBDebunk Follow @ThePostWest

1. Quote of the Week

Hopefully with the emergence of better cloud infrastructure and unstructured databases, it'll become easier and easier to build utilities to handle the intake and transformation of big, messy datasets into units of info ready for insights. SocialScale (socialscale.io) just launched an MVP a month ago to provide instant access to raw social data (via Gnip), ready-for-analysis, in any tool. --LinkedIn.com

2. To Laugh or Cry?

Are SQL Relational DBMS's Here to Stay?

3. Online Debunkings

• Comments on Integrity constraints as approximations to business rules
• Comments on First Normal Form, Part 1 Atomicity

4. Interesting Elsewhere

• Lies, Damn Lies And The Myth Of Following The Data
• What Does Big Data Mean: A Cynic's Guide

5. And now for something completely different

Follow @DBDebunk Follow @ThePostWest

See series starting at

The First Normal Form in Theory and Practice Part I

Follow @DBDebunk Follow @ThePostWest

1. Quote of the Week

I'm not sure why you think integrity constraints are purely logical. Primary keys are physical constraints. They enforce that the primary key remains unique. Here's an example of SQL that creates a physical foreign key constraint.

ALTER TABLE FactInventoryCollections
 ADD CONSTRAINT
  FK_FactInventoryCollections_ClientPK,
  FOREIGN KEY (ClientPK)
   REFERENCES ViewCubeDimClient(ClientPK);

Physical constraints allow the database engine to return an error if an operation attempts to insert a row that violates any defined constraints. --LinkedIn.com

2. To Laugh or Cry?

When One Data Model Just Won't Do: Polyglot Persistence

3. Online Debunkings

• Comments: Atomicity and its reinterpretation
• Comments: Corporate Data Model re-defined as Enterprise Data Model (EDM)

4. Interesting Elsewhere

David McGoveran has been working on a book tentatively titled LOGIC FOR SERIOUS DATABASE FOLKS intended to set some matters straight regarding the formal, set-theoretic and logic foundations of the RDM which have been misinterpreted. While he is not ready to publish yet, I asked and he agreed to post at his site a draft of a chapter on view updating which I consider a must read (together with the Introduction), particularly since it exposes the thinking behind the Principle of Orthogonal Design rejected by Date and Darwen.

• Introduction
• Can All Relations Be Updated?

David invites comments.


5. New Links

Added the following to the LINKS page:

• The database curmudgeon speaks again
• Synthesizing 3NF Relations from FD's
• KnowOS

6. And now for something completely different