Re: Relation Schemata vs. Relation Variables
Date: 6 Sep 2006 06:36:35 -0700
Message-ID: <1157549795.702923.101910_at_i3g2000cwc.googlegroups.com>
Brian Selzer wrote:
> "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.
You cannot pair up values David. You can only compare the sets as a whole.
> 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:36:35 CEST