Re: View updates (was "is something a RDBMS")

"Mikito Harakiri" <mikharakiri_at_ywho.com> wrote in message news:ty63b.21$84.154_at_news.oracle.com...
> That depends how agressive the goal is. A common and less ambitious
approach
> is allowing programmer to code "on update" trigger. Sometime ago Vadim
> Tropashko posted an article where he demonstrated that one can write such
a
> trigger mechanically if one knows the inverse view. From relational
> perspective substituting procedural code into declarative inverse view is
a
> big deal. This is why I freely manipulate the term "inverse view" in the
> context of view update threads.
>
> And I was wrong when commented out that inverse view = complement view
from
> Banchilhon&Spyratos paper. Complement view serves the purpose making view
> operator invertible, but offers no help calculating inverse view.
>
> In short, it is a grey area if RDBMS supports "on update" trigger whether
it
> conforms rule #6 or not.

I don't think it is a grey area at all. You are taking a rule of thumb that is useful for comparing two things as if it has an absolute meaning when examining one thing. It has an absolute meaning only when describing an absolute lack.

Obviously, the ideal situation is one where the dbms combines the expression defining a view and the expression for a given assignment statement to automatically determine what steps to take to perform the assignment. As you mention, automatically deriving the procedure is provably hard in the general case; however, this does not prevent the dbms from automating the derivation for large classes of important special cases. Even still, a data modeller may confront a situation where no design allows the dbms to fully derive all assignments without expert intervention.

The question then becomes what interventions best allow the dbms to fulfill view update requests. Obviously, as well as minimizing the requirement for expert interventions, we want to hide expert interventions from casual users. Even though one might argue we are overcoming a limitation at the log ical level of discourse (especially when dealing with ambiguities), one might also argue we are overcoming a performance issue (decidability or NP-complete or whatever). To keep the conceptual model simple, I suggest we consider these expert interventions as interventions at the physical level of discourse. Because casual users do not see anything at the physical level of discourse, casual users will then not see the interventions. At the physical level, of course, the allowable interventions are wide open.

Declarative interventions or pragmatic hints obviously rank above procedural interventions, but if no other option remains, a procedural intervention will do.

Of course, most vendors will provide only procedural interventions and push as much effort as possible onto users--in this case DBAs. I do not see that as acceptable conformance; although, it is better than an absolute lack of view updatability.

> "Heikki Tuuri" <Heikki.Tuuri_at_innodb.com> wrote in message
> news:fQ53b.680$n62.269_at_read3.inet.fi...
> > Mikito,
> >
> > good that you bring up the problems in determining the updateability of
a
> > view. That is exactly why in the thread "does a table always need a PK?"
I
> > asked Bob Badour and Lee Fesperman to show where that rule 6 of Codd is
> > formally defined. They seem to be ignorant of these problems.
> >
> > We can guess that generally determining if a view is updateable is an
> > undecidable problem. That would make it impossible ever to make a
database
> > which satisfies Codd's rule 6.
> >
> > Best regards,
> >
> > Heikki
> >
> > "Mikito Harakiri" <mikharakiri_at_ywho.com> kirjoitti viestissä
> > news:Wv53b.19$84.119_at_news.oracle.com...
> > > "Mikito Harakiri" <mikharakiri_at_ywho.com> wrote in message
> > > news:dZ43b.18$84.104_at_news.oracle.com...
> > > >
> > > > D&D ad-hock updateability rules.
> > >
> > > Let's clarify why I call those "ad-hock".
> > >
> > > Given a view A transforming set of relational vars x into another set
of
> > > relational vars y, we can write it like this:
> > >
> > > Ax=y
> > >
> > > Solving view updates involves finding another view A^(-1) ("inverting"
> > > operator A) so that
> > >
> > > x=A^(-1) y
> > >
> > > This notation is perfectly justified when we write classic linear
> algebra
> > > example problem in terms of relations
> > >
> > > select x1+x2 as y1, 2*x1+3*x2 as y2 from X
> > >
> > > You may notice that vector (x1,x2) is relational var x, and (y1,y2) is
> > > relational var y, while matrix [[1,1],[2,3]] is operator A in terms of
> > > notation introduced earlier.
> > >
> > > Linear Algebra has a method of inverting the above view to
> > >
> > > select 3*y1-y2 as x1, -2*y1+1 as x2 from Y
> > >
> > > It is this math method that I'm contrasting to D&D ad-hock approach.
> > >
> > > Of course, I don't have a slightest idea what the method is when we
> write
> > > equations involving relational operators. The major problem is that in
> > math
> > > we can freely apply laws to transform expressions like this
> > >
> > > u+v=w
> > >
> > > into
> > >
> > > u=w-v
> > >
> > > while we have major difficulties manipulating relational expressions.
> For
> > > example,
> > >
> > > u union v = w
> > >
> > > and we don't seem be able to apply any tranformation to it which would
> > move
> > > v to the other side of the equation.
> > >
> > > In short, given the context of the problem above it seems unlikely
that
> > > solving equations in the relational algebra would be reduced to
applying
> a
> > > set of simple rules soon.
> > >
> > >
> > >
> >
> >
>
>
Received on Thu Aug 28 2003 - 04:47:33 CEST