Re: I am looking for references on updatable views

From: Mikito Harakiri <mikharakiri_nospaum_at_yahoo.com>
Date: 8 Oct 2005 09:35:00 -0700
Message-ID: <1128789299.963841.243480_at_o13g2000cwo.googlegroups.com>


Marshall Spight wrote:
> Mikito Harakiri wrote:
> > "Show me your view update strategy, and I'll prove it failing on my
> > example"
> >
> > The example I have in mind is very simple. Consider
> >
> > rename( X(t,v), v->w ) = Y(t,w)
> >
> > If we update the view Y, what modification to the relation X data
> > should be? This might seem absurdly naive example, since the view
> > equation solves in a moment
> >
> > X(t,v) = rename( Y(t,w), w->v )
> >
> > Not so fast, however. Let <v=w> be (an infinite) binary relation
> > {(v,w) | v=w}. Then, the first view equation can be written as
> >
> > project_t_w(X(t,v) join <v=w>) = Y(t,w)
> >
> > Y is still a perfectly updateable view, but suddenly, the method of
> > solving this equation becomes not obvious.
>
> Interesting.
>
> I like to think of joins with infinite relations as rather being
> joins with intentional relations, aka functions. That is, rather
> than joining with {(v,w) | v=w}, we instead join with
> func(v -> w) { w = v; }
>
> In such cases, being able to apply the reverse of the join requires
> being able to invert the function. Since assignment is invertible,
> this would seem to work okay.

This looks OK, on informal level, although you ignored projection. A convincing argument would be formally transforming one equation into the other. Admittedly, I don't know how to do that. Received on Sat Oct 08 2005 - 18:35:00 CEST

Original text of this message