Re: Possible problems with Date & McGoveran View Updating

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.

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

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

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

That doesn't matter, the definition would still define a trivial property. As I already said, you can always take for Q^-1 the function that maps any relation (or any tuple, if you change the definition) to X.

• Jan Hidders