whose name derives from "ExtendedSpreadSheet dataBASE", was originally developed
by Arbor Software, which merged with Hyperion Software in1998. It is currently
available from Hyperion Solutions Corporation (now a subsidiary of Oracle Corporation

earlier famous set of twelve rules defining the relational model. This whitepaper,
published byComputerworld, was somewhat explicit in its reference to Essbase features,
and when it was later discovered that Codd had been sponsored by Arbor Software,
Computerworld controversially withdrew the paper.[3]

), OLAP defines a database technology that is optimized for processing human queries rather than transactions. The results of this orientation was thatMDBMS oriented their performance requirements around a different set ofbench marks (Analytic Performance Benchmark, APB-1) than that of RDBMS (Transaction Processing Performance Council (TPC)).

practitioners. The Essbase brand was later returned to the official product name for
marketing purposes, but the server software still carried the "Analytic Services" title until
it was incorporated into Oracle's Business Intelligence product suite.[4]

multi-dimensional database technology that put online analytical processing on the
business intelligence map. It has spurred the creation of scores of rival OLAP products –
and billions of OLAP cubes".

Although Essbase has been categorised as a general-purpose multidimensional database,
it was originally developed to address thescalabilit y issues associated withspreadshe ets
such as Lotus 1-2-3 and Microsoft Excel. Indeed, the patent covering Essbase uses
spreadsheets as a motivating example to illustrate the need for such a system.[1]

In this context, "multi-dimensional" refers to the representation of financial data in spreadsheet format. A typical spreadsheet may display time intervals along column headings, and account names on row headings. For example:

Quantity1000 2000 3000 6000
Sales$100 $200 $300 $600
Expenses$80 $160 $240 $480
Profit$20 $40 $60 $120

Quantity240 1890 50 2180
Sales$24 $189 $5 $218
Expenses$20 $150 $3 $173
Profit$4 $39 $2 $45

Quantity760 110 2950 3820
Sales$76 $11 $295 $382
Expenses$60 $10 $237 $307

Quantity1000 2000 3000 6000
Sales$100 $200 $300 $600
Expenses$80 $160 $240 $480
Profit$20 $40 $60 $120

An alternative representation of this structure would be a three-dimensional spreadsheet
grid, giving rise to the idea that "Time", "Account", and "Region" aredimensions. As
further dimensions are added to the system, it becomes very difficult to maintain
spreadsheets that correctly represent the multi-dimensional values. Multidimensional
databases such as Essbase provide a data store for values that exist, at least conceptually,
in a multi-dimensional "hypercube".

A technical problem faced by multidimensional databases is the physical representation
of data as the number and size of dimensions increases. Say the above example was
extended to add a "Customer" and "Product" dimension:

If the multidimensional database reserved storage space for every possible value, it would
need to store 2,400,000,000 (4 × 4 × 3 × 10000 × 5000) cells. If each cell is represented
as a 64-bit floating point value, this equates to a memory requirement of at least 17

arranging the members of each dimension into one or morehierarch ies. A Time
dimension, for example, may be represented as a hierarchy starting with "Total Time",
and breaking down into multiple years, then quarters, then months. An Accounts
dimension may start with "Profit", which breaks down into "Sales" and "Expenses", and
so on.

In the example above, if "Product" represents individual productSKUs, analysts may want to also be able to report using aggregations such as "Product Group", "Product Family", "Product Line", etc. Similarly, for "Customer", natural aggregations may arrange customers according to geographic location or industry.

The number of aggregate values implied by a set of input data can be surprisingly large. If the Customer and Product dimensions are each in fact six "generations" deep, then 36 (6 × 6) aggregate values are affected by a single data point. It follows that if all these aggregate values are to be stored, the amount of space required is proportional to the

Since version 7, Essbase has supported two "storage options" which take advantage of
sparsity to minimize the amount of physical memory and disk space required to represent
large multidimensional spaces. The Essbase patent[1] describes the original method, which