Re: Relation Schemata vs. Relation Variables

From: David Cressey <dcressey_at_verizon.net>
Date: Sat, 26 Aug 2006 13:37:12 GMT
Message-ID: <c8YHg.45$8Q6.5_at_trndny01>

"Brian Selzer" <brian_at_selzer-software.com> wrote in message news:vYJHg.17542$gY6.10049_at_newssvr11.news.prodigy.com...
> >> > 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.
>

OK. No harm done. The subject of UPDATE ... WHERE CURRENT is worth a side discussion here, because
it blurs the distinction between content based addressing and location based addressing. The CURRENT row of a result table is like "the can of Campbell's chicken noodle soup that I have in my left hand", although at a different level of abstraction.

I should mention in passing that I am NOT one of those purists in this forum who consider SQL so fallen as to be not worth the effort. On a practical level I'll settle for SQL until I learn something better. And I'm not in a hurry to learn something better. Later in this post, I'm going to discuss triggers that are fired on update, in order to get a more concrete handle on the abstraction that you are describing as a "transition".

And, sometimes, expressing things in a
> > 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.
>

The above is also worth a discussion of its own. Essentially the relational model (or at least the part of the model I'm familiar with) models the state of the database between transactions, not the intermediate states of the database during a transaction.
During a transaction there is code operating on the client side and also code that's operating on the server side. Describing database based constraints that operate in that environment can get awfully complex.

In that context I'm going to refer you to the discussions about tutorial D that surface in this forum. I've never fooled around with D, so I lack the specific concrete knowledge to comment on those discussions. But here's what I've gleaned from following the discussions.

In a language like SQL, A transaction is a series of actions, starting with an action that requires a transaction, and ending with a COMMIT or a ROLLBACK. (Actually, DEC Rdb/VMS had a specific "start transaction" action, but I don't think that's standard SQL.) Control is passed back and forth between the client and the server in the middle of all of this.

In D, if I understand correctly from what I've read in this forum, A transaction can (and should?) be expressed as a single message from the client to the server. Thus the entire transaction is atomic, not only with regard to the effect on the database, but also with regard to the client. I can't be sure of this, but I expect that this would simplify transition analysis a great deal.
A model such as your "set of triples" could be subjected to a rigorous analysis in D, in a way that baffles me with regard to SQL. Or so I imagine. I await eagerly the input of those who know both SQL and D.

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

It depends on what you mean by the above. I only know the internals of one product (DEC Rdb/VMS) well enough to comment on the above. With regard to Oracle RDBMS, all I can do is trust the documentation and the engineers and hope for the best. I forget wat Oracle documentation says about this.

Let me say a word about triggers, here. In SQL, a trigger can be fired up by an update. In fact, a trigger can even be specified as being fired up once for the entire update, or once for each row that is about to be updated. In the latter case,
the prodecure invoked by the trigger has available two values within the context of a single row, namely the old value and the new value.

In this context, your concept that the triple (r, t, t') refer to the same "thing" has a concrete meaning that I can wrap my mind around: the same "thing" refers to the same table row. However, I have the uneasy feeling that by "the same thing" you mean "the same thing" in the world of the subject matter. (Oops, meybe I ASS-U-ME too much). I await your shedding some light on this before proceeding.

anyway, back to SQL triggers. Note that at the end of the update, but before the commit, the client is going to receive control. The trigger alert the client by generating an error. So this kind of trigger operates not merely in the context of a single transaction, but in the context of a single action within that transaction. As such, it provides a poor concrete simile for the kind of analysis you are attempting with the sets of triples.

By an amazing coincidence, the "old" and "new" values in the context of a trigger during an update suffers from the exact same mystery as the UPDATE .... WHERE CURRENT suffers from. Received on Sat Aug 26 2006 - 15:37:12 CEST