Re: algebra equations for Reference and FD constraints

From: paul c <>
Date: Mon, 29 Dec 2008 06:56:04 -0800
Message-ID: <Ww56l.37835$lX6.24803_at_newsfe06.iad>

Brian Selzer wrote:
> for recording moves starts out empty. Once a move is played, how can the
> database reflect that fact unless there is some means to assert that fact?
> Database updates are indeed a relational model concept even though neither
> the algebra nor the calculus are sufficient to express them..
> ...

This reminds me of a janitor I knew. When we were hanging around the computer room he would pester us to make the computer predict the horse races for him. He was so persistent that we finally gave him our picks each week and told him the computer had decided. As far as he was concerned, the computer picked the horses. He was a mystic.

I don't think it's a good idea, at least in c.d.t, to talk of a relation changing its value any more than it's a good idea to talk of a light bulb changing itself. Ironically, such concepts are not only theoretically unsound, but impractical too. It's like the little king telling Alice that the word means what he wants it to mean. Saying so doesn't make it so.

In the case of the chess moves, the user chooses to believe that the current database value 'reflects' the history of the match. The 'reflection', if any, is only in the mind's eye.

When most people talk about updates, the word gets tossed around in so many ways that I can't be sure whether they are talking about an SQL verb or 'deletes' and 'inserts' too. These are all old words from the file-based days and I wish Codd had gotten rid of them. It would be better if he had just talked about symbolic results.

For that matter, I've yet to see a formal definition of 'update' that doesn't rely on 'delete' and 'insert' and I've never seen a formal definition of the latter two that wasn't expressed in terms of the calculus or algebra. Just saying to the effect that 'the computer MUST be updating because I'm seeing the result I want' doesn't lead me to any useful conclusions about how an implementation's symbolic manipulations should operate and achieve logical consistency at the same time. (Since I don't think much of the kind of prose-based rules that I've seen in SQL so-called 'definitions' or the Oracle 'rules' Vadim posted lately. Way too easy for an implementor or user to mis-interpret.)

I'm with McGoveran when he said:
8. We must avoid the temptation to think of a relational update as anything other than a declarative specification of a resulting relation (a set) incorporating the relvar predicate of source relation and its current value. Nothing else is pertinent to computing the value that is to be "assigned" to the relvar. If a reference to one or more tuples occurs within the update expression, we should not think even of these as anything other than a particular way of expressing a constraint (i.e., as part of an "update predicate"). (end quote)

(I realize McGoveran mentions 'relvars' but I don't claim a dbms must implement relvars, I just think they are useful for those of a procedural or imperative bent to talk more precisely.) Received on Mon Dec 29 2008 - 15:56:04 CET

Original text of this message