Re: Jan's well-defined view updates definition

"Jan Hidders" <jan.hidders_at_pandora.be> wrote in message news:d14ab.25480$rw3.1352807_at_phobos.telenet-ops.be...
> Mikito Harakiri wrote:
> >
> > We can't continue going round and round, so let's move on to the second
> > paragraph of your definition.
>
> Well, I would still be interested in your opinion on whether the
definition
> I gave makes sense or not, and what the intuition is behind the
definitions
> you gave. It's almost as if you are affraid of such discussions.

I thought that algebraic manipulations that I spiced all my previous messages with were convincing enough.

It is not if your definition makes sence or not, because given a set of equations that has multiple roots we can be very inventive defining the "best" or "most natural" solution. My point is that focusing on view transformations either with unique solutions or with ambiguities, we would still need a method of solving those equations.

As far as the best intentions to serve the user are concerned, that doesn't always work either. Semantic web, XML and other buzzword innovators claim solving very practical issues. But their theory is poor.

> > "Jan Hidders" <jan.hidders_at_pandora.be> wrote:
> >> Finally, we define a view V as *updatable* by a certain set of updates
U
> > if
> >> for all databases D that satisfy the schema all updates in U are
> >> well-defined. Additionally we say that V is *commutatively updatable*
by
> >> U if for all databases D that satisfy the schema it holds that if two
> >> series of updates from U have the same result when applied to Q(V) and
> >> perform only well-defined updates then they result in the same database
> >> when applied to D.
> >
> > Could you please provide a non-commutatively updatable example that we
can
> > discuss?
>
> Lets say I have base relations R(a,b) and S(b,c) with a foreign key R.b ->
> S.b and a view V that is defined by the natural join of R and S. The
> additions and deletions are both well-defined but if I add the tuple
> (a1,b1,c1) and then remove it then the end result is an additional tuple
> (b1,c1) in S, which is not the same as the end result of adding 0 tuples.
> So for the class of updates that consists of inserts and deletes it is not
> commutatively updatable.

Non commutativity is an obvious consequence of admitting approximate solutions.

Clearly,

approximate(roots(A) intersect roots(B)) != approximate( approximate(roots(A)) intersect approximate(roots(B)) ) Received on Thu Sep 18 2003 - 18:00:35 CEST