Re: algebra equations for Reference and FD constraints

"paul c" <toledobythesea_at_oohay.ac> wrote in message news: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.
>

Yet the purpose of that database was to record chess moves....

> 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.

Perhaps some clarification is in order.

<QUOTE from "A Relational Model of Data for Large Shared Data Banks"> The totality of data in a data bank may be viewed as a collection of time-varying relations. These relations are of assorted degrees. As time progresses, each n-ary relation may be subject to insertion of additional n-tuples, deletion of existing ones, and alteration of components of any of its existing n-tuples.
</QUOTE>

"Update" when used collectively and "database update" denote any combination of insertions, deletions or alterations that completely describes what is different between one instantaneous state of the data bank and the next. "Update" when not used collectively denotes just "alterations."

> 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.)
>

The problem with a definition of update that relies on delete and insert is that the semantics of update--that is, the assertion that a particular individual appears different--is not the same as the semantics of delete and insert--that is, the assertion that there is a different individual. For example, suppose that there is a guy wearing a red hat in one picture and a guy wearing a blue hat in another. Under the semantics of update, the guy wearing the red hat is the guy wearing the blue hat--it is one individual that just happened to wear a different hat at different times, but under the semantics of delete and insert, the guy wearing the red hat is not the guy wearing the blue hat--they are two distinct individuals.

> I'm with McGoveran when he said:
> (quote)
> 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.)

I disagree with him. The primitives insert, delete and update are assertions: insert asserts that something exists now that hadn't, delete asserts that something that existed no longer does, and update asserts that something that exists differs in appearance.

A database is a set of named sets of sets of named values. It is not a set of named sets of named sets of named values. As a consequence, assignment is not sufficient to describe what is different between one instantaneous state of the data bank and the next. A set of deletes, inserts and updates, on the other hand, can be. Deletes identify those tuples in the previous state that have no corresponding tuple in the next state. Inserts identify those tuples in the next state that have no corresponding tuple in the previous state. Updates identify those tuples in the previous state that have different components in the next state and what those new component values are. Received on Wed Dec 31 2008 - 11:15:00 CET