Re: Lucid statement of the MV vs RM position?

David Cressey wrote:
> At first you said that SUMMARIZE is not an aggregate operator. Then you say
> it produces a relation. Did you not intend to imply that the fact that it
> produces a relation was relevant to its not being an aggregate operator?

No, just that it was relevant to its not being the aggregate operator SUM. I'm trying to draw an analogy: If you call the "operator"

SUMMARIZE R BY { X } ADD (UNION(RELATION{TUPLE{Y Z}}) AS W an aggregate operator---call it GROUP---then you must for consistency also call the "operator"

SUMMARIZE R BY { X } ADD (SUM(Y) AS Z) an aggregate operator---and it seems you must also call it SUM (what else?). Which for one thing is a significant departure from Bob's own definition of an aggregate operator, because there is a *lot* more than iterated addition going on in the above expression. It also begs the question what manner of beast the "SUM(Y)" expression that's part of it denotes---is that *also* the aggregate operator SUM?

To return to you question, the definition of the aggregate operator SUM implies that it results in a number. Thus, the SUMMARIZE expression above that uses SUM cannot be the aggregate operator SUM, because (among other reasons) it results in a relation.*

Thus, the only recourse left if you don't accept my claim that GROUP (and by extension, SUMMARIZE...SUM) isn't an aggregate operator, is to use the term "aggregate operator" for *both* an iterated operation (as in Bob's definition) *and* the use an iterated operation (but presumably just one at a time!) as a term in a SUMMARIZE expression. And I don't understand why anyone would want to do this.

-- 
Jon

*On the other hand, the aggregate operator UNION, defined as iterated
union (of relations), is an aggregate operator that *does* result in a
relation, so that argument isn't as obvious for GROUP.