Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Fact table boundaries 1
- Thread starter flicg
- Start date
- Thread starter
- #3
It's my (recent) understanding that fact tables are built around (forgive my unexpert terminology) 'concepts'. I would say 'entities' or 'objects' if i didn't think those terms probably mean something else. So, one fact table would contain aggregaged data from different systems about say what i am calling the concept 'service request', another fact table would contain data relating to the concept of 'order' etc. Is that correct?
-
1
- #4
johnherman
MIS
Fact tables are based on measurable quantitative attributes surrounding business entities, usually processes. If the business process crosses normal departmental boundaries, then so be it. If it crosses transactional system boundaries, then so be it.
For example, Purchasing may have several systems (requisition, vendor management, receiving, inventory) and cross departmental boundaries (purchasing, accounting, warehouse, etc).
In your case, the fact table processes are Service Request and Order Fulfillment (pardon me for putting words in your mouth - use your business terminology).
-------------------------
The trouble with doing something right the first time is that nobody appreciates how difficult it was - Steven Wright
For example, Purchasing may have several systems (requisition, vendor management, receiving, inventory) and cross departmental boundaries (purchasing, accounting, warehouse, etc).
In your case, the fact table processes are Service Request and Order Fulfillment (pardon me for putting words in your mouth - use your business terminology).
-------------------------
The trouble with doing something right the first time is that nobody appreciates how difficult it was - Steven Wright
- Thread starter
- #5
Great,thanks, just what i needed! Opportunistic I know, but about measures, I understand that they are sums or counts of data, so for instance: total number of service requests, total travel time, total part usage, total working days. When combined in a MOLAP cube with a dimensional characteristic like who or when, this allows a detailed business analysis of the data. If this is correct then it would mean that in a 5 layer architecture of 1) Staging > 2) ODS > 3) Data warehouse> 4 Datamart > 5 MOLAP > the measures could only be created at the MOLAP stage. Have I got that right?
johnherman
MIS
Either at Datamart or MOLAP level.
Sometimes the datamart is already summarized or contains summary tables for things like total travel time, total working days, etc summarized by, say, month, or Year to Date, etc.
-------------------------
The trouble with doing something right the first time is that nobody appreciates how difficult it was - Steven Wright
Sometimes the datamart is already summarized or contains summary tables for things like total travel time, total working days, etc summarized by, say, month, or Year to Date, etc.
-------------------------
The trouble with doing something right the first time is that nobody appreciates how difficult it was - Steven Wright
- Thread starter
- #7
- Status
Similar threads
- Locked
- Question