Re: Possible problems with Date & McGoveran View Updating
Date: Fri, 12 Sep 2003 19:32:59 GMT
Message-ID: <Lbp8b.16976$3F1.656455_at_phobos.telenet-ops.be>
Costin Cozianu wrote:
> Jan Hidders wrote:
>>
>> 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.
>
> I don't think "smallest" is good enough , it has to be unique.
My mistake. When I wrote "a unique smallest set" I meant "a unique minimal set" where "miminal" means, as usual, that there is not a proper subset that also satisfies the requirements.
> 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).
No, in general that is not true, i.e., there can more than one such minimal set. For example if the view is defined as a union of two relations.
> 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.
Actually, no, I don't believe it does break the CWA. The CWA says that all the facts that you told to the database are presumed by it to be true and all other facts that are not implied by these facts are presumed to be false. This means that facts that the database can derive with the help of constraints or view definitions (conceptually a view definition is not really different from a constraint) are also considered by it to be true, and facts that it cannot derive are considered to be false. That's exactly why you add the (unique) minimal extra set of facts; these are precisely the facts that logically follow from the constraints and the update that was made.
- Jan Hidders