Re: Guessing?

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