Re: Relation Schemata vs. Relation Variables
Date: Fri, 25 Aug 2006 07:17:31 GMT
Message-ID: <fuxHg.10510$6s.7395_at_trndny08>
"paul c" <toledobythesea_at_oohay.ac> wrote in message
news:8YrHg.452473$Mn5.358194_at_pd7tw3no...
> paul c wrote:
> > Bob Badour wrote:
> >> paul c wrote:
> >>
> >>> Bob Badour wrote:
> >>>
> >>>> paul c wrote:
> >>>>
> >>>>> paul c wrote:
> >>>>> ...
> >>>>>
> >>>>>> PMFJI, I would say that the VALUE of a candidate key identifies
> >>>>>> one and only one tuple FOREVER!
> >>>>>
> >>>>> Stupid me, I have to take part of that back - the value of a
> >>>>> candidate key obviously could identify several tuples but I still
> >>>>> think that would hold forever. Might have been better to say the
> >>>>> value of a candidate key identifies a tuple regardless of time.
> >>>>
> >>>> A candidate key does not identify a tuple. A candidate key is a
> >>>> constraint on a relvar and not on a tuple.
> >>>
> >>> No argument about a candidate key being a constraint. I`m talking
> >>> about the value of a candidate key. If you can infer the values of
> >>> the other attributes from that value, I`d say you have achieved
> >>> identification.
> >>
> >> And one cannot infer anything from a subset of the attributes when one
> >> is talking about a tuple. The only thing that identifies a tuple is
> >> the tuple's value. Just as the only thing that identifies the number 5
> >> is the number 5.
> >
> > There must be a subtlety here that eludes me. If a candidate key, k, of
> > a relation has a value of 1 in some tuple and a tuple in that relation
> > has a value of {k 1, x 2} then I would say that the value k = 1
> > certainly identifies that tuple.
> >
>
> Okay, maybe now I'm seeing the subtlety, if you are talking about the
> tuple after it's been identified, ie., a tuple in the context of a
> relation. If I've got that right, I could have been more clear that I
> was talking about identifying a tuple within a relation. Your emphasis
> on language precision, which some people might call pedantry, hurts my
> head, but I suppose it's necessary and I really shouldn't complain if
> the theorists are to find any common ground with the hackers (or if the
> hackers are to get their act together).
>
> p
I disagree about the emphasis on precision being pedantry. It's pedantry
only when the distinction makes no difference.
In that context, I have to back track a little. A few responses back, I
said that a candidate key doesn't identify a tuple.
Perhaps I should have said "relvar that contains a tuple". In the context
of an update, it's easy to confuse the two.
Let's go back to the start of this thread:
> A transition can be defined as a set of triples (r, t, t') where r is the
name
> the proposed state.
There's a problem here: what ties t and t' together? Do they share a common identity? Well, no they don't, because they aren't the same tuple. However what I think Brian implies is that there is a relvar that has the state t before the transition and the state t' after the transition. Notice that it's the relvar whose identity endures the transition, not the contents.
A small digression: all this reminds me of the (in)famous SQL construct:
UPDATE .... WHERE CURRENT of <cursor>
End digression.
Anyway, how does
(r, t, t')
differ from the pair of transitions?
(r, t,empty)
(r,empty,t')
Received on Fri Aug 25 2006 - 09:17:31 CEST