Re: The Practical Benefits of the Relational Model

From: Peter Koch Larsen <pkl_at_mailme.dk>
Date: Sat, 28 Sep 2002 09:17:15 +0200
Message-ID: <3d95577e$0$70305$edfadb0f_at_dspool01.news.tele.dk>


"Mikito Harakiri" <mikharakiri_at_yahoo.com> skrev i en meddelelse news:bdf69bdf.0209271521.7d87e40a_at_posting.google.com... > "Peter Koch Larsen" <pkl_at_mailme.dk> wrote in message news:<3d94aae2$0$18114$edfadb0f_at_dspool01.news.tele.dk>...
> > > > Another vague and very central subject is that of view
> > > > updateability: hardly discussed at all.
> > >
> > > View updatability is clearly spelled out by Date in several places.
> > > The most recent of these is the 7th edition of An Introduction to
> > > Database Systems. There, update rules are spelled out for each
> > > relational operator. The Dataphor DAE fully supports view
> > > updateability.
[snip]
>> The brief mention of the subject
> > in TTM claims that (with a back door wrt constraint violations (pg 151))
and
> > follows up with an example of an update of a union, where both
underlying
> > relations are updated. While this does work wrt the view, there is no
> > argumentation that this should be so - you could e.g. just update one of
the
> > relations. I am sceptical of such an approach, especially when the
choice
> > seems so arbitrary and justification is not present. Anyway it is a
> > disappointment on such a central point not to see references to books
that
> > are not by the present authors.

>
> I agree: those are just a set of ad-hock rules hardly illuminating
> anything about the problem. If we allow domain operators, however,
> (and D4 allows them, right?) then the problem becomes more
> challenging. Telling the rules for relational operators is not enough
> anymore, we have to be able to solve equations. For example, is a view
>
> select x+y, x-y from point
>
> updateable? If it is, then how about

This view looks updateable for a DBMS with a sufficienty strong inference mechanism, but there are are subtle reasons it might not be so. As an example imagine inserting a tuple { 100, - 100}. This would have the solution x = 0,y = 100, but if x and y are represented with limited precision (e.g. standard reals as represented in the most normal IEEE format), the solution x = 3.0 E-21 and y = 100 and a plethora of other would be an equally good solution. Which of the two tuples should be inserted? What happens if e.g. the value { x = 0.0, y = 100.0} is already present - should a nonpresent solution be inserted? Even if we disregard these points as nitty-gritty, your next example raises other points...

>
> select arccos(x/(x*x+y*y)), sqrt(x*x+y*y) from point
>
> ?

...namely that solving for x,y might result in a solution, where the inserted tuple because of the infinite precision might not even be present in the result set. Again disregarding this as nitty-gritty, what about a query such as

select uppercase(name) from person?

>
> Even if we don't allow domain operators, what can we infer about
>
> select id, 'VOICE' type, voice phone
>       from contact
>       union
> select id, 'FAX' type, fax phone
>       from contact
>
> ?

It was an example such as this that came to my mind while I read pg. 151 of TTM.

>
> Therefore, claim like "The Dataphor DAE fully supports view
> updateability" is just naive marketing.

I would say that a RDBMS that does not support view updateability in the above cases would be most satisfactory. My comments are not directed against the Dataphor product which I do not know.

Kind regards
Peter Koch Larsen Received on Sat Sep 28 2002 - 09:17:15 CEST

Original text of this message