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
   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.

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

Saturday, March 7, 2015

Weekly Update (UPDATED)

1. Quote of the Week
I have been in the data side of IT for quite some time now and have seen the evolution of how data is ingested, manipulated and regurgitated to the end users in hope of telling our consumers "how much of something did something". The main issue seems to be complexity of the data models and the fact we don't have a model that can expand with the data without adding tons of new schema. The solution.

2. To Laugh or Cry?

3. Online Debunkings

4. Interesting Elsewhere

5. And now for something completely different

Thursday, March 5, 2015

Domains, R-tables, and SQL

March blog post @All Analytics:

To ensure sensible results from and correct interpretations of analysis of data from SQL tables or extracts thereof, analysts must know the tables’ interpretation -- the business rules underlying them -- which is rarely documented.

They should be represented in the database by integrity constraints -- not perfect substitutes, because they are very loose approximations to the rules -- but if they are enforced in the database by the DBMS they are usually recorded either in the definition statements that created the tables and constraints, or the database catalog.

Read it all