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
