Re: Practical considerations of dealing with two meanings of NULLs

From: <>
Date: Fri, 10 Aug 2007 10:39:57 -0700
Message-ID: <>

On Aug 10, 8:58 am, paul c <> wrote:
> Thanks very much for that detailed reply which explains much of the
> lingo for me.
> p

Sure. One more point in case it's not obvious, there's a subtle difference between the class-mapping problem and the state problem. In brief, sub-class attributes are "inapplicable" to instances that are not of the same class, while attributes in the state model are always applicable to all states but may be "optional" in some states.

An example may help. Suppose that object class A has attribute X, and classes B and C, which are subclasses of A, each have an attribute Y. First off, B.Y and C.Y are not semantically equivalent and should not be folded together in any view over the objects. Even if C.Y were forced to use a different name e.g. C.Z, it would still be fair to say that C.Z is inapplicable to instances of B. In contrast, if I have states A B and C of an object type, property X would have a semantic universal to all of them, though possibly only required by state C. If these examples were decomposed into base relations with no nulls, you could end up with similar-looking tables, but in any view unioning (or joining) them together, semantically identical attributes of states would be folded into the same column, will nulls meaning unavailable, whereas in the class-inheritance case, you would never fold attributes from sub-classes into the same view column (except along super-class/sub-class lines where the semantic is the same).

Fortunately in most data-intensive applications sub-classing is rare. Unfortunately, it's therefore common practice to lump all the subclasses  into a single relation, which means, of course, lots of nullable columns. Received on Fri Aug 10 2007 - 19:39:57 CEST

Original text of this message