Re: A different definition of MINUS, Part 3

On Dec 17, 8:12 pm, "Brian Selzer" <br..._at_selzer-software.com> wrote:
> Regardless of how many possible values there can be for a database, only one
> can actually be the value of the database at any set point in time.
> Algebraic expressions derive information from the actual value of the
> database; updates, on the other hand, assert which possible value for the
> database is also the actual value.  Common sense tells us to discard a
> result that is based upon a false premise, so it follows that the result of
> an algebraic expression that involves a possible value for the database that
> is not also the actual value is just as useless.  The algebra and the
> calculus are therefore limited in their utility to answering queries from
> the actual value of the database and have absolutely nothing to do with
> selecting which possible value is also the actual value.  In other words,
> neither the algebra nor the calculus are sufficient when it comes to
> database updates.  As a consequence, a 'purely algebraic' approach here is
> contraindicated.

Purely algebraic approach,,,, all the way to go. Consider a linear (or more general polynomial system), e.g.

x + y = t
x - y = s

It is a mapping of input set of variables (vector) into an output set. To extend the analogy to view updates, we also have an input delta vector mapped into the output delta. In this particular example, it is easy to establish that the view update problem (that is calculating input delta vector from output one) is well defined.

Contrast this to relational model where a view is a mapping from a set of base relations into some output relation variable. We have two differences
i. The algebra
ii. The number of equations, because a view is defined as a single equation

I never understood why view update problem is scoped to a single view. In a typical usage scenario -- database schema evolution -- a set of base tables is substituted with a set of views, and the user can see the whole update transaction as affecting multiple views. Therefore, it is not unreasonable to generalize view updates to a *system* of view equations. Why do we want to do that? Two reasons: 1. Database constraints are equations, and this generalization is a natural way to encompass them.
2. Information preservation. This one is easier to explain by the familiar linear system example. If there is not enough (linearly independent) equations, then there is a fundamental ambiguity of the inverse map that calculates input delta vector from the output. Received on Thu Dec 18 2008 - 22:17:30 CET