Re: Relation Schemata vs. Relation Variables

"Jon Heggland" <jon.heggland_at_idi.ntnu.no> wrote in message news:ed9fsd$n9q$1_at_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?
>

I think that's my whole point. UPDATE cannot be a shorthand for relational assignment unless keys cannot change. If keys can change, then tuples from successive database states cannot be paired for comparison by joining R to R'. So we're stuck with either implementation-specific row-level transition constraints such as a FOR EACH ROW triggers or Dataphor's implementation, or introducing tuple identifiers or sets of object identifiers to guarantee that at least one key won't change. A better solution is needed. Instead of exposing only the proposed state, that is, R', the transition itself could also be exposed as a set of relations, Rd, Ru, Ri, representing respectively the tuples that will be removed, the tuples that will be different and how, and the tuples that are being added. For example, given the relation schema R {A, B, C}, a constraint could be defined declaratively not in terms of just R and R', but in terms of R and relations conforming to the following schemata:

Rd: {A, B, C}
Ru: {A, B, C, A', B', C'}
Ri: {A', B', C'}

For that matter, given an additional relation schema, S {A, D}, a constraint could be defined in terms of R, S, the above three relation schemata, and the following:

Sd: {A, D}
Su: {A, D, A', D'}
Si: {A', D'}

With this scheme, enforcible set-based transition constraints can be defined declaratively, involving multiple relation schemata, using standard operators from the algebra or the calculus, in the presence of volatile keys, without using object identifiers.

>> 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 Sat Sep 02 2006 - 07:42:40 CEST