Are dates degenerated dimensions?

Hi,

Am I allowed to look at date dimensions as like a degenerated dimensions or do I need always to have a surrogate key for them?

Regards,

Evgeni

A degenerate dimension is a source system identifier with no describing attributes used to group facts. That is not the purpose of a date. Add the foreign key.

evgeninikolov wrote:Hi,

Am I allowed to look at date dimensions as like a degenerated dimensions or do I need always to have a surrogate key for them?

Regards,

Evgeni

What does your date dimension look like? It should contain a lot of things, such as month labels, day of week, fiscal calendar data, and so on. The question is, does the date you are trying to store need these attributes? If it does, then store a FK to the date dimension. If it is something like an effective date that would only ever be used as a date to filter selections, then you can just store the date itself as a degenerate dimension.

ngalemmo wrote:
What does your date dimension look like? It should contain a lot of things, such as month labels, day of week, fiscal calendar data, and so on. The question is, does the date you are trying to store need these attributes? If it does, then store a FK to the date dimension.

Yeah, it is a full blown date dimension :-( And since the fiscal year is different than the calendar year I need those attributes. OK, so the decision is taken! I think that the main argument is that there should be a special values for invalid or infinite dates as AFAIK null values and outer joins are not permited in the dimensional modelling.