Re: MERGE as the imperative form of aggregation

"Bob Badour" <bbadour_at_pei.sympatico.ca> wrote in message news:d9MUh.25058$PV3.252617_at_ursa-nb00s0.nbnet.nb.ca...
> Marshall wrote:
>
>> On Apr 15, 8:16 pm, "Brian Selzer" <b..._at_selzer-software.com> wrote:
>>
>>>"Marshall" <marshall.spi..._at_gmail.com> wrote in message
>>>
>
> [snip]
>
>>> You can't use a key: [large snip]
>>
>> I definitely *don't* want to have the whole keys/correlating
>> tuples conversation again!
>>
>> Instead, I would like to discuss the application or importance
>> or theoretic foundation of transition constraints and/or triggers.
>> Anyone?
>
> Transitions are a distinguishing feature of state machines. I suggest each
> implies the other. If I recall his argument correctly, Brian's position
> assumes tuples are implicit state machines.
>

That's not quite how I would put it, since tuples are values. It's true that I think that a state machine can be used to limit the possible values for tuples and combinations of tuples in proposed database states with respect to the current database state.

> For a deterministic state machine, a new state is a function of a prior
> state and some event:
>
> f(S,E): S
>
> S_1 === f(S_0,E_0)
> S_n+1 === f(S_n,E_n)
>
> For a non-deterministic state machine, f above is a relation. One can
> change that into a boolean relation that tests the validity of a state
> transition:
>
> f'(S,S,E): {true,false}
>
> f'(S_n,S_n+1,E_n) is true iff a transition from S_n to S_n+1 is valid in
> response to even E_n.
>
> The form of f' is exactly the form of a relation in the relational model.
>
> If we have only partial information about E, a deterministic transition
> would appear non-deterministic based on the available information.
> (external predicate) In the degenerate case, we can know nothing about E
> and still express a transition constraint describing the allowable
> transitions for any E.
>
> As one can see, a transition constraint is a relation of degree 3.
>
> I see no particular restriction on the domains involved. S could be any
> domain and E could be any domain. This, of course, means S could be a
> tuple type.
>
> Brian's position simultaneously acknowledges and ignores logical identity
> and the information principle.
>

I think you need to review the definitions of logical identity and the information principle. Logical identity makes it possible to pick one element out of a set. It does not make it possible to pick out the same element in another set. Your understanding of logical identity is obviously flawed, therefore your argument is flawed.

> His logic follows the form of: Suppose we have a relation R(A) and a
> transition constraint X(A,A,E), it is possible that the attributes of A
> forming the candidate keys might change. We thus need a special statement
> that knows which of the values correspond.
>
> However, while his logic acknowledges candidate keys, it ignores what
> logical identity and the information principle actually say.
>
> While the relational model does not prevent A tuples from participating in
> transition constraints, logical identity and the information principle
> require us to identify the A's across the transition, and Brian's position
> simply ignores this requirement. This requires the designer to change R(A)
> to R(k,A) where k is a key of R.
>
> Then if we have an imperative statement where R(k,A) becomes R'(k',A'),
> and a transition relation X(A,A,E) the constraint becomes:
>
> assert (k != k') \/ (exists e | X(A,A',e))
>
> Note that we place no restrictions on the type or form of imperative
> statement whatsoever. The statement could assign a literal to a relvar and
> the constraint works the same as it would for an update statement.
Received on Mon Apr 16 2007 - 20:50:33 CEST