Re: Possible problems with Date & McGoveran View Updating

"Jan Hidders" <jan.hidders_at_pandora.be> wrote in message news:jWo9b.22053$NH3.1410149_at_phobos.telenet-ops.be...
> Mikito Harakiri wrote:
> > "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.
> >

This would fail also if the employee only had visibility to marketing information. The view would have to be qualified as dept='SALES' OR dept='MARKETING' for a view update to be acceptable based on the constant complement approach.

> > We fundamentally disagree here. It would be helpful if somebody else
> > comment here.

>

You would, in effect, be modifying the constant complement view, which should be invariant through the update process.

• Dan

> I'm afraid they won't. Is it that hard to explain what is wrong with my
> argument?

> -- Jan Hidders

> Received on Thu Oct 02 2003 - 02:57:18 CEST