Sunday, September 21, 2014

New Paper on Domains

I have just published a new PRACTICAL DATABASE FOUNDATIONS paper. See the PAPERS page for pricing and ordering information.

Domains: The Database Glue 

Abstract: Domains are a fundamental database feature. Codd, the inventor of the relational model referred to them as the "glue that holds the database together". Mathematical relations are defined on domains and, therefore, so are their database representations, R-tables. Yet they are one of the least understood database features. This is both a cause and a consequence of the failure by SQL DBMS's to implement them truly and fully. The negative implications e.g., weak support for complex and/or user-defined data types" is claimed a weakness of the relational model, rather than an industry implementation failure. This paper
  • Defines and explains the domain concept;
  • Distinguishes between domains and data types;
  • Discusses kinds of domains;
  • Clarifies DBMS domain support;
  • Discusses practical implications for database and DBMS design.

Table of Contents


1. Property Business Rules and Domains

2. Domains vs. Data Types

3. Value Atomicity and Encapsulation

4. Kinds of Domains
4.1. Simple and Complex Domains
4.2. System-defined Domains
4.3. User-defined Domains

5. DBMS Domain Support
5.1. Complex Domains

6. Practical Implications
6.1. Relational Domains vs. Object Classes
6.2. Business Modeling
6.3. Database Design
6.4. DBMS Design
6.4.1. SQL “Domains”
6.4.2. “Universal” DBMS

7. Conclusion


Sunday, September 14, 2014

Weekly Update


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

@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
Got that?

2. To Laugh or Cry?

3. Online Debunkings

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

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.

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

@The PostWest