Re: Relation Schemata vs. Relation Variables

"Brian Selzer" <brian_at_selzer-software.com> wrote in message news:JYBHg.11338$1f6.574_at_newssvr27.news.prodigy.net...
>
> "David Cressey" <dcressey_at_verizon.net> wrote in message
> news: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
> >> of a relation, t is a tuple from the current state, and t' is a tuple
> >> from
> >> 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>
>
> That's probably because it hasn't clicked yet that a transition is a *set*
> of triples, where each element represents only a distinct component of the
> overall difference between the current database state and a /possible
> state/. The above construct involves something that passes over a result
> set in a particular sequence. That's a totally different thing
altogether.
>

I'm well aware that you are talking about a set of transitions. Your professional history of dealing with bozos has conditioned you into a habit of condescension that is out of place in this newsgroup.

What may not have clicked with you is that the "set of transitions from one state to another" describes, nearly exactly, the progress of a processor executing a computer program. Abstracting out all of the intermediate states, where some, but not all of the transitions have been carried out, is the essence of atomicity of transactions.

> My thinking is that a user must assert which combination of component
> differences applies to a particular change, since there can be more than
one
> combination for a /possible state/ and not all of those combinations may
be
> allowed.
>
> >
> > End digression.
> >
> > Anyway, how does
> >
> > (r, t, t')
> >
> > differ from the pair of transitions?
> >
> > (r, t,empty)
> > (r,empty,t')
> >
>
> In the transition {(r, t, t')}, t and t' both /concern/ the same thing;
> however, in the transition {(r, t, empty), (r, empty, t')}, t and t'
> /concern/ different things.
>

How do you know?

PS: in the above, I intended to say "the pair of transitions", rather than "the transition composed of the pair of triples". If you treat

(r, t, empty)
(r, empty, t')

as a single transition composed of two triples, you're going to be in deeper water than you already are. Received on Fri Aug 25 2006 - 20:25:33 CEST