Re: more on delete from join

From: Nilone <>
Date: Thu, 27 Aug 2009 02:24:40 -0700 (PDT)
Message-ID: <>

On Aug 26, 5:16 pm, Kevin Kirkpatrick <> wrote:
> On Aug 25, 9:47 pm, paul c <> wrote:
> > Bob Badour wrote:
> > > paul c wrote:
> > >> Mr. Scott wrote:
> > ...
> > >>> I don't think this is right.  It assumes that a delete from J
> > >>> translates into a delete from both A and B, when a delete from either
> > >>> A or B would suffice.  ...
> > >> Yes, it does make that assumption, consequence of logical independence
> > >> I think.
> > > Preservation of symmetry as well. However, I see no theory to support
> > > either choice, which is why I prefer the pragmatism of allowing an
> > > expert user to specify how the delete should operate in this situation.
> > No argument that people who design the predicates in the first place
> > should be able to trump any dbms conventions they want to, although I
> > doubt if more than a few at most of today's dbms'es can express
> > constraints flexibly enough to always allow that.  Maybe I'm talking
> > about a convention rather than theory, but my basic point seems logical
> > to me and might go like this:  While a relation represents the extension
> > of a predicate, there is no way for a dbms designer (as opposed to a db
> > designer) to choose whether a particular relation value formed by <OR>
> > or UNION has a predicate that involves disjunction, at least in the
> > absence of explicit constraints to prevent or void results that are not
> > wanted.  Since all propositions represented by the tuples of a relation
> > (at least tuples in named relations) are taken to be true as far as that
> > relation is concerned (maybe false in the face of other relations, but
> > if false, they're not individually false, rather their logical
> > conjunction is false), the fact that a named relation might have been
> > formed by means of disjunction isn't of any consistent use to a
> > mechanical engine.  Most base relations are formed with disjunction and
> > I don't see why views should be treated differently.  In the absence of
> > contrary constraints, it seems most reasonable to me for a dbms, say
> > within the scope of a named view, to 'assume' identical predicates for
> > relations with equal headers.
> > My view of RT is extremely narrow, partly to avoid mysticism and partly
> > to see the minimum machinery a dbms really needs.  I think a relation's
> > 'definition' consists of nothing more than a header and constraints and
> > the constraints must all be expressible in the chosen algebra (this
> > doesn't mean I think the dbms needs to directly execute the algebra).
> By the narrowest interpretation of RT, shouldn't the whole "view
> update" problem just be tossed out once and for all?  Tuples in base
> relvars represent business meaningful propositions, and tuples in
> virtural relvars represent business meaningful conclusions drawn from
> base relvar propositions.    As such, view updates amount to letting
> end-users assert conclusions and having the DBMS make "educated
> guesses" at the appropriate modifications to business meaningful
> propositions such that those conclusions will be reached.  Seems
> inherently mystical to me.
> In short, before delving into, "*how* should the DBMS handle view
> updates?", I'd like to see a discussion about the question, "*should*
> the DBMS handle view updates?".

Let's clearly separate the relational model from the DBMS. The relational model requires no addition or modification to support updateable views, since a view is just another relvar. The problem is not in updating the view (which is considered transient by the DBMS), but in updating the persistent base relations accordingly. As such, it resembles constraint satisfaction problems, a completely different (but related) branch of logic.

Whether the DBMS should support updateable views depends on the implementer, I'd say, but it's certainly a powerful and useful feature that I want in any DBMS I use. Even though the derivation of a view is not always reversible, it is still useful when it is, and I can often design a view to be so.

My biggest frustration with views in existing products is not that some views aren't updateable, but that it is difficult to see whether a view is updateable or not, based on the syntax of query. Received on Thu Aug 27 2009 - 11:24:40 CEST

Original text of this message