Oops. I forgot to add a couple of other very important differences between BI/DW and OLTP.

In some shops, ETL processing will allow separate Operational Reporting on the staging databases and presumably the data is cleansed. That is, the traditional data quality issues in OLTP are certified to be corrected. If you have confidence in the cleanliness of your ETL data, there is no need to restrict your loading/inserting to a fact table with a unique index/primary key. That is an unneeded overhead. On the other hand, if you doubt the cleanliness of the data coming in (e.g., duplicate primary keys in the fact table), you have no choice but to slap a unique index on the logical primary key of the fact table. It is regretable but unavoidable.

Another problem is what to do about monster dimensions. From the DBMS's optimizer standpoint, they look like two fact tables getting joined together. Some DBMSes have something called Materialized Query Tables (or automated summary tables) that can mitigate the performance problem here. Again, the 80/20 rule comes into play.