Re: Relation Schemata vs. Relation Variables
Date: Fri, 01 Sep 2006 03:53:45 GMT
Message-ID: <d9OJg.501786$IK3.102075_at_pd7tw1no>
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.
>
> 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.) >> 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).
>
>>> 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.
I'm not sure that the comment about tuples matters, but anyway, I think those are excellent examples and points you make.
Regarding the salary increment and going back to algebra, say D&D algebra since I don't really know much of any others, I wonder whether delete and insert expressed in terms of assignments aren't in fact capable of handling the constraint of not lowering anybody's salary.
Not to say that end users must use an algebra, but an algebra is what an engine is likely to use underneath whatever syntax the users have. So I assume an engine that was instructed to obey the TC would invoke something like (assuming the user langugage allowed transition constraints):
R' = R <AND> <NOT> {ID 1} <AND> <NOT> {Salary LE 60000} as part of a 'delete' "step". Depending on the implementation, this might raise an exception or not, just as a subsequent assignment such as
R'' = R' <OR> {ID 1, Salary 60000, ...) might or might not raise an exception. I know most people would prefer an exception, I'm just pointing out that the most elemental algebras don't embody exceptions.
Surely a verb like 'update' is just a shortcut if an implementation uses an algebra such as D&D's which apart from no exceptions, has no operator for update?
Just my two cents, we can only accomplish what the 'bare metal' allows (these days D&D's Algebra is as close as I get to bare metal, which I find a little ironic, since it is not supposed to be about bare metal at all!)
p Received on Fri Sep 01 2006 - 05:53:45 CEST