Most good texts on database design will extol the benefits of normalising the design. However apart from performance there are other benefits to denormalisation. There are similar benefits in software design and arguably in most forms of communication. In this paper I look at what I perceive as an excess of normalisation in the world.
"When I use a word", Humpty Dumpty said, in rather a scornful tone, "it means just what I choose it to mean - neither more nor less." (Carroll, Lewis; "Through the Looking Glass")This is the basis of my thesis that the world is overnormalized. Communication is a two-way street, a two-actor interaction, and it is seldom perfect. Very frequently we forget that what is not said is as important as, if not more important than, what is said. In this paper I will also work extensively with two related concepts, valid and correct. These are not the same thing at all.
So let's start with database design. In a perfectly normalised database every point of the domain is equally valid; any change to the data results in an equally valid one. However it may not be equally correct. Many years ago I remember hearing the assertion that some gas bills were sent out with ridiculous amounts due to cosmic radiation ionising areas of memory resulting in zeroes becoming ones or vice-versa. The resulting state of the data might be valid but the customer would argue with it being correct. Now in a denormalised database only a small portion of the database states are actually valid. One fundamental conclusion can be reached on detecting an invalid data state; it is incorrect. We don't know in what way it is incorrect but we know that it is. The more normalised the database design the lower the probability that errors in correctness can be detected by discrepancies in the validity.
So how does this relate to software? One suggestion I remember hearing with regard to software programming is that comments are a bad thing, one should read the code. Let's ignore those cases where all the comment does is state what the next line of code does. I assume that a comment serves one or more of the following purposes:
While on the subject it is also worth noting the benefit of pairs of maintenance instruction comments, i.e. double-chained comments. Maintenance comments are desirable because a single piece of functionality normally actually requires code to be added in several areas and so introduces dependencies between them. Therefore maintenance comments point from one such area to another. Theoretically of course when changing an area of code one could scan
There is a related issue which is one of my personal buttons. Again I remember hearing a statement that "if the converse of a statement is obvious then do not state it". I cannot agree. I know of several occasions when "the obvious" has not been obvious to me, or has been obvious in some different way. It reminds me of when my father and I, many years ago, were wasting time in a bookshop looking at one of a set of Mensa puzzles. We each arrived at different answers and accepted each others' derivations. However neither of us could figure out how the authors got theirs. In particular I contend that it is frequently important explicitly to state what has not been done as well as what has. As an example consider the following from the UNIX world. One of the ways of initialising a UNIX System V semaphore involves three different functions and things that they state that they do. However it also requires that one of them does not do something that it doesn't currently do. Of course the documentation doesn't state that it doesn't do this; after all there is an infinity of things that it doesn't do, including making the coffee. However in order to prevent future problems it must never do this one thing and so this negative needs to become part of the definition. The details are available elsewhere, as are the details of another example from the FORTRAN world.
This brings me to the third area; communication in general. For good communication it is important that messages flow in both directions. The sender sends a message and then waits for the feedback that says it has been received correctly. The feedback may be explicit such as "so what you are saying is.." or it may be more subtle such as facial expression and body language. Frequently not watching for the feedback leads to miscommunication. ("Wouldn't it be nice if...?", "Yes it would.", "You said you'd do it.", "No I didn't"). And of course the amount of required feedback varies with how well the two actors naturally understand each other. At the limit communication is impossible when the two actors have no common understanding, especially when they think they have, and so they talk past each other. So here again we are back at denormalisation. If one says "the same thing" in several different ways this increases the chance that a misunderstanding will be detected.
Interestingly there is a useful converse to the previous issue; hypergames. Mathematically a game is a contest, normally with two players, with a set of possible outcomes. Of course the problem with games is that there are winners and losers; how can both players win? The possible outcomes are measured in some way in order to give value and normally one player gets a higher value than the other. In hypergames the two players disagree about the valuations of the outcomes and so it is possible to have an outcome that is desirable to both sides. This is of course the desire of most good diplomats. (I accept that this is a gross oversimplification but it is adequate for the purposes of this discussion.)
Perhaps part of the issue in all of this is the way in which life is becoming increasingly busy. The result is that we give in to an excess of short-sighted pragmatism and only later do we count the cost.