Re: Relation Schemata vs. Relation Variables

Brian Selzer wrote:
> "Jon Heggland" <jon.heggland_at_idi.ntnu.no> wrote in message
> news:ed9fsd$n9q$1_at_orkan.itea.ntnu.no...

>> vc wrote:
>>> My point is that if 'update' is shorthand for the respective relational
>>> assignment,  then by the same token the update constraint must be
>>> shorthand for the respective relvar constraint: IS_EMPTY(R RENAME
>>> (Salary AS NewSalary) JOIN R' RENAME (Salary AS
>>> OldSalary) WHERE NewSalary < OldSalary).
>>
>> In that case, the shorthand is insufficient, because it doesn't specify
>> what you should join on. You could say it should join on the key by
>> default, but what if there's more than one key? What if you want keys to
>> be able to change?

Huh? On the contrary, relvar-based TCs make that no problem at all. It is only (what I call) tuple-based TCs that suffer from this problem. I think you are confused by thinking in terms of entities instead of propositions.

> So we're stuck with either implementation-specific row-level transition
> constraints such as a FOR EACH ROW triggers or Dataphor's implementation, or
> introducing tuple identifiers or sets of object identifiers to guarantee
> that at least one key won't change. A better solution is needed. Instead
> of exposing only the proposed state, that is, R', the transition itself
> could also be exposed as a set of relations, Rd, Ru, Ri, representing
> respectively the tuples that will be removed, the tuples that will be
> different and how, and the tuples that are being added.

This is nonsense. Within the confines of an atomic statement, there is no logical difference between "changing a tuple" and "removing a tuple and adding another". All that matters is that some propositions cease to be true, while others begin.

-- 
Jon