Date dimension in your data warehouse

The importance of date dimension
in a data warehouse and BI project
Date: March 3th 2015
Author: Dirk Cludts

The importance of a date dimension in a data warehouse and BI project
Web-IT Support and Consulting ~ info@webit-support.com
1. Introduction
You're about to set up a new data warehouse, modify an existing one or maybe you are struggling
with dates in reports, dashboards, ... If so, this article will help you to understand what are the
benefits of a date dimension table. I will even try to prove you that a data warehouse always needs
to contain a date dimension table and that cubes, reports, dashboards, ... that are based on dates
use in 99% of the cases a date dimension table (or should do).
2. What's in it for you
Ask yourself the following questions and if you answer yes to one or more of these questions, then I
would invite you to read on.
I never used a dedicated date dimension?
I don't know what a date dimension is?
I need to perform analysis over a different periods (weeks, months, quarters, years)?
I need to do some specific grouping on dates?
I have gaps in my date ranges?
Departments in my company have different approaches to what is the first day of the week,
what is the first week of the year, what are the legal holidays (per country), what is the first
quarter depending on fiscal or standard year, ...?
I work in an international company and have big issues with all kinds of date formats?
I can't get all the information I want out of date (fiscal information, holiday, working day even if
weekend, ...)?
Did you answer “Yes” at least once? Guess
what? 8 out of 10 people do when they
start with data warehouses and Business
Intelligence projects. Enjoy the next
chapters and if you have additional
questions, send me a message and I will try
to help you.

3. What and why?
A date dimension contains all the information you need about a certain date and allows
developers, analysts, users, ... to analyze data as efficiently and accurate as possible. The most
commonly known date attributes are: day, week, month, quarter and year. But many more (very
useful) attributes can be collected from a date (see later).
Having this information at any time at your disposal without having to perform calculations, will
make date operations much more performant, will allow you to access the attributes very efficiently.
On top of that all people in your company will talk the same way about dates (standard or fiscal)
and no more additional coding in stored procedures, reports, PowerPivot, ... will be needed.
In this article I focus on dates and not so
much on time. But the same principles apply
to time, although with different attributes
(seconds, minutes, hours).
Nevertheless we advice you to separate these
two dimensions, mainly because of
performance issues. A day has only 24 hours,
so the time dimension will be a fixed table
that never changes. Once you created it, it
will last forever and contains normally 86.400
records (60 seconds x 60 minutes x 24 hours).
If you would combine this with every single
date in the date dimension it would lead to
millions and millions of records, which makes no sense and will slow down date operations in your
procedures. And to be honest, not so many companies need a time dimension, whereas every
company needs a date dimension.
For example: the amount of records for 1 year would go to 31.536.000 records (60 seconds x 60
minutes x 24 hours x 365 days) instead of 365 records.
4. Date attributes
First things first, so we understand each other crystal clear:
The following attributes are not an exhaustive list. More attributes are possible (seasons, fiscal
information, company specific information, extended holidays, boxed periods (Easter, Christmas,
company events, ...), ...).
None of the fields are calculated. The values are entered directly in the field, never calculated!
Mostly the content is uploaded with company specific scripts, certainly for fiscal and company
definitions
Each day can only appear ones in your dimension table. Even when your fiscal year is not the
same as a standard year, all the information of 1 day needs to be in 1 record.
Whatever information you think is useful for a date and will avoid calculation or concatenations
or wrong interpretations, just add it as an additional field.

4.1. Example of a dimension table structure I mostly use for my
customers
As said before, there can be many fields. This depends all on the kind of date-related information
you need. The screenshot below only contains the fields I mostly use for a calendar year
(DateStandardXXXXXX). The same goes for fiscal year and should be additional fields added behind
all these ones (DateFiscalXXXXXX).

Fields that are often used in selection criteria should also be properly indexed. This is very important
for performance reasons. Most likely these fields are CHAR, INT or DATETIME fields. But all depends
on your data warehouse architecture. Unfortunately, there are no real golden rules, just good
common sense.
4.2. Example of live data for one date
The title says it, it's an example. If you want to format your information in a different way, you can.
Personalize all your fields the way it's best for the type of output you need. And if for some reason,
the number of the week, the weekday, etc are different for your organization, just adapt it to you
needs. Again, no gulden rules, just down to earth logic.

5. Useful date functions to help you fill in the table
The next few lines of code will often be the basis to calculate the different date elements you need
to insert into the dimension table. Depending on the fields and types, you need to be creative with
those (and other) date functions. But this is a good start.
To fill the table with a set of dates, the code structure looks like this (not all the details are coded
since they depend on your table):

6. Translations
For multinationals or companies who want to report their information in several languages, it can
be a better option to create special translation tables. In the above example I added 4 languages
(NL, FR, UK and GE) for month names, quarter names, ... This is the easiest way to set things up and
most of my customers report in one of those languages. So no need to make more tables and more
complex structures (you could even add Spanish and Italian). But if you're not sure that these
languages are sufficient, a better solution is to work with separate tables. So for each possible
description of a month, quarter, ... you will have 1 record per item and per language. For
translations of the month January for example you would have a table that has the next set of
records:
Important: if you need to add Turkish, Russian, ... translations, all VARCHAR fields need to be
NVARCHAR fields so you can store unicode characters too!
7. Summary
By now you should be ready to relate all your relevant dates from different tables in your data
warehouse to this very important dimension table.
No more gaps in date ranges since you have
every single date in this table.
No more wrong ideas and opinions on weeks,
quarters or other periods.
No more issues when grouping dates in reports
or PowerPivot.
Easy date hierarchy set up in your cubes (SSAS).
Correct date formats through the entire
company.
And many more advantages.
I hope you found this article interesting and above all useful. If so, you don’t need to ask me
whether you can share it with colleagues, friends, partners, students, ... Because sharing knowledge
is what it's all about.

One vision, one goal!
Learning & sharing information never ends…

Date dimension in your data warehouse

Recommandé

Recommandé

Contenu connexe

Similaire à Date dimension in your data warehouse

Similaire à Date dimension in your data warehouse (20)

Plus de Dirk Cludts

Plus de Dirk Cludts (7)

Dernier

Dernier (20)

Date dimension in your data warehouse