Re: Idempotence and "Replication Insensitivity" are equivalent ?

<pamelafluente_at_libero.it> wrote:
> I have problems to follow you here. Has I said I know nothing about
> theory. Do not know what you mean by the term "projection of
> relations".
> Is it something simple to grasp?
It just means that you form a new relation which contains a subset of the information in the first relation by choosing some of the columns. If you have an n-ary relation of the form A1 x A2 x A3 x ... x An, then there are 2^n - 1 possible projections (excluding the project that selects no columns, because it's useless; but quite arbitrarily including the identity projection, which is just the original relation). Because a relation is a set, the projection will combine any tuples that have duplicate values in ALL of the projected columns. So if you have:

    Name Age Salary

    Brenda   17       33,000
    Mike     23       27,000
    Bob      45       33,000
    Joe      17       50,000
    Carol    23       27,000

And so a project to the columns (Age, Salary), you get

    Age Salary

    17       33,000
    23       27,000
    45       33,000
    17       50,000

(Note you've dropped a column because (23, 27000) was a duplicate.)

If you project it to (Age), you get:

    Age

And you've lost two columns, because there were two duplicates in the age column alone.

So COUNT DISTINCT (Age, Salary) basically just means project the original table to the columns (Age, Salary), and then count the rows. Counting the rows is an aggregate function. Projecting the relation is not an aggregate function.

> My original goal was actually to discuss a method to deal with report
> functions under value duplication and create the appropriate unions of
> subqueries, ad Business Objects does, but, actually, if I could grasp
> some concept useful to improve the programs it would be really nice !

Well, good luck with that. If you also decide to talk about database theory, feel free to do so. (No, the question of how to define an aggregate function has very little bearing at all on how you should write a reporting application.)

-- 
Chris Smith