What is OLAP? At its simplest, Online Analytical Processing is a way to explore and calculate accumulated business data across several dimensions—such as time, product, region, account, and scenario—quickly enough to pursue one question after another.
A transaction system records that a sale occurred. An OLAP system helps someone ask why margin fell, compare regions, drill from a year into a month, switch from actual results to budget, or recalculate a forecast after an assumption changes. One protects individual events; the other supports reasoning across many events.
That practical meaning has proved more durable than any technical definition. OLAP has described specialised cube servers, relational systems, semantic models, cloud warehouses, and analytical query engines. Its history is therefore not a straight progression toward one correct architecture. It is the history of a useful problem that no vendor, analyst, council, or benchmark managed to own.
What Multidimensional Analysis Means
Business questions rarely fit into one table viewed one way. Revenue may need to be examined by month, product, region, customer, currency, and scenario. Cost may need to be consolidated through both account and organisational hierarchies. A forecast may need to preserve several versions while allowing authorised users to change assumptions.
In OLAP language, revenue and cost are measures. Time, product, region, and scenario are dimensions: perspectives through which those measures can be grouped and compared. A user can aggregate months into a quarter, drill from a region into a country, rotate from products by month to products by customer, or calculate variance between actual and budget.
The familiar cube is a metaphor for this arrangement, not a restriction to three dimensions. Some systems store data in specialised multidimensional structures. Others reproduce the same conceptual view through relational, columnar, or semantic technology. The defining experience is movement through connected business perspectives without rebuilding the question each time.
One measure can be aggregated, compared, and recalculated through several connected business perspectives.
The Products Came Before the Name
By 1993, the analytical problem was already familiar. Spreadsheets offered immediacy but became fragile when models had to be shared and governed. Transaction systems protected corporate facts but were designed to record events, not to reformulate analytical questions. Decision-support systems promised managerial insight, but the term covered everything from reporting to modelling.
TM/1 is one clear example of a product that later entered the OLAP market before the category existed. During the 1980s, it was described as a table manager, multidimensional spreadsheet, relational spreadsheet, decision tool, and tabular database. The changing descriptions reflected a product searching for a recognised category as much as a category waiting to be named.
So far, no evidence has been found of the exact phrase before July 1993. That dates the label, not multidimensional analysis itself. OLAP placed existing products into a common comparison set and told buyers which capabilities should count.
Codd Named a Category—and the First Ranking Was Retracted
The public naming event was the July 26, 1993 Computerworld feature “Beyond Decision Support,” by E. F. Codd, Sharon B. Codd, and Clynch T. Salley. It named Online Analytical Processing, described the analytical limitations of relational databases and familiar front ends, and supplied twelve rules for evaluating products.
Those rules can be reduced to four concerns. Users should receive a genuinely multidimensional view. Data should remain accessible through familiar tools. Performance should remain consistent as models changed. The system should support shared use, cross-dimensional calculation, and flexible reporting.
Codd had used this method before. During the 1980s, he formulated rules and product ratings to decide which database systems deserved to be called relational. In 1993, the same method was transferred to analytical processing. It gave buyers a checklist and vendors a category to claim.
The commercial setting complicated that authority. “Beyond Decision Support” included a five-product chart in which Arbor Software’s Essbase satisfied all twelve rules and no rival satisfied more than half. The feature also invited readers to request the accompanying Codd et al. paper, Providing OLAP to User-Analysts: An IT Mandate, distributed by Arbor.
On October 11, 1993, Computerworld editor in chief Bill Laberis disclosed that the publication had not known the feature was part of an Arbor-paid white paper. Pilot Software denied that the Codd group had contacted it despite the chart’s stated sourcing. Laberis directed readers to disregard Pilot’s data and the entire chart.
The July product checklist and the October retraction belong together. The chart is historical evidence of the category’s launch, not reliable evidence of product performance.
In 1994, Sinper distributed the distinct Codd-associated paper OLAP with TM/1, applying the rules-oriented framework to TM/1. Once the rules existed, vendors could use them to establish category membership even though the original comparison had been discredited. The definition had become competitive infrastructure without an accepted authority to certify the claims.
Finkelstein and FASMI Pulled OLAP in Different Directions
Richard Finkelstein’s 1994 Understanding the Need for On-Line Analytical Servers asked why transaction-oriented infrastructure was insufficient for analysis.
His answer was a workload distinction. Online Transaction Processing systems were optimised to record and protect individual events. Analytical users wanted to aggregate, compare, drill, consolidate, and repeatedly reformulate questions across large bodies of data. Complex joins, maintained summaries, front-end calculations, and hierarchical consolidation made conventional relational approaches awkward for this work.
Finkelstein used the newly introduced OLAP term to argue for specialised multidimensional servers. He did not propose replacing relational systems: OLTP and OLAP would coexist because they addressed different work. But his definition located multidimensionality primarily in a class of technology.
Nigel Pendse pulled the term in another direction. On February 25, 1995, he posted “OLAP — Debate a proposed definition” to comp.databases.olap and proposed FASMI.
FASMI shifted attention from the server to the user’s problem. Fast Analysis of Shared Multidimensional Information meant:
- Fast: can people move from one question to the next without waiting so long that they lose their train of thought?
- Analysis: can they perform the calculations, comparisons, allocations, and other business logic they actually need—not merely retrieve data?
- Shared: can several people work with the same information securely, including changing numbers without corrupting the common model?
- Multidimensional: can they view the same measures by time, product, region, scenario, and other business perspectives?
- Information: can the system handle enough relevant source and calculated data for the application?
For Pendse, multidimensional described how users should understand the information, regardless of storage. “Shared” also brought planning into view: confidentiality, concurrent updates, locking, and data integrity made budgeting and forecasting more than read-only analysis.
FASMI was easier to apply to a business problem, but harder to test. Its original five-second expectation did not specify data volume, calculations, concurrency, or query complexity. FASMI never became a certification scheme or reproducible scorecard. It remained a concise way to ask whether a system supported useful analytical work.
Finkelstein identified a specialised technical response; FASMI described the analytical experience a user should receive.
The OLAP Report Made One Market from Different Technologies
Definitions do not create a market by themselves. Buyers also need products to be classified and compared.
Work on The OLAP Report began in early 1995. The OLAP Report: Succeeding with On-Line Analytical Processing appeared that September as a two-volume work by Pendse and Creeth, published by Business Intelligence. One volume addressed planning, design, and development; the other product evaluation and selection.
By March 1997, its online index placed TM1, IQ/Vision, Essbase, IBM DB2 OLAP Server, and a much wider field under the same OLAP banner. These were not variations of one standard design. They included specialised multidimensional servers, desktop products, relational approaches, and combinations of client and server processing.
The Report’s architecture pages described those differences, but its product index, reviews, rankings, and market totals created the appearance of a homogeneous market. The homogeneity came from classification, not from the technologies. This useful act of classification gave buyers a field to survey and vendors a market in which to compete. It also made the category look more settled than it was.
One label made different technologies appear comparable, but the scorecard still determined which differences counted as success.
The OLAP Council and the Problem of Comparing Unlike Solutions
The OLAP Council was established in January 1995 by Arbor, Comshare, IRI Software, and Pilot Software. It promoted common definitions and interoperability and produced the APB-1 benchmark. Its central problem still appears whenever different technologies are proposed for the same business requirement: users may receive a similar report or planning model even though the systems use very different combinations of storage, pre-calculation, calculation on demand, and client or server processing.
A common scorecard cannot avoid choosing which differences matter. Total completion time, time to first answer, storage, data loading, concurrency, freshness, and hardware cost can each produce a different ranking. APB-1 made that difficulty visible in 1996 by giving unlike systems one sales-and-marketing workload. The workload was common; the implementations were not.
The 1997 results consequently supported several victories: Applix emphasised TM1’s preparation time, storage, and early answers; Oracle emphasised Express’s query and total completion time; Arbor emphasised Essbase’s loading and calculation improvements. Each could cite disclosed results because each selected a different meaning of performance.
An audit then found omissions, rule violations, inconsistent query interpretations, client-side work assigned by the specification to the server, and incomplete returned results. Release II tightened disclosure and comparison rules, yet warned that APB-1 covered neither every OLAP requirement nor the realities of a customer application. A stricter test could reduce ambiguity, but it could not make different architectures equivalent.
The Council could promote the category more easily than it could make these trade-offs disappear. Its interface specification never became the default; its remit broadened in 1999; and by 2002 and 2003 contemporary observers described the Council and its successor as defunct or nonviable. Its failure did not make comparison pointless. It showed that a shared label and scorecard cannot by themselves make different technical solutions equivalent.
The same issue persists in modern requests for proposal. An RFP turns a business problem into rows that vendors are expected to answer in comparable form. But “supports multidimensional analysis,” “responds within five seconds,” or “handles concurrent planning” are not neutral criteria unless the workload and operating boundaries are defined. A checkbox can conceal materially different solutions. The reverse mistake is to prescribe a cube structure, pre-calculation method, interface, or processing location when the requirement is really an outcome, excluding another architecture that could solve the same problem.
The Workload Outlived Every Definition
OLAP now covers two related meanings. Microsoft still uses it for traditional cube-based Analysis Services. DuckDB uses it for analytical operations such as grouping, filtering, rollup, and aggregation. Google Cloud applies it to warehouse workloads, while ClickHouse uses “real-time OLAP” for low-latency analysis of frequently refreshed data. The same term can therefore describe a multidimensional model or a broader analytical workload contrasted with transaction processing.
OLAP survived because the distinction between recording business events and reasoning over them remained useful. Its definitions failed because organisations can perform that reasoning through different technologies. The name identifies a family of problems; it cannot decide which architecture, performance measure, or trade-off matters in a particular organisation.