Re: more on delete from join
Date: Thu, 03 Sep 2009 23:34:23 GMT
Message-ID: <3oYnm.42532$Db2.776_at_edtnps83>
Joe Thurbon wrote:
> On Thu, 03 Sep 2009 04:23:48 +1000, paul c <toledobythesea_at_oohay.ac> wrote: >
>> Joe Thurbon wrote:
>> ...
>>> So, to update a view, rather than update the conclusion directly, one
>>> must update (one of) the base relvars that are used to derive the
>>> conclusion/view. That is abductive.
>>> ...
>>
>> Joe, if one does that, one is replacing the value of something other
>> than the relations that form the join and it wouldn't actually be
>> accurate to call it a "join update". To use the term "update", one is
>> updating two relvars that point to subsets of the "base relvars".
>
> I'm afraid I don't understand what you mean.
In C = A JOIN B, there may be 'spurious' tuples in A or B that aren't
implied by tuples in C. Many people talk about delete from join as if
those tuples must somehow be involved but by definition, the join view C
= A JOIN B does not necessarily consist of tuples that are implied by
the logical expression:
(A AND B) OR (A AND NOT (A AND B)) OR (B AND NOT (A AND B)).
(This could be put loosely as (A JOIN B) UNION (A MINUS C) UNION (B
MINUS C).)
I think it is actually one of these expressions that people are talking
about when they say delete from join isn't possible. But they don't
actually say so, Instead they pretend what they are dealing with is A
AND B . To be fair, some people do talk about 'delete through join',
but I think that's misleading and not the same as 'delete from join'! I
believe the correct expression for 'delete from join' is merely A AND B.
The spurious tuples never appear in the extension of A AND B, so they
could hardly be deleted. Nor could one insert such spurious tuples to a
join because then they wouldn't be spurious.
What about preserving spurious tuples? If a language requires relvars, I believe the correct way to approach delete from join would be to define five relvars instead of the three mentioned, as well as various constraints so that the starting position for 'delete d from c' is actually a join and not the unions or disjunctions above. The relvars involved in the join will point to subsets of A and B that are disjoint from the spurious tuples. Two other relvars would contain the spurious tuples, each disjoint from A and B When all the relvar constraints are made mutual, I think it will be seen that the complement of A AND B that is so constrained is in fact NOT A AND NOT B. I believe this is what McGoveran called 'relative complement'.
I think projections of the union of those five relvars are the logical values of the resulting A and B relvars and no 'guessing' will be involved.
Of course one can take the starting position that one doesn't want to update views, which to me has as much justification as sayhing that views can't be stored, ie., none as far as I'm concerned. I would rather have same behaviour for all relvars, not two. But if people insist, I wish they would start with an accurate definition, not the misleading one. Received on Fri Sep 04 2009 - 01:34:23 CEST