Re: Possible problems with Date & McGoveran View Updating

From: Bob Badour <bbadour_at_golden.net>
Date: Tue, 16 Sep 2003 07:56:37 -0400
Message-ID: <06E9b.48$F03.3654798_at_mantis.golden.net>


"Mikito Harakiri" <mikharakiri_at_ywho.com> wrote in message news:PAo9b.25$lB2.165_at_news.oracle.com...
>
> "Jan Hidders" <jan.hidders_at_pandora.be> wrote in message
> news:s7n9b.21899$%C3.1400873_at_phobos.telenet-ops.be...
> > Mikito Harakiri wrote:
> > > "Jan Hidders" <jan.hidders_at_pandora.be> wrote in message
> > > news:Ym%8b.20114$7y3.1376399_at_phobos.telenet-ops.be...
> > >> Mikito Harakiri wrote:
> > >> > "Jan Hidders" <jan.hidders_at_pandora.be> wrote in message
> > >> > news:PX38b.14807$2Z.580673_at_phobos.telenet-ops.be...
> > >> >> A small example. Suppose we have a table Emps(name,dept) and a
view
> > >> >> TrEmps defined by
> > >> >>
> > >> >> SELECT name
> > >> >> FROM Emps
> > >> >> WHERE dept = "sales";
> > >> >>
> > >> >> then if you add a tuple to this view it is perfectly clear which
> tuple
> > >> >> should be added to Emps and so this is a well-defined update.
> > >> >
> > >> > This view is not updateable. If you delete a tuple from this view,
do
> > >> > you
> > >> > delete from the base table or update dept = 'sales' into some other
> > >> > value
> > >> > (which we can't deduce from TrEmps alone)?
> > >>
> > >> According to the definition I gave this deletion is well-defined. The
> > >> unique
> > >> "minimal" solution is that the corresponding tuple is deleted from
> Emps,
> > >> and indeed that is all that the database knows for certain: this
tuple
> > >> has to to be removed. I find this quite intuitive, can you explain
why
> > >> you don't?
> > >
> > > Because if you update base table
> > >
> > > update Emps
> > > set dept = 'marketing'
> > > where dept = 'sales'
> > >
> > > the observed effect on TrEmps is deletion of a tuple.
> >
> > No, this is an illegal update because you are trying to insert a tuple
> into
> > a relation that cannot have such a tuple. This makes sense because your
> > view is your ontology so the only thing that you can tell the database
is
> > that someone is no longer with sales. It's the user with the
> marketing-view
> > that should tell the database that this employee is now with marketing.
>
> We fundamentally disagree here. It would be helpful if somebody else
comment
> here.

I agree that the update would have the effect of making the tuple disappear from the view, but I wonder where the dbms gets the idea to use 'marketing' ?!? Why not 'engineering' ?

The update seems to play fast and loose with the closed world assumption, and I note that it changes the nature of the request from a delete to something else. While the effect has some utility for workflows etcetera, I think I would prefer a triggered procedure for those applications. Received on Tue Sep 16 2003 - 13:56:37 CEST

Original text of this message