Re: MERGE as the imperative form of aggregation

"Bob Badour" <bbadour_at_pei.sympatico.ca> wrote in message news:Ek3Vh.25366$PV3.257421_at_ursa-nb00s0.nbnet.nb.ca...
> paul c wrote:
>
>> Bob Badour wrote:
>>
>>> ...
>>> Brian's position simultaneously acknowledges and ignores logical
>>> identity and the information principle.
>>> ...
>>
>> Regarding "logical identity" (a phrase that has a familiar ring even
>> though I don't remember seeing a definition), does it mean anything but
>> equality of values?
>
> Logical identity depends on the equality of values. Logical identity
> requires one express identity as explicit values via one or more candidate
> keys. Codd originally expressed it as a requirement for a primary key in
> his 12 rules.
>

Again, Logical identity cannot be used because it would require that ALL attribute values be identical, not just those for a candidate key. Your argument is without merit because if no differences exist, then no transition occurred! The Information Rule and the Guaranteed Access Rule only apply to consistent database states, not changes of state. In fact, Codd understood that the database might be inconsistent during a transition. I think he referred to them as "transitory inconsistencies."

> Selzer basically wants to have sets of state machines without identifying
> the state machines.

No. That's not true either. What I want is the ability to determine which transition the user specified so that transition constraints can be checked. Your argument appears to be that keys are never updated, despite the fact that Codd specifically uses the phrase "key update" in the definitive "A Relational Model of Data for Large Shared Data Banks" published in 1970. Who are we to believe, Bob Badour or E. F. Codd?

The bottom line is that the value of a key can only be used to identify a tuple in a single database state. Since a transition involves two database states, a key value from the preceding database state can't be used to identify a tuple in the succeeding database state. Since keys can't be used, some other mechanism should be made available that correlates tuples from the preceeding database state with those in the succeeding state. My argument is that since the user supplies that information when he submits an update, make it available so that constraints can be declared that take advantage of it. It's as simple as that. Received on Tue Apr 17 2007 - 19:06:38 CEST