Re: Possible problems with Date & McGoveran View Updating

"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.

> >> By the way, what is exactly your definition of "updatable"? Should
there
> >> be
> >> at least one instance and one update such that the result is
> >> well-defined, or should for all instances all updates be definied, or
> >> something in between?
> >
> > I would rather start with "invertible"
> >
> > #1 Transformation Q is locally invertible for database instance X and
set
> > #of
> > views Y if there exists Q^(-1) such that:
> >
> > Q * X = Y <=> X = Y * Q^(-1)
>
> I assume you meant "Q * X = Y <=> X = Q^(-1) * Y" ?

Yes.

> That's a trivial property: every transformation is locally invertible in
> that sense. Note that because of the way you formulated it I only have to
> show that given an X an Y there is a Q^-1. An example would the function
> that maps every relation to X.

(select x as y from X where x > 0
union select 0 as y from X where where x <= 0) * X(x) = Y(y)

is locally invertible for any x > 0.

Perhaps, database variable is the source of confusion here. We have nested variable: outer var is the database instance, while the inner var is tuple. By X and Y in the definition #1 I should have meant tuples, not relations.

> > #2 Transformation Q is globally invertible if #1 holds for any X and Y.

>

Not true, see above. Received on Mon Sep 15 2003 - 21:31:25 CEST