Re: Requirements for update languages?

hidders_at_hcoss.uia.ac.be (Jan Hidders) writes:

> In article <m2k7jo87eh.fsf_at_pcwi1068.uni-muenster.de>,
> Jens Lechtenbörger <lechtej_at_uni-muenster.de> wrote:
> >Dear reader,
>
> Hi, Jens! Nice to see you here. Sorry to hear your paper was rejected. That
> always hurts, even if the referees are so clearly wrong. ;-)
>
> >1. I believe that SQL data manipulations are not adequate for bags,
> > as they lack the ability to manipulate duplicates. (E.g., you
> > can neither delete 3 out of 5 duplicates nor insert 3 duplicates
> > at once.)
>
> Although in views bags can sometimes convey some meaningful information it
> is probably a better idea to stick to the relational model and let views
> also be sets. Especially if you want your view to be updatable because IMHO
> in principle an insert (delete) amounts to the user telling the database
> that a certain proposition is (not) true. As usual it doesn't make much
> sense to say that something is two times true.

As I said in my reply to Paul Vernon: I don't believe in bags, but SQL has bag semantics.

And I might buy two boxes of beer, which---you must agree---is better that just one.

> >2. As a db user, I expect that I can undo (inadvertent) data
> > manipulations, e.g., undo an insertion via a deletion or vice
> > versa.
> > Does anybody else believe that this is a reasonable requirement?
>
> Not always. I would consider it a consequence of the fact that you are
> looking at a view and not at the original base tables. Compare it for
> example to the case where you have two base tables R1(A,B,C) and R2(A,B)
> which are linked by the consraint that R2 = R1[A,B].

*grin* Such constraints do not exist.

You don't store the contents of R2 redundantly but define a view.

> If you tell the
> database that R2(a,b) no longer holds than it can infer that certain other
> tuples in R1 also no longer hold, and ultimately the database will be
> consistent again. But if you add the fact that R2(c,d) then the database is
> not consistent after you add all the derived consequences.

This is a very nice point. In fact, I thought about "on cascade delete" foreign keys. They might break my assumptions but for now I believe that you should not be allowed to delete from R2 if you are not allowed to delete from R1.

> >3. As a db admin, I expect that users know what they are doing when
> > they manipulate data.
> > Does anybody else believe that this is a reasonable requirement?
>
> Yes, but only in the sense that there should be a meaningful predicate that
> corresponds with the view. That means that in the case of the projection
> R1[A,B] the user of the view should know what a tupel in the projection
> means, i.e., be able to verify in the real world whether it actually holds
> or not.
>
> >It turns out that (2) and (3) above are equivalent.
>
> They are? How did you define (3) formally? (Yes, I know, it's in the paper.
> Sorry for being a bit lazy.)

Very short: They see all effects of their updates in the view. Slightly longer: Please see my answer to Mikito Harakiri.

BTW, congratulations to your ICDT paper,

Jens Received on Sat Nov 09 2002 - 23:47:56 CET