Re: thinking about UPDATE

"x" <x-false_at_yahoo.com> wrote in message news:40feafc9_at_post.usenet.com...
> **** Post for FREE via your newsreader at post.usenet.com ****
>
> "Marshall Spight" <mspight_at_dnai.com> wrote in message
> news:YhxLc.4607$8_6.1154_at_attbi_s04...
>
> > > 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.
>
> It is one thing to not allow duplicates, it is another thing to have a
> primary/candidate key that is a strict subset of all relation attributes.

If you allow the key to be a proper subset of the attributes, and you only have one key, this is the same thing as a function, which is pretty cool in itself. This opens up the possibility of mixing generators and extensional relations.

> > > 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.
>
> You are not alone :-)

Always nice to know.

> > Presumably one could infer the keys on the results of a relational
> > operator.
>
> Try it. For project operator for example.

Okay....

Marshall
(will check back later) Received on Thu Jul 22 2004 - 05:28:09 CEST