Re: Guessing?

On May 27, 9:57 pm, paul c <toledoby...@xxxxxxxx> 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)).

We assume

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.

.

Relevant Pages

  • Re: Guessing?
    ... Such a request must be reflected in some change applied to the base relations, ... it is not appropriate to assume that the DBMS or the database has ... updates to the base relvars. ... base relvar updates that are consistent with the derived relvar ...
    (comp.databases.theory)
  • Re: Guessing?
    ... Consider the intensional definition: ... able to tell us how to apply updates over time. ... That would suggest that the DBMS should ... base relvar updates that are consistent with the derived relvar ...
    (comp.databases.theory)
  • Re: Guessing?
    ... That would suggest that the DBMS should ... updates to the base relvars. ... base relvar updates that are consistent with the derived relvar ... Regarding the insertions to the projection, I vaguely remember a book by a Russian guy where IIRC he was suggesting that all tuple components should be set-valued. ...
    (comp.databases.theory)