|
|
The Importance of 'Disjoint' Reporting:To be able to create a report that takes values from more than one cube is important for two main reasons:
Firstly, cube design. A complication is the fact that very often budgets/forecasts are at a higher level of granularity than actuals. So a business may have an actuals cube with half a dozen or more dimensions & a forecast cube with just two or three dimensions (which are also used in the actuals cube, but where data entry is still not at the leaf level). Sure, there are one cube solutions & one may use virtual cubes & 'lookupcube' functions, but these should not be used simply because of the shortcomings of the front-end, i.e. no support for retrieving values from more than one cube - no disjoint reporting. If your front-end does support disjoint reporting then using the conformed dimensions that are used by both cubes, useful, dynamic, writeback reports can be created with the variances calculated in the front-end & with a simpler OLAP design to support. Secondly, as I can testify in practice, creating the desired report can be very difficult & often impossible in front-ends that don't support disjoint reporting (Crystals & Cognos immediately come to mind). But for those that do, the users are getting the reports that they want without having to do any workaround with the OLAP design. And to be able to create disjoint reports easily, I find the best way to insert the dimension members (& member properties if desired) & then the values, often individually. Some values may reference the previously inserted members, some member names that have been manually typed in, some completely self contained & referencing no other part of the report. This is the flexibility that is required to produce good reports. The only front-end for Analysis Services that I've seen that can do this well is XLcubed. If you are a vendor & believe your product can do the same, or better, please send me an evaluation copy & I'll be happy to review it. |