Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: Relation Schemata vs. Relation Variables

Re: Relation Schemata vs. Relation Variables

From: Jon Heggland <jon.heggland_at_idi.ntnu.no>
Date: Fri, 01 Sep 2006 16:23:14 +0200
Message-ID: <ed9fsd$n9q$1@orkan.itea.ntnu.no>


vc wrote:
> Jon Heggland wrote:

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

I can't recall I have called it a "tuple constraint". I have called it a "tuple-based transition constraint". I know it is not a tuple constraint.

> 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?

> If Dataphor silently ignores shorthand constraints with relational
> assignment, then the implementation is deficient.

Transition constraints aren't shorthand in Dataphor; they don't have relvar-level TCs. Whether or not the implementation is deficient is a matter of viewpoint; if they define relational assignment as delete followed by insert, they honour the TCs just fine. Just not as the user might expect... so I am inclined to say that using relational assignment in Dataphor is not very practical, and their TCs a bit of a hack. They're still useful, though.

> Alternatively, one
> can treat update constraints as matching old/new rows by some hidden
> row_id rather than by the primary key,

There are no primary keys in Dataphor.

> but such treatment is also no
> good since hidden row_id's is not part of the relational model.

Agreed.

> Is it the case that the Dataphor relational assignment does not honor
> any constraints ?

Of course not. It's just TCs that are an issue, and the way they do it does make sense.

> If so, how can one seriously consider using the
> assignment?

I just use it to fill empty tables in a somewhat novel way. It isn't really needed for anything.

-- 
Jon
Received on Fri Sep 01 2006 - 09:23:14 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US