Re: On view updating

From: Alfredo Novoa <alfredo_at_ncs.es>
Date: 20 Sep 2004 16:15:45 -0700
Message-ID: <e4330f45.0409201515.58140a0e_at_posting.google.com>


"Tony Andrews" <andrewst_at_onetel.com> wrote in message news:<1095685404.749627.19430_at_h37g2000oda.googlegroups.com>...

> Agreed. I don't like a lot of the view updating rules laid out in the
> latest Intro to DB Systems, and nor apparently does C J Date any more.
> I'm intrigued that David McGoveran still considers it a "solved
> problem".

Perhaps because he has fixed the rules.

> I suppose it depends on what you mean by solved. We seem to
> have started from "All views are updatable; SQL vendors should do
> better" via "all views are updateable - subject to certain constraints"
> to "all views are updatable - subject to certain constraints AND the
> Assignment Principle". This is all very well, but it seems to me we
> are effectively back to square one: "some views are updateable; some
> are not".

All views are updateable, but some views are updateable never :D

But most views are updateable.

For instance.

var r relation { n char, a integer } key { n }; var v view summarize r per r{n} add Sum(a) as s;

The view "v" is clearly updateable (and I am not crazy).

The extreme case of Hegner's slides in which "no view updates posible under any reasonable translation strategy" is updateable in several ways.

An example of an "updateable never" view could be:

var r relation { a integer } key { a };
constraint stupid IsEmpty(r);
var v view r;

> Some clear problems with updating views:
> 1) the transformation made by a view is often one way: you can't be
> sure what is in the base tables to achieve the result you see from the
> view.

With a good database design this is not a problem.

> 2) views, unlike base tables, are often not even in 2NF - hence
> updating views could lead to "update anomalies": if you delete the last
> v_employee then you also delete his department.

This is an specifical problem of a rule that does not follow the logical inference: not (P(A) or P(B)) => not P(A) and not P(B).

That stuff happens when do you use the logic without logic, like a direct application of Set Theory and Predicate Logic, blah, blah, blah, that uses strange (but symmetrical) ad hoc rules instead of making logical inferences.

Frankly, I am rather surprised about this.

> My feeling is that views are NOT equivalent to base tables in all
> cases

Feelings are not enough. In which cases views are not equivalent to base tables?

Regards Received on Tue Sep 21 2004 - 01:15:45 CEST

Original text of this message