Saturday, April 18, 2015

Weekly Update

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
Brin: Write a contract to sell my soul to the devil
A Freudian slip? 

The PostWest  

Want to understand why the West systematically loses against its enemies? e.g.
Read this:  The Blackmailer Paradox! The enemy gets this Game Theory Calls Cooperation into Question but the West does not.
Back in my old country we'd say "They pee on you and you pretend it's raining".

Obaminations


The Oldest, Only Acceptable Hatred
Looks like even with eye-witnesses it has not been very effective.

Let's Give Them a State


This week's video
but Islam has nothing to do with Islam
 

This week's book
A New History of Life



Wednesday, April 15, 2015

Class Rules and R-table Constraints

My April blog post @All Analytics: 





Saturday, April 11, 2015

David McGoveran Interview

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.


Saturday, April 4, 2015

Weekly Update

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

4. Interesting Elsewhere

5. And now for something completely different
The PostWest
Pathetic!

The oldest hatred
Reality Check: Arab-Israeli Conflict
This week's video
America in Retreat
This week's book
88 Days to Kandahar: A CIA Diary



Saturday, March 28, 2015

First Normal Form, Part 3: The Domain Imperative

(Continued from Parts 1 and 2)

As I explain in paper #6, a relation is defined on domains--it is a subset of a Cartesian products thereof. It follows that to be a faithful database representation of a relation, a R-table is also defined on domains--constrained data types, that is, types with constrained value ranges and applicable operator sets, which represent real world properties--from which columns--representing entity attributes--draw their values. Otherwise put, there are no R-tables without domains.

Saturday, March 21, 2015

Weekly Update

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

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.
David invites comments.


5. New Links

Added the following to the LINKS page:

6. And now for something completely different
Demis Hassabis, Founder of DeepMind Technologies and Artificial-Intelligence Wunderkind at Google, Wants Machines to Think Like Us | MIT Technology Review Demis Hassabis, Founder of DeepMind Technologies and ... The man behind a startup acquired by Google for $628 million plans to build a revolutionary new artificial intelligence ... At Harrah’s Casino on the shores of Lake Tahoe, DeepMind researchers showed off software that had learned to play classic Atari games including Space Invaders and Pong better than any human.
Can't get deeper than this!

The PostWest
In my native tongue there is a saying: "If somebody pees on you, don't pretend it's raining". Hard to tell the super- from the third rate power, ain't it?

The oldest hatred
Upside down and backwards: It's not the  US that wreaks havoc in the ME via Iraq, Afghanistan, Egypt, Syria, Lybia and IRAN, no, it's--you guessed--Israel that causes chaos! Anti-semitism is a blinding sickness.
Middle East Reality Check

This week's video
Self-Organization: Turing & Darwin

This week's book
The Great Reformer: Francis and the Making of a Radical Pope




Saturday, March 14, 2015

First Normal Form, Part 2: Some History

(Continued from Part 1)

Consider now the email's author reply to the question in the exchange to which he referred me:
Re "atomic": In Codd's original 1969 and 1970 papers he explained that "atomic" meant not relation-valued (ie not table-valued):
So far, we have discussed examples of relations which are defined on simple domains--domains whose elements are atomic (nondecomposable) values. Nonatomic values can be discussed within the relational framework. Thus, some domains may have relations as elements.
He used "simple", "atomic" and "nondecomposable" as non-relational informal expository notions. He understood that a relation has rows of which each column has an associated name and value, and whatever ("single") value is put in is what comes out. The only structural property that matters relationally is being a relation. It is also just a value, but you can query it. Then he used "nonsimple" etc. meaning relation-valued.