In AS2K, when you process a multi-level dimension, the query includes the columns needed to support all the levels. This means that even if the dimension comes from multiple, snowflaked dimension tables, the result will only include higher-level members where lower level members exist. For example, if you have a Time dimension with a Year table and a Month table, but have months for only 2004, then even though the Year table has values from 1994 to 2004, only the members that make it through the join appear in the dimension.
AS2005 is very different. Each attribute gets its own query. This means that you can easily have 10 years of Year members, but only 1 year of Month members. This doesn’t violate relational integrity, because you can always have extra members on the Primary Key side of a relationship.
When I first noticed this behavior, I thought it was very strange—if not an outright bug. But after more thought, it is a very nice capability. Suppose you want to show the current year orders with daily detail, but want to shrink your data warehouse by aggregating all prior years to the month level. Just create two fact tables, one at the daily grain for the current year, and one at the monthly grain for prior years. Create two measure groups, one for each grain. Then create a calculated member that adds the two together. (Because the data is partitioned over time, a simple sum doesn’t double-count anything.) Now you can seamlessly display the whole ten years of data at the year or month level, but the only the current year at the daily level.
In AS2K, you could always assign the first-day-of-the-month ID to represent months, but it’s very difficult to create a calculated member that properly nulls out the daily values when the first day of the month is not a valid day. With the new multi-grain approach, the values only get stored where they really belong.