Re: Does entity integrity imply entity identity?
From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Thu, 06 Aug 2009 15:11:55 -0300
Message-ID: <4a7b1cec$0$23755$9a566e8b_at_news.aliant.net>
>
>
> 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.
>
>
>
>
> 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>
Date: Thu, 06 Aug 2009 15:11:55 -0300
Message-ID: <4a7b1cec$0$23755$9a566e8b_at_news.aliant.net>
Mr. Scott wrote:
> "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>
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