Re: MERGE as the imperative form of aggregation
Date: Mon, 16 Apr 2007 19:29:37 GMT
Message-ID: <B8QUh.10893$Kd3.5090_at_newssvr27.news.prodigy.net>
"Brian Selzer" <brian_at_selzer-software.com> wrote in message
news:ZzPUh.10890$Kd3.9572_at_newssvr27.news.prodigy.net...
>
> "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.
>
Correction: Logical identity makes it possible to pick one element out of a set. It does not make it possible to pick out a similar element in another set. Things are not identical unless every attribute is identical.
>> 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 - 21:29:37 CEST