Re: Practical considerations of dealing with two meanings of NULLs
From: paul c <toledobythesea_at_oohay.ac>
Date: Fri, 10 Aug 2007 20:32:51 GMT
Message-ID: <TX3vi.49057$rX4.27541_at_pd7urf2no>
>
> 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 sub-
> classes into a single relation, which means, of course, lots of
> nullable columns.
>
Date: Fri, 10 Aug 2007 20:32:51 GMT
Message-ID: <TX3vi.49057$rX4.27541_at_pd7urf2no>
Doug_McMahon_at_yahoo.com wrote:
> On Aug 10, 8:58 am, paul c <toledobythe..._at_oohay.ac> 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 sub-
> classes into a single relation, which means, of course, lots of
> nullable columns.
>
Thanks for another illustration of the difficulties many systems get into. I think the language is unfortunate, mixing up objects and relations as it does but I realize that isn't your invention as I've heard such elsewhere. (The reason I think it's unfortunate is that I suspect it gets in the way of seeing better ways to implement physical stores by enticing users to roll-their-own at a logical level.)
p Received on Fri Aug 10 2007 - 22:32:51 CEST