Re: Lucid statement of the MV vs RM position?

From: Jon Heggland <jon.heggland_at_idi.ntnu.no>
Date: Wed, 10 May 2006 10:11:24 +0200
Message-ID: <e3s7bh$vp6$1_at_orkan.itea.ntnu.no>


Bob Badour wrote:
> Jon Heggland wrote:

>> I don't dispute that; please pay attention. I'm saying that SUMMARIZE is
>> not an aggregate operator; in particular, it is not SUM.

>
> That's right. It is just a lexical token in the grammar. The token forms
> part of a phrase that specifies a projection extended with aggregated
> operations like addition, union or variance. When applied to an empty
> relation, the operation specified by the phrase will yield another empty
> relation of a different type.
>
> One can have other phrases that specify aggregate operations. For
> instance, one can use SUM token or other aggregate operators without the
> SUMMARIZE token. When applied to an empty relation, these aggregate
> operations will yield the identity element for the base operation.

Your point being..?

> Tutorial D also has a phrase involving the token GROUP. The phrase
> specifies a combined type conversion and aggregate operation using UNION.

No. Reusing your words, it specifies /a projection extended with/ a combined type conversion and aggregate operation using UNION.

> Your whole position seems predicated on GROUP and SUMMARIZE and SUM as
> tokens in the grammar. As tokens, they are merely symbols with no
> inherent meaning.
>
> You, yourself, admitted one can define the operation specified by the
> GROUP phrase as a type conversion and an aggregate using repeated UNION.

Wrong. I said you can define it as a SUMMARIZE using (the aggregate operator called) UNION---in other words, "a projection extended with a combined type conversion and aggregate operation using UNION." I obviously consider the "a projection extended with" bit important.

You defined "aggregate operator" as
1. operation and identity, e.g. SUM: (+,0) 2. expression of other aggregate operators, e.g. AVG: SUM / COUNT

The "operation specified by the GROUP phrase [in Tutorial D]" is neither of the above. As I understand you, you want to extend the definition to include

3. a projection extended with an(/one and only one?) aggregate operator

(though more precision is needed, of course). If this is right, we have little more to discuss---though I question the wisdom in extending the definition in this way.

>> SUMMARIZE
>> produces a relation; SUM produces a number. Is your point that you
>> actually want to use the same name for these two operations? Why?

>
> Don't be absurd.

"The same name" here being "aggregate operator", then. One last time: given a relation R { X, Y }, the (possible) longhand

(1) SUMMARIZE R BY {X} ADD (UNION(RELATION{TUPLE{Y Y}}) AS AGG_Y for

(2) R GROUP ({Y} AS RVA) is obviously isomorph to

(3) SUMMARIZE R BY {X} ADD (SUM(Y) AS AGG_Y) Thus, if GROUP (2) is an aggregate operator, (1) must be as well---and hence for consistency, (3) too. Where does the absurdity occur, in your opinion?

>> All your arguments are just "Yes, it is!".

>
> You have already admitted that it is when you admitted one can define
> GROUP as a type conversion and iterated UNION.

I'll repeat: I didn't. Please don't misrepresent me like that.

> Why you continue to argue
> that it is something else is beyond me. However else one might define
> the operation, it must still operate according to the aggregate function
> definition.

But GROUP doesn't, because your definition does not mention projection and extension. Thus, either you need to extend your definition; or, you have to define GROUP differently from D&D (which makes this discussion even more pointless than it already is); or, you have to accept that GROUP is not an aggregate operator.

> The operation specified by the phrase using the GROUP token in the
> Tutorial D grammar is an aggregate function. It is in fact a shorthand
> for a combined type conversion and union aggregate.

Are we referring to the same Tutorial D? I'm talking about the one in "Databases, Types and The Relational Model" (TTM 3rd ed.)

> 1. You don't object to the grammar.

Correct. (That is, I find Tutorial D a bit messy and long-winded, but my point in this thread is not to criticise it.)

> 2. But your whole argument is predicated on the grammar itself and
> specific tokens in isolation.

Incorrect. The grammar and tokens have little to do with it, but are needed to be able to talk about things. My argument is based on what operators *do*, not what they are named.

> 3. You admitted one can define the operation specified by the GROUP
> phrase as a type conversion and aggregate union.

Incorrect, as already stated twice.

> I am concluding that your whole argument is pointless.

You conclusion is based on false premises. My one and only point was to respond to Marshall's "Isn't GROUP an aggregate operator?" with "No (at least, not in the same sense as SUM is)." Since you piped up to support Marshall, and he and I now agree (apparently because of something *you* said(!)), I am left wondering what *your* point is.

-- 
Jon
Received on Wed May 10 2006 - 10:11:24 CEST

Original text of this message