We must assume that whoever banned the DV, will monitor all EDW's to see if it used same structures, only with other names. So, we need a better disguise. Let's gamify it! Firstly, the users of the EDW now becomes a Player. The player can create their own tasks or can be given tasks by other players. These tasks can be automated, if you have aquired tools, knowledge and ressources. There are a lot of games where you build buildings to store resources. And games often use inventories and use magic to improve stuff. We can see a satellite of a HUBs as a storage building for a single type of ressource. And the HUB is just the index cards. The data in the satellite is reflected in the inventory list. The most recent record in the inventory list shows the current state, but of course we need the historic records also, as the players might need to explore the past to find clues for solving their tasks. Single ressources can be made into products. These equals the links. Multiple single ressources (stored in the HUBs) are combined in the Links. So we need some structures to store this: HUB - Resource HUB satellite - ResourceInventory LINK - Product Link satellite - ProductInventory Of course, the resources in a HUB/sat or LINK/sat do not just appear there. They are transported there from storage buildings in other countries, using horse transport, car transport, boats or planes (ETL). There is an element of Just in time, so the players must ensure that the ressources arrive in time for their tasks. PIT/BRIDGES are handled by magic. And Dimensions and Facts are different kinds of Treasures for the users.

I think the key (pun intended) here is the "unit of work". Whenever you you analyze a source file for business keys, you have to consider what the purpose of the file/table is, and never just load one business key. So I go with Tim's approach, and carefully evaluate if there are additional business keys in it. So, if you find multiple business keys, (with different semantic meaning), you should keep the "unit of work", and put all the keys in the link. BUT, I would then also model the HUB's, even if they are not in the scope yet. IF you already have an incomplete link, you would need to consider the grain. - Does the new business key change the grain, I would make a NEW link in the Raw Data Vault and handle it in the business vault (or bridge). - If not, you might just add the business key to the link. But you are now faced with the problem that historic records does not have data for this attribute.