Guessing?

Thanks to Brian S for reminding about Codd's book. On the question of view updateability, I'm interested in comments about this quote from page 294:


Now for a second example, this one involving union and a view based
on two relations, not just one as in the first example. Suppose that two of
the base relations in the database are SE and SW, where SE provides the
identification and immediate properties of suppliers east of the Mississippi
River, while SW provides similar information about suppliers west of the
Mississippi. Suppose also that SE and SW are union-compatible and that
neither SE nor SW contains a column that indicates directly by its values
whether the supplier is east or west of the Mississippi.

Base: SE ( S# SNAME CITY STATE... )
SBase: W ( S# SNAME CITY STATE... )

Now, suppose that a view S is created as the union of SE and SW.
Suppose also that a user is authorized to enter a new row into the view S.
Such a request must be reflected in some change applied to the base relations,
which are the only relations that reflect the true state of the database. How
does the DBMS decide which of the two base relations SE and SW is to be
the recipient of this row? Even if two of the immediate properties of suppliers
recorded in SE and SW are the city and state in which each supplier is
located, it is not appropriate to assume that the DBMS or the database has
any knowledge about geography, and in particular about which cities and
states are on which side of the river.
>
It is worth noting that, in this second example, the view S is actually
the disjoint union of SE and SW, a reasonably simple case; still, however,
entry of new rows into the view is not admissible. Nevertheless, whatever
it does, the DBMS would be guessing the user's or program's intent, and
such behavior is unacceptable in managing a shared database.


I'm fastening particularly on where he says it is unacceptable for the DBMS to "guess" at intent. I'm inclined to call his attitude mystical. If the DBMS is ordered to insert the tuple and no information it has been given, such as constraints, countermands that, and it has a consistent method for doing so, why the dickens shouldn't it?


It is just as much a guess for the DBMS to give the impression that the request/order is ambiguous (a word Codd uses earlier on). In this case, it just doesn't know, ie., hasn't been told and should keep its figurative mouth shut!


(My attitude about such inserts is for the DBMS to use its UNION feature to all base relations in the definition, then apply any defined constraints to the results. In the purest implementation some results might be seen by programmers as inconvenient, for example where a primary key was involved and the request implied a contradiction, the result might be an empty relation, so an implementation might support the raising of exceptions for convenience, but this is outside the RDM's scope.)


Rather than guessing, I think he is really talking about the Information Principle, which is an idea that concerns designers, not DBMS implementations.
.