Re: a union is always a join!

On Mar 18, 11:43 am, Tegiri Nenashi <TegiriNena..._at_gmail.com> wrote:
> 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.
>

I don't think so. I think that the delete/insert pair states that there is a different thing with key p = 1, whereas the update states that the thing with key p = 1 merely appears different. In other words, the delete/insert pair describes two distinct things, whereas the update describes two distinct appearances of the same thing. The delete/insert pair,

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

states that there are two distinct things with exactly the same components, just during adjacent intervals.

> > 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?
>

I just don't agree with you on this. I presented an alternative definition that is independent of keys.

>
> > > 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).- Hide quoted text -

Unfortunately, it just isn't that simple. Since the key components that identify something can be different at different times yet still identify that same something, there can be more than one transition that yields a resulting state. For example, if the guy that had up to this point been first in line at the bank was wearing a blue hat, and if the guy that is now first in line is wearing a red hat, then one possibility is that there is a different guy that is first in line, the guy wearing the red hat, but another possibility is that the guy that had up to this point been first in line is still first in line but just put on a red hat. So which is it? If the transition consisted of a delete/insert pair, then it's clear that it's the first possibility, but if the transition consists of an update, then it's clearly the second.

> - Show quoted text -
Received on Thu Mar 19 2009 - 03:25:16 CET