Re: Relation Schemata vs. Relation Variables

"David Cressey" <dcressey_at_verizon.net> wrote in message news:xgHHg.17$XK4.4_at_trndny07...
>
> "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.
>

I ASS-U-MEd that you were confusing triples with transitions because of the digression below. I was wrong, and I apologize. I did not intend to be condescending.

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

I'm not sure that I understand what you're trying to say. Yes, there may be intermediate states within a transaction, and from a logical standpoint, it's not necessary that we know what those are.... Did I somehow imply by saying "from one state to another" (I didn't think I said that...maybe it was in another thread) that there would be a series of successive transitions between the current state and each possible state? That was definitely not my intended meaning. What I did intend was that the user specifies one and only one transition, which when applied to the current database state yields one and only one possible database state. Just as the set of all state constraints defines a set of consistent database states, each of which may become current; the set of all transition constraints defines a set of possible transitions, each of which by itself describes the difference between the current database state and a possible database state.

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

In the one transition both tuples appear in the same triple, whereas in the other, they appear in different triples. So if they appear in the same triple, then they concern the same thing. If they don't appear in the same triple, then either they don't concern the same thing, or it wasn't important that they do. In a closed world, if you're not told that facts concern the same thing, then you cannot prove that they do, so they don't.

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

Is this not what happens with relational assignment? The old values are deleted and the new values are inserted.

>
>
>
>
Received on Fri Aug 25 2006 - 23:28:59 CEST