Re: Does entity integrity imply entity identity?

"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> Received on Thu Aug 06 2009 - 20:05:39 CEST