parent child dimension model

What is the best option for the parent child dimension model in the below scenario.



Option 1:
* Keep the dimension tables similar to source tables and include dimension key
Option 2:
* Keep the dimension tables similar to source tables and include dimension key
* Repeat the higher level attributes in lower level tables.
Option 3:
* Snow flaking dimension.
Option 4:
* Snow flaking dimension.
* Repeat the higher level attributes in lower level tables.

How about option 5: A single Product dimension table that contains category and subcategory attributes?

Thanks for the new option ngalemmo.
I think you mention the "Product" table in Option2 or Option4.
But we have facts in Category and Sub Category levels as well.
Could you suggest which option is suitable in this case.

Option 2... sorry I did not look that close and was thinking just a single dimension table.

However, since you have other facts that are at one of these other grains, you need dimension tables for those as well. There would be no relationship between these tables. Different facts would reference the dimension appropriate for its grain. Facts would be combined based on conforming attribute values.

The other thing is the alternate key designation is confusing. The only alternate key a dimension should have is it's natural key. So, in the Product table, the alternate key is the product code (natural key). Category and subcategory codes are attributes, not part of any key to the table.