Re: Relation Schemata vs. Relation Variables

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.

• Jan Hidders