Cube Design & extensibility

We do allocations utilizing the UD3 dimension to store the logic in member formulas using "api.Data.Calculate". We then use the flow dimension to break apart the base (loaded data), Alloc_In (Allocated data), Alloc_Out (Net out the member you are allocating from Base). We do all of this in a single cube.

If you have the same entities in both cubes, the two cubes are not linked, so you will have to explicitly move data through the two, either with rules or Data Management jobs (or possibly Hybrid Scenarios).

You can change your Account and UDs per Scenario Type. So the same cube could have "Account Hierarchy A" for Actual scenarios and "Account Hierarchy B" for Budget scenarios. That's so-called "Horizontal Extensibility": the Entity structure stays the same, but the Account-like dimensions can be different for each use case. This will not significantly impact performance, it's fine to have one cube if your needs are limited; performance issues are, typically, a result of using the same Account/UDs for Scenario Types with significantly different requirements.

Multiple cubes are typically used when the Entity (or Scenario) structure has to be different. For example, you'd have a couple of base cubes to collect actual data, and a parent cube to consolidate everything at a very high level. That's Vertical Extensibility. Again, Account dimensions can be different per Scenario Type and per Cube.

Note that you don't have to deal with extensibility just to move data around between accounts, that's all done in rules no matter what. There are api calls to automatically deal with extended dimensions in some cases (ConvertDataBufferExtendedMembers etc).