Introduction to MSSQL Server 2000 Analysis Services: Actions in Virtual Cubes - Page 4
April 19, 2004
A (Quick) Review of Virtual Cubes
As many of us are aware (see, Exploring Virtual Cubes, earlier in this series) a virtual cube is a logical (versus physical) cube, composed of one or more regular cubes. An analogy I hear and read often, in varied attempts to explain the "logical cube" concept, is a view, within the context of a relational database. In a view, as most of us know, tables and / or other views are combined to embody a single "source" from which data can be presented. Virtual cubes are flexible, as they allow us to "consolidate" cubes, and it is flexibility that makes the virtual cube attractive to architects and developers.
When we construct a virtual cube, we can pick and choose the measures and dimensions we want to present from the population of dimensions and measures in the constituent, underlying cubes. "Consolidated" is a concept that is particularly meaningful in scenarios I frequently design and implement for clients. An example might be a group of single P & L cubes, one each for standalone entities that are identical in structure otherwise. In this case, a virtual cube makes for an excellent "consolidated" financial statements reporting tool (the intercompany balances can be housed within one or more additional standalone cubes, which become part of the group that is "consolidated," with the intercompany cube(s) obviously netting to zero, due to mutual offsets therein). It's the kind of stuff CPA's fantasize about!
The information consumers, of course, see the virtual cube as a single cube from the perspective of the reporting package, browser, or other tools they use. As we noted in our introductory article, virtual cubes can also be used to control the information (measures and / or dimensions) that consumers can see in a single cube, working again like a view in "hiding" that which we want to keep away from them. This, too, can become quite useful as a mechanism for controlled presentation, particularly when we combine a virtual cube, designed to present a restricted view, with an underlying, unrestricted cube; we then exercise control over access using security roles that group users by which cube we want them to access.
As many clients have been delighted to learn (and I, of course, delighted to relay), virtual cubes require practically no physical storage space. We can combine and / or control the data in multiple cubes that are already in place without a material increase in storage demands. This is because virtual cubes physically contain no data - only their own definitions. A potential downside is the need to process a virtual cube before it can be browsed the first time: While the linking that occurs between the virtual cube and its underlying components is rapid enough, the virtual cube's processing triggers the processing of any underlying cube that it determines to need it. This can be mitigated with some fairly straightforward planning and scheduling, but it is important to note that, even with virtual cubes, there is no totally free lunch