Re: Relation Schemata vs. Relation Variables
Date: Fri, 25 Aug 2006 11:51:41 GMT
Message-ID: <hvBHg.1296$9u.19320_at_ursa-nb00s0.nbnet.nb.ca>
David Cressey wrote:
> "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).
>
> 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>
>
> End digression.
>
> Anyway, how does
>
> (r, t, t')
>
> differ from the pair of transitions?
>
> (r, t,empty)
> (r,empty,t')
Or how does
(r, t0, tn)
differ from the sequence of transitions?
(r0, t0, t1',r1)
(r1, t1, t2',r2)
...
(rn-1, tn-1, tn',rn)
Where rk are the states of some relvar r caused by a sequence of n assignments for k in [0,n], ti is the set of tuples in ri not appearing in ri+i for i in [0,n-1], and tj' is the set of tuples in rj not appearing in rj-i for j in [1,n].
Your comment regarding 'where current of' is apropos. If a dbms implements 'on update cascade' semantics, the dbms has full use of its internal representation for implementing those semantics. There is nothing wrong with the dbms using physical pointers for keeping track of what goes where.
I suggest 'on update cascade' semantics can only apply for something like the SQL UPDATE statement and not for generalized relational assignment. Obviously, for INSERT, the dbms cannot cascade inserts out of thin air. If a dbms implements 'on delete cascade' and 'on update cascade' semantics for a set of relations, then (r, t, empty) followed by (r, empty, t) will have the effect of deleting all references to t from all referencing relations.
Because the Tutorial D comma operator combines multiple queries into a single atomic statement, I expect that Tutorial D will have problems implementing 'on update cascade' semantics.
I question the need for 'on update cascade', but I note that some views would exhibit behavior similar to 'on update cascade'. This suggests those views pose problems for generalized assignment too.
For example, if we have two base relations ree and rer (for referree and
referrer) were ree has two candidate keys k0 and k1 and where rer has a
foreign key reference k0 to ree, one could create views
vee as ree{all but k0}
and
ver as (ree join rer){all but k0}.
It would appear that updates to vee will cascade to ver, but what happens in the case of an arbitrary assignment?
Suppose somebody made a copy of vee yesterday in relation rhist. What would happen to ver if someone assigned the value of rhist to vee? Received on Fri Aug 25 2006 - 13:51:41 CEST