Stiivi
commented
11 years ago Looks like useful feature.
To have more information in-place, here is quote from the mondrian docs:
Virtual cubes occur surprisingly frequently in real-world applications. They occur when you have fact tables of different granularities (say one measured at the day level, another at the month level), or fact tables of different dimensionalities (say one on Product, Time and Customer, another on Product, Time and Warehouse), and want to present the results to an end-user who doesn't know or care how the data is structured.
Any common dimensions -- shared dimensions which are used by both constituent cubes -- are automatically synchronized. In this example, [Time] and [Product] are common dimensions. So if the context is ([Time].[1997].[Q2], [Product].[Beer].[Miller Lite]), measures from either cube will relate to this context.
Dimensions which only belong to one cube are called non-conforming dimensions. The [Gender] dimension is an example of this: it exists in the Sales cube but not Warehouse. If the context is ([Gender].[F], [Time].[1997].[Q1]), it makes sense to ask the value of the [Unit Sales] measure (which comes from the [Sales] cube) but not the [Units Ordered] measure (from [Warehouse]). In the context of [Gender].[F], [Units Ordered] has value NULL.
Requirements/questions:
- How to define the virtual cube model?
- How to define virtual cube dimensions? We can have similar way as for templated dimensions and use something like
from_cube(analogous to mondrian's plaincube) - How to define interface for backends to be able to support this feature?
It would be nice to implement virtual cubes like in Mondrian (see http://mondrian.pentaho.com/documentation/schema.php#Virtual_cubes)