Building Time Dimension Hierarchy

In your time dimension (I always call it a "date" dimension, and make a separate "time" dimension with HH MM SS if necessary), you'll want to make the key for the month attribute so that it contains the year, e.g. 200901.

I usually set up my date dimension so it contains:

DateKey int      -- contains values like 20090101
DateName varchar() -- contains values like "Jan 1, 2009"
DateSortKey -- contains the same value as the DateKey (except in rows like "unknown", "old", "n/a" which I make 99999999 or whatever in order get them to sort to the bottom)
YearMonthKey int  -- contains values like 200901
YearMonthName varchar() -- contains values like "Jan 2009"
YearMonthSortKey -- same note as above on DateSortKey
YearQuarterKey int -- contains values like 2009001 (i usually make this a 7 digit to distinguish it from yearmonth)
YearQuarterName varchar() -- values like "2009 Q1"
YearQuarterSortKey -- same note as above on DateSortKey
YearKey int -- values like 2009
YearSortKey -- same note as above on DateSortKey

Carefully set the attribute keys, names, and sortkeys in the dimension designer.

Optionally you might like to include "yearless" attributes which would sum up or provide sliceability to sets based on the month with no specific year getting involved.  If you build these be careful not to include them in the hierarchies based on the date attributes that do include the years.  I suppose you could set up these in their own "yearless" hierarchy but I think it could be confusing and perhaps even dangerous to do so.  In fact, I'd only *create* these if I really needed to:

MonthKey int -- contains values like 1, 2, ..., 12
MonthName varchar() -- contains values like "January"
QuarterKey int - values like 1, 2, 3, 4
QuarterName varchar() -- "Q1"

If your keys in the fact table don't quite match the format then you can either choose different values to store as the keys (like YearMonthKey) in the dimension or just transform them in the DSV on the fact table.

Join from the fact table to the proper level in the date dimension and at cube design time the dimension usage tab should recognise that you're connecting the fact to the dimension at a granularity higher than the key for the dimension.  do not panic, this is fine, and it is common to have cubes designed this way --  for instance actual sales usually join to date at the date grain, but forecasts forecasts or quotas are stored at the month, quarter, or year.

Hope this helps.