Re: Relation Schemata vs. Relation Variables

Jon Heggland wrote:
[...]
> >> and aren't enforced usefully
> >> when using relvar assignment (as opposed to insert/update/delete).
> >
> > I am not intimately familiar with Dataphor, but my impression was that
> > they did not implement relational assignment at all, just the
> > 'shorthand' delete/upadate/insert operators. Is that so ?
>
> No, they have relational assignment; implemented as delete-insert, as
> far as I can tell.

I did not see any examples of Dataphor relational assignment in the online manuals they have on their website. Could you provide a reference ? 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.

>Which means that their transition constraints can be
> circumvented, if they're not carefully written.
>
> > In any
> > case, they did what they could by implementing row-level declarative
> > transition constraints 'set-theoretically', something the OP was
> > wondering about.
>
> Then I probably misunderstand what you and Marshall mean by
> 'set-theoretically'. 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 ?

> TTM-style transition constraints, based on comparing
> (pairs of) relations, not tuples, avoid those problems.

For example (Dataphor vs. TTM) ?

> 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" ? At the logical level, there is no 'at a time' in either case, at the implementation level there may be (in both cases), but not otherwise.

> --
> Jon
Received on Thu Aug 31 2006 - 18:49:58 CEST