Re: thinking about UPDATE

"x" <x-false_at_yahoo.com> wrote in message news:40fe3be3$1_at_post.usenet.com...
> **** Post for FREE via your newsreader at post.usenet.com ****
>
> "Marshall Spight" <mspight_at_dnai.com> wrote in message
> news:N0mLc.114236$WX.22912_at_attbi_s51...
> > Hi all,
> >
> > I was thinking about the relationship between operations of the
> > relational algebra and SQL statements.
>
> > INSERT is a lot like union, but with an odd restriction that the
> > intersection of the new set and the existing set must be empty. (Why?)
>
> This is only if you define a primary or candidate key.

But I always do! :-)

> > DELETE is the same thing as set subtraction.
>
> > But what the heck is UPDATE?
>
> > If T : {a1, a2, ... an}
>
> > UPDATE T set a1 = 0 where <cond>
> > is
> > T' = T { 0, a2, ... an | <cond> }
> > T = T - T { a1, a2, ... an | <cond> }
> > T = T union T'
>
> > That's certainly more complicated than I would suspect
> > for what seems like such a simple operation.
>
> > Am I making it needlessly complex, or is this about right?
> > Is there some other way to think about UPDATE?
>
> You could think about it as a set transformation
> T --- f ---> T'
> {t | t in T}---> {f(t) | t in T}
>
> Some questions to think about:
> Why there is a need for primary/candidate keys in RM ?

It's not a set if it allows duplicates.

> If keys are essential, why the definitions of the relational operators don't
> include them ?

For one thing, what you get back from a select (I guess I'm talking SQL now) is a value that you can't really do much with. You can't assign it to a relational variable and manipulate it further, so any constraints you might expect to see on the value are irrelevant. Which bugs me.

Presumably one could infer the keys on the results of a relational operator.

Marshall Received on Wed Jul 21 2004 - 18:59:36 CEST