The only thing I would add is that once you use the ISO format, you no longer have a surrogate key; you have an ISO date that can be used like you would a degenerate dimension. That’s what makes the date dimension exceptional (for the reasons I listed). Otherwise, you can use a sequential number (a real surrogate) and force your DBA to do some math and date mapping in his/her partition scheme (keys 1-31 = partition 1, keys 32-59 – partition 2, etc..).

When building ROLAP queries, you can gain some nominal performance benefits and simplify some queries by not joining on the date dimension when unnecessary. The ETL developer, the DBA, and the analyst are all happy for various reasons. There is always a trade-off between convention (fact/dimension surrogate key system) and usability/performance. The date dimension / foreign key is one of those cases that the normal rules can be bent (IMHO).

“You can treat Date dimensions a little differently. Instead of making the first row in your Date Dimension start at 1, use the ISO 8601 date standard YYYYMMDD format. This makes sense for a few reasons. First, it is easier to look at a row in a Fact table and have the date available without a join to the Date dimension or one of its role players. Second, a Date Dimension is treated as a Type 1 SCD, meaning, you would never have the same date repeated with one row being active and the other inactive as in TYPE 2 SCDs (hence throwing off the ISO date format). Third, because Fact tables generally contain several dates, using the integer date key (which is an int in the ISO date format) instead of fetching the formatted date from the Date Dimension may have some performance benefits because you can easily format the date later on in the presentation layer. Lastly, you can usually predict with certainty the total number of rows that the Date Dimension will have, and then pre-populate all the dates before you even do your first integration. This removes the Date Dimension from the surrogate key processing all together.”

I agree that YYYYMMDD should be used as the primary key, however it is NOT for any of the reasons you listed. In fact, ANY end-user interpretation of a foreign key in a fact table violates the whole idea of surrogate keys.

The reason date dimensions are an exception to the rule is to make life easy for DBAs when they need to define partitions for fact tables. Date is, by far, the most common partitioning criteria used in physical database design. If the value of the date key column is known in advance, the DBA can do his thing with the DDL to lay out partitions to support data distribution, archiving and a host of other functions. If the date dimension uses a true surrogate key, it would require the dimension to be built in advance and remain unchanged before the rest of the physical database is constructed. Doing it that way creates a lot of headaches.

Even though the key is in a known format, you should never shortcut the dimension process and try to directly interpret the foreign key value in a data warehouse query.