Good heavens what dangerous nonsense.

A database doesn't represent data extracted from some platonic ideal world in which everything is known, it represents our knowledge of the real world. Sometimes there will be things we just don't know; we don't want to put in a default value, because risks making anyone looking at the data believe that we do know (with potentially catastrophic results). We don't want to split an attribute that might be unknown into two attributes (one to contain the value or a default, and another to say whether the value in the first actually means anything) because (a) that makes handling aggregates rather clumsy and (b) it increases the number of columns and (c) the results are generally extremely hard to understand. We don't want to split the X table into a large number of tables "X for which attribute A is unknown", "X for which attribute B is unknown", X for which attributes A and B are both unknown, etcetera (2 to the power N tables where there N attributes which may or may not be unknown) nor yet into a different large number of tables "X and attribute A", "X and attribute B" etcetera (N+1 tables where there are N attributes whhich may or may not be known and at least 1 non-key attribute that is always known) because this wastes space, disc head movements, and performance. In fact we don't want to do any of the null-avoidance tricks advanced by the anti-null fanatics of the world, because they all lead to schemata which are difficult to understand, code which is inelegant and over-complex, and performance that is fairly appalling. So we have a standard which includes NULL (it has probably got NULL wrong since we seem to need to distinguish between at least two different sorts of NULL and work with a 4-valued logic, not a 3-valued one), and when we encounter (in the real world, not some platonic ideal with no real existence) an attribute which may sometimes be unknown we use that standard and the NULL that it provides to cope with this real world situation in a reasonably efficient manner.

I suspect Shaun has been reading too much Date and not enough Codd - it's salutary to see what Codd said about NULL, and to remember that when the inventor of the relational model published his rules for what properties a DBMS must have to be considered relational one of those rules said plainly and clearly that it must support NULL.