1. Quote of the Week
I use the word grain in the same sense as Kimball although I use it across Facts and Dimensions. I like the term over things like Uniqueness, Constraint, Key because it is a term that business readily understand, and can be used prior to the formal identification of a final key. In Dimensional Modelling it is a best practice for the Fact tables to have such a grain (a composite key across associated Dimensions) and is also necessary for many Dimensions (to assist with updates, type-2 logic etc.) - to the point where it is a best practice to identify the grain (Row Natural Key, Source Id, etc.) of the Dimension. The use of a surrogate key on either Dimensions or Facts must be backed by this level of rigor if data integrity is to be maintained. It also forces modeller consideration of source system issues such as multi-source key uniqueness, reuse of keys, deletions, etc. To clarify a little on Dimensions, the grain of an example type-1 customer dimension would be 'a customer id', the grain of an example type 2 customer dimension would be 'a customer id + as at time'. So 'grain' means the defined uniqueness for a row in the table. Generally, this also has the advantage of calling out poorly designed structures that have not established their relational uniqueness correctly - the cause of the irritating duplicate row issue in a Surrogate Key-oriented Fact table.--LinkedIn.comGot that?
2. To Laugh or Cry?
3. Online Debunkings
- First normal form question
- The 'Real World' and Database Design
- Data Model: Neither Conceptual, Nor Logical, Nor Physical
4. And now for something completely different
Two books that every American should read (but won't).
- Matt Taibbi: DIVIDE - AMERICAN INJUSTICE IN THE AGE OF THE WEALTH GAP
- Michael Lewis: FLASH BOYS
- Holocaust Inversion: “Gaza = Auschwitz”
- Obama’s Irrational Animus for Israel
- Allah_Islam: Say Goodbye to Europe and Civilization
- Israel and the PostWest: Denial, Illusion & Delusion
- It's The Jews, Stupid!