Possible problems with Date & McGoveran View Updating

#71

Mikito Harakiri wrote:

Quote:

The problem of inverting views and solving transformation equations seems to
be more general than just view updates. For example, given

Q * D = V

one can be asked to find base relations D that look like V after being
transfomed by Q. Here V is not a single view, but a set of views, of course.
Once again, the way we treat view updates is highly unsymmetrical: we
consider a single view, but many base relations.

That's not a problem, just let both be database instances defines as,
for example, functions that map relation names to a relation.

Quote:

Adding symmetry and generalizing the problem is a typical
mathematical approach. (Unlike computer science that jumps to
definitions without trying to understand the problem;-)

As a typical mathematician, you are overgeneralising here. :-P

Quote:

There seems to be a way to consolidate our positions, though.

Consolidate or reconcile? Actually I think you misunderstand what we
disagree about. I never claimed that my definition is *the* definition.
At most I would claim that it is probably the most liberal one that
still has a firm logical basis, doesn't introduce ad-hoc rules and
therefore makes sense. But as I already said, other more restrictive
definitions can certainly be useful and it is very interesting to
compare them to see which restrictions are introduced and what the
benefits of these restrictions are.

Quote:

Given a
well-defined view update, if we can specify an additional view constraint
equation that gives the unique solution, we both would be happy, right? In
your Emp example there is such an equation (found by trial and error), but
what general case is like?

Anyway, could you please outline next step(s), assuming that we accepted
well-definess and commutativity?

Well, the point of the notion of commutatively updatable is that it
captures the intuition that the user can undo or repair his or her
mistakes by adding a few more updates. Sounds familiar doesn't it?
Sounds very much like the constant complement approach, which again is
very similar to what you are proposing (the non-updated part in the
extra views stays constant). Could they be one and the same?

-- Jan Hidders

#72

"Jan Hidders" <jan.hidders (AT) pandora (DOT) be> wrote

Quote:

Mikito Harakiri wrote:
"Jan Hidders" <jan.hidders (AT) pandora (DOT) be> wrote in message
news:s7n9b.21899$%C3.1400873 (AT) phobos (DOT) telenet-ops.be...
Mikito Harakiri wrote:
"Jan Hidders" <jan.hidders (AT) pandora (DOT) be> wrote in message
news:Ym%8b.20114$7y3.1376399 (AT) phobos (DOT) telenet-ops.be...
Mikito Harakiri wrote:
"Jan Hidders" <jan.hidders (AT) pandora (DOT) be> wrote in message
news:PX38b.14807$2Z.580673 (AT) phobos (DOT) 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.

Quote:

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

Quote:

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

Quote:

-- Jan Hidders

#73

D Guntermann wrote:

Quote:

"Jan Hidders" <jan.hidders (AT) pandora (DOT) be> wrote in message
news:jWo9b.22053$NH3.1410149 (AT) phobos (DOT) telenet-ops.be...

Mikito Harakiri wrote:

"Jan Hidders" <jan.hidders (AT) pandora (DOT) be> wrote in message
news:s7n9b.21899$%C3.1400873 (AT) phobos (DOT) telenet-ops.be...

Mikito Harakiri wrote:

"Jan Hidders" <jan.hidders (AT) pandora (DOT) be> wrote in message
news:Ym%8b.20114$7y3.1376399 (AT) phobos (DOT) telenet-ops.be...

Mikito Harakiri wrote:

"Jan Hidders" <jan.hidders (AT) pandora (DOT) be> wrote in message
news:PX38b.14807$2Z.580673 (AT) phobos (DOT) 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.

Yes, but I was not assuming the constant complement approach. In fact, I
was trying to find out if there exists some theoretical justification
for this approach. As a consequence I have to start without the assumption.

-- Jan Hidders

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Possible problems with Date & McGoveran View Updating

comp.databases.theory comp.databases.theory

Re: Jan's well-defined view updates definition - 09-19-2003 , 07:02 PM

Re: Possible problems with Date & McGoveran View Updating - 10-01-2003 , 07:57 PM

Re: Possible problems with Date & McGoveran View Updating - 10-03-2003 , 03:59 AM