Well, if you have multiple business units sharing the DimDate table, then you copy over 365 records (i.e.: one record per day indexing on the date key) for each client into that table with a business unit identifier (foreign key). Then you ensure that identifier is also present on the Fact tables so when you do JOIN the DimDate table and aggregate it, then you are only aggregating the date records for the specific business unit. This allows you to have different fiscal calendars for different clients where maybe January 1st is not Fiscal Week 1, but maybe Fiscal Week 2 or something
This isn't per the Kimball method. If you look at the diagram with which I opened the thread, you will see that it does not require the fact table to have the calendar key in it. The way you're proposing would require a separate fact entry for each separate calendar. I've read about this before, but it's generally discouraged because of the row count increases in the fact table. It would also mean that if you added a new calendar, you would then have to take each of the transactions and create a new set for the new calendar. The advantage of the Kimball approach (in theory) is that a new calendar would simply have to be added to the calendar record. Unfortunately I can't get the solution to work completely correctly as a practical matter, and I don't know what I'm missing. Surely someone has used this method as (supposedly) it is the method by which the Kimball team approached this problem.
It just depends. In many cases, the data warehouse already has a unique key per business unit in order to allow data marts to be built separately per business unit. While it's true, that business unit may not pass to the data mart because no other business unit exists in said data mart, adding a fiscal key that is specific to that business unit in the fact is not increasing the record count unless there is more than one fiscal key per business unit. The impact is more of making the fact table wider and if you are entirely row-based, that does have a slight impact to performance. In my case, I'm all column-store.
Anyways, my question would be how do you filter for the right calendar with OrderDateKey (FactSales) -> DateKey (DimDate) -> DateKey (DimCalender) when the CalendarKey does not exist in the FactSales when it comes from data warehouse to data mart?