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
