Browse Prior Art Database

One-Dimensional Indexing For A Multi-Dimensional MDX Query Disclosure Number: IPCOM000226436D
Publication Date: 2013-Apr-03
Document File: 6 page(s) / 155K

Publishing Venue

The Prior Art Database


Disclosed is a method to create a Multi-Dimensional eXpressions (MDX) query wherein the resultant Cellset is one-dimensional. This solution consists of two parts: (1) creating an MDX query to return a linear list, and (2) indexing the list given a set of coordinate elements. The algorithm converts the coordinate element names into integer indices. The algorithm then uses these indices to discern the resultant index with only a few simple mathematical calculations. Returning a single-dimensional array allows easy indexing, despite the number of row, column and slicer dimensions.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 30% of the total text.

Page 01 of 6

One-Dimensional Indexing For A Multi-Dimensional MDX Query

When performing a Multi-Dimensional eXpressions (MDX) query, the Cellset that is returned is a two-dimensional table representing a slice of the queried cube. When the Cellset is returned, it is up to the developer to index the results so that they line up with the view that is being created. Every element in a cube has a unique coordinate, specified by its row and column elements as well as its remaining slicer elements. The task of resolving a Cellset becomes much more difficult when trying to index a batch of results wherein the elements do not share the same row or column dimensions (in the case of different row/column elements in the same dimension, as well as row/column elements in completely different dimension hierarchies).

One partial solution is to create a view definition and store this within the Online

Analytical Processing (OLAP) server, but this means extra overhead in terms of storage as well as the foresight to have created the view beforehand. This assumes that the server has support for this special view storage functionality. This is an even less adequate solution if the view definition was meant to be temporary, in the case of batch querying often and regularly. As a view has to pre-exist on the server, a view for every batch of cells must be preemptively created, which is not a solution to the problem of

dynamically querying for any batch of cells.

A second partial solution involves issuing an MDX query. This either returns too much

information (if querying for the whole view), or is difficult to index due to gaps in the returned two-dimensional Cellset, as illustrated in Figure 6.

The solution is to use multiple MDX queries in order to avoid the gaps between cells; ideally, use a single MDX query with any given dimension elements, placed in any order, and resolve them with 100% accuracy. A single MDX query allows greater

performance over issuing multiple MDX queries. In addition, a single MDX query does not have to be persisted on the OLAP server.

A new solution to this problem is to create an MDX query wherein the resultant Cellset

is one-dimensional. Because cell coordinates are the same whether any of the elements are on the row, column, or slicer dimensions, said coordinates can all be appended on the same dimension (e.g., all in the same column dimension), thus returning a Cellset that is a linear list. The list must then be indexed properly; otherwise, there is no way to retrieve the results. An algorithm must be used to map

each result index to its corresponding spot in the Cellset, which is now a simpler task

since indices are one-dimensional ranging from 0 to N, as opposed to being mapped to a two-dimensional grid. This approach does not involve any persistence of the data, and the MDX query can be generated dynamically every time, based on the needs of the client. Creating a view definition cannot work in this case, and a regular MDX query...