Can a fact table act as dimension table?

Question

I was exploring through Kimball's 'The data warehouse tooklit', where I came across scenario where fact table is acting as dimensions, but I wasn't very pleased with explanation mostly, because I am new to dimension modelling.

My question is

1. what are the instances/examples where a fact table can act as a dimension table? (request to put up some easy example to understand)
2. Is it a good design?

I read through this tek-tips forum, but it didn't help me well.

original source: Kimball's article

edit:

Along with above link, Kimball's aggregated facts also enabled me to ask scenario where aggregated facts is used as dimension.

Answer 1

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.