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.
Dig Deeper on Oracle database design and architecture
A SearchOracle.com member asks why a low-cost query has a slower speed than expected.
We are working on the development of a datamart (in 9i) which takes data from two source systems. Since this is a transaction system, there is a lot ...
I am new to Oracle's ETL tool and I need information on data migration using Oracle ETL.
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.