Data Warehousing Community Forum Data Warehousing Community Forum
The Warehouse of Data warehousing knowledge ...
 
*
Welcome, Guest. Please login or register.
Did you miss your activation email?
September 06, 2010, 02:31:28 am


Login with username, password and session length


Pages: [1]   Go Down
  Print  
Author Topic: Fact table to capture data across different time grains  (Read 275 times)
ashgo2k10
DW Fresher
*

Reputation: +0/-0
Offline Offline

Posts: 2


View Profile
« on: March 29, 2010, 02:33:18 pm »

Hi,

I am very new to data warehousing. I need to construct a data warehouse for a metrics application which can generate dynamic reports from millions of data. These reports can be hourly, daily, weekly, monthly and so on.

I know I will have to create a time dimension table storing a time key (integer) and other information like day of month, week , month, year, etc.

My question is should i create a single fact table that stores all the information at lowest grain (i.e. hour) and then query this fact table to generate all kinds of reports?

I see a disadvantage to this approach: If I need a weekly report, then lot of time would be taken to query such huge data in way of grouping and summing. So should i be creating a different fact tables which capture the calculated data for different time grains.. like a fact table for weekly reports, another one for monthly reports, and so on? Or should I create just one fact table and have different indexed views for better performance?

Please bear with me as I am a novice and would greatly appreciate any help that comes my way.
Logged
Whoever
Administrator
*****

Reputation: +34/-0
Offline Offline

Posts: 114


Forum Don


View Profile WWW
« Reply #1 on: March 29, 2010, 10:31:52 pm »

My question is should i create a single fact table that stores all the information at lowest grain (i.e. hour) and then query this fact table to generate all kinds of reports?

I see a disadvantage to this approach: If I need a weekly report, then lot of time would be taken to query such huge data in way of grouping and summing. So should i be creating a different fact tables which capture the calculated data for different time grains.. like a fact table for weekly reports, another one for monthly reports, and so on? Or should I create just one fact table and have different indexed views for better performance?
One fact table would be the most logical/maintainable solution.

You really shouldn't worry about the performance degradation due to the required aggregation/summation.
You would be surprised as to just how efficiently database engines can aggregate upon integer fields, especially if indexed well.

Also, indexed views is a good idea if you face performance issues.

However, the ideal solution would be to use a dedicated multi-dimensional "OLAP" engine. (such as Microsoft Analysis Services)
Such engines are designed specifically for quick retrieval of aggregated views of data.
Logged

You don't get it.  I built this place. Down here, I make the rules. Down here, I make the threats. Down here, I'm God.
ashgo2k10
DW Fresher
*

Reputation: +0/-0
Offline Offline

Posts: 2


View Profile
« Reply #2 on: March 30, 2010, 08:48:37 pm »

Thanks so much, Whoever!
Logged
Pages: [1]   Go Up
  Print  
 
Jump to:  



© Copyright 2006-2010 DW Forum. All rights reserved

contactSanghala | Cyber Militia | Powered by SMF | SMF © 2006-2009, Simple Machines LLC | Dilber MC Theme by HarzeM