Re: A different definition of MINUS, Part 3

"paul c" <toledobythesea_at_oohay.ac> wrote in message news:5h83l.48993$mY6.41775_at_newsfe10.iad...
> Cimode wrote:
> ...
>>> The whole notion that there is some algebraic solution to the "problem"
>>> is
>>> ludicrous.
>> paul c and Vadim never claimed that algebric expression of the problem
>> is the solution. They are only trying to rely on a formalism which
>> has proven to be effective.
>> ...
>
> Yes, nobody but Brian S has suggested that the A-algebra was put forth as
> providing a solution to a language implementation problem.

There you go again attributing references to language implementation to me when it was...wait for it...YOU that brought up the whole notion of implementation.

How is the fact that only one of the possible values for a database can actually be the value of the database at any given time and the fact that database updates--including view updates--simply assert which possible value is also the actual value a matter of language implementation? Do you really think that you can ignore the fundamental nature of the Relational Model by relegating my comments concerning your 'purely algebraic approach' to the bin as implementation issues? Bottom line: the algebra is not an essential part of the Model, nor is it even sufficent to describe the Model. It is certainly not sufficient to describe database updates, which involve more than one possible value for the database, since it cannot even operate beyond the scope of a single value for the database.

> My hope is to find a language definition (WITHOUT changing any existing
> A-algebra operators, just to remind, there are fundamentally only three of
> those, some of the ones typically used are merely derivations of those
> three, you can say there are four if TCLOSE is included), that allows a
> language implementation that is not only effective for some purpose, but
> closed for the desired expressions of that language. In other words, one
> of my guesses about the problem so far is that it is the language
> definition that is preventing closure of certain language artifacts. So
> far, I have no doubt that the A-algebra is closed, and determinate, where
> its own defined artifacts and the results of its operators are concerned.
>

Well, I have no doubt that my sledge hammer is hard and heavy, but I don't think it would be very effective for cutting paper :-)

At least one of the A-algebra operators is binary, and therefore some information, while not necessarily lost, is not accessible through any view whose definition invokes a binary operator. For example, without prior knowledge of their values it is unclear from which operand or operands the tuples in a relation derived from <OR> originate. In the same way it is unclear why some tuples do not appear in a relation derived from <AND>--do they not appear because they don't appear in the first operand or the second or both? More obvious is that each tuple in the result of a projection only indicates that at least one tuple appears in the original relation that has the same values. You have to look at the original relation to find out how many. What you should take away from this is that the fact that the A-algebra is closed and determinate only guarantees that an algebraic expression that involves a given set of operand values always yields the same result; it does not guarantee the reverse--that is, that an algebraic expression that yields a given result always involves a particular set of operand values.

> For example, if the language has a concept of 'relvar', I want to be able
> to substitute not the concept, but merely the name of the relvar in an
> algebraic equation (in order to compare language results to algebraic
> results). While the name of the relvar no doubt has other significance in
> a language implementation, its only significance in an algebra is to be a
> shorthand for some extension. This is the algebraic advantage - such
> language significance is stripped out of the language expressions, leaving
> only algebraic formulas and equations, removing the otherwise problem of
> having to make algebraic comparison of results and to deal with some
> extraneous language 'meaning' at the same time. If the concept of relvar
> in some language doesn't allow a one-for-one mapping of certain extensions
> to relvars, then I want to change the language, not the algebra. Within
> the algebra, asking what relvar values does a relation name signify is
> like asking what colour a relation is. The algebra's results reduce to
> extension values which the language definition must then map to its own
> concepts, relvars with fixed headings, for one example. Same goes for any
> talk of the Assignment Principle within the A-algebra - search the formal
> definition at http://www.dcs.warwick.ac.uk/~hugh/TTM/APPXA.pdf}
> and you will see that there is no mention of 'assignment' or 'principle.
>
> As best as I can understand him, McGoveran wants to prohibit certain
> relvar values. While I don't argue that this will solve the language
> problem of 'view updating', it prevents a convenience in a dbms that I've
> often use, eg., copying a table to one with a different name that I can
> use for testing without a lot of tedious renaming (I suspect there are
> many other such conveniences that people find 'ergonomic'). I'll grant
> that there are other language or environmental devices that give me the
> same ability and I'll admit that some expert language designers might say
> that such devices ought, on principle, to involve orthogonal concepts, but
> I'd just as soon not have to learn such concepts if re-defining the
> implementation language more precisely will do instead.
Received on Tue Dec 23 2008 - 06:50:15 CET