Re: cdt glossary 0.1.1 [Transaction]

"paul c" <toledobythesea_at_oohay.ac> wrote in message news:x6SVh.98742$DE1.19705_at_pd7urf2no...
> mAsterdam wrote:
>> paul c wrote:
[snip]

> I wasn't suggesting it did. As far as I know, "order of work" is not a
> relational issue, nor is a transaction a relational concept any more than
> invoices are. Wondering why they aren't part of RT is like asking why the
> RM isn't based on a state machine.
>

So what would you call something that transforms one database state into another? In 1970, Codd called them "state-changing transactions."

> I would say "order of work" is a language concept and is not necessarily
> required by all possible languages. I also think it is not necessarily
> part and parcel of a transaction concept. (For example, my preferred
> language would not require statements to be ordered by the programmer,
> even though the machine might have to order them.) Saying that one can't
> have an atomic group of statements that either all complete successfully
> or none of them completes without the programmer's statements following
> some order is like saying that relations must be stored in the same table
> form that they might be displayed in.
>

I think that if a transaction contains more than one operation, then the order in which each operation is evaluated is critical. 2 + 3 * 5 = 17, not 25.

After the following transaction,

UPDATE r SET x = x + 5 WHERE k = 22,
UPDATE r SET x = x * 4 WHERE k = 22

Is the result (x + 5) * 4 or (x * 4) + 5? Or is it x * 4, which is what D&D's multiple assignment would produce?

Do you limit a transaction so that only one transformation can occur per relation? Per tuple? Per attribute value?

Should all constraints be checked after each operation? Only some? Or should they all be deferred until the end? I mention this because the result of one operation may leave the database in an inconsistent state, making any subsequent operations suspect.

If it were possible to convert a group of statements into a single operation, then there would be no need for order, there would only be one transformation per relation, per tuple and per attribute value, and constraints would only need to be checked once. Alas, this capability is not available in any commercial system that I know of, and even D doesn't doesn't support it.

> (To my mind, that appendix lays a basis for the bare naked relational
> model and includes formal definitions too. Unfortunately for those who
> don't have one of three printed editions, the chapter five of the third
> edition that is on the TTM web site doesn't have the section "mapping the
> relational operators" section that the second edition's chapter five
> included (eg., that's where UNION/INSERT are defined in terms of <OR>). I
> guess it is in some other chapter of the print version of the third
> edition, at least I hope so since it rounds out the bare naked model for
> me.)
>
> p
Received on Fri Apr 20 2007 - 05:42:48 CEST