Re: Requirements for update languages?

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.

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

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

>Basically, the anonymous referees did not buy (2) and (3).

That suprises me a little, because I'm not sure that this is really so relevant. I would say that sometimes you want a view that behaves as if it is the entire database. If you have a syntactic decidable characterization of when exactly that is possible then that is an interesting result.

• Jan Hidders