Accumlated fact v/s transaction fact
2 posters
Page 1 of 1
Accumlated fact v/s transaction fact
Currently I am reviewing a Dimmodel for a recruiting domain project.
I am not happy as per how the modeler has done that as for each activity or each phase he is adding a row in the fact.
For example -
Resume Reveived
Screening
I st interview
II Interview
HR Interview
Offer Given
Offer accepted
Joined
A candidate would go through all these stages (if..) and for each stage a row will go to the fact.
As per ralph Kimball if we have to design a model for a activity which time bound or for small period we should use accumlated fact and not a transaction kind of fact.
Accumlated fact helps in reporting as you get all the details from on row and answer many business questions from a simple query.
If transaction fact is used you need to create subqueries for answering the same questions.
whats opinion?
I am not happy as per how the modeler has done that as for each activity or each phase he is adding a row in the fact.
For example -
Resume Reveived
Screening
I st interview
II Interview
HR Interview
Offer Given
Offer accepted
Joined
A candidate would go through all these stages (if..) and for each stage a row will go to the fact.
As per ralph Kimball if we have to design a model for a activity which time bound or for small period we should use accumlated fact and not a transaction kind of fact.
Accumlated fact helps in reporting as you get all the details from on row and answer many business questions from a simple query.
If transaction fact is used you need to create subqueries for answering the same questions.
whats opinion?
Vishy- Posts : 75
Join date : 2012-02-28
Location : India
Re: Accumlated fact v/s transaction fact
Sounds like a great use for an accumulating snapshot. Anytime you are modeling a workflow, accumulating snapshots should be considered.
BoxesAndLines- Posts : 1212
Join date : 2009-02-03
Location : USA
Re: Accumlated fact v/s transaction fact
Thanks,
But I still wonder why we don't see many accumulated fact in projects ???
1) Have people forgot this approach ?? OR
2) they are more used to transaction/snapshot facts so never think on other lines OR
3) Modelers get scared of adding few more columns for creating accumulated fact but still happy with too many rows and hell complexity in report development. OR
4) ER modelers doing dimensional modeling and they psychologically trapped in normalized things and consider accumulated fact a SHIT.
Kimball has openly advocated this type of facts and I have seen this used in few successful projects but mostly this idea has been neglected !!!
But I still wonder why we don't see many accumulated fact in projects ???
1) Have people forgot this approach ?? OR
2) they are more used to transaction/snapshot facts so never think on other lines OR
3) Modelers get scared of adding few more columns for creating accumulated fact but still happy with too many rows and hell complexity in report development. OR
4) ER modelers doing dimensional modeling and they psychologically trapped in normalized things and consider accumulated fact a SHIT.
Kimball has openly advocated this type of facts and I have seen this used in few successful projects but mostly this idea has been neglected !!!
Vishy- Posts : 75
Join date : 2012-02-28
Location : India
Re: Accumlated fact v/s transaction fact
5. People are undeducated on the different solutions that are available.
BoxesAndLines- Posts : 1212
Join date : 2009-02-03
Location : USA
Similar topics
» Transaction fact without obvious transaction type field
» Transaction fact table and Transaction line item fact table
» Conformed Dimension for Transaction Fact and Accumulating Snapshot Fact Table
» Transaction Fact or periodic snapshot fact
» Timespan Transaction Fact
» Transaction fact table and Transaction line item fact table
» Conformed Dimension for Transaction Fact and Accumulating Snapshot Fact Table
» Transaction Fact or periodic snapshot fact
» Timespan Transaction Fact
Page 1 of 1
Permissions in this forum:
You cannot reply to topics in this forum