Google Trends highlights the awkwardness of OLAP straightforwardly:
How could this happen to OLAP? Did the father of relational database E.F.Codd make a serious mistake in introducing the OLAP? Off course no. However, the traditional OLAP tools should be blamed for it. These traditional OLAP tools have a deadly shortest board in computing. The time and money it costs the customers just flow away from this shortest board, only leaving the complaint and anger as an inevitable result.
Here is a practical example: To help a telecommunication company analyze its profit, the traditional OLAP tools are usually like this:
1. Have a double expert in both OLAP product technology and telecommunications business (usually an employee from the developer) to propose a common model in the industry. Then, have a double expert in both database technology and telecommunications business (usually an 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, users have to consider various factors from a strategic perspective. Because the post-modeling modification would involve huge workload, the time would be relatively lengthy.
2. Have the data retrieved from database and populated into model by double skilled expert in both SQL 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.
3. Business personnel will perform the data analytics based on the model to reach a certain conclusion. Broadly speaking, this procedure is called "computing" for which there is only a limited number of computing methods available, such as rotation, slice, and drilling. In fact, due to the elusive changing business 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.
4. The "presentation" stage refers to presenting the result through the user-friendly and easy-to-understand style. This stage typically comprises a wide variety of tables and charts rich in styles and forms.
As we know, the traditional OLAP procedure comprises 4 stages: Modeling - Querying - Computation - Presentation.
Modeling is an unnecessary stage. Modeling is like a rather closed cell in which the jailed people are 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, or other means? Still impossible!
In the OLAP procedure, the next step computing depends on the intermediate results. Analysts 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:
Modeling cannot solve the above problems because modeling conflicts with the original intention of OLAP. It is high costly, often requires a long cycle, restricts the freedom, and unable to rapidly 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 is a stage in which there is still room to improve. The traditional OLAP is not only a bit too time-consuming, but also demands too much on users' technical background. In view of this, the query stage should be optimized so that even non-technical staffs can grasp it easily and implement rapidly. This article will not talk about query in detail since query is another topic to be discussed separately.
Computation stage suffers from a serious shortest board. For most enterprises, lots of the commonest computation goals are impossible for the traditional OLAP tools to implement, such as:
The traditional OLAP does not support the arbitrary and interactive data computation, while this is the essence of OLAP. For example, decompose a complicated great goal to several simple steps. 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 analytics task.
In fact, "modeling" is the pitfall introduced by the traditional OLAP tools to cover up their weakness in computing. Modeling adds limited computational capability to OLAP tools at the cost of a huge amount of time and money. It is evident that the limited computational capability is rather weak to support and produce the truly valuable analysis conclusion. Ultimately and regretfully, we see the undesirable result of Lose-Lose: OLAP lost the market and users waste their money and time.
The only meritorious stage is the presentation The traditional OLAP tools have done so well in the presentation that they are virtually comparable to the professional reporting tools. This is the only meritorious stage for the traditional OLAP tools. OLAP is by no means to simply act as any kind of reporting tools. The excellent presentation performance cannot remedy their lame computational capability. After all, 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 so-called OLAP?
From the above analysis, we may find that the traditional OLAP should remove the modeling, optimize the query, rebuild the computing, and keep the presentation stage. The desired result would be Query - Compute - Present. Of which, rebuilding is the core to implement the arbitrary and interactive data computation. Obviously, the last resort of OLAP is to find a tool that is capable to remedy the shortest board of OLAP.
The last resort is esProc, as a BI tool not requiring any modeling, it is capable to conduct the arbitrary computation and implement the true essence of OLAP. Let's find more about esProc:
Gird-style intuitive interacting: esProc supports the Excel style interface with an extra visibility into the intermediate result of each step, capable to carry on the computation by making a reference to the intermediate result with the cell name, as shown in the below sample figure:
Perfect support for step-by-step computation: esProc can decompose the complex problem to simple computation procedure according to the business description. For example, analyzing the box office characteristics of new released movie, this complex and obscure problem can be decomposed to several such simple and clear problems as "total box office in last week".
Tailored support for massive structural data: esProc is designed especially to process the structural data that is a common type of the business data. It is capable to filter, group, associated query, make statistics, and conduct other computations freely through the agile and easy-to-understand expressions.
Support for explicit set: esProc is fully set-lized to represent the set, member, related generic object, and object reference conveniently. For example, to compute the clients whose sales are always among the top 10 in every year.
Support for ordered computation: In the practical data analysis, a great number of complex computations are related to the data order, such as "to compute the month-over-month growth in percent". With esProc, the alike complex problems can be solved easily.
Support for object reference: For the complex association at multiple levels, users can write the expressions following their business logics intuitively. With the period "." to make a reference to the object, the complex and lengthy multi-table Join statements can be converted into the simple object access. For example, to compute problems like: Of those line managers winning the President's Award, whose subordinates won the Outstanding award of the year?
esProc requires no modeling in terms of OLAP analysis. With the professional computational capability, esProc enables users to rapidly respond to the ever changing business opportunities, submit the reference data for decision making, and save the operation cost in time and money.
esProc provides the arbitrary computational capability to implement the truly arbitrary OLAP computation. The enterprise can thus be provided with the valuable data for decision-making.
esProc does not require users having any experience in software development, offload the work from the senior technical assistance teams or double experts, reduce the technical requirements on the analysts, and further cut the human resources cost for enterprises.
esProc remedies the shortest board of OLAP completely. It is a blockbuster to the deathly still OLAP market.
Related News From Raqsoft:
Christmas Big Discounts with Cash Back on IT Products
Business Intelligence Suppliers: Are You Ready for 2013?
Made-in-China IT Products Emerge with Outstanding Capability
No comments:
Post a Comment