Re: On view updating
Date: Mon, 20 Sep 2004 05:57:46 GMT
Message-ID: <tju3d.73716$MQ5.3136_at_attbi_s52>
"Costin Cozianu" <c_cozianu_at_hotmail.com> wrote in message news:2r6lvdFl18ghU1_at_uni-berlin.de...
> 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.
I dunno. It seems to me that regardless of this distinction, updatable views are very useful.
[...]
> 3) That it is useful and even that it is palatable for the database
> designer to specify all static invariants in a database schema.
I'm curious as to the use of the word "static" here. (It may be that there is background to this comment that I'm not aware of.)
I would describe most of the invariants or constraints in a dbms
as non-static, in that they are not checkable ahead of time, or
at compile time, or statically, but maybe this is not what you
mean in this context by that term.
> Then there's the third point that the relational model is by design a
Less powerful, you say? Can you explain this? I spent the weekend reading
papers describing the relational algebra as being exactly as powerful as
the relational calculus which is in turn exactly as powerful as the
first order predicate logic. But you are saying "less powerful." Can you
help me resolve this paradox?
> Now by mandating the view update sucessful resolution, we want to
> 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.
> transform relational model into Prolog.
> We don't need that because if we want Prolog, we already have it.
I'm not sure whether we really want Prolog by itself, expect perhaps as an interesting example.
But mightn't we want a general purpose application language with relational features that was Turing complete? That would necessitate adding something beyond the basic relational model, and perhaps adding Prolog is just the ticket. Actually, I'd probably add a bunch more things as well.
Marshall Received on Mon Sep 20 2004 - 07:57:46 CEST