Re: A different definition of MINUS, Part 3

"paul c" <toledobythesea_at_oohay.ac> wrote in message news:Chd2l.8032$fv3.1578_at_newsfe06.iad...
> paul c wrote:
> ,,,
>> Neither has the Y' result dropped any tuples and we have a situation
>> where R = X <AND> Y, but R' is NOT equal to X' <AND> Y', in other words
>> DELETE R WHERE X = 1 AND Y = 1 does nothing! ...
>
> Oops, just noticed, that was pretty clumsy, what I wrote denies everything
> I've been saying all along and I didn't mean that. I should have said it
> subjunctively: "... if we had a situation where R' were not equal to X'
> <AND> Y', we would have a serious contradiction in the algebra, so R' IS
> equal to X' <AND> Y' and no tuples are dropped from the result...". I
> stand by the rest, ie., the DELETE statement does nothing.
>
> (I don't know why Date referred to the statement as an "operation".
> Personally, I think calling it an operation takes a turn that might risk
> confusing a language implementation with the algebra the language
> interprets or, equally, is based on. But as long as I live, I imagine
> there will always be nuances he suggests that will puzzle me.)
>
> Also, I want to comment further on what 'BS' said in a reply about an
> algebra and it not having any notion of 'before' or 'after'. I agree that
> the A-algebra doesn't have such notions, which in fact is one of its
> advantages, eg., there are fewer concepts in an algebra to confuse us (and
> I do mean the plural 'us'). As Darwen likes to point out, logic isn't
> concerned with meaning, which is its advantage because we can choose the
> analogues we want to use it for. It's like when McCarthy talked about
> submarines not being able to swim. They can't but we can pretend that
> they can pretend to (apologies to Bob B for the possible homomorphism, but
> even D&D overload the verb 'to know' when they talk about dbms's! As
> Djiksta said, when you get right down to it, all a program does is
> manipulate symbols. What the symbols mean is up to 'us').
>
> But I would like to ask how is that a result can't be interpreted as an
> 'after value' when an algebraic equation does allow us to talk of a result
> of algebraic operations? What's more, no matter what changes happen over
> time, such an equation, if it doesn't contradict any others, as well as
> the result, is always true.
>
> It is simple to invent algebraic operands that can be interpreted as
> 'before' and 'after', one just makes up names, eg., R' and R. The names
> can stand double-duty too in that (consistent) equations are invariant.
>
> Personally I am coming to believe that the only "dire consequences" one
> can encounter turn up when one talks about the RM in terms of a language
> implementation, instead of sticking either to the algebra or to the
> calculus. Whether dire or not, I judge them to be self-inflicted
> consequences.

It isn't about implementation: it's about the logic that underpins the RM. Regardless of how many possible values there can be for a database, only one can actually be the value of the database at any set point in time. Algebraic expressions derive information from the actual value of the database; updates, on the other hand, assert which possible value for the database is also the actual value. Common sense tells us to discard a result that is based upon a false premise, so it follows that the result of an algebraic expression that involves a possible value for the database that is not also the actual value is just as useless. The algebra and the calculus are therefore limited in their utility to answering queries from the actual value of the database and have absolutely nothing to do with selecting which possible value is also the actual value. In other words, neither the algebra nor the calculus are sufficient when it comes to database updates. As a consequence, a 'purely algebraic' approach here is contraindicated.

There's nothing wrong it using the algebra or the calculus for what they were designed for, which is answering queries, or even for calculating the resulting set of relations that are becoming the new value for the database, but it's important to remember that it is the result that is assigned, and that the assignment principle doesn't require that the result be recalculated once the assignment has been made. Consider:

x := x + 1

replaces the contents of the variable x with the result of incrementing the current value in x. This is in accord with the assignment principle because the rhs of the assignment is only evaluated once. Received on Thu Dec 18 2008 - 05:12:43 CET