Hi,
I'm just finishing off the modelling of a classic Sales Orders fact and have pushed all of the header information down to the line level as I believe is best practice. I've also got the Order number as a degenerate dimension but there are attributes that really are attributes of the header which implies I need a dimension to hang them off. Having a D-Order dimension attached to the fact defeats the whole point of pushing the header information down. It occurred to me that I could create a junk dimension of header attributes such as order status, order source and hang that off the fact thus removing the need for the D-Order dimension completely. (Actually while typing this it just became clear these are dimensions so I could just have two new dimensions hanging off the fact - or put them in a junk dimension as there are just 9 cross combinations)
Does this sound like a good approach? Any thoughts on what could be a better approach?
one issue that crossed my mind is that if there is no Order dimension and I have a second fact table built around the Invoice (I'm assuming a different grain if I keep invoice line in the fact) how would I relate an Order in the Orders fact to its Invoices in the Invoice fact?
Tom
I'm just finishing off the modelling of a classic Sales Orders fact and have pushed all of the header information down to the line level as I believe is best practice. I've also got the Order number as a degenerate dimension but there are attributes that really are attributes of the header which implies I need a dimension to hang them off. Having a D-Order dimension attached to the fact defeats the whole point of pushing the header information down. It occurred to me that I could create a junk dimension of header attributes such as order status, order source and hang that off the fact thus removing the need for the D-Order dimension completely. (Actually while typing this it just became clear these are dimensions so I could just have two new dimensions hanging off the fact - or put them in a junk dimension as there are just 9 cross combinations)
Does this sound like a good approach? Any thoughts on what could be a better approach?
one issue that crossed my mind is that if there is no Order dimension and I have a second fact table built around the Invoice (I'm assuming a different grain if I keep invoice line in the fact) how would I relate an Order in the Orders fact to its Invoices in the Invoice fact?
Tom