Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase

Adding time dimension in the project Expand / Collapse
Author
Message
Posted Friday, March 01, 2013 11:29 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Thursday, April 10, 2014 5:01 AM
Points: 190, Visits: 1,052
I have two dimensions

Contact and Sales and fact table

fact table contains following attributes

OrderDate,TotalDue,TaxAmt,SubTotal,Freight

My Source table does not contain any Time table.I want to add Time dimension and want to aggregate the data on based on year,semister,quater wise etc

I have done this using some tricks i am not sure whether i am correct or wrong

What i did

1. Right Click on Dimension

2.Add New Dimension

3.Selected 'Generate a time table in the Data Source'

4.Selected First calender day(Jan 1 2001) and Last Calender Day(31 Dec 2004) since Sales Table contains Orderdate starting from 2001 to 2004

5.Selected all the Time Periods

6.Created Time Dimension

7.Added this to existing data source view and made Date as Primary Key and linked to OrderDate attribute in Sales

8.Done the same thing in the attribute relationship tab

For my happiness it worked very well and aggregation i am getting accordingly verified in the data base with SQL statements

So my question is did i made the right relation ship with Sales

table and whatever steps i followed is fine?

Please let me know i am relatively new to SSAS. Any advice or suggestions are appreciated
Post #1425657
Posted Monday, March 04, 2013 10:24 PM


SSC-Addicted

SSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-Addicted

Group: General Forum Members
Last Login: Tuesday, April 01, 2014 2:57 PM
Points: 443, Visits: 822
Sounds OK.

I would make the Calendar table a lot longer, like to 2050 or something. The table won't be very big even with 365/366 rows per year that's only about 13,000 rows. Generally with a datawarehouse you are incrementally adding new data daily (or weekly or whatever) and if you get data after 2004 you won't have any way to link your fact table to your date (calendar) dimension. BTW, a table with dates is not really a time dimension, it's a date or calendar dimension. A separate time dimension would be useful if you are recording time of day, if you require that level of granularity.

Another suggestion is to always use surrogate keys, even for calendar dimensions. I.e. don't use the date value as the key itself. Kimball has a good explanation of this here

The basic reasons are that integer keys are quick and smart keys (with information encoded into the key) are generally a bad idea because it encourages them to be used in client applications and they lose their robustness. It also makes it awkward to have a calendar table that includes holidays for different geographical regions.
You also get stuck if your source data has a bad date, it means you can do error handling so you have a way to link it to an "unknown" member of the date dimension.
Post #1426599
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse