Re: Does entity integrity imply entity identity?

From: Bob Badour <>
Date: Thu, 06 Aug 2009 15:11:55 -0300
Message-ID: <4a7b1cec$0$23755$>

Mr. Scott wrote:

> "Keith H Duggar" <> wrote in message

>>Mr. Scott wrote:
>>>"Walter Mitty" wrote:
>>>>Every information system needs a way of marking the absence of data in 
>>>>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 
>>>>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" <> 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 
>>>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 
>>>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>

Well, I guess it's a good thing nobody here suggested using Darwen's design, then. Isn't it? Received on Thu Aug 06 2009 - 20:11:55 CEST

Original text of this message