|
|
THIS PAGE REPRESENTS ONLY A VERY SHORT EXTRACT FROM THE FULL REVIEW.
TO VIEW THE FULL REVIEW YOU CAN PURCHASE THE REVIEW INDIVIDUALLY OR PURCHASE AN ANNUAL SUBSCRIPTION TO THE OLAP REPORT WHICH ALLOWS ACCESS TO ALL OLAP REPORT CONTENT.
Business Objects is proud of the fact that its products do not have their own database, but instead report on data in both relational and multidimensional databases. Indeed, it is this omission of a database in its own products that made it easier for Business Objects to partner successfully with companies like SAP, IBM, Hyperion, Microsoft and the former Adaytum, prior to its acquisition by Cognos. However, of late, Business Objects’ partnerships have become much less successful, in sharp contrast to Crystal Decisions. Business Objects’ previously successful partnerships with IBM and SAP have waned, and the Adaytum partnership was obviously severed the moment that Cognos bought the company. There are still some remaining joint sites, but most Adaytum sites have switched to using Cognos tools instead of BusinessObjects.
But although Business Objects no longer promotes the fact, every BusinessObjects report is actually delivered via a cube! If the report is of relational data, then it will have invariably been produced using a BusinessObjects ‘dynamic microcube’ — a small MOLAP cube that can be pre-generated or created on-the-fly. If the data comes from an OLAP database, such as Microsoft Analysis Services, SAP BW or Hyperion Essbase, then it could be produced using a microcube or, in some cases, via a direct query. In particular, (the soon to be superseded) BusinessQuery MD and WebIntelligence 2.7 query OLAP databases directly without building microcubes, but the rich reporting is only possible via microcubes.
Users wishing to produce a new report on relational data must first define the scope of the query. This is done by selecting business terms from pre-defined ‘universes’. When selecting the query scope, the user can choose how many levels of each hierarchy to download; restricting the number of levels will lead to the creation of a much smaller download, which will be faster, but will mean that it may not contain enough detail to complete the task in hand. Behind the scenes, the universes map these terms to columns in one or more tables, and can also include calculations to be performed in the source database.
The query is then executed as one or more SQL Select statements, performed by one or more database servers (or from local files). The results of these are returned to the client PC or the mid-tier server and immediately read into memory where they are converted to multidimensional structures called microcubes, and this is the form that they are stored in if the document is saved.
The dimensions of a microcube are defined by the scope of the query, and the members of the dimensions depend on the actual rows returned, so that dimensional structures do not have to be pre-defined. In this sense, the engine behaves like a ROLAP. It is also ‘aggregate aware’, so that it can take advantage of pre-created summary tables, but it is not as intelligent at using the closest available summary tables as the more specialized ROLAP products if the query cannot be satisfied by a pre-existing summary table. Instead, a list of available summary tables is provided and the first one from the list that is sufficiently detailed to support the query is used. In other words, the list should be arranged to have the most summarized tables at the beginning and the least summarized at the end, so that for any particular query, the first table that is at or below the level needed will be used. In practice, this may not always be the ideal choice, but if the list is sensibly organized, should not be far from optimum.
The microcube engine subsequently behaves more like an MDB, with a multicube OLAP engine, which automatically matches dimensions between multiple subcubes. There is no explicit limit on dimensions, dimension sizes and model sizes, but these will all be limited by memory availability and performance. This flexible multicube structure is unusually versatile for a desktop OLAP tool.
The microcubes are stored in memory (or in a report) as a set of compressed arrays. Each microcube can hold the results from one of more SQL Select statements; all of the results which share the same dimensions generate a single microcube. Thus, a complex query which generates a number of Select statements, each grouped by different dimensions, will result in several microcubes being created.
The data is held in the form of a Type 1 table, with eight bytes reserved for numeric measures, and between one and eight bytes for the dimension keys, depending on the cardinality of the dimensions (dimensions with fewer than 256 members will only need one byte, those with fewer than 64k members will need two bytes, and so on). It is likely that most practical dimensions suitable for analysis on a typical client PC will need either one or two bytes. BusinessObjects treats each level of a dimension as another dimension, so the size of the key is likely to be quite large compared to the data, and BusinessObjects microcubes are much less scalable than the equivalent memory PowerCubes in PowerPlay (but, of course, unlike PowerCubes, BusinessObjects microcubes do not have to be created in advance, and can be dynamically refreshed by end-users without IT involvement). We also believe that calculation performance is unlikely to be optimized through this relatively simple multidimensional data structure.
Documents complete with data (in the form of microcubes) can be stored and distributed as PC files; these are the documents that InfoView uses. In effect, these hold data in the form of disk based multidimensional databases, so Business Objects can also be viewed as a MOLAP. This chameleon nature is characteristic of all the desktop OLAP products, although BusinessObjects is more like a ROLAP than other desktop OLAPs due both to its ability to access summary tables in the RDBMS and to dynamically create microcubes from any part of a large RDBMS.
By OLAP server standards, microcubes are very small databases, but Business Objects overcomes this problem by providing an ingenious facility to create dynamic new microcubes when a user reaches the limit of the current microcube. When a user elects to drill past the edge of the current microcube held in RAM, a new query is automatically generated. The database server executes the query, the results are returned and compiled into a new microcube in the client PC. The time taken for this may vary from a few seconds (if the new microcube is small and the server fast), to several minutes (or worse) in larger cases. A query governor can be used to prevent large queries being submitted, and to kill long running queries.
We were not happy that when a user triggers a new query in this way, the additional query results do not simply supplement the information from the previous microcube that is already in memory. Instead, the latter is discarded, and if the user wishes to view that information again, the microcube will have to be recreated from scratch (unless the user has saved the document). If both the new details and the original information are to be viewed together, then a much larger microcube will need to be created, also from scratch. While this does not, technically, limit the capacity or functionality of the product, we believe that it will have the effect of slowing down queries and increasing network traffic. This will inhibit users from navigating freely in multidimensional space.
In principle, the microcube approach has a number of attractions (compared to the approach used in BusinessObjects’ main competitor, PowerPlay) in that the IT burden of creating and updating relatively large pre-built data cubes is largely eliminated. While it is possible to create such cubes automatically in advance, using the BusinessObjects Broadcast Agent Server, the user is still able to perform multidimensional analysis on data that has not been pre-built. This gives the users more flexibility, and cuts the administrative effort. However, we think that some of the potential attractions have been lost because of apparently inefficient use of memory, and the failure to retain the current microcube when a query extends beyond its boundaries.
Business Objects currently provides a variety of means of querying and reporting from leading OLAP servers, and in these cases, capacity depends mainly on the server’s scalability, rather than Business Objects. The 6.1 WebIntelligence OLAP allows automatic drill through to related (pre-defined) relational reports, with the dimension selections being used as reporting parameters. It also adds any cube to any cube drilling. Users can drill to and from the same server cubes or to other server cubes (ie, from an Analysis Services cube to an Essbase cube). Note that these capabilities will be superseded in BusinessObjects 12 by technology from Crystal Analysis.
|
|
THIS PAGE REPRESENTS ONLY A VERY SHORT EXTRACT FROM THE FULL REVIEW.
TO VIEW THE FULL REVIEW YOU CAN PURCHASE THE REVIEW INDIVIDUALLY OR PURCHASE AN ANNUAL SUBSCRIPTION TO THE OLAP REPORT WHICH ALLOWS ACCESS TO ALL OLAP REPORT CONTENT.
