Re: Guessing?
Date: Thu, 19 Jun 2008 19:20:46 GMT
Message-ID: <iky6k.38011$gc5.36565_at_pd7urf2no>
Bob Badour wrote:
> paul c wrote:
...
>> Bob Badour wrote: >> ... >>
...
>
> With POOD, any tuple satisfies the predicate of at most one relation in
> the dbms. Thus, with POOD, the dbms can calculate a unique relation to
> which to apply any insert, update or delete with the goal of avoiding
> anomalous behaviour.
>
> In the case of the union view from Codd's book, POOD requires the base
> relations to have disjoint predicates. ...
That is an attractively terse definition of POOD, not saying whether I understand it completely. Just to explore POOD a little bit and regarding view updating, suppose we have a db with just three relations or relvars if you like:
SSP(S#,SNAME,P#,QTY)
which is the join of
S(S#,SNAME) and
SP(S#,P#,QTY)
(I think these are more or less the relations CJ Date mentioned at
http://www.dbdebunk.com/page/page/1396086.htm )
It seems a trivial observation that the predicate for SSP, say "there exists a supplier S# with name SNAME who supplies part P# in quantity QTY" is satisfied by the tuple/proposition < S1, Smith, P1, 100>. Also (taking it literally) that this tuple doesn't satisfy any possible predicates for S nor for SP (because it doesn't have the same attributes).
It seems to me that a user who can access only SSP is most definitely asserting all three tuples when he inserts and is denying all three when he deletes. This may fly in the face of logic but the fact remains this particular db permits it.
OTOH, a second user who can access all three relations might object that the tuple < S1, Smith> can be true without the other tuples being true. Nevertheless, whoever designed this database has set the scene for such objections - let me assume for some unknown but necessary/intentional reason. If this second user is right, he knows something the first user doesn't know (but doesn't need to know in order to do his job).
In the above dbdebunk exchange, Date agrees with the poster that you can't infer NOT(PA) AND NOT(PB) from NOT (PA AND PB) on purely logical grounds then goes on to say why that might be less important than allowing deletes on both base relvars when a user deletes from SSP.
One might argue that if the access/security rules for such a db are such that NO user can access the base relations (which I think Codd had in mind for all base relations, excepting administrators who are to be considered as superhuman and whose activities are probably beyond the understanding of mortal users and certainly beyond that of executives) then the dbms would know for all time that no tuple could exist in S without having a 'corresponding' tuple in SSP, similarly for SP and SSP. I think I go along with this, in other words, in this situation we can infer NOT(PA) AND NOT (PB) from NOT(PA AND PB).
Maybe this is a case where non-logical considerations (physical ones?) trump logical ones. An argument against this might be that a dbms can't know whether the 'hidden' base relvars might someday be made available to users. But I'd say the dbms shouldn't act on information it doesn't know. Further, even if the db contains info to the effect that all three relvars are accessible by users, when a user deletes from SSP, there is nothing to consider but what satisfies the SSP user's request, assuming there are no explicit constraints to the contrary.
Come to think of it, I'm not sure the above has much to do with POOD, maybe it's more to do with the Principle of Interchangeability even though I find that one ironic - it seems quite arbitrary even though it forbids arbitrariness. Maybe somebody will also object that users should never see 'non-normalized' relations - I gather that Date doesn't consider SSP to be non-normalized but even if he's wrong, that wouldn't bother me (I imagine that it is possible with a graphical interface for a user to see a single relation which the interface has means to operate on as if it were two). Received on Thu Jun 19 2008 - 21:20:46 CEST