OLAP Cask Principle Reveals the Future for OLAP Tools Manufacturer

This post is originally posted on http://it.toolbox.com/blogs/data-analytics/olap-cask-principle-reveals-the-future-for-olap-tools-manufacturer-54044.

Cask principle illustrates this idea: no matter how high the cask is, it is the shortest board of the cask, not the longest one, determines how much water the cask can hold. Same principle also applies to OLAP. The traditional OLAP comprises 4 pieces of slabs: modeling, query, computation, and presentation, the longest one is the presentation and the shortest is the computing. Unfortunately, computing is just the core to OLAP.

Suppose an insurance company needs analyzing its operating status, and the traditional OLAP tools set the 4 boards as follows:

Modeling: Have the double expert in OLAP product technology and insurances industry (usually the employee from the developer) to propose a common model in the industry. Then, have the double expert in database technology and insurances business (usually the employee from the enterprise) to modify and customize this model according to the requirements and the data characteristics of itself. This stage can be called as “modeling”. Generally, analyzers have to consider various factors from a strategic perspective. Because the post-modeling modification would be huge, the time would be relatively lengthy.

Modeling is like a rather closed cell in which people is confined to take restricted actions. Try to analyze the data outside the analytical model? Impossible! Try to analyze the data through methods other than rotating, slicing, drilling, and other methods? Still impossible!

In the OLAP procedure, the next computation depends on the intermediate results. Analyst can neither predicate nor design a complete analytical model in advance. They can only take some assumptions according to the analysis goal, then verify and correct these assumptions continuously till achieving the desired results. For example: Analyze the differences of operation characteristics of various retail stores between the course of the Olympic Games and the normal days. Find out the reason for the recently released products suffering poor sales.

Modeling cannot solve the above problems because modeling conflict with the essence of OLAP. It is highly costly, requires a long cycle, restricts the freedom, and unable to react to the fast changing business opportunities. The only advantage of modeling is the fast computational speed. However, with the several hundred-fold increases in these 20 years, computational speed is far less important than it used to be.

Query: Have the data retrieved from the database and populated into model by skilled double expert in SQL techniques and OLAP products. This stage can be generally referred to as “query”. Because it requires developing a great number of scripts, the procedure is rather lengthy.

The traditional OLAP is not only a bit too time-consuming, but also requires too much on users’ technical background. The querying stage should be optimized for average person to grasp it easily and implement rapidly. This paper will not detail the query since query is another topic to be discussed separately.

Computation: Business personnel will perform the data analysis based on the model to reach a certain conclusion. This procedure can be referred to as “computing” broadly. In addition, preparation of data source, ETL procedure, and data analysis all belong to the scope of computation. As we know, the computational methods of OLAP are rotating, slicing, drilling, and other limited ones. In fact, due to the elusive changing commercial opportunity and market tendency, the original model is hard to meet the demands and the remodeling is usually unavoidable. This stage would be also very time-consuming.

For most enterprise, lots of the commonest computation goals are very difficult for the traditional OLAP tools to implement, for example: Of the 2 types of mobile phones with the highest sales volume, which 3 brands have the greatest sales amount?

Which products have the consecutive rising customer satisfaction in the recent 6 months?

The traditional OLAP does not support the arbitrary and interactive data computation, while this is the essence of OLAP. For example, decompose the complicated great goal to many a simple milestone. This is called as “Step-by-step Computation”; Intuitive Interacting refers to viewing every intermediate result in an intuitive and understandable way to determine the computation of the next step; Perform any processing on the business data, including the filtering, grouping, associated querying, making statistics. The said business data is usually the massive structural data; Perform the set operation on the data from the business prospective. For example, to compute clients which is based in foreign countries and has a sales over one million; This is called as “Explicit Set”;Order Computation refers to ranking the business objects, link relative ratio, year-over-year compassion, and order-related computation; Access the associated data at multiple levels , for example, solve a problem through the “object reference” method: Of those line managers winning the President’s Award, whose subordinates won the Outstanding award of the year?

It is not the original intention of the traditional OLAP to ignore the arbitrary interactive computation. It is all because the traditional solutions are full of unsolvable contradictions. For example, although JAVA, VB, and other senior languages are powerful enough to perform the step-by-step computation, they lack the computational abilities of structured data.SQL is powerful enough to perform the structured data computation. However, the computation level of SQL is relatively too low, while the technical requirements of SQL are relatively high. A bit more complex computation would require a great amount of obscure scripts. Since OLAP is the tool for business expert, few qualified talents who both excel in both business and SQL could be found. The competent person would be very costly to hire. Though Excel has the outstanding “intuitive interaction” ability, its computation is set for the independent cell data instead of the structural data. Plus, not having such features as “explicit set”, “order computation”, and “object reference”, Excel cannot undertake the complex and in-depth analysis task.

Presentation: The “presentation” stage refers to representing the result through the user-friendly and easy-to-understand style. Usually, this stage comprises a variety of tables and charts rich in styles and forms.

The traditional OLAP does so well in the presentation that it virtually reaches the effect of professional report. This is the only meritorious stage. However, OLAP is not the reporting tool. The excellent presentation performance cannot remedy the lame computation ability. Moreover, computation is the top priority of OLAP. No wonder many users comment that OLAP is “the reports flexible to some extent but quite costly”. May I ask which customer can hold back his anger about the wronged OLAP?

As we can see, the cask of OLAP has already been leaked seriously. Google Trends highlights the awkwardness of OLAP straightforwardly:

10 years ago, OLAP ushered the brilliant age of business intelligence. In the global market, it keeps growing at double digits. Enterprisers hope this new technology will help them implement the flexible and free data analysis, provide the truly valuable business decision, and tell them which are their businesses of cash cows and stars types? With 10 years passing by, to date, the splendid prospect of OLAP has long gone, enterprisers are completely disappointed with OLAP: It is a greedy monster that swallowing a great deal of money and time, leaving the ROI usually worse than the average reporting tools.

How the traditional OLAP tools to cover up the poor computational capabilities? That’s right. It is the modeling. Modeling gains the limited computational capabilities for OLAP tools at the cost of huge amount of money and time of users. Of course, the limited computational ability is not enough to generate the truly valuable analysis conclusion. Ultimately, we see such lose-lose result: OLAP lost the market, and users waste the money and time.

How to get recognized by the industries and welcomed in market again? How to save the money and time for customers? This last resort is esProc, as a BI tool not requiring any modeling, capable to conduct the arbitrary computation, and implement the true essence of OLAP. It removes the modeling stage, optimize the querying stage, rebuild the computing stage, and maintain the presentation stage. This is all about it should be: Query – Compute – Present. It featured: gird-style intuitive interacting, perfect support for step-by-step computation, tailored support for massive structural data, support for explicit set, support for ordered computation, support for object reference.