stevefromOZ (7/20/2016)
Yes. Like i said though, the BillTo FK in the fact becomes superfluous though, because you can get to the analysis of BillTo simply by using the top level of the BillTo+ShipTo hierarchy.
That makes sense.
stevefromOZ (7/20/2016)
A couple of things to watch for -it looks like you're building the fact at the line level. While it's nice to have the order in the fact record, you could get to this via the LineID key , assuming that you have an Order dimension that has Order (being a parent of) Line in it.
I don't have an Order Dimension -- my thinking was that with an order dimension I'd have a dimension that was growing nearly as quickly as my fact table. So I decided to denormalize the order data into the fact table.
stevefromOZ (7/20/2016)
do you really need a 'factid' - the combination of FK's technically is the unique identifier for the fact record. If you don't have a specific need for an identifier on the fact, don't add one.
Thank you for pointing that out! I will review whether or not I need a factID.
Thank you again for the advice -- very helpful.
_____________________________
Past performance != future results.
All opinions and suggestions are my own, unless they're really good. Then I most likely read them here...