Date: Tue, 27 May 2008 13:57:59 GMT
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.
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. Received on Tue May 27 2008 - 15:57:59 CEST