Re: Possible problems with Date & McGoveran View Updating

From: Costin Cozianu <c_cozianu_at_hotmail.com>
Date: Thu, 11 Sep 2003 13:43:15 -0700
Message-ID: <bjqmkq$mburj$1_at_ID-152540.news.uni-berlin.de>


Jan Hidders wrote:
> Mikito Harakiri wrote:
>

>>>Definition #0:
>>>
>>>Given D and V such that
>>>
>>>Q( D ) = V
>>>
>>>and some deltaV, Q is called well-defined if there exists deltaD such
>>>that
>>>
>>>Q( D + deltaD ) = V + deltaV
>>>
>>>The alternative term I might prefer is "locally invertible".
>>
>>Sorry, I overlooked minimality here again. Time to think more...

>
>
> Ok. In the meantime let me try to give some intuition behind the definitions
> I gave. It's not really mine btw., just one I know from the literature and
> that is IMO the best semantical definition of updatable.
>
> If you update the view by giving some additional tuples then you are telling
> the database about a few new facts. Logically speaking a view is just
> another relation that happens to be fully determined by a database
> constraint in the form of an equation V = Q(D) with Q some query over the
> database D. So we can use this constraint (and other constraints that might
> hold) to derive other facts in other relations that then also must hold. If
> there is a unique smallest set of facts that we can add to make the
> database consistent again then it is clear that this set is both necessary
> in the sense that they logically follow from the update on the view and
> sufficient in the the sense that they are enough to make the database
> consistent. In other words, the database knows exactly what other facts
> should also be added to the instance.
>
> 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.
>
> -- Jan Hidders
>

I don't think "smallest" is good enough , it has to be unique.

Maybe you can derive that the existence of smallest implies uniqueness (The examples that I think of where there is no unique set also implies there is no smallest).

If we pick smallest (vs. unique), then we can have problems, i.e. users observe a derived fact, the database chooses the "smallest" update, however in reality a "larger" set of facts is true. Then we broke the close world assumption: the user might:

        select count(*) ...
and get the wrong results.

Best,
Costin Received on Thu Sep 11 2003 - 22:43:15 CEST

Original text of this message