Re: Lucid statement of the MV vs RM position?

From: Jon Heggland <jon.heggland_at_idi.ntnu.no>
Date: Sat, 06 May 2006 17:07:28 +0200
Message-ID: <e3ie3f$dsh$1@orkan.itea.ntnu.no>

Bob Badour wrote:
> Jon Heggland wrote:

>> That said, I guess GROUP could also be defined as a SUMMARIZE with an
>> aggregate operator (or "summary"; TTM distinguishes between them) that
>> computes the RVA value based on a set of attributes. That aggop/summary
>> would be a bit non-standard, though, since it would need take a variable
>> number of arguments, not just one. That still wouldn't make GROUP an
>> aggregate operator, though.

>
> What would make it an aggregate? It has an identity element and one can
> define it as a repeated union operation. Of course, one must first
> perform a type conversion to change each tuple to a relation with
> cardinality 1 before one can perform the union operation.

Maybe I was unclear. TTM has such an aggregate operator; it is called UNION. You could define GROUP as SUMMARIZE ... ADD (UNION(...) AS RVA)---provided you have this mechanism for "converting" a set of attributes to a singleton relation---but GROUP is still not an aggregate operator. UNION is. In other words, UNION is to (eh...) UNION as SUM is to +.

> I don't see this as any different than performing a type conversion
> before performing the addition for SUM.

I think we are just quibbling over Tutorial D syntax, or over which operators should be defined in terms of which others. R GROUP ({X} AS Y) is a valid expression; R SUM (X AS Y) is not.
SUMMARIZE R BY { ALL BUT X } ADD (SUM(X) AS Y) is a valid expression; SUMMARIZE R BY { ALL BUT X } ADD (GROUP(X) AS Y) is not.

> Aggregate operations are defined using an identity element and a
> repeated operation or as an expression on other aggregate operations.

Thanks! Source?

-- 
Jon

Received on Sat May 06 2006 - 10:07:28 CDT