Re: a union is always a join!

From: paul c <>
Date: Wed, 18 Mar 2009 18:04:57 GMT
Message-ID: <dJawl.18624$PH1.11373_at_edtnps82>

Tegiri Nenashi wrote:
> On Mar 17, 10:31 pm, "Brian Selzer" <> wrote: ...
>>> Morale: you
>>> can't possibly define what update is without a key.
>> Yes, you can: Consider the equivalence between the two D expressions from
>> /TTM Third Edition/ pages 112-113:
>> UPDATE r (Ai := X, Aj := Y)
>> where i != j is equivalent to
>> ( ( EXTEND r ADD ( X AS Bi, Y AS Bj ) )
>> { ALL BUT Ai, Aj } RENAME { Bi AS Bk, Bj AS Aj, Bk AS Ai}
>> ...

Right. So-called "UPDATE" is a language device and when defined algebraically doesn't need to depend on keys. (The exact quote can be found at the bottom of page 24 at )

>> Now let's look a bit more closely at this expression. The first part
>> ( ( EXTEND r ADD ( X AS Bi, Y AS Bj ) )
>> results in a relation in which each tuple contains both the old components
>> and the new components, and from that relation it is possible to determine
>> exactly what is different--tuple, by tuple. But then that /stated/
>> correlation is projected away by
>> { ALL BUT Ai, Aj } RENAME { Bi AS Bk, Bj AS Aj, Bk AS Ai},
>> so clearly, information is lost when translating an update into an
>> assignment. Now if we could just shift constraint enforcement to just
>> before that information is projected away, then we could specify transition
>> constraints declaratively.
> ...

To be precise, this particular language definition (Tutorial D) "loses" information. That doesn't prevent some other language or environment definition from presenting the un-renamed, un-projected relation value to some declarative expression, ie., the algebra doesn't prevent such a language.

> I'm not sure what relational assignment is to form an opinion if it
> adequately preserves information to be leveraged in transition
> constraints. It is obvious that transition constraint is nothing more
> than algebraic-relational expression that includes two variables: the
> state of relation before update R(t_1) and the state after R(t_2).

If you're saying you're not sure what relational assignment is, it is the assignment of a relation value to a variable, aka pointer, ie., it   is a language device. Don't confuse relational assignment with any of the relational operators, which involve no notion of pointers. I wish people would clarify whether they are talking about the RM or about some language or other.

Notions of 'before' and 'after' don't matter to an algebra, only two possible relation values, as the Tutorial D definition hints at - nothing prevents a language from having a notation that presents a single relation value with tuples that have two values for each attribute. Received on Wed Mar 18 2009 - 19:04:57 CET

Original text of this message