Transaction fact with different grain dimension hierarchy

I have a dimension with hierarchy -  say Division and Sub Division.  Usually we put both Division and Sub Division in one dimension or snowflake the Sub Division into separate table.  But, in my case two fact tables are using this hierarchy with different grain.  One fact table has grain on Division and another fact table has grain on Sub Division.  

Right now, I have this schema, but I am directly connecting the snow flaked dimension.  I think it is not a best practice, right?  Should I remove the division_key from dim_sub_division and treat them as two separate dimensions.

dim_division (division_key, division, description)
dim_sub_division(sub_division_key, sub_division, description, division_key)

fact_1(customer_key,  date_key, division_key, measure)
fact_2 (customerkey, date_key, division_key, sub_division_key, measure)

Keep the division information in your sub-division dimension and also create a Division dimension - you then join your fact tables to whichever Dimension is appropriate.

This is the same design pattern as dealing with Date/Week/Month/Year: your standard date Dimension has date/week/month/year attributes in it. But when you create aggregate fact tables at the week/month/year grain you also create aggregate "date" dimension tables for week/month/year - Kimball calls these "Shrunken rollup dimensions" I believe

Thanks for the reply.  I have seen rollup date dimensions.  I have either uses dates in the fact tables itself or created one date dimension.  Creating the rollup on weekly or monthly should have performance benefit depend on the situation.