Re: Date and McGoveran comments on view updating 'problem'
Date: Fri, 12 Dec 2008 20:55:07 GMT
Bob Badour wrote:
> vadimtro_at_gmail.com wrote:
>> On Dec 11, 2:03 pm, Bob Badour <bbad..._at_pei.sympatico.ca> wrote: >> >>> A more important question is: How would one write a constraint that >>> deletes from SP ^ S affect SP but not S? >> >> (S ^ D) v R00 = R00 >> >> With this constraint the view update proves easily. >> >> (z ^ x) v R00 = R00 & >> (x ^ y) ^ R00 = z ^ R00 & >> (z ^ (x ^ y)) = z >> -> (x ^ (z' v (x ^ R00))) ^ (y ^ (z' v (y ^ R00))) = (x ^ y) ^ z'. >> >> >>> I assume the constraint would say that combining D with SP would yield >>> an empty relation of some sort while combining D with S would yield a >>> non-empty relation. I think these equations will be necessary to yield a >>> determinate result. >> >> If you are implying that presence of D in the constraint is somewhat >> unfortunate, then I agree.
> I was not trying to imply that. I tend to agree it is a little
> unfortunate, but better to have some way to express it than to have no
> way at all.
> I long ago concluded the 'problematic' view updates were all just cases
> of insufficient information yielding indeterminate results. Nobody seems
> to worry too much that one cannot solve for three variables using two
> linear equations. I don't see why anyone should fret too much over
> deletes of joins as long as the symbolic language has some way to
I think if we want relational closure that the delete to join is a bigger problem than the three variables, two equations problem, because it doesn't just affect deletes, it affects queries. (That's not my idea, I think McGoveran already suggested it.)
Eg., I think McGoveran means that "R WHERE R.X NE 5 OR R.Y NE 6" is on quicksand if the definition of R is "A JOIN B", because there is actually a deletion involved (eg., <AND> <NOT). I realize that most people if doing the query by hand would take the extension of A JOIN B, then examine each tuple of R and use something like the C language's shortcut for 'or' to decide if the tuple were in the result. But I think that is simplistic and, to be blunt, a cheat. Unfortunately I can't go much further than that because I am still a novice when it comes to predicates - one reason for that, I think, is that the RM is still in its infancy when it comes to expressing predicates. I realize that you, Bob, have lately said similar, at least regarding 'join deletion rules' and how to express them in a language.
Since the OP got a few thoughtful replies, I spent quite a few hours trying to massage D&D's A-algebra to get "the answer I wanted"! Found myself going around in circles that never seemed to narrow. In the last day or so, I've been wrestling (above my weight class, I admit) with some of the nuances of the tuple calculus and still don't have enough to nail my objection down very precisely. But the more I ponder McGoveran's words, the more I come to think that one must establish a programming language framework to deal with delete through join and insert through union. I'm guessing so far that the D&D definition of MINUS is not good enough. Perhaps it needs to be qualified with a kind of invariant. So far, I'm thinking of an equation to do that. It would be "SSP' = SSP <AND> (<NOT> D). The prime single quote lets me see SSP' in TWO ways at the same time, But I still need to try and buttress the equation with a notation that includes all of the relevant predicates for the view and the relations it uses. If I ever find a way to attach a coherent, non-circular, non-contradictory way to that equation, I'll certainly post it here for you to dissect! Received on Fri Dec 12 2008 - 21:55:07 CET