Re: Does entity integrity imply entity identity?
Date: Thu, 6 Aug 2009 14:05:39 -0400
Message-ID: <neKdnQpsNIXohubXnZ2dnUVZ_q2dnZ2d_at_giganews.com>
"Keith H Duggar" <duggar_at_alum.mit.edu> wrote in message
news:7df59048-8fe8-4de4-8f1f-69ec98f69221_at_g6g2000vbr.googlegroups.com...
> Mr. Scott wrote:
>> "Walter Mitty" wrote:
>> > Every information system needs a way of marking the absence of data in
>> > a
>> > place where there might have been data. In some situations, there not
>> > only might have been data, but there should have been data. In other
>> > situations, a place for data has been created, but it is inapplicable
>> > to
>> > the situation.
>>
>> "Inapplicable data" is an oxymoron, so it doesn't make sense to provide a
>> place for it. A table that allows "inapplicable nulls" has a disjunctive
>> predicate and should be split up into one base table for each disjunct.
>
> The above comment indicates that you at least know the concept
> of disjunction and that you understand one alternative to nulls
> in that case: decomposition. However in other post we have you
> outlining an example having (in part) such a disjunction:
>
> On Aug 6, 8:42 am, "Mr. Scott" <do_not_re..._at_noone.com> wrote:
>> Here's a more concrete example. Software can be delivered to a customer
>> over the internet or through the mail or both, but in order to deliver
>> over
>> the internet there must be an e-mail address, and in order to deliver
>> through the mail there must be a snail-mail address. There may also be a
>> delivery contact phone number. So for a given order K, there must be at
>> least one of an e-mail address A or a snail-mail address B, and there may
>> be
>> a delivery phone number C.
I don't think it's the same kind of disjunctive predicate. In the case of
inapplicable nulls it is the intension that is disjunctive; in the case of
applicable nulls it is the elements of the extension that are disjunctive.
In the example, there is still supposed to be a value for A, B and C even if
it is at present unknown, but in order to complete an order there must be a
way to deliver the product so a value for either A or B must be specified.
>
> and yet offering no acknowledgement that you already understand
> some alternatives. In other words you are "holding back" and/or
> feigning ignorance. This is indicative of troll behavior and/or
> someone just looking to fight. Please explain yourself.
I mentioned Darwen's approach and the problems associated with it in an
earlier post. This example illustrates those problems. If the table is
decomposed into tables (X), (X,A), (X,B) and (X,C), then multiple assignment
is needed in order to meet the requirement that whenever there is an X there
must be either an A or a B or both. In addition to the referential
constraints from (X,A), (X,B) and (X,C) to (X), there is also a need for a
referential constraint from (X) to the union of the projections over X on
(X,A) and on (X,B). As far as I know, multiple assignment is not supported
in any commercially available DBMS, and I could be wrong but I don't think
it is possible to reference a view in a foreign key constraint, so from a
practical standpoint Darwen's decomposition solution is clearly not viable
at present. From a theoretical standpoint, the example shows that the
decomposition alternative introduces 'referential cycles' which I think
should be avoided. (By 'referential cycles' I mean that whenever there is a
row in (X), there must also be a row in either (X,A), (X,B) or both with the
same value for X, and whenever there is a row in (X,A), (X,B) or both with a
value for X, there must also be a row in (X) with the same value.)
<snip>