Re: relative complement?

From: Erwin <e.smout_at_myonline.be>
Date: Wed, 16 Mar 2011 14:56:51 -0700 (PDT)
Message-ID: <5ebcafc7-51fe-4b40-a57b-36b76c06ee8c_at_x11g2000yqc.googlegroups.com>


On 23 feb, 17:30, paul c <anonym..._at_not-for-mail.invalid> wrote:
>   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:
>
> <quote>
> ... 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:      http://www.dbdebunk.com/page/page/1396086.htm              )
>
> 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:
>
> A:
> S#
> __
> S1
> S2
>
> B:
> S#
> __
> 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?

Chastifying yourself again over view updating, heh ?

The complement of a join A JOIN B is equal to : (C(A) JOIN Ub) UNION (Ua JOIN C(B))

C(X) stands for the complement of X (that is, the _relative_ complement, relative to the Universal relation Ux, which contains all possible tuples that could possibly appear in X, _disregarding_ any constraints other than the one implied by the type declaration of X). Ux stands for the Universal relation of the (relation) type of X.

It must always be true that, for all X, X UNION C(X) = Ux. Any system in which this is not true sounds like unsound to me.

In your example, (C(A) JOIN Ub) UNION (Ua JOIN C(B)) amounts to ({S3} JOIN {S1 S2 S3}) UNION ({S1 S2 S3} JOIN {S2 S3}), which is {S2 S3}.

Deleting from the JOIN means inserting into the complement of the JOIN, means inserting into the UNION, means there are three distinct possible solutions (inserting into C(A), inserting into C(B), inserting into both).

But perhaps I see things to simple. McGoveran was hard to follow in this article, partly because of sloppinesses such as "NOT PA OR NOT PB" (NOT is a logical operator, and as such doesn't apply to predicates, but solely to propositions. PA and PB are predicates, however. If I got things right. At any rate, I still fail to see where on earth he got the idea that "The "problem" of finding a unique inverse transformation for a join view in a given context without specifying any context goes away.". As far as I can see, the ambiguity (or multitude of solutions) still exists as big as it ever was.

Cheers. Received on Wed Mar 16 2011 - 22:56:51 CET

Original text of this message