Re: What is Aggregation? Re: grouping in tuple relational calculus

From: Mikito Harakiri <mikharakiri_at_iahu.com>
Date: Fri, 18 Feb 2005 14:54:24 -0800
Message-ID: <dzuRd.36$o%4.38_at_news.oracle.com>


"Jan Hidders" <jan.hidders_at_REMOVETHIS.pandora.be> wrote in message news:L2uRd.14949$TV7.1119364_at_phobos.telenet-ops.be...
> Hmmm, yes, but list aggregation is a bit cumbersome in the context of
> the relational model. There it is easy to identify a bag of domain
> values, just give me a relation and point to one of its columns. For
> lists you would probably also need to indicate how you would like to
> order the tuples in the relation, and that may not be obvious.
>
> On the other hand, if you have lists, why require associativity and not
> simply consider all functions over lists as aggregation functions?
>
> It's all a matter of definition, of course, and hence ultimately
> meaningless.

All of them -- sets, bags, and lists -- have their place in RM. The importance is shifted heavily toward the left side: bags are only important in the context of aggregation, and lists are even less important as the "order by" SQL clause is virtually the only usage for them.

Once again, if we loose accociativity, then we have to expand our semantics spectrum to admit trees

sets, bags, lists, trees

This progression is natural:

sets -- idempotent, commutative, associative
bags -- nonidempotent, commutative, associative
lists -- nonidempotent, noncommutative, associative
trees -- nonidempotent, noncommutative, nonassociative

The further down to the right you are, the less declarative RA becomes. Every algebraic property that is lost contributes to making a query more procedural. Received on Fri Feb 18 2005 - 23:54:24 CET

Original text of this message