Tom Chester and Associates

I'm reposting this 2003 article because, unfortunately, it's still pertinent:
___________________________________________________________

Choosing an OLAP Client

an important criterion that everyone overlooks
Tom Chester, 2003

Somehow it has come to be that most of the popular off-the-shelf OLAP clients are fundamentally crippled compared to their relational brethren. And this despite the fact that OLAP is supposed to be enabling technology.

To compound matters, this (as yet undefined) drawback tends to slip beneath the radar. That is, it is a criterion not typically considered when organizations evaluate OLAP front-ends.

The Problem

Can you imagine selecting a relational front-end tool that doesn’t allow a developer to specify a SQL statement? Of course not, this would be a non-starter. Yet this is the lay of the land in the OLAP niche. Many of the shrink-wrap clients that work with Analysis Services do not allow the developer to attach a query – an MDX SELECT statement – to a given view or report. This is even true of the venerable Microsoft Excel, arguably the most commonly used front-end to Analysis Services. Whereas Excel allows a SQL SELECT statement to be attached to a PivotTable (when sourced from RDBMS), and has done so since the inception of PivotTables in version 5.0, it does not provide the ability to attach an MDX SELECT when the PivotTable is sourced from a cube. Excel is not alone here.

And since the developer community takes this in stride, blithely expecting the respective canned UIs to answer every possible question posed by users, no pressure is exerted on the software companies to get their acts together. 

There’s a potential price to pay, a looming pitfall which this article intends to shed light on.

Who needs to SELECT? 

Some argue this is a moot point; that one of the main purposes of OLAP is get out of the customization mire; that a primary value of shrink-wrap clients is to eliminate the need for developers to write MDX SELECT statements; that basic cube browsing is all that’s needed by users, thank you very much. 

These are admirable sentiments. But the fact is, once users get past the initial euphoria of plain vanilla cube browsing, there is an inclination to start asking more complex questions. Not to mention the hard-core analysts, who need to ask complex questions from the get-go. There are countless questions that basic cube browsing cannot easily answer. Questions such as “What are the top 10 stores, and what are the top 3 products per store?” Or “Show me sales for each day of the year that falls after a holiday.” 

Naturally, different client tools expose different functionality. The more robust clients indeed go beyond basic cube browsing, and provide user interfaces that allow more complex questions to be asked and answered. While this functionality is to be applauded, this is a slippery slope, one that leads to an inordinately complex user interface for the majority of users who don’t need to do the fancy stuff. Not to mention the fact that even the most robust clients, those capable of answering a myriad of complex questions, fail to come even remotely close to exposing the full power of the MDX language.  

In short, you may never need to write an MDX SELECT statement. However, in the event your users require functionality not provided by a shrink-wrap UI, be careful not to paint yourself into a corner. 

How to Tell

You might think it’s a simple matter to discern which tools support MDX SELECT. Not quite. To be able to pose the right questions to your prospective software vendor, and make sense of answers that are apt to be confusing, you must understand the role of MDX within Analysis Services. 

MDX, an acronym for Multi-Dimension eXpressions, is more than a query language. It is also a calculation language. MDX is used to define calculated members, calculated cells, and a handful of other calculation constructs within Analysis Services. While calculations can be defined on-the-fly as part of an MDX SELECT statement, they are typically defined in the cube, within the OLAP database. When calculations are defined in the cube, they are along for the ride, free for the taking. That is, MDX calculations defined in a cube are automatically exposed via any and all OLAP clients.

Software vendors, less than eager to reveal their weak points, take credit for supporting MDX by virtue of the fact that MDX calculations are viewable. But that’s not the issue. The question to pose to the front-end vendors is this: “Does your product allow a developer to specify a custom MDX SELECT?” And since many of the vendors market a suite of products, don’t assume that just because product A supports MDX SELECT, that product B from the same vendor does so too.

Does Data Source Flexibility Merit an Exception?

There are shrink-wrap products that are tightly bound to Analysis Services, and those that are not. The tightly bound products, such as ProClarity (from the company of the same name) and Novaview (from Panorama Software, the original developers of Microsoft’s OLAP engine), are well integrated with Analysis Services, and expose many of the server’s advanced capabilities, including MDX SELECT. Then there’s the generalist camp – those front-end tools that work with a variety of data sources, at the expense of tight integration with any particular back-end. These are the players who tend not to expose MDX SELECT. I have one question to pose to these vendors: Do you know how to spell pass-through?

In other words, support for MDX SELECT is not a lot to ask for; no fancy UI required; just give developers a place to stick a (long) text string, and pass it through. As most of the vendors are no doubt working on XML/A implementations, this is the perfect opportunity to provide a sorely needed capability to the developer community.