# Re: Date and McGoveran comments on view updating 'problem'

Date: Thu, 11 Dec 2008 18:03:49 -0400
Message-ID: <49418e47\$0\$5473\$9a566e8b_at_news.aliant.net>

```> On Dec 11, 1:28 pm, vadim..._at_gmail.com wrote:
>
```

>>On Dec 8, 4:13 pm, vadim..._at_gmail.com wrote:
>>
>>>As for deletion here is my worksheet
>>
>>....
>>
>>>Now, we are proving the following decomposition
>>
>>>(SP v D')^(S v D') = (SP ^ S) v D'.
>>
>>This assertion is wrong. If D is the set of tuples that we delete from
>>SP ^ S, then the condition is:
>>
>>(SP ^ (D' v (SP ^ R00))) ^ (S ^ (D' v (S ^ R00))) = (SP ^ S) ^ D'
>>
>>Informally, on the right side we have a relation which is the result
>>of deleting D tuples from SP ^ S. On the left side is a relation that
>>is a join of two base relations SP and S, each trimmed with some
>>projection of D.
>>
>>I fail to derive it with any assumptions, except the obvious, like
>>demanding that D acted only on SP (or S). Therefore, there might be
>>some truth to people questioning the validity of deletion from join
>>view...
```>
> Ugh, wrong again! Here is the deletion case solved:
>
> 1. (SP ^ S) ^ R00 = D ^ R00
> "Tuples D are deleted from SP ^ S, therefore they have the same
>
> 2.  (D ^ (SP ^ S)') ^ R00 = R00
> "D is subset of SP ^ S"
>
> The reason why I was confused is that set containment can be written
> in "more intuitive" fashion as
>
> D ^ (SP ^ S) = SP ^ S
>
> and this appeared to be a weaker condition!

```

The idea being an informed expert (ie. designer) needs to express to the DBMS the rule that when a user deletes from the view, the expected outcome is to delete from the SP relation but not the S relation. Depending on the design, the designer might instead express that deletes affect S but not SP or that deletes affect both.

Other alternatives might be to delete the SP tuples and delete the S tuple only if D contains all of the tuples corresponding to some S. Received on Thu Dec 11 2008 - 23:03:49 CET

Original text of this message