Should all dimensions keys in the fact be PKs?

Hi all,
I think I still come from the 3NF mentality that the PK should be the minimal set of attributes that can uniquely identify a row in a table. But as for the fact table in dimensional modeling, this "rule" does not follow right?

My question is, should the primary key of the fact table always be the collection of all[u] FKs of the dim tables? Let us say for example, I have 10 dates in the fact (one is a transaction date which is logically be a PK and the others are 9 are "attribute" dates), should all of these 10 date keys be part of the PK?

Thanks,
Ed

Nope. Use the minimum set of columns to define the PK. In fact I now just put a surrogate key on my fact tables as well. A single numeric PK for all tables in the warehouse is a wonderfully useful thing.

To add to that, there really isn't any particular reason to declare a PK unless you intend to update rows in the fact. If you have a transactional type of fact table where you only insert rows, there isn't a need for a PK.

Also, as far as fact tables go, it is not a good idea to actually enforce PKs even if you need one. It only introduces unnecessary overhead.