# Re: A simple notation, again

Date: Tue, 17 Jul 2007 13:51:49 GMT

Message-ID: <VP3ni.126636$1i1.122622_at_pd7urf3no>

Brian Selzer wrote:

> "paul c" <toledobythesea_at_oohay.ac> wrote in message

*> news:4kWmi.125098$1i1.56624_at_pd7urf3no...
*

>... >>Also, this gives me an excuse to mention one of my pet penchants again. >><NOT> (A <OR> B) is the complement of a union in D&D terms and when A <OR> >>B is true, it implies that (<NOT> A) <AND> (<NOT> B) is false. I find it >>interesting to think about a relation's complement when thinking about >>insert to "union". When A and B have the same heading and we insert a >>single tuple to a view that is A <OR> B, some people say inserting to one >>or the other of A or B is just as logical as inserting to both A and B, so >>we can't really decide what to do. But it seems reasonable to me that the >>complement of the view must also respect the complements of A and B, so >>neither of those complements should contain the inserted tuple, which >>means that both A and B would contain it after the insert. >>

*>*

*>*

> I don't think this is quite right.

*>*

*> Suppose t is a tuple whose presence in A or in B would not violate any*

*> constraints. Then t must necessarily be an element of either A or its*

*> complement, and t must necessarily be an element of either B or its*

*> compliment. Now, if t does not appear in A union B, then t must necessarily*

*> be an element of both the complement of A and the complement of B. As a*

*> result, an insert of t into the view, A union B, does not map to any one of*

*> these operations: (1) an insert of t into A, (2) an insert of t into B, or*

*> (3) an insert of t into both A and B.*

*> ...*

I mentioned "insert ... to a view" but I think I shouldn't have, because dbms's don't insert into views!

p

> As an aside: if one adheres to the Principle of Orthogonal Design, then the

*> individual represented by the tuple t can never* exemplify both A and
**> B--that is, t would violate the predicate of A or of B, so an insert of t
**> into the view, A union B, would necessarily be deterministic. (There is one
**> exception, but it is trivial: when the keys of both A and B are composed of
**> their entire headings and when an inclusion dependency is defined between A
**> and B, then it is possible for t to exemplify both A and B, but it should be
**> obvious that the view, A union B, would necessarily be composed of just
**> those tuples that exist in whichever is the referenced relation, so it would
**> be pointless to create such a view in the first place.)
**>
**>
**>
*

>>p

*>*

*>*

*>*

Received on Tue Jul 17 2007 - 15:51:49 CEST