Re: A different definition of MINUS, Part 3


<vadimtro@xxxxxxxxx> wrote in message
news:d04ff8bf-8aa0-440a-b809-a186c2026f52@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Dec 17, 8:12 pm, "Brian Selzer" <br...@xxxxxxxxxxxxxxxxxxx> 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.

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.




.

Relevant Pages

  • Re: a union is always a join!
    ... algebra, while necessary for describing database updates, is not ... database, not two successive databases. ... is not presupposed by either the relational calculus or the relational ... updates and deletes are shortcuts for assignments ...
    (comp.databases.theory)
  • Re: A different definition of MINUS, Part 3
    ... can actually be the value of the database at any set point in time. ... updates, on the other hand, assert which possible value for the ... neither the algebra nor the calculus are sufficient when it comes to ... To extend the analogy to view updates, we also have an input delta ...
    (comp.databases.theory)
  • Re: too much OOP ?
    ... backing up 4GL is relational algebra. ... "relational people" did it in a 3GL with an elaborated types system then it ... Also don't forget that there is no market of languages. ... Or should they use some other kind of database? ...
    (comp.object)
  • Re: a union is always a join!
    ... algebra, while necessary for describing database updates, is not ... database, not two successive databases. ... is not presupposed by either the relational calculus or the relational ... Regarding transactions and concurrency control 'belonging' to implementations, it is more that most people are blinded by past practice, failing to see that Codd's 'keys' might offer a theoretical way to describe those aspects. ...
    (comp.databases.theory)
  • Re: A different definition of MINUS, Part 3
    ... Y', we would have a serious contradiction in the algebra, so R' IS ... Regardless of how many possible values there can be for a database, ... calculus are therefore limited in their utility to answering queries from ... recalculated once the assignment has been made. ...
    (comp.databases.theory)