Re: A different definition of MINUS, Part 3

<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}}?

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.

That's an interesting take. I'm assuming that these equations can be expressed in the algebra. Supposing that you have relation schemata R{A, B, C} and S{A, D}. How would you express an interrelational constraint, such as the inclusion dependency,

R[A] IN S[A]

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

AB --> C

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