We are building a star schema with several slowly changing dimensions (Type 2). One of our dimensions is a date dimension. We use the date dimension key in the fact table. But what about other dimensions, should we use a date datatype, or should we use a date_key column linking by foreign key back to the date dimension? Using a date datatype allows us to not have to join to the date dimension every time we do a query. But what is the best practice?

    Requires Free Membership to View

The basic approach that we take to dimensional tables does provide us with a clear direction that all dimensional values should be linked to a fact table via a surrogate key. The date dimension is no different. It is a very important dimension and by providing users with a date table, it provides you with significant business benefits in terms of the business specific date analysis that you will be able to perform. As well, certain BI tools will insist on having a separate dimension for dates to supply data to dimensional filters.

Bottom line here is that I would create a surrogate key, but I will also let you in on a trick that we use around date keys. We define the surrogate date key to always be supplied in the numerical format of YYYYDDMM, although a true surrogate key, we can now infer meaning from this key through the use of TO_CHAR or TO_DATE functions.

This was first published in April 2005

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: