In computing, online analytical processing, or OLAP , is an approach to answering multi-dimensional
analytical queries swiftly. OLAP is part of the broader category of business intelligence,
which also encompasses relational database, report writing and data mining. Typical applications
of OLAP include business reporting for sales, marketing, management reporting, business
process management, budgeting and forecasting, financial reporting and similar areas, with
new applications coming up, such as agriculture. The term OLAP was created as a slight modification
of the traditional database term Online Transaction Processing.
OLAP tools enable users to analyze multidimensional data interactively from multiple perspectives.
OLAP consists of three basic analytical operations: consolidation, drill-down, and slicing and
dicing. Consolidation involves the aggregation of data that can be accumulated and computed
in one or more dimensions. For example, all sales offices are rolled up to the sales department
or sales division to anticipate sales trends. By contrast, the drill-down is a technique
that allows users to navigate through the details. For instance, users can view the
sales by individual products that make up a region’s sales. Slicing and dicing is
a feature whereby users can take out a specific set of data of the OLAP cube and view the
slices from different viewpoints. Databases configured for OLAP use a multidimensional
data model, allowing for complex analytical and ad hoc queries with a rapid execution
time. They borrow aspects of navigational databases, hierarchical databases and relational
databases.
Overview of OLAP systems Core of any OLAP system is an OLAP cube. It
consists of numeric facts called measures which are categorized by dimensions. The measures
are placed at the intersections of the hypercube, which is spanned by the dimensions as a Vector
space. The usual interface to manipulate an OLAP cube is a matrix interface like Pivot
tables in a spreadsheet program, which performs projection operations along the dimensions,
such as aggregation or averaging. The cube metadata is typically created from
a star schema or snowflake schema or fact constellation of tables in a relational database.
Measures are derived from the records in the fact table and dimensions are derived from
the dimension tables. Each measure can be thought of as having a
set of labels, or meta-data associated with it. A dimension is what describes these labels;
it provides information about the measure. A simple example would be a cube that contains
a store's sales as a measure, and Date/Time as a dimension. Each Sale has a Date/Time
label that describes more about that sale.
For example:
Sales Fact Table +-------------+----------+
| sale_amount | time_id | +-------------+----------+ Time Dimension
| 2008.10| 1234 |---+ +---------+-------------------+ +-------------+----------+ | | time_id | timestamp
| | +---------+-------------------+
+---->| 1234 | 20080902 12:35:43 | +---------+-------------------+
Multidimensional databases Multidimensional structure is defined as “a
variation of the relational model that uses multidimensional structures to organize data
and express the relationships between data”. The structure is broken into cubes and the
cubes are able to store and access data within the confines of each cube. “Each cell within
a multidimensional structure contains aggregated data related to elements along each of its
dimensions”. Even when data is manipulated it remains easy to access and continues to
constitute a compact database format. The data still remains interrelated. Multidimensional
structure is quite popular for analytical databases that use online analytical processing
applications. Analytical databases use these databases because of their ability to deliver
answers to complex business queries swiftly. Data can be viewed from different angles,
which gives a broader perspective of a problem unlike other models.
Aggregations It has been claimed that for complex queries
OLAP cubes can produce an answer in around 0.1% of the time required for the same query
on OLTP relational data. The most important mechanism in OLAP which allows it to achieve
such performance is the use of aggregations. Aggregations are built from the fact table
by changing the granularity on specific dimensions and aggregating up data along these dimensions.
The number of possible aggregations is determined by every possible combination of dimension
granularities. The combination of all possible aggregations
and the base data contains the answers to every query which can be answered from the
data. Because usually there are many aggregations
that can be calculated, often only a predetermined number are fully calculated; the remainder
are solved on demand. The problem of deciding which aggregations to calculate is known as
the view selection problem. View selection can be constrained by the total size of the
selected set of aggregations, the time to update them from changes in the base data,
or both. The objective of view selection is typically to minimize the average time to
answer OLAP queries, although some studies also minimize the update time. View selection
is NP-Complete. Many approaches to the problem have been explored, including greedy algorithms,
randomized search, genetic algorithms and A* search algorithm.
Types OLAP systems have been traditionally categorized
using the following taxonomy. Multidimensional
MOLAP is a "multi-dimensional online analytical processing". 'MOLAP' is the 'classic' form
of OLAP and is sometimes referred to as just OLAP. MOLAP stores this data in an optimized
multi-dimensional array storage, rather than in a relational database. Therefore it requires
the pre-computation and storage of information in the cube - the operation known as processing.
MOLAP tools generally utilize a pre-calculated data set referred to as a data cube. The data
cube contains all the possible answers to a given range of questions. MOLAP tools have
a very fast response time and the ability to quickly write back data into the data set.
Advantages of MOLAP Fast query performance due to optimized storage,
multidimensional indexing and caching. Smaller on-disk size of data compared to data
stored in relational database due to compression techniques.
Automated computation of higher level aggregates of the data.
It is very compact for low dimension data sets.
Array models provide natural indexing. Effective data extraction achieved through
the pre-structuring of aggregated data. Disadvantages of MOLAP
Within some MOLAP Solutions the processing step can be quite lengthy, especially on large
data volumes. This is usually remedied by doing only incremental processing, i.e., processing
only the data which have changed instead of reprocessing the entire data set.
MOLAP tools traditionally have difficulty querying models with dimensions with very
high cardinality. Some MOLAP products have difficulty updating
and querying models with more than ten dimensions. This limit differs depending on the complexity
and cardinality of the dimensions in question. It also depends on the number of facts or
measures stored. Other MOLAP products can handle hundreds of dimensions.
Some MOLAP methodologies introduce data redundancy. Relational
ROLAP works directly with relational databases. The base data and the dimension tables are
stored as relational tables and new tables are created to hold the aggregated information.
It depends on a specialized schema design. This methodology relies on manipulating the
data stored in the relational database to give the appearance of traditional OLAP's
slicing and dicing functionality. In essence, each action of slicing and dicing is equivalent
to adding a "WHERE" clause in the SQL statement. ROLAP tools do not use pre-calculated data
cubes but instead pose the query to the standard relational database and its tables in order
to bring back the data required to answer the question. ROLAP tools feature the ability
to ask any question because the methodology does not limit to the contents of a cube.
ROLAP also has the ability to drill down to the lowest level of detail in the database.
Hybrid
There is no clear agreement across the industry as to what constitutes "Hybrid OLAP", except
that a database will divide data between relational and specialized storage. For example, for
some vendors, a HOLAP database will use relational tables to hold the larger quantities of detailed
data, and use specialized storage for at least some aspects of the smaller quantities of
more-aggregate or less-detailed data. HOLAP addresses the shortcomings of MOLAP and ROLAP
by combining the capabilities of both approaches. HOLAP tools can utilize both pre-calculated
cubes and relational data sources. Comparison
Each type has certain benefits, although there is disagreement about the specifics of the
benefits between providers. Some MOLAP implementations are prone to database
explosion, a phenomenon causing vast amounts of storage space to be used by MOLAP databases
when certain common conditions are met: high number of dimensions, pre-calculated results
and sparse multidimensional data. MOLAP generally delivers better performance
due to specialized indexing and storage optimizations. MOLAP also needs less storage space compared
to ROLAP because the specialized storage typically includes compression techniques.
ROLAP is generally more scalable. However, large volume pre-processing is difficult to
implement efficiently so it is frequently skipped. ROLAP query performance can therefore
suffer tremendously. Since ROLAP relies more on the database to
perform calculations, it has more limitations in the specialized functions it can use.
HOLAP encompasses a range of solutions that attempt to mix the best of ROLAP and MOLAP.
It can generally pre-process swiftly, scale well, and offer good function support.
Other types The following acronyms are also sometimes
used, although they are not as widespread as the ones above:
WOLAP - Web-based OLAP DOLAP - Desktop OLAP
RTOLAP - Real-Time OLAP APIs and query languages
Unlike relational databases, which had SQL as the standard query language, and widespread
APIs such as ODBC, JDBC and OLEDB, there was no such unification in the OLAP world for
a long time. The first real standard API was OLE DB for OLAP specification from Microsoft
which appeared in 1997 and introduced the MDX query language. Several OLAP vendors - both
server and client - adopted it. In 2001 Microsoft and Hyperion announced the XML for Analysis
specification, which was endorsed by most of the OLAP vendors. Since this also used
MDX as a query language, MDX became the de facto standard. Since September-2011 LINQ
can be used to query SSAS OLAP cubes from Microsoft .NET.
Products History
The first product that performed OLAP queries was Express, which was released in 1970. However,
the term did not appear until 1993 when it was coined by Edgar F. Codd, who has been
described as "the father of the relational database". Codd's paper resulted from a short
consulting assignment which Codd undertook for former Arbor Software, as a sort of marketing
coup. The company had released its own OLAP product, Essbase, a year earlier. As a result
Codd's "twelve laws of online analytical processing" were explicit in their reference to Essbase.
There was some ensuing controversy and when Computerworld learned that Codd was paid by
Arbor, it retracted the article. OLAP market experienced strong growth in late 90s with
dozens of commercial products going into market. In 1998, Microsoft released its first OLAP
Server - Microsoft Analysis Services, which drove wide adoption of OLAP technology and
moved it into mainstream. Product comparison
Market structure Below is a list of top OLAP vendors in 2006,
with figures in millions of US Dollars. See also
Data warehouse Online transaction processing
Business analytics Predictive analytics
Comparison of OLAP Servers Data Mining
Thomsen Diagrams Bibliography
Daniel Lemire. "Data Warehousing and OLAP-A Research-Oriented Bibliography".
Erik Thomsen.. OLAP Solutions: Building Multidimensional Information Systems, 2nd Edition. John Wiley
& Sons. ISBN 978-0-471-14931-6. Ling Liu and
Tamer M. Özsu. "Encyclopedia of Database Systems, 4100 p. 60 illus. ISBN 978-0-387-49616-0.
O’Brien, J. A., & Marakas, G. M.. Management information systems. Boston, MA: McGraw-Hill/Irwin.
References