# Re: Relation Schemata vs. Relation Variables

Date: 1 Sep 2006 06:41:01 -0700

Message-ID: <1157118061.640351.213230_at_i3g2000cwc.googlegroups.com>

Jon Heggland wrote:

*> 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.
*

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).
*

If Dataphor silently ignores shorthand constraints with relational assignment, then the implementation is deficient. Alternatively, one can treat update constraints as matching old/new rows by some hidden row_id rather than by the primary key, but such treatment is also no good since hidden row_id's is not part of the relational model.

Is it the case that the Dataphor relational assignment does not honor any constraints ? If so, how can one seriously consider using the assignment?

[...]

*> >> 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.)
*

If the Dataphor relational assignment does not honor constraints, then the implementation is seriously broken.

*> >
**> > Could you be more specific about 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).
*

Right, if the Dataphor TC matches, conceptually, old/new tuples by a hidden id as it appears to do, then there is no way to enforce TC1 with the above update (except by disallowing the key update).

*>
**> >> TTM-style transition constraints, based on comparing
**> >> (pairs of) relations, not tuples, avoid those problems.
**> >
**> > For example (Dataphor vs. TTM) ?
**>
**> 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.
**> >
**> > Are you saying that a predicate "AgePrev - AgeCurrent <= 0" is somehow
**> > less 'set-theoretical' than "sum(account) = 1000" ?
**>
**> 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.
*

Even with the apparently broken Dataphor constraint implementation, one can still regard its TCs as dealing with sets obtained as a result of matching old/new tuples by the row id rather than some row-by-row sequential process (which it may very well be under covers).

*> --
**> Jon
*

Received on Fri Sep 01 2006 - 15:41:01 CEST