Virtual cube scenarios

Common scenarios for using virtual cubes are described here. You can combine these scenarios based on your specific needs.

Cubes with partitioned data

Sales information for a large region is stored in two cubes. Fact data for each cube can originate from a single fact table or two separate fact tables. One cube, WestSales, stores sales information for the west region, and the other cube, EastSales, stores sales information for the east region. WestSales and EastSales have the same structure. To provide a combined view of the sales data, you can define a virtual cube AllSales to merge the two regional cubes.

Cubes with pre-cached historical data and current data

Sales information is stored in a single cube called AllSales. The cache of this large cube must be rebuilt frequently to reflect the updates in the database. The rebuilding process usually takes a long time.

To address this problem, you can split AllSales into two cubes: one to record the historical sales information (HistoricSales), and another to record the daily sales information for the current month (CurrentMonthSales). You can then define a virtual cube called VirtualSales to join these two cubes. By reorganizing the cubes this way, performance is improved in the following ways:

  • Because you refresh data only for CurrentMonthSales, cube refreshing performance is improved.
  • Because query results from HistoricSales are pre-cached, and CurrentMonthSales is small in size, performance for queries run against the sales data of the entire time period is improved.
  • Because of the smaller size of CurrentMonthSales, performance for queries run against the sales data of the current month is improved.

Cubes with shared dimensions

Sales information is stored in a single cube called GlobalSales. You need to convert some sales figures into other currencies. You could add exchange rates to this cube, but the cube might contain redundant data and would be hard to maintain.

Instead, you can create a cube called ExchangeCurrency to store the exchange rates, and define a virtual cube SalesConversion to perform currency conversion for the sales data. GlobalSales and ExchangeCurrency share some dimensions but do not have the same structure.