Path: dp-news.maxwell.syr.edu!spool.maxwell.syr.edu!drn.maxwell.syr.edu!news.maxwell.syr.edu!wn14feed!worldnet.att.net!attbi_s52.POSTED!53ab2750!not-for-mail From: "Marshall Spight" Newsgroups: comp.databases.theory References: <2r6lvdFl18ghU1@uni-berlin.de> Subject: Re: On view updating Lines: 71 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Message-ID: NNTP-Posting-Host: 24.5.186.86 X-Complaints-To: abuse@comcast.net X-Trace: attbi_s52 1095659865 24.5.186.86 (Mon, 20 Sep 2004 05:57:45 GMT) NNTP-Posting-Date: Mon, 20 Sep 2004 05:57:45 GMT Organization: Comcast Online Date: Mon, 20 Sep 2004 05:57:46 GMT Xref: dp-news.maxwell.syr.edu comp.databases.theory:26055 "Costin Cozianu" wrote in message news:2r6lvdFl18ghU1@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. There was a time when I considered a database schema to be something unique, but now I see that it is just an interface; an API even. In that light, updatable views can be thought of as a declarative mapping from one interface to another. Given that much of modularity depends on interfaces changing rarely if at all, then the ability to define views declaratively gives one the ability to specify a per-application interface to an underlying interface that is then free (or anyway freer) to evolve according to changing business needs. [...] > 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 > 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. 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 > 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