Re: Relation Schemata vs. Relation Variables

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

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.

A thing can come into existence, can change in appearance, and can become nonexistent. The distinction between the two transitions makes it possible for the database designer to constrain information about each type of event. For example, the U.S. government requires additional documentation for cash transactions that exceed $5,000. The above distinction makes it possible to reject such a cash transaction without the requisite documentation. Since a transition is a set of component differences, one component could represent the documentation while another could represent the cash transaction, and a transition constraint could then eliminate from consideration all transitions that don't include both the documentation and the cash transaction whenever the amount exceeds $5,000.

>
>
>
>
>
>
>
>
>
Received on Fri Aug 25 2006 - 14:23:05 CEST