Re: Relation Schemata vs. Relation Variables

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.

Technically, the Dataphor TC is not a tuple constraint because it references two tuples, or rather two sets of tuples, not just a single tuple. You can think in terms of ordered pairs too, but it's a matter of taste.

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