I have a fact table “Sales_F” that contains two surrogate keys: ship_to_vendor_key and bill_to_vendor_key. These keys originate from the same dimension table Vendor. IF I create two alias tables on Vendor, say Ship_To_Vendor and Bill_To_Vendor (leaving the original vendor table aside). Will I have to create a set of objects for Ship_to vendor info (such as ship to city, ship to state, ship to zip, etc) and another set of objects (such as Bill To City…) in the Sales class? THis would enlarge the class. Is there another way to get shi to and bill to vendor information?
Yes you need aliases, your dimension is playing two roles (ship_to, bill_to). You have to create aliases and individual objects so that the users can easily grab them in their query.
The date dimension plays several roles in typical fact tables. Suppose we are looking at an accumulated fact table with 10 dates, does this imply that we need to create 10 date table aliases and 10 groups of date related info in our class? Seems that the universe will expand like a hot air balloon in no time !
A date dimension is linked to a fact table(accumulated measures) based on a single key field(surrogate key mostly). Do you want to join the fact table on different date fields and not calendar date.
You ask the same question again and again… on this board, you will get the same answer.
What part of the accumulated fact table did you not get? If there are 10 surrogate date keys I would hope they originate from the same Date dimension (each playing a different role). I want to report on date related facts from the Date dim for each of these. I know you say 10 Aliases are needed.
I was hoping somebody else would read this and give me his/her suggestion.
What kind of fact table are you talking about, Is it EVENT, PERIODIC or ACCUMULATED ?
The reason I suggested you to create two aliases for Vendor dimension earlier is because you will have two addresses: Bill_To, Ship_To.
(BOB member since 2004-06-06)
