Re: Relation Schemata vs. Relation Variables

"Jan Hidders" <hidders_at_gmail.com> wrote in message news:1157574550.782575.68320_at_b28g2000cwb.googlegroups.com...
>
> Brian Selzer wrote:
>>
>> 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.
>
> Well, it means that the old rule that was used in the transition
> constraint to "pair up" tuples such that they describe the same entity
> isn't right anymore, and should be changed. So you have to redefine the
> transition constraint. It's not really that surprising that a change to
> your static constraints also implies a change to your dynamic
> constraint, is it? But I assume you are arguing that such changes to
> dynamic constraint would be unncessary under your approach.
>
>> [...] 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.
>
> I can see where the pairing would come from for updates, but not with
> deletes and inserts. So you could get around the constraint by
> simulating the update with a combination of delets and inserts. If you
> want a real solution for this I don't think you can get around proper
> support for object / entity / tuple identifiers at the logical level.
>

I need to think about this.... A delete/insert combination would have to satisfy any delete constraints or insert constraints or both, but that doesn't mean that the update constraint couldn't still be circumvented. Foreign key constraints would make it more difficult, still.... I think this may have to do with the difference between consistency and correctness. A DBMS can't get inside the mind of a user to determine intent: it can only work with what it has been told, and under different circumstances the delete and insert could be a valid transition. Relational assignment can't prevent a user from inserting consistent but incorrect information, so it stands to reason that a user could choose a consistent but incorrect transition. What I want is a mechanism for the user to specify which of the many transitions that produce the proposed database state was intended. I also don't want to lose any information in translation. Additional information than just the old and new tuples may be useful, such as the names of the attributes that were targeted by the change, the names of the attributes that were used to target a subset of the relation, and the identity of the user that initiated the change.

> -- Jan Hidders
>
Received on Thu Sep 07 2006 - 08:47:51 CEST