Date: Wed, 28 May 2008 00:05:05 -0700 (PDT)
On May 27, 9:57 pm, paul c <toledoby..._at_ac.ooyah> wrote:
> David BL wrote:
> > It seems to me that every base relvar will in practice have some
> > defined intensional definition outside the RM formalism and
> > inaccessible to the DBMS.
> A practitioner who (knowingly) tolerates or suggests that is likely
> either a sucker or a charlatan. (Bob B called Codd's example a straw-man.)
> That would suggest that the DBMS should
> > only permit updates to derived relvars that map uniquely to associated
> > updates to the base relvars. Without any need to anthropomorphize the
> > DBMS, it is mathematically well defined whether there are alternative
> > base relvar updates that are consistent with the derived relvar
> > update. In such a case the DBMS should indicate an ambiguity error.
> > In the example from Codd, I think it is incompatible with the
> > Interchangeability Principle. The problem is that the database schema
> > doesn't allow for missing information about whether a given supplier
> > is east or west of the Mississippi. Since the DB cannot represent
> > that kind of partial information it cannot support updates from a view
> > (ie derived relvar) with the missing information. The problem is
> > analogous to attempting insertions to a derived relvar that has
> > projected away an attribute.
> Regarding the insertions to the projection, I vaguely remember a (thin)
> book by a Russian guy where IIRC he was suggesting that all tuple
> components should be set-valued. Lost the book and can't remember the
> name. Apologies for the mysticism, I'm imagining he might have been
> suggesting that empty sets could be used, ie., that non-specification of
> an attribute value would be interpreted as 'no value'. I guess this
> would require re-thinking of projection as a basic operator, otherwise
> some people would start thinking about NULL's again
Here's a variation of Codd's example that could support missing infomation...
Let the following intensional definitions of predicates s,se,sw,su be defined.
s(X) :- it is known that X is an supplier.
se(X) :- it is known that X is a supplier east of the Mississippi. sw(X) :- it is known that X is a supplier west of the Mississippi. su(X) :- s(X) and (not se(X)) and (not sw(X)).
se(X) => s(X) and
sw(X) => s(X)
It follows that
se(X) or sw(X) or su(X) <=> s(X)
Accordingly let se,sw,su be the base-relvars with mutual exclusion constraints, and let s be a derived relvar formally defined to the DBMS as follows
s(X) :- se(X) or sw(X) or su(X).
Now consider an insertion of new tuple x into derived relvar s. It seems we have missing information. The intensional definitions above have been worded so that the CWA applies and therefore it can be assumed that
not(se(x)) and not (sw(x))
So the appropriate response is to insert x into (and only into) su.
Presumably the DBA needs to be able to configure the DBMS to work this way. Received on Wed May 28 2008 - 09:05:05 CEST