Re: Relation Schemata vs. Relation Variables

"Jan Hidders" <hidders_at_gmail.com> wrote in message news:1157532864.768886.10750_at_d34g2000cwd.googlegroups.com...
>
> Brian Selzer wrote:
>> "Jan Hidders" <hidders_at_gmail.com> wrote in message
>> news:1157457516.222077.154380_at_b28g2000cwb.googlegroups.com...
>> >
>> > Sets of facts can and do change, and transitional constraints restrict
>> > wich transitions from one set of fact to another are allowed. I don't
>> > see a fundamental problem here. Note btw. that they are a strict
>> > subclass of the restrictions that might be expressed by some kind of
>> > temporal logic.
>>
>> I don't understand what you mean. Are you saying that transition
>> constraints can be expressed as state constraints?
>
> A transitional constraint is a binary predicate over states. One
> argument is the old state and the other the new state. Or, put in
> another way, a transition constraint constrains the transitions. This,
> I would say, is pretty much the definition of the term.
>
> Or did I misunderstand your question and are you asking about temporal
> logics?
>

No. I just wanted to be sure that we're on the same page.

The point that I was making in the original post is that because keys can change, there isn't enough information given only the old state and the new state to pair up the values in the old state with those in the new state for comparison. A database state is a set of named sets of sets of named values, not a set of named sets of named sets of named values. The guaranteed access rule states (I'm paraphrasing) that each and every atomic value can be located in a database state by using a combination of the name of a relation, the name of an attribute and a candidate key value, so the value of a candidate key may appear to some to be a third "name." This is not necessarily true because keys can change--"key updates" was the phrase Codd used. Since keys can change, identification cannot be used to pair up values in the old state with values in the new state for comparison; therefore, a transition constraint f(D, D') may not work correctly if one or more keys change--indeed, f(D, D') will only work deterministicly in all cases if tuples are named (tuple identifiers), or if what is being compared are aggregates. Instead, a transition constraint could be defined as a function f(D, P), where P is a set of paired tuples describing what is different between D and D'. P is the result of observation, not identification. That is, the user targets a set of values, and then informs the system how each value in the set will be different in the new state. As a consequence, there is no need to locate a value in the new state to pair it with one in the old state because that pairing has already been done when the user targeted the set of values. Of course, this means that a mechanism must be available to allow the user to pass along that information--that is, to select which of the many transitions resulting in the new state was intended.

> -- Jan Hidders
>
Received on Wed Sep 06 2006 - 15:08:08 CEST