Re: Date and McGoveran comments on view updating 'problem'
- From: paul c <toledobythesea@xxxxxxxx>
- Date: Fri, 12 Dec 2008 20:55:07 GMT
Bob Badour wrote:
vadimtro@xxxxxxxxx wrote:
On Dec 11, 2:03 pm, Bob Badour <bbad...@xxxxxxxxxxxxxxxx> 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 disambiguate.
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!
.
- References:
- Date and McGoveran comments on view updating 'problem'
- From: paul c
- Re: Date and McGoveran comments on view updating 'problem'
- From: vadimtro
- Re: Date and McGoveran comments on view updating 'problem'
- From: paul c
- Re: Date and McGoveran comments on view updating 'problem'
- From: vadimtro
- Re: Date and McGoveran comments on view updating 'problem'
- From: vadimtro
- Re: Date and McGoveran comments on view updating 'problem'
- From: vadimtro
- Re: Date and McGoveran comments on view updating 'problem'
- From: Bob Badour
- Re: Date and McGoveran comments on view updating 'problem'
- From: vadimtro
- Re: Date and McGoveran comments on view updating 'problem'
- From: Bob Badour
- Date and McGoveran comments on view updating 'problem'
- Prev by Date: Re: Onto a potential relational manipulation language
- Next by Date: Re: Onto a potential relational manipulation language
- Previous by thread: Re: Date and McGoveran comments on view updating 'problem'
- Next by thread: Re: Date and McGoveran comments on view updating 'problem'
- Index(es):
Relevant Pages
|