From M&A Impact, a sister publication.
There have been two defining moments in the OLAP (on-line analytical processing) market; the entry of Oracle by its acquisition of Express, and the purchase by Microsoft of Panorama, which will enable it to enter the market later this year. The first moment defined OLAP as a valid technology for Information Services departments, the second as a valid technology for end-users.
By Krishna Roy
The Panorama acquisition validates OLAP as an area within which Microsoft, or perhaps more significantly the Microsoft channel network, will become very active over the next year, selling solutions based upon shrink-wrap products. This will greatly expand the potential installed base of query tools which operate against OLAP servers. It was for its OLAP server technology that Microsoft acquired Israel-based Panorama Software as long ago as October 1996. The Panorama acquisition led to a project known as Plato that has, in turn, delivered a product known as Microsoft OLAP Server. You cannot, however, go out and buy this product – yet. Its been made available only to a number of partners. OLAP servers are also known in many contexts as multi-dimensional databases or MDDBs and the use of OLAP is becoming widespread and there are a range of enterprises, both large and small, where OLAP may be appropriate.
Unique form
By its nature OLAP is quite a constrained technology. It forsakes the generality of a relational database with its large range of data models, and provides a unique form of data model based upon a multidimensional view of events within a business. A typical example of an event might be the record of a sale, a withdrawal from a cash machine, or a claim under an insurance policy. A typical dimension might refer to certain product line, to a particular retail outlet, or to a specific time. These aspects can be viewed as dimensions of sales. Conceptually, each sale must refer to a product, a sales outlet and occur at a particular time. Within each dimension there will typically be hierarchies. For example, sales outlets might be organised into territories that are organised into regions and further organized into countries. Products may be organized into product groups, which themselves are organized into product sectors. Time, as a dimension, tends to have a natural hierarchy based upon seconds, minutes, hours, days, weeks etc. So an OLAP server is simply an engine that provides access to data which is logically organized in this manner. Despite its lack of generality (compared with relational databases) in terms of the things it can naturally represent, OLAP is a technology which has universal applicability. Every mom and pop video store could, in principle, be interested in understanding the events (e.g. sales) within its business in terms of various dimensions. The Microsoft OLAP Server is actually formed from the integration of OLAP and relational technology, in the form of a new version of SQL Server (Version 7). Our current understanding is that you will be able to buy SQL Server 7 separately from the OLAP Server, but that you will not be able to buy the OLAP Server without SQL Server (since the OLAP Server relies on SQL Server for its storage technology). It also seems likely that IBMs OLAP Server offering will be similarly-packaged. It is based upon Arbor Software’s Essbase OLAP Server with DB2 for relational storage (though Essbase has an open relational interface, which will allow it to be plugged into other relational databases). These packaging decisions are important in terms of the way that OLAP will be defined in the rest of the marketplace. It is clearly going to put price pressure on the OLAP client tool vendors. Typically end-user tools come in at a headline price of around $1,000 per user, but we can expect this to halve in the next year or so. Microsoft will also be introducing more OLAP-aware functionality into its own desktop applications (notably Excel), which will allow it to be used as a front-end to OLAP Servers in many cases. In fact, it may be that the Microsoft game-plan is not to compete with the front-end OLAP tools vendors directly at all, but to squeeze them out by feature-creep in Excel. The marketing of OLAP has already changed in a number of important ways as a result of Microsofts acquisition of Panorama and the OLAP Server developments. There used to be two concepts in OLAP servers: ROLAP (for relational OLAP), and MDDBs. ROLAP was a high-end product, typically acting as a front-end onto a large-scale data warehouse. Microsoft is not targeting this market. Rather it is pursuing the market which has hitherto been the province of MDDBs: small-scale data marts which operate at a departmental level and which, in many cases, are dependent upon a central data mart for population. There is thus a slight marketing hiatus in resolving the fused relational database and OLAP Server as a departmental-scale OLAP solution. The result is a concept known as hybrid OLAP, a notion designed to capture the idea that the new relational/MDDB fusions are actually hybrids between MDDBs and ROLAP servers. The key to this seems to be that the hybrid OLAP systems use the relational database as a storage mechanism but do not require explicit management of the relational database. The multidimensional tabular structure within the relational database, as well as all summary tables, are managed by a software component which is known as the hybrid OLAP Server, to differentiate it from an MDDB or a ROLAP engine. Building a hybrid OLAP Server can be as simple as taking an existing MDDB and cutting out the specifics of the product which deal with storage of data on disk, and replacing them with tabular access to a relational database.
Binding clients
The main issue is that the APIs of the hybrid OLAP Server can essentially be those of the MDDB from which it was derived. These APIs give access to functionality such as management of dimensions, summaries, hierarchies of summarization, and so on. There is also a range of computation functions that, the MDDB vendors claim, was always wider than that present in ROLAP engines. Whatever the case an important point here is that APIs similar to those provided by MDDBs are made available by the OLAP Server to allow it to be accessed and managed as if it were an MDDB – even though it is using a relational database for storage. And although Microsoft OLAP Server has not yet shipped, Microsoft has already made an important move concerning APIs – a move the signals the future shape and direction of the market. Microsoft has in its gift the ability to define client-end APIs by fiat, and has done so in the form of OLE DB for OLAP – a general technique for binding clients into any form of data source.
