Re: On view updating

I think they've got it wrong on several counts.

1. Is whether view updating is crucial to "logical data independence".

Very little have I seen in the way of defending this point. Since relvars are "variables" and the rest are computed values, and Date insists so much on the logical distinction between variabke and values, well we should apply a rather trivial distinction

that rvalues are not lvalues.

By insisting that views should be seen as updatable Date actually insists that in his model some values should be used as lvalue.

2) That the principle of orthogonal design has any pragmatic meaning, and should have a decissive contribution to shaping the relational model.

3) That it is useful and even that it is palatable for the database designer to specify all static invariants in a database schema.

Then there's the third point that the relational model is by design a model less powerful than first order logic in order to address the pragmatics of database implementation. It is a very desirable trade-off between expressivity and engineering properties of the software systems.

Now by mandating the view update sucessful resolution, we want to transform relational model into Prolog.
We don't need that because if we want Prolog, we already have it.

Best,
Costin

Alfredo Novoa wrote:
> What do you think about this?
>
> http://www.dbdebunk.com/page/page/1396086.htm
>
> I can't agree more with this:
>
> ---
> I therefore have come to believe that "view updateability" should be
> allowed to happen IF AND ONLY IF the system has PRECISELY ONE WAY to
> "resolve" the user's request.
> ---
>
> In my opinion any approach to the view updating problem that is not
> based in logical inference is an absurd.
>
> And a DBMS designed to make "inferences" like this:
>
> A or B => C
> C
> -----------
> A and B
>
> is something really awful and this is the behavior we can obtain from
> the application of Date & McGoveran's union update rules.
>
> A DBMS that does this is a DBMS that lies, and this is not a very nice
> property for a DBMS IMO.
>
> On the other hand, the rules are not able to infere updates so trivial
> like this:
>
> var r relation { a integer, b integer } key { a, b };
> var v view r where b = 1;
>
> insert into v relation { tuple { a 1 } };
>
> Any little child would infere that the base relvar update should be:
>
> insert into r relation { tuple { a 1, b 1 } };
>
> In the case of the join rules the problems are very numerous.
>
> I agree on that not everything must be based in logic, but view
> updating definitely must be.
>
> I sympathize a lot more with what McGoveran said like:
>
> ---
> 3. A DBMS that supports the relational model cannot be "magic." It
> cannot compensate for ambiguity, intuit withheld information or
> assumptions, or correct expressions that violate the designer's or
> user's intent. If the designer fails to capture information in
> database design, if information is hidden from the user, or if the
> user incompetently fails to express their intent [Ed. Note: Or if the
> data language is not sufficiently expressive], it will certainly
> produce seemingly anomalous or "surprising" results when faced with
> these problems.
> ---
>
> A DBMS must not make wrong inferences, and whether a correct inference
> leads to surprising or counter intuitive results, it is a database
> designer's fault and not a DBMS flaw.
>
>
> Regards
> Alfredo
Received on Mon Sep 20 2004 - 02:18:42 CEST