Re: The Practical Benefits of the Relational Model
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