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

From: Bob Badour <bbadour_at_golden.net>
Date: Wed, 27 Aug 2003 23:20:28 -0400
Message-ID: <sGf3b.52$ja3.7766109_at_mantis.golden.net>


"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?"

Well, now, that's convenient. If you had concerns about computability theory, you could have simply mentioned those concerns and I could have cleared them up ages ago. Instead, you claimed the relational model lacks a formality and refused to accept the formal definition as contradiction of your claim.

> I
> asked Bob Badour and Lee Fesperman to show where that rule 6 of Codd is
> formally defined.

Actually, you said the relational model lacks formality, and I can take you back and show you exactly where you said it if you want to play "he said, she said".

The rule of thumb you refer to as rule 6 is a useful tool for comparing two dbmses. It is neither necessary nor desirable for it to have a formal definition.

> They seem to be ignorant of these problems.

I am certainly in no position to criticize you for ad hominem, and I won't. I resort to it myself. However, I generally make an honest effort to test the hypothesis before making a public declaration. By your apparent criteria, you seem ignorant of every topic you and I have never discussed; although, I fail to see the use of the observation.

> 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.

Hello! McFly! You don't seem to be listening. Lee and I have said on multiple occasions that Codd's 12 rules are simply rules of thumb and that they are specifically useful for comparing dbmses. Why would you think it impossible for one dbms to conform more to rule 6 than another dbms? One can devise a principle of halting detection and compare algorithms on their ability to detect halting algorithms even though the general problem is provably unsolvable. Duh!

> 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 - 05:20:28 CEST

Original text of this message