Sunday, September 14, 2014

Weekly Update


Housekeeping:

  • Added a LINKS page to the top site menu, with links to items I deem worth reading. Added a few from my old site and new ones will be added as I come across them.
  • Overhauled the FUNDAMENTALS list of sources at the right of the HOME page. It now includes links to the bibliographies of E. F. Codd, D. McGoveran, C. J. Date, H. Darwen, myself and the old DBDebunk site @the Internet Archive. 


1. Quote of the Week
The future in data modeling is Object Role Modeling (ORM).  It is a far superior way to approach data modeling (compared to any record-based methods such as relational) that avoids all the pitfalls of "Table Think" and the necessity of normalization. --LinkedIn.com
2. To Laugh or Cry?
Survey data model, what is the best approach?
3. Online Debunkings
Dr. Robin Bloor: Big Data is “nonsense”
4. Elsewhere
5. And now for something completely different
Senator Challenges Zuckerberg
American patriot.
The Exorcisms of Anneliese Michel
Fascinating.

@The PostWest:



Sunday, September 7, 2014

Weak Entities, Referential Constraints & Normalization (UPDATED)

A LinkedIn exchange initiated by the question What is a weak entity? diversified into various aspects of data modeling and database design. My interest was mainly in references to the relational model that warranted debunking or clarifications. So here goes.

Sunday, August 31, 2014

Weekly Update


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.com
Got that?

2. To Laugh or Cry?

3. Online Debunkings

4. And now for something completely different
Inside The Mind Of Leonardo
Fascinating.

Two books that every American should read (but won't).

@The PostWest




Sunday, August 24, 2014

NEW: Paper revisions available


Revisions of the following three papers are now available from the PAPERS page:

Paper #1: Business Modeling for Database Design
Paper #2: The Costly Illusion: Normalization, Integrity and Performance
Paper #5: Truly Relational: What It Really Means

Those who ordered them
  • in 2014 can request free copies
  • in 2013 get a 25% discount



Friday, August 15, 2014

Weekly Update


1. Quote of the Week
Invoice number is the key (key is not unique in this table). Although structure or key constraints doesn't enforce uniqueness of rows, the assumption is there will not be duplicate rows. --LinkedIn.com

2. To Laugh or Cry?
Relational Queries by Reference

3. Online Debunkings
What is Weak Subtype

5. And now for something completely different
Tim's Vermeer
Fascinating

@The PostWest

Sunday, August 10, 2014

The 'Real World' and Database Design


Conveying data fundamentals to practitioners, losing neither rigor, nor the audience is a difficult task. There are many experienced professionals with tool expertise, but poor foundation knowledge for which there is little regard. Even in academia education has been substituted by training, which is not the same thing.

One dilemma faced by an educator is the tension between the simplicity of examples effective for conveying general concepts or principles and the complexity of the reality to be represented in databases. The latter requires integration of many concepts and principles, as well as thorough business knowledge. This is part of the reason why I normally refrain from specific online modeling/design advice and limit myself to the general principles that must be adhered to in the process.