# Re: a union is always a join!

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" <br..._at_selzer-software.com> 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

http://www.dcs.warwick.ac.uk/~hugh/TTM/CHAP05.pdf )

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

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