Re: Jan's well-defined view updates definition

Jan Hidders <jan.hidders_at_pandora.be> wrote in message news:<sLq9b.22177$my3.1385515_at_phobos.telenet-ops.be>...
> > You don't have any constraint on the base table. Therefore,
> >
> > deltaD = (
> > update Emps
> > set dept = 'marketing'
> > where dept = 'sales'
> > )
> >
> > is legal.
>
> Sure. But it's
>
> deltaV = (
> update TrEmps
> set dept = 'marketing'
> where dept = 'sales'
> )
>
> that is illegal, i.e., not well-defined. The view definition acts as a
> constraint here. There is not update that you can do on the base tables
> that would change the view in the way that is specified by deltaV.

I don't understand. deltaV is trivially illegal as written since it refers to nonexisting column dept.  

> > This update is "projected" into the view but the projection
> > looses some information. For example,
> >
> > deltaD = (
> > delete from Emps
> > where dept = 'sales'
> > )
> >
> > would be indistinguisheable from the above update. You suggest restoring
> > the lost information by accepting the second update as "natural"
> > translation of
> >
> > deltaV = (
> > delete from TrEmps
> > )
>
> Indeed. But actually I'm not transforming anything. All I do is look at the
> logical consequences of what the user has told the database. It is crucial
> that we regard the view as a set of facts and interpret updates as
> additions of deletions of facts to a certain predicate. Anything else would
> be heresy. :-)

But aren't you essentially mapping one set of views of the facts (being deltas or cumulative) into another set of views? User told database his vision in terms of views that he understands (in French;-) and we need to translate this into other set of views (in English). If some word have multiple meanings we have ambiguity, but typical solution in computer science is not to guess the best solution, right?  

> > My position is that we restore missing information by considering more
> > views. For example, suppose we have
> >
> > Q1 = (SELECT name
> > FROM Emps
> > WHERE dept = "sales"
> > )
> > Q2 = (SELECT name
> > FROM Emps
> > WHERE dept <> "sales"
> > )
> >
> > and
> >
> > deltaV1 = (
> > delete from TrEmps
> > )
> >
> > (It might be a good idea to switch notation here from TrEmps to V1)
> >
> > deltaV2 = no change
> >
> > Then
> >
> > Q * (delete from Emps where dept = "sales") =
> > = <deltaV1,deltaV2>
> >
> > (Here we have multiple relations on both sides of the equation, therefore
> > I swithed to notation that uses "vector" of deltas).
>
> and the fact that you like geometry has nothing to do with this? :-)
>
> > We see that Q is updateable for that particular combination of deltas, but
> > it wouldn't be updateable for
> >
> > deltaV1 = no change
> >
> > deltaV2 = (
> > delete from V2
> > )
>
> Why not?

Wrong example, sorry. Clearly any

deltaD = (

   update Emp aka D set
   set dept = 'engineering'
   where dept = 'marketing'
)

indistinguishable from

deltaD = no change

as reflected in the set of views V=<V1,V2>

We need one more equation/constraint

Q3 = (select dept from Emp aka D
where dept not in ('sales','marketing') ) = DUM  

> So if we make the view big enough then your definition allows the updates
> that my definition already allowed for the smaller view. Why does the view
> have to be so big? Why do you want to be so strict? What is the intuition
> behind your restriction besides that the math looks cute (which is IMO
> actually not unimportant)?

Simpler math is the only justification I ever accept:-) Received on Tue Sep 16 2003 - 05:44:29 CEST