Re: Relation Schemata vs. Relation Variables

vc wrote:
> I did not see any examples of Dataphor relational assignment in the
> online manuals they have on their website. Could you provide a
> reference ?

I don't know if they mention it specifically in the documentation anywhere; maybe not, since it is a somewhat obvious consequence of relvars being, well, variables. I know they support it because I use it.

> Also, if the r.a is indeed implemented as a
> delete/insert/update and you specify some constraint for a d/i/u, it's
> unclear why such constraint should be circumvented.

Consider the TC that employee salaries may not decrease:

transition constraint TC1 on update new.Salary >= old.Salary

Now consider the relvar R = table { row { 1 ID, 70000 Salary } }. "update R set { Salary := 60000 }" will fail because of TC1, but the corresponding relational assignment, which can be simplified to "R := table { row { 1 ID, 60000 Salary } }" will succeed. I cannot see how tuple-base TCs (or referential actions, for that matter) can work if one takes update-as-relational-assignment completely seriously.

Including "on delete false" in TC1 might on first glance seem to resolve the problem, since then the assignment will also fail. But *any* relational assignment (in Dataphor) will fail in that case (except if the relvar is empty to begin with), so that's not very useful.

I also note that the delete constraint might be needed even if we avoid relational assignment, because else we could circumvent the TC by first deleting the tuple, and then inserting a new corresponding (i.e. same key) tuple with lower salary. But the point is: Tuple-based TCs and relational assignment don't work well together.

>> My point was just that Dataphor's TCs are (for
>> update) based on comparing pairs of tuples, and the pairing is based on
>> the formulation of the 'update' statement. When using relational
>> assignment (including translating an update shorthand to an assignment)
>> this pairing is lost; thus, that kind of TC doesn't work. (It also has
>> other problems.)

Relvar R with the TC1 update constraint:

ID Salary
==+------
0 60000
1 70000

update R set { ID := (ID + 1) mod 2 };

TC1 isn't violated, yet employee 1's salary has decreased. This may be why some hold that keys must be constant / tuples must have identity (speaking loosely).

>> TTM-style transition constraints, based on comparing
>> (pairs of) relations, not tuples, avoid those problems.

A corresponding TTM TC would be something like this, I think:

IS_EMPTY(R RENAME (Salary AS NewSalary) JOIN R' RENAME (Salary AS OldSalary) WHERE NewSalary < OldSalary)

It will prevent the updates above, including the relational assignment. It will not preventing deleting an employee and reinserting it with a lower salary, though. Another constraint is needed for that, but it will work with both assignment and insert/update/delete.

>> I thought this
>> was what you meant by the term 'set-theoretic': set-at-a-time vs.
>> tuple-at-a-time.

You are leaving out the crucial context of these predicates: The point is how to determine which AgePrev/AgeCurrent pairs to compare. Hopefully the examples above make it clear what I mean.

-- 
Jon