# Re: A different definition of MINUS, Part 3

Date: Sat, 20 Dec 2008 06:09:23 -0500

Message-ID: <En43l.11250$be.5334_at_nlpi061.nbdc.sbc.com>

<vadimtro_at_gmail.com> wrote in message
news:d04ff8bf-8aa0-440a-b809-a186c2026f52_at_s1g2000prg.googlegroups.com...

> 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.
*

I think it is unreasonable. Take the case of a simple join view. If there are no other related views, then how can you create a *system* of view equations. Perhaps a clearer definition of the "problem" is in order: Given the result of an operation, find the operands.

So if the result of the binary operation '*' is 45, then what are the
operands?

1 and 45? 3 and 15? 9 and 5? Which?

So if the result of R JOIN S is {{A:3, B:6}, {A:3, B:7}}, then what are the operands?

{{A:3, B:6}, {A:3, B:7}, {A:4, B:7}} and {{A:3, B:6}, {A:3, B:7}}? {{A:3, B:6}, {A:3, B:7}} and {{A:3, B:6}, {A:3, B:7}, {A:4,B:6}}? {{A:3, B:6}, {A:3, B:7}} and {{A:3, B:6}, {A:3, B:7}}?Which?

The whole notion that there is some algebraic solution to the "problem" is ludicrous.

> Why do we want to do that? Two reasons:

*> 1. Database constraints are equations, and this generalization is a
**> natural way to encompass them.
*

as an equation using the algebra? Or for that matter, how would you express the functional dependency,

as an equation using the algebra?

> 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 Sat Dec 20 2008 - 12:09:23 CET