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
» 
Comment and Contribute
