Re: a union is always a join!

On Mar 17, 10:31 pm, "Brian Selzer" <br..._at_selzer-software.com> wrote:
> Your argument rests on the premise that keys permanently
> identify things in the universe of discourse.  But by definition, all that
> is required is that no two tuples in the same relation in the same database
> have the same key components.  What that means is that what identifies
> something in the universe of discourse at t' could identify something
> totally different at t''.

Well, there is no such thing as well defined update operation. Because, it depends on the key. Example

delete {(p=1,q=a)}
insert {(p=1,q=b)}

with key {p} is equivalent to

update where p = 1 set q = b

Therefore, the update relative to key {p,q} is different from update relative to key {p}. My take is that update is nothing more than syntactic shorthand for combination of insert and delete.

> In other words, just because keys are the same at different times doesn't
> necessarily mean that they map to the same thing in the universe of
> discourse, and similarly, just because keys are different at different times
> doesn't necessarily mean that they don't map to the same thing in the
> universe of discourse.

Keys were the only option to try to define update formally. Again, if not through keys, how do you formally define update?

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

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). Received on Wed Mar 18 2009 - 16:43:52 CET