Data Model Physical Independence

A data model describes our logical view on an application domain.

• Therefore a data model should be always defined in logical terms and contain no physical considerations.
• As a consequence, pointers have no business in a data model, how we store information on disk also have no business in a data model. (be it at 'cylinder/sector/head' level, or even something higher level of the genre - these tables are clustered, we have these and the other hash-indices, one B-tree index, and two bitmapped indices) {The definition of pointers be a sticking point. Record ID's and keys are "pointers" also by some accounts.}
• Before the relational model, all data models were physical. Some argue that OO models make a little room for some physical considerations to make it back into the logical model (through the use of pointers alias object references).
• At the current time, nobody seems to be against this principle, although many tend to forget it and break it in some subtle ways.

Actually, I've seen several examples of deliberately denormalized data designs in order to speed retrieval for online transaction processing. The logical model was broken into a much less logical model, in order to accommodate the perceived limitations of the physical storage system. I don't think that any performance tests were done before the data model was denormalized, but that it was just assumed that denormalization would be necessary. The people involved made those decisions before I came on the scene and stopped talking to me shortly after I arrived, so I never found out their reasons. (This was a very unhappy work environment for me and it took a year before I could imagine nice, competent people having a good reason for denormalization.)

Denormalization for performance is a controversial topic. Perhaps we should explore specific examples in its own topic. -- AnonymousDonor

For example, in many OO models, Class1 has an aggregation relationship with Class2 through an ArrayList (or through a Bag, or through a TreeSet, or the like). How a relationship is implemented does not belong to the logical model, a relationship is a relationship at a logical level, even if I choose a java.util.TreeSet, a java.util.HashSet, a java.util.ArrayList (the last one is a very bad choice indeed). How do I represent the relationship within my own little application is my own business, and should not clutter the logical domain model.

What if other applications want to see the aggregation view also? The need for cross-app or cross-language data sharing is a common "new" requirement in my experience. (ReinventingTheDatabaseInApplication)