Re: The Practical Benefits of the Relational Model

"Mikito Harakiri" <mikharakiri_at_yahoo.com> skrev i en meddelelse news:bdf69bdf.0209281038.61057969_at_posting.google.com...
> "Peter Koch Larsen" <pkl_at_mailme.dk> wrote in message
news:<3d95577e$0$70305$edfadb0f_at_dspool01.news.tele.dk>...

> > > 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...
>
> To say it politely, finite precision float values (IEEE format or
> other) are "mathematically challenged". Yes one can do simple
> ariphmetics with them, but not real math. IEEE should put disclaimer
> on them: "This product is dangerous for a consumer, and can't be used
> for anything more serious than rendering 3D graphics". In databases,
> we can't even enforce constraints on real domains, let alone pretend
> equation solving. Therefore let just drop "real values" from any
> theoretical consideration altogether.

Ahh..... 3D graphics? I believe there are a few more areas, where they are used. But they do give lots of problems.
>
> > >
> > > 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
>
> The real issue here is that the mapping is not one-to-one. If we
> insert (x=0,y=1) point, then what angle it would be? Pi/2 or -3*Pi/2?

Or infinitely many other values, but that could be solved by a constraint.

>
> > select uppercase(name) from person?
>
> If there is uppercase(name)=name constraint on the name domain, then
> your view is clearly updateable. If there is lowecase(name)=name on
> the name domain, then it is still updateable. If there is no
> constraint on the name domain, then your view is not one-2-one, so
> that we have to add one more pseudocolumn to make it updateable:
>
> select uppercase(name), isuppercase(name) from person
>
> where isuppercase(name) maps each character of the "name" string into
> 0 or 1, depending if the ccharacter is upper or lower case.

Actually, it was just a not one-2-one query I was trying to give. If you insert e.g. "LARSEN" into the view, there would be 64 names that could be inserted into the basetable(assuming no constraints on that column). If you (or others) have references to papers describing view-updateability, I would be happy if references were provided.

Kind regards
Peter Received on Sat Sep 28 2002 - 22:11:53 CEST