Kimball is not saying that "fact table is acting as dimensions". He is saying that numeric values can sometimes be modeled either as a dimentional attribute (a field in a dimension table), or a fact (a field in a fact table), or both.
A classic example of that is product list price, such as MSRP (manufacturer suggested retail price). Some designers will model it as fact (because it's a number - i.e., in fact table "Sales"). Others will model it as a dimesional attribite (i.e, in dimension table "Product"). What Kimball is saying is that you can have both in the same model. MSRP as a dimensional attribute can be used for filtering, while MSRP as a fact can be used to do calculations (i.e, MSRP - Sale Price = Sale Discount).
Sublte points are these:
- If you model product price as an atribute, it will make your dimension a "slowly changing dimension", because each time product list price changes, you will need to change the attribute - which adds burden to your ETL process.
- If you model product price as a fact, you will only have it in star schema if there are records in the fact table. If, for example, some products have no sales in a particular period, than you won't have their list price in the system in case you need it.
Having it in both places gives you ultimate flexibility and simplifies use of the model, but increases ETL work. So, if you need such flexibility, it's a good design. If you only plan to use the value in one specific way, you can save yourself some data warehouse work.
