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?
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 Content Component encountered an error
I am evaluating ETL tools for the organization. Considering that I am looking at three or four tools, how do I rate these and put a weight-age for ...continue reading
What are the pros/cons of custom development vs. an ETL tool? The question of custom code versus the use an ETL tool is one that we are faced with ...continue reading
ETL tools provide very robust support for complex business logic.continue reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.