It’s a good suggestion and the scenerios vary by company to company.  I agree what ever you say.
Do you mind to provide the solution basing on the above example please?

One other idea is to store as many type 2 SCD’s as you want on the table, but also store for each field, the date that the type 2 SCD changed. If the type 2 SCD field does not change, then leave the date field blank. You can then create a view for each type 2 SCD field which will allow you to filter out only changes for that specific field.

However, with all that said, I completely agree with you. If you only need to report the type 2 SCD’s in conjunction with a fact table, then store as many type 2 SCD’s on a table as you want, and don’t worry about what is written in this article.

I certainly agree that recording history for dimensions is often overused really isn’t required based on real requirements (it however, often gets requested by people that think it’s better to ask for everything up front).  Having said that, if a customer requirement truly dictates type 2 SCD, then enforcing/suggesting that only a single attribute should be historically captured seems like an over simplification of real life.  I can’t think of many cases where if we had to capture type 2 SCD, that we only needed to do it for 1 attribute.  Once you have to do it, the work to capture others (depending on how you approach it) is not much extra work processing wise.  Not that I’m saying you need to capture every attribute, only one doesn’t see relaistic to me.

Like I said, unless the user requires call for it, it’s best to avoid since in the end I have found it just makes reporting more difficult for  end users (who now have to then qualify what version to associate with related facts….this is of course if you allow them to link any version of a dimension to facts.  If you embed the surrogate key of the version into the fact, then there is no issue there).

My two cents

Cheers