Logical database design strives to represent the predicates and propositions of truth that are relevant to the universe of discourse supporting the functions involved with the business issues addressed by a proposed solution. But just what exactly is truth?
Truth by most people’s standards involves some level of agreement with reality. However if truth were to be laid out simply, then we would not have so many theories attempting to explain truth. Correspondence theory maps ideas with concrete objects in the belief that there exists an objective reality we all inhabit, one truth for all. Coherence theory looks at things being true or not based on how elements fit together within the whole system. Constructivist theory holds that what society accepts as true defines truth. Similarly consensus theory, as the name implies, holds that what we agree to as truth is truth. Pragmatic theories generally state that what works it true, what doesn’t work is false. Minimalist theories explore the slippery slope of a version of truth relativism. And there are still more theories.
Many designers seem to approach a database design as if there is a single objective reality that circumscribes all truth and that happens to align with exactly how they see the world. Honestly, is it expected that there is an absolute truth for everything? And that single absolute truth goes from the highest level of abstraction to the lowest level of detail? Things within that truth sphere are by definition true and everything else must be by definition false? Should things really work in such a fashion, then one would suppose a single database design sufficient for use across every organization in the world. Obviously, such is neither the case nor anyone’s desire. In point of fact, truth is a very complex and subtle issue. Yet in composing new databases, designers seem to have little caution or concern in jumping to a table design that represents the predicates and propositions of truth. While not often consciously aware, designers are not only defining what is true for the organization they are also choosing a theory of how truth is explained for an organization. Or designers may jump across the many theories of truth without rhyme or reason. One table designed via a correspondence theory approach and the next based on consensus theory. Should database designs not be held accountable to any specific perspective of the truth? Maybe only specific kinds of attributes contain truth? For instance, perhaps the measures within a fact of a multi-dimensional design are true, but descriptors within the dimensions are more ambiguous?
Normalization is the application of an analysis of functional dependencies across the set of attributes under discussion. Those functional dependencies are driven by the nature of the truth being expressed. Therefore, it is the truth to be expressed that drives the entities and the attributes within them. Perhaps designers would do better to take a moment to two, and consider the nature of the truth they are to deal with when they start exploring a new database or organization.