• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 762
  • Last Modified:

ROLAP date dimension link to OLTP datetime fields in tables

Hi Experts,


SQL Server 2008 R2

I have created a simple ROLAP database with four tables:


My DimDate dimension is already populated with date range and the rest of the tables are empty.

Now I want to transfer data from my OLTP database into my ROLAP database. My Date granularity is at the day level.

Now what I am absolutely stumped with is how do I load data from my OLTP database into my ROLAP database with regards to date?

So for example in my OLTP database if I want to load from 2005 -2007. How do I load this data into ROLAP database, so that the ROLAP database knows I'm loading data from 2005-2007 from the OLTP database. So if i run a query in the ROLAP for date range 2005-2007 I will get the same results as OLTP.

I have looked at AdventureWorksDW2008 and I cant figure out how data was loaded from OLTP into ROLAP whilst keeping the date in sync.

Ultimately what I am asking if I am loading data from any source into ROLAP, what actions do I take to match the data dates?

Many Thanks,
  • 2
  • 2
1 Solution
J3D1-KN1G1-1tAuthor Commented:
Dont worry I got it, the Fact table has the related OLTP dates....

I will still award though for best answer.
ValentinoVBI ConsultantCommented:
"I will still award though for best answer."

Understood :)

"Ultimately what I am asking if I am loading data from any source into ROLAP, what actions do I take to match the data dates?"

I would say it depends on the source and on the design of the DimDate.  My ETLs usually use a staging database so the data transition would happen in two phases:

1. load from source into staging - data types are preserved as much as possible
2. load from staging into ROLAP - data types are converted to match ROLAP

It's in the second phase that the fact records need to get matched with the correct dimension records. Usually I use the SSIS Lookup component for that.

Now, DimDate is a special case. In most cases it is a bad idea to put any logic in a primary key but in the case of DimDate it's actually very practical.  Just as they did in AdventureWorksDW, the DateKey is an int with a special structure: YYYYMMDD.

The fact that DimDate is a pre-populated dimension means we know exactly what's in there and what the foreign key in the fact table needs to look like.  Which means we don't need to waste time on a lookup here.

In case your incoming date field is of type datetime (or date), you could fabricate the key using the SSIS Derived Column transform and some math through an expression like:

YEAR(YourDate) * 10000 + MONTH(YourDate) * 100 + DAY(YourDate)
J3D1-KN1G1-1tAuthor Commented:
Thank YOu
ValentinoVBI ConsultantCommented:
So no further questions on that? Cool! Thank you for accepting my answer! :)
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

  • 2
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now