Re: Idempotence and "Replication Insensitivity" are equivalent ?

From: David Cressey <>
Date: Mon, 25 Sep 2006 13:49:06 GMT
Message-ID: <m7RRg.4040$Zj4.440_at_trndny04>

"paul c" <> wrote in message news:GUGRg.23213$1T2.14136_at_pd7urf2no...

> If you just mean project in some mathematical sense that is apart from
> the RM, then I suppose the domain formed that way could still have the
> same name as the relation (at least that would be convenient).

As Bob has already pointed out, project in the RM sense is mathematical projection, although mathematical projection has a wider scope than what the RM makes use of.

I'm not really interested in "projecting a relation into its domain". That should always yield the same relation.
(See "idempotent"). What I am interested in is "projecting a bag into its domain". Unless I miss my guess, this is the mathematical equivalent of "eliminating duplicates".

The major point I've been driving at, in several of my recent responses, is that, if you start out with bags, (SQL tables that need to allow duplicates), and you apply SQL *as if you were operating on sets*, you get "wrong" answers. I'm deliberately omitting the definition of "wrong".

When Pamela introduced the concept of "replication insensitivity" to the discussion, she combined two issues into one. One is that a relational join can introduce "unwanted" duplication. I'm deliberately not defining "unwanted". The other issue is that there were duplicate rows in her original tables. These duplicate rows were "wanted" for reasons that I summarize as "the cat food problem". So, when you resort to SELECT DISTINCT, or GROUP BY, you get different "wrong" answers than you did before. This is a consequence of the "cat food problem."

When Pamela said, "forget about normal forms", that was my signal to extricate myself from the discussion. If you've been following my posts, you know that I'm not a purist about always following normalization rules. But "forget about normal forms" is, to me, nearly tantamount to saying "forget about database theory". And I don't choose to participate in a discussion held in comp.database.theory, where the underlying premise is that database theory is irrelevant. Received on Mon Sep 25 2006 - 15:49:06 CEST

Original text of this message