relative complement?

From: paul c <anonymous_at_not-for-mail.invalid>
Date: Wed, 23 Feb 2011 08:30:01 -0800
Message-ID: <201102231630.UTC.ik3cmc$qmj$>

  Every so often I wonder about an old article that puzzled me when I first read it and still does and whether I've misunderstood the implications of what McGoveran meant by:


... The "problem" of finding a unique inverse transformation for a join view in a given context without specifying any context goes away. Clearly, the delete must satisfy 'NOT PA OR NOT PB'. (Aside: We must be very careful what we mean by NOT, avoiding confusion with simple complement. Relations have a relative complement - tuples not asserted to be 'true' - with a scope that is distinct from that of the relvar predicate - tuples that cannot belong to the relation.) ...
<end quote>

(The above is part of comments he made at:               )

An (maybe extreme) example I have in mind assumes a supplier name domain/type S# with possible values { S1, S2, S3 } and relations A { S# } and B { S# } with values:


S1 ,

I take it that the relative complement of ( A JOIN B ), given the above headings and values, not only doesn't include tuple < S# S1 > but also can't include tuples < S# S2 > and < S# S3 > (because, to use McGoveran's phrase, they "cannot belong" to this particular relation) .

In this case, as far as I can make out, the relative complement would be empty (in fact I'm guessing it's empty whenever equal headings are involved, as strange as that might seem). Whereas the absolute complement would contain those latter two tuples. To put it another way, the set union of the tuples in a join and the tuples in its relative complement is not always the same set. Is this a right reading of what McGoveran wrote or is it wrong? Received on Wed Feb 23 2011 - 17:30:01 CET

Original text of this message