Вы находитесь на странице: 1из 33

OLAP Option to the OracIe Database 11g

1he OLAP Option to Oracle

Database 11g

vrorivg Q a.ea v.ive.. vtettigevce 1oot. ritb
vrorea Perforvavce ava .vat,tic Covtevt

.v Oracte !bite Paer
]vt, 200

The OLAP Option to OracIe Database 11g Page 2

1he ollowing is intended to outline our general product direction. It is intended
or inormation purposes only, and may not be incorporated into any contract. It is
not a commitment to delier any material, code, or unctionality, and should not be
relied upon in making purchasing decisions. 1he deelopment, release, and timing
o any eatures or unctionality described or Oracle`s products remains at the sole
discretion o Oracle.
The OLAP Option to OracIe Database 11g Page 3

Introduction ....................................................................................................... 5
SQL and OLAP Query o Cubes.................................................................... 6
Blended Relational-Dimensional Model ........................................................
Beneits o Cubes ..............................................................................................
Query Perormance ...................................................................................... 8
Ad-loc s. Predictable Query Patterns................................................ 8
Optimized lor Summary Data............................................................... 9
last Incremental Update ........................................................................... 10
Lnhancing the Analytic Content o Business Intelligence Applications12
Leeraging the Dimension Model or Deining Calculations.......... 13
Summary o Calculations Aailable in the Cube ............................... 15
BI Meta Data in the Oracle Data Dictionary.......................................... 16
Querying the Cube Using SQL ..................................................................... 1
Cube-Organized Materialized Views and Query Rewrite ..................... 1
Oeriew ................................................................................................. 1
Query Lxample....................................................................................... 18
Managing Stale Data .............................................................................. 19
Cube Views .................................................................................................. 20
Oeriew ................................................................................................. 20
Query Lxamples ..................................................................................... 23
Designing and Managing Cubes.................................................................... 28
Analytic \orkspace Manager.................................................................... 29
Materialized View Reresh o the Cube................................................... 30
Other Beneits o an Lmbedded OLAP Solution...................................... 31
Conclusion........................................................................................................ 32
The OLAP Option to OracIe Database 11g Page 4
The OLAP Option to OracIe Database 11g Page 5
OLAP Option to the Oracle Database 11g

1he OLAP Option to Oracle Database 11g is a ull eatured on-line analytical
processing serer embedded within the Oracle Lnterprise Ldition Database. 1he
OLAP Option is used in the ollowing roles:
A summary management solution to SQL-based business intelligence tools
and applications.
A calculation engine that proides SQL-based business intelligence tools with
rich analytic content.
A ull-eatured multidimensional serer, sericing dimensionally oriented
business intelligence tools and applications.
1he OLAP Option to the Oracle Database Lnterprise Ldition is the only on-line
analytical processing ,OLAP, serer that is ully embedded in a relational database.
It is also the only OLAP serer that proides a ull-eatured SQL interace to
OLAP cubes and dimensions.
As an embedded solution, the OLAP Option runs within the Oracle Database
instance. 1here are no separate serers, users or database iles to manage. It
inherits the security and high aailability eatures that make Oracle an enterprise-
ready database. \ith a SQL interace to OLAP cubes, it allows any application that
can query a star schema to easily query OLAP cubes and beneit rom improed
query perormance and analytic content.
Cube-organized materialized iews, new to Oracle 11g, urther extend the role o
OLAP cubes to that o a summary management solution or SQL-based business
intelligence tools. Cube-organized materialized iews allow the database to
transparently rewrite queries written to detail relational tables to access summary
data within the OLAP cube or improed query perormance. Cube-organized
materialized iews are the same as table-based materialized iews in nearly all
respects, the major dierence is that the data are stored in a cube.
Cube-organized materialized iews also hae signiicant manageability beneits in
that they represent all possible summaries in a single object and are almost always
incrementally rereshable.
The OLAP Option to OracIe Database 11g Page 6
1o understand whether the OLAP Option can beneit your organization, ask the
ollowing questions:
Does your organization use business intelligence tools such as
BusinessObjects, Cognos ReportNet, MicroStrategy or Oracle Business
Intelligence Suite Lnterprise Ldition
\ould users o these applications beneit rom signiicantly improed query
\ould business users beneit rom rich analytic content being made aailable
within these applications
\ould business users beneit rom the ability to update data sets more
requently \ould the I1 organization beneit rom the ability to update the
data sets more eiciently
\ould the organization beneit rom the ability to manage data, metadata and
calculations centrally in the database and share these aluable assets among
any number o dierent tools and applications
I the answer to any o the aboe questions is \es`, the OLAP Option to the
Oracle Database has the potential to improe your business intelligence solutions
with improed perormance and rich analytic content.
1he architecture o the Oracle Database allows a single OLAP cube to play three
dierent roles simultaneously:
A summary management solution, transparent to your applications.
A supplier o rich analytic content to SQL-based business intelligence
applications, transparent to your applications.
A ull eatured multidimensional OLAP serer.
Oracle OLAP cubes, when cast as cvbe orgaviea vateriatiea rier., allow SQL based
applications to automatically access summary data managed within the cube using
query rewrite capabilities o the Oracle Database. \ith this usage o the cube,
Oracle aggregates and manages summary data within the cube and the application
continues to query the base relational tables using SQL. \hen a query requires
summary leel data, Oracle automatically rewrites the query to the cube. 1he SQL
based application is completely unaware o the existence o the cube, yet it beneits
rom the perormance o the cube.
SQL based business intelligence tools can query the cube directly using OLAP cvbe
rier., gaining both perormance improements and access to analytic content o the
cube. Cube iews are relational iews o the cube that present data as a relational
star schema. Unlike the typical star schema, OLAP cube iews proide detail and
aggregate leel data as well as interesting measures that are calculated dynamically
Because OracIe cubes can be queried with
SQL based appIications, your investment
in the cube can be Ieveraged by a wide
variety of business inteIIigence
appIications, even those that have no
awareness of the OLAP Option.
The OLAP Option to OracIe Database 11g Page 7
within the cube. In this usage, the SQL based application is mapped to relational
iews o the cube but is typically unaware o the cube itsel.
1he cube can also by queried by dimensionally aware applications using the Oracle
OLAP API. 1his style o application typically proides the end user with a query
experience that reeals the dimensional query and calculation model. It might
proide users with an experience that includes drill and piot, a dimensionally aware
query builder and the ability to deine custom measures ,acts,. 1his application is
designed or the OLAP Option and is ully aware o cubes.
One cube can serice each o these styles o query simultaneously, thereby
leeraging the inestment in the cube across many applications and many users or
maximum beneit.
1he OLAP Option, as an embedded eature o the Oracle Database, allows
applications to blend elements o the relational and dimensional model within a
single application.
1he calculation model o the cube is dimensional, which allows deelopers and
database administrators to embed dimensional and hierarchical calculations into the
Database. 1hese are easy to deine and eiciently executed at runtime.
Because Oracle oers a ull-eatured SQL interace to the cube, rom a query
perspectie cubes can simply be thought o as relational objects that happen to
oer improed perormance and a lot o analytic content. Dimensions can be
thought o as relational objects that happen to include columns with inormation
useul to creating hierarchical queries.
Using SQL, an application is ree to blend relational and dimensional concepts. An
application is also ree to join relational tables with cubes and dimensions. An
application might query the cube in a dimensional context with drill, piot,
hierarchical ilters and calculations, perorm attribute based reporting with SQL
aggregation unctions and drill to detail in a relational table.
1he cube is simply another data type in the database with special charactoristics. It
can be one part o an oerall model that includes relational tables and
multidimensional cubes. Application deelopers can choose the most appropriate
type o object depending on the requirements and seamlessly blend them within a
single model and query.
1his is all possible because cubes are ull-eatured dimensional objects that can be
queried using SQL and can be joined with relational objects.
Oracle OLAP cubes are data types within the Oracle Database that can enhance
your business intelligence applications with important beneits. 1his include:
Improed query perormance.
OnIy OracIe supports fuIIy transparent
SQL query of cubes and aIIows
appIications to bIend the dimensionaI
caIcuIation modeI with the reIationaI query
The OLAP Option to OracIe Database 11g Page 8
last, incremental update.
Rich analytic content.
Metadata that describes the logical business model and the relational
representations o the cube.
Any application, whether SQL or OLAP API based, has the potential to be
improed by taking adantage or one or more o these eatures.
Query Performance
1here are two signiicant and related challenges to achieing excellent query
perormance in a business intelligence application. lirst, almost eery query made
by the user o a business intelligence application requires summary data. Second,
users tend to want to explore data on their own by deining their own queries and
reports. 1his exploration results in unpredictable, or ad-hoc, query patterns.
Ad-Hoc vs. PredictabIe Query Patterns
\hen query patterns are predictable, it is relatiely easy to optimize query
perormance o an application by pre-calculating data that satisies particular
queries. I, or example, a BI dashboard contains twenty dierent queries it might
be reasonable to create summary tables or materialized iews to support each o
those queries and achiee excellent query perormance.
As query patterns become less predictable, pre-materialization or speciic queries
becomes impractical. Consider a data model that has ie dimensions ,perhaps
time, customer, product, distribution channel, supplier and shipping method,, each
o which hae six leels o summarization ,or example, in the time dimension, day,
week, month, quarter, hal year and year,. In this example, there are 15,624

possible unique leel combinations representing summary leel data that users
might query.
DBAs and BI application administrators oten try to sole this problem by
constraining the end user community to predeined queries that can be tuned by
pre-materializing a certain amount o summary data using summary tables or
materialized iews.
Constraining the users to predeined reports or queries reduces the scope o the
problem and allows the DBA to create speciic summary tables or materialized
iews that satisy those queries with good query perormance. 1his solution,
howeer, also reduces the users ability to ask their own questions and reduces the
eectieness and alue o the business intelligence application. Or, i users are
allowed to explore data using ad-hoc queries, they are exposed to query
perormance problems.

lie dimensions with six leels each, less one base leel or ,5
- 1,
A singIe OracIe cube can provide an
optimized summary management soIution
for ad-hoc query patterns. Cubes offer
exceIIent query performance and are easiIy
managed as a materiaIized view.
The OLAP Option to OracIe Database 11g Page 9
Instead, the DBA might choose to create a collection o summary tables or
materialized iews that sere as a general-purpose summary management solution.
1his will typically be a collection o tables or materialized iews with data at certain
leel combinations. 1he hope is that queries will either select directly rom those
leel combinations or that a summary table or materialized iew is close enough to
the query to proide good perormance with runtime summarization. 1he
eectieness o this solution depends on how many summary tables are created
and the query patterns. 1his solution oten proides inconsistent perormance.
Queries that select directly rom or are ery close to summary tables will perorm
well. Queries that are not well sericed by summary tables might perorm poorly.
Proiding excellent query perormance throughout the entire data model can be
extremely diicult because it would likely require ery large numbers o summary
tables or materialized iews. Again, consider the example with 15,624 possible leel
combinations. Creating een ie percent o the possible leel combination ,which
would result in hundreds o summary tables or materialized iews, would likely be
only a partial solution or query perormance and would create signiicant oerhead
in the management o the data set.
Optimized For Summary Data
Oracle cubes are designed to handle just this situation, a business model that might
be queried by end users with unpredictable query patterns that exposes the entire
business model to query at any gien moment.
A single OLAP cube represents all leels o summarization within a single object in
the Oracle Database. Cubes are highly optimized or hierarchical aggregations and
the management o summary data. lurthermore, OLAP cubes are highly
optimized or the random cell ,or row, rom a SQL point o iew, access that is
typical o ad-hoc query patterns.
1he OLAP option applies unique and patented methods or the aggregation
and storage o summary leel data. 1hese methods are highly optimized or
the ery sparse data sets that are common to business intelligence
applications. 1hese methods include compressed cube and cost-based
aggregation technologies, both o which are unique to cubes.
Reerences to the cells o a act ,measure, use oset addressing and
specialized indexing methods in which dimensions act as indices to the data.
Array-based storage eliminates the redundant storage o keys and compacts
the data.
Measure data is pre-joined to dimensions, allowing cubes to be extremely
eicient when applying ilters to the data and when resoling outer joins ,as
are required or many time series calculations,.
1he cube organized materialized iew represents all possible summaries in a
single object. 1his allows the SQL optimizer to quickly choose the object
that is the best candidate or query write.
OracIe cubes are made up of
muItidimensionaI data types that are highIy
optimized for aggregation, ah-hoc queries
and runtime caIcuIations.
The OLAP Option to OracIe Database 11g Page 10
SQL-based business intelligence applications can take adantage o the cube`s query
perormance by either substituting cube-based materialized iews or the current
summary management strategy or by querying OLAP cube iews directly.
1he ollowing chart can be used to help understand the relatie query perormance
o summary tables or table-organized materialized iews and cubes. In general,
both data types ,tables and cubes, are appropriate or applications that eature
predeined reports or relatiely little ad-hoc query. As the queries become more ad-
hoc, the cube oers improed query perormance.
Slower Query
Iaster Query
Query Performance
Ad-Hoc Nature of Application and Query Patterns
Less Ad-Hoc
Predictable Queries
Simple Calculations
More Ad-Hoc
Unpredictable Query Patterns
Sophisticated Calculations

Fast IncrementaI Update
Query perormance is only part o the perormance equation - any summary
management solution should be easy to manage and oer perormance adantages
or periodic updates o the data set.
Oracle OLAP cubes are highly optimized or ast, incremental update. Because all
summaries are managed in a single object, cubes are more easily managed as
compared to a large number o summary tables or materialized iews.
Cubes are aggregated and stored using patented algorithms that take
adantage o sparsity characteristics typical to hierarchical aggregations.
Aggregation within the cube is almost always incremental. 1he cube
recognizes changes to base leel data and only re-aggregates summary leel
data when base leel data has changed.
The OLAP Option to OracIe Database 11g Page 11
1he cube is a single object within the database. Detail tables that are the
source to the cube are only scanned. All aggregations are deried rom that
single scan o the source table.
Beginning with Oracle Database 11g, the cube can be updated using the
Oracle materialized iew reresh system. 1he cube can process changes to
source tables rom materialized iew log tables, eliminating the need to scan
the source tables. Inserts, updates and deletes are incrementally processed
rom the materialized iew log tables.
It should be understood that cubes typically calculate most summary leel data at
runtime in response to queries, rarely are cubes ully materialized by pre-calculating
all summary data. In most cases, only a relatiely small amount o data is pre-
aggregated during the update o the cube.
1he cube has some distinct adantages when it comes to runtime aggregation o
data. 1wo o the most important adantages are a ine-grained approach to pre-
aggregating summary data and the pre-joining o dimensions to cubes.
Cost based aggregation, new to Oracle Database 11g, utilizes a ery ine-grained
approach to pre-aggregation o data. Rather than pre-aggregating data using a ery
course strategy such as choosing leel combinations, cost based aggregation
determines which cells ,or rows, in SQL terms, are expensie to calculate
dynamically and stores only those cells. 1his determination is made, in part, by
examining the data and understanding how many child cells are needed to produce
the aggregate or a parent cell. 1he cost threshold can be inluenced by the DBA.
1he cost based aggregation strategy results in a ery ine mesh` o pre-aggregated
cells and more consistent perormance throughout the entire cube.
As part o the array based implementation o the cube, dimension and cube are pre-
joined. As a result, join processing is completely eliminated rom the process o
producing aggregate data within the cube.
Because somewhat more work is done up ront in the process o maintaining cubes
- or example compiling dimensions, enorcing reerential integrity and
automatically indexing data - it can be expected that the cube will hae a longer
minimum data preparation time as compared with simply inserting data into a
relational table. Once indexing tables and the creation o summary tables or
materialized iews is taken in account, cubes begin to hae an adantage o shorter
oerall data preparation times.
\hether the cube or summary tables are aailable or query more quickly depends
on the query load and required query perormance. Once again, consider the
dierence between predictable and ad-hoc query patterns. I the query patterns are
ery predictable, only a ew summary tables or materialized iews might be
required. Building those tables might be aster than building the cube.
As the query patterns become more unpredictable, the cube has the adantage
because it tends to become ully optimized or query relatiely quickly due to the
Cost-based aggregation adds to
compressed cube technoIogy to
significantIy enhance the performance,
scaIabiIity and manageabiIity of cubes in
the database.
The OLAP Option to OracIe Database 11g Page 12
highly eicient aggregation algorithms ,again, compressed cubes and cost based
aggregation,. Pre-aggregating a relatiely small amount o data using cost based
aggregation tends to optmize the cube or query quickly. In the case o summary
tables or materialized iews, more and more tables need to be created to improe
query perormance as the query load becomes more ad-hoc. 1his relationship is
shown in the ollowing graph.
More 1ime
Less 1ime
1ime 1o Prepare Data for Query
Ad-Hoc Nature of Application and Query Patterns
Less Ad-Hoc
Predictable Queries
Simple Calculations
More Ad-Hoc
Unpredictable Query Patterns
Sophisticated Calculations

Gien that the cube is well suited to sericing both predictable and unpredictable
query loads, organizations should consider the cube and cube organized
materialized iews as the summarization strategy or any dimensional data set.
Enhancing the AnaIytic Content of Business InteIIigence AppIications
1he perormance characteristics o the cube alone should be enough to cause
organizations to consider adding cubes to their data warehouse or data mart.
Perormance is, howeer, only one o the beneits o the cube. Another beneit is
the ability to dramatically improe the analytic content o business intelligence
A wide ariety o analytic calculations can be deined within the cube. 1his include
hierarchical aggregation, calculated measures, allocations, statistical orecasts and
systems o interrelated equations
1he cube is automatically represented in the database as a star schema. 1here are
relational iews or each o the cube`s dimensions - and a single iew to represent
The OLAP Option to OracIe Database 11g Page 13
the cube`s measures. 1he cube`s analytic calculations are simply exposed as
relational columns in the cube iew. lor example, there may be a column or sales
reenue, sales year to date, inentory balance and inentory cost. Although the
column may return a complex calculation ,e.g. sales year to date, or require an
adanced aggregation method ,e.g. inentory balance, - the query tool does not
need to understand the calculation complexity. 1he tool issues simple SQL and the
cube perorms the calculation automatically.

.v aticatiov bvitt v.ivg Oracte .ticatiov re.., rbicb ba. vo .ecific /vorteage of
bv.ive.. ivtettigevce or cvbe., i. av eavte of av aticatiov tbat cav qver, avat,tic covtevt .vcb
a. ,ear to aate catcvtatiov. vavagea iv tbe cvbe.
Leveraging the Dimension ModeI for Defining CaIcuIations
1he cube uses the dimensional model to simpliy the deinition o calculations. lor
example, measure calculations can be deined using syntax that is aware o
hierarchical relationships such as parentage, children, ancestors and descendants.
Although the syntax used to deine measure calculations is dimensionally aware,
OLAP unctions are based on SQL grammar and will be amiliar to deelopers and
DBAs who are experienced with SQL analytic unctions such as LAG and RANK.
One signiicant beneit o calculation unctions that are hierarchically aware is that a
single expression works anywhere within the cube. \ith traditional SQL based
applications the expression may change based on what columns are being queried.
Because caIcuIations are embedded into
the cube, any SQL-based appIication even
those that have no caIcuIation or business
inteIIigence functionaIity, can query the
cube and deIiver rich business inteIIigence
The OLAP Option to OracIe Database 11g Page 14
lor example, consider the LAG unction. I a product dimension has the leels
1otal, Manuacturer, Brand, Item and SKU and an application needs to rank
products within parents, it would need to deine one expression or each leel. lor
-- Rank brands with Total
-- Rank items within Brand
-- Rank SKUs within Items
\hile some o the more sophisticated query tools can sole this problem by
deining hierarchies and calculations in the middle tier, many applications cannot.
In these cases, the end user must deine the expression or each leel o
summarization. 1his can be a signiicant burden, particularly in applications that
need to drill up or down within the data.
\ith the cube, a single expression can be used to deine hierarchical calculations
that work anywhere within the model. 1he ollowing rank expression will rank
products within their parents anywhere within the hierarchy and can replace the
three dierent SQL rank unctions aboe.
-- Rank within parent
Note that the OLAP expression is similar to the SQL expression, but a hierarchy
and the PARLN1 keyword replace the partition by column. Because the OLAP
expression describes a relatie relationship rather than a hard coded one, it works at
any leel o summarization. 1his same pattern can be seen in another example, this
one based on a period-to-date time series calculation:
-- SQL expression
SUM(f.sales) OVER(PARTITION BY t.calendar_year ORDER BY
t.end_date RANGE BETWEEN unbounded preceding AND current row)
-- OLAP expression
SUM(units_cube.sales) OVER HIERARCHY (time.calendar BETWEEN
unbounded preceding AND current member WITHIN ancestor at level
AppIication deveIopers who are famiIiar
with SQL anaIytic functions wiII quickIy
recognize that OLAP cube expressions
foIIow simiIar syntax and are very easy to
The OLAP Option to OracIe Database 11g Page 15
Like the preious example, OVLR lILRARCl\ replaces OVLR and elements o
the hierarchy replace column names.
Similar unctions are aailable or common calculations such as shares, prior,uture
periods, period to date, period rom date, moing aggregates and cumulatie
aggregates. \ith each type o calculations, ariations are aailable or calculations
relatie to parents, ancestors at particular leels and within leels.
1ime series calculations are urther simpliied because the cube automatically
executes a partitioned outer join to densiy the data. 1his ensures that the
calculation always returns the correct results or prior and uture period
calculations, een when the alue o the prior or uture period is null. Because
dimensions and cubes are automatically joined, this operation is ery eicient in the
OLAP unctions can be combined or nested to design new unctions. Also, most
SQL single row unctions ,e.g., DLCODL and ROUND unctions, can be used
within OLAP calculations that are embedded in the cube. As a result, ery
powerul user deined calculations can be deined within the cube.
As mentioned earlier, all measure calculations reeal themseles in the SQL cube
iew as a column. Applications simply select rom the column in the SQL cube
iew to access the results o a calculation.
Summary of CaIcuIations AvaiIabIe in the Cube
1he dierent types o calculations that are aailable in the cube can be described as
itting into one o the ollowing categories: hierarchal aggregations, measure
calculations, allocations, statistical orecasts and model. Lach o these are
described in the ollowing sections.
Hierarchical Aggregations
lierarchical aggregations are calculations that aggregate data rom lower leel
members in a hierarchy to higher-leel members. 1he OLAP Option supports a
wide ariety o aggregation methods including sum, hierarchical weighted aerages
and scaled sums. Aggregation methods can ary by dimension. lor example, the
aggregation o a leadcount measure might be a sum oer an Organization
dimension and an aerage rom days, to months, quarters and years o a 1ime
Calculated Measures
A calculated measure is a measure that exists in the cube as a ormula that is
calculated dynamically during query. Lxamples include time series calculations,
market shares and indices, ariance and rankings. 1he cube can process measure
calculations extremely eiciently, een when they require inter-row calculations,
outer joins and joins between dierent cubes.
Calculated measures are added to the SQL cube iew as an additional act column.
The OLAP Option to OracIe Database 11g Page 16
Allocations distribute data rom high-leel members within a hierarchy to lower
leel members. lor example, a corporate budgeting system might use the allocation
system to distribute budgets or the next iscal year rom diisions to product
groups, and inally to indiidual products.
1he OLAP Option supports a wide ariety o methods including copy methods
,hierarchical copy, minimum, maximum, irst, last,, een distribution methods
,een, hierarchical een, and proportional ,including weighted distributions,.
1he results o an allocation are stored in the cube and are queried as a act column
in a SQL cube iew.
Statistical Forecasting
OLAP Option proides a complete statistical orecasting system. lorecasting
methods include non-linear regression, single exponential smoothing, double
exponential smoothing and lolt,\inters. 1he orecasting system also supports
eatures such as seasonality o data.
1he results o a orecast are stored in the cube and are queried as a act column in a
SQL cube iew.
OLAP models calculate the alue o indiidual dimension members, each according
to their own unique calculation rules. 1he OLAP Option automatically orders the
calculations and supports simultaneous equations. Models are oten used in
inancial applications, particularly or deining calculations within non-hierarchical
dimensions such as a chart o accounts.
BI Meta Data in the OracIe Data Dictionary
1he cube represents seeral import assets o an enterprise business intelligence
platorm: data, the logical business model, calculation rules and a physical
representation o the business model. Lach o these elements is described in the
Oracle data dictionary. Business intelligence applications can query the data
dictionary to discoer any aspect o the cube and automatically populate their own
metadata repositories with the inormation needed to query SQL cube iews.
Generally speaking, OLAP metadata can be grouped into one o two categories:
Inormation about the cube`s structure, data and how it is calculated.
Inormation about how the cube is represented or query using SQL cube
The OLAP Option to OracIe Database 11g Page 17
1he data dictionary iews that describe the cubes structure allow applications to
ind cubes dimensions, hierarchies, leels, attributes and measures. In the case o
cubes and measures, the dictionary iews describe how the cube is calculated and
the calculation expression o a measure. Applications can use this inormation to
understand the logical model o the cube.
1he data dictionary iews that describe how the cube is exposed thru SQL describe
the cube, dimension and hierarchy iews with inormation such as iew names,
column names and their roles. Applications can use this inormation to map their
applications to the SQL cube iews.
OLAP data dictionary iews are easily ound by looking or the preix XXX_CUBL
,or example USLR_CUBL, ALL_CUBL and DBA_CUBL,.
SQL is the most commonly used query language within business intelligence and
query and reporting applications. 1his is not surprising gien that the ast majority
o data is managed in relational databases. 1he OLAP Option embraces SQL
based applications and allows them to query the cube using standard SQL. 1he
application can access any data in the cube - detailed, summary, stored and
calculated - with simple SQL and without any understanding o how data within
the cube is calculated.
An application typically alls into one o two categories:
Applications that seek only a perormance improement rom the cube.
1hese applications can use cube-organized materialized iews to access
summary data in the cube.
Applications that seek the perormance and analytic content o the cube.
1hese applications can query cube iews to gain perormance and access any
content within the cube.
Cube-Organized MateriaIized Views and Query Rewrite
Cube-organized materialized iews allow any application to transparently access
summary data managed by the cube or an immediate query perormance
Cube-organized materialized iews, introduced in Oracle Database 11g, play the
same role as table-based materialized iews. 1hat is, a summary management
solution that is transparent to the querying application. Like table-based
materialized iews, the application queries the detail tables and the database
automatically rewrites the query to access summary data in the materialized iew.
Any appIication can query the OracIe data
dictionary to discover both the business
modeI of the cube and the reIationaI
representation of the modeI.
Cube-organized materiaIized views have
the potentiaI to revoIutionize how
summary data is managed in the database.
They are very efficient, transparent to
appIications and have the potentiaI to
repIace thousands of tabIe based
materiaIized views with a singIe cube.
The OLAP Option to OracIe Database 11g Page 18
In the case o cube-organized materialized iews, the data is managed in the cube
rather than a table. As such, the cube-organized materialized iew automatically
inherits all o the query and reresh perormance beneits o the cube, including:
Compressed cube aggregation technology.
Cost-based aggregation.
Management o all possible summaries in a single database object.
Array based storage and ast cell ,row, access.
last, incremental reresh and aggregation.
A cube-organized materialized iew is similar to a materialized iew on pre-built
table in that it is a metadata only object. 1he data is managed and stored in the
cube, the materialized iew contains only the metadata that is needed by the
database or query write and reresh o the cube ia the materialized iew reresh
system. Data is not replicated rom the cube to the cube-organized materialized
1here is a single materialized iew that represents all summary data in the cube.
1his single cube-based object, rather than the tens, hundreds or een thousands o
table based materialized iews that might by used as a summary management
solution, improes the eiciency o the query rewrite eature by dramatically
reducing the number o materialized iews that the optimizer needs to consider
beore completing the execution o the query ,in addition to the other adantages
o the cube,.
Because the cube-organized materialized iew represents all possible summaries,
the rate at which the database rewrites queries to the materialized iew is typically
ery high. 1esting with leading business intelligence tools has shown this to be the
Cube-organized materialized iews can be recognized by their CB> name preix.
lor example, the materialized iew representing a cube named UNI1S_CUBL will
be named CB>UNI1S_CUBL. 1he DBA adds the cube-organized materialized
iew to the cube ia the OLAP administration tool or the OLAP API. 1he
database then automatically maintains the deinition o the materialized iew.
Cube organized materialized iews are completely transparent to the querying
application and the processes o managing and rereshing the source tables. 1he
application continues to query relational tables. 1he process o managing the tables
is unchanged by the cube.
Query ExampIe
1he ollowing example illustrates how cube-organized materialized iews allow
applications to transparently access summary data in a cube.
In this example, assume that there are ie tables: 1IML_DIM, PRODUC1_DIM,
CUS1OMLR_DIM, ClANNLL_DIM and UNI1S_lAC1. 1he _DIM tables are
The OLAP Option to OracIe Database 11g Page 19
dimension tables. 1he UNI1S_lAC1 table is a act table. 1ogether, this
collection o tables comprises a star schema.
A cube has been created that mirrors the dimensions, hierarchies and act data o
these tables and the DBA has turned on cube-organized materialized iews. 1he
cube-organized materialized iew is named CB>UNI1S_CUBL.
1he application is unaware o the cube or the materialized iew. It simply queries
the tables, as it would hae beore the cube was created, with a query such as:
SELECT t.calendar_year_id time,
p.class_id product,
c.region_id region,
SUM(f.sales) sales
FROM time_dim t,
product_dim p,
customer_dim c,
units_fact f
WHERE t.month_id = f.month_id
AND p.item_id = f.item_id
AND c.ship_to_id = f.ship_to_id
GROUP BY t.calendar_year_id,
1he Oracle optimizer recognizes that the cube contains the summary data
requested in this query and rewrites the query to the cube-organized materialized
iew. 1he resulting SQL execution plan ollows.
1he CUBL SCAN operation indicates that data is being returned by the cube row
source. CB>UNI1S_CUBL is the cube-organized materialized iew.
Managing StaIe Data
Like table based materialized iews, the database understands when changes hae
been made to source tables and that the cube is no longer a current representation
o the tables. \hen a cube is a current representation o the source data it is said
to be fre.b. \hen it is not, the materialized iew is said to be .tate. 1he materialized
iew system allows the database administrator to allow or preent rewrite to stale
materialized iews. In this regard, table and cube-organized materialized iews are
The OLAP Option to OracIe Database 11g Page 20
Cube Views
Oracle OLAP cube iews proide organizations with the ability to both improe
the perormance and analytic content o SQL based business intelligence
applications. OLAP cube iews are relational iews o OLAP cubes, dimensions
and hierarchies that reeal the ull content o cubes and dimensions.
Cube iews allow applications to query stored acts and analytic content such as
calculated measures that are embedded in the cube. Dimension and hierarchy
iews allow applications to query or dimension members and attributes o the
members. In an OLAP dimension, attributes can include hierarchical attributes
such as leels, parentage and ancestors that can be used to add elements o the
dimensional query model to SQL based applications.
Lach cube, dimension and hierarchy within a dimension is always represented to
SQL-based application as a relational iew. 1here are three types o iews:
Cube iews.
Dimension iews.
lierarchy iews.
1hese iews are automatically created and managed by the database. Application
deelopers and DBAs are welcome to create additional iews rom the system
maintained cube iews.
1he collection o iews that represent the cube, dimensions and hierarchies are
structured in the orm o a star schema.
Cube Views
Cube iews represent the act data o the cube. 1he cube iew includes columns
or each key ,representing each dimension, and each act. An innoatie eature o
the cube iew is that it represents all data in the cube: stored measures, calculated
measures, detail data and summary leel data. 1his means that the application does
not need to understand how a act is aggregated or calculated in order to query it
with SQL. 1his allows the cube iew to sere as both a summary management
solution and as a calculation rich data source.
A typical cube iew might include the ollowing columns:
Cube views present the entire cube
incIuding summaries, caIcuIations and
dimensionaI attributes to any SQL based
The OLAP Option to OracIe Database 11g Page 21
Name Type
------------------------------ -------------

Note - 1he roles and descriptions o cube iew columns are aailable in the
xxx_CUBL_VIL\_COLUMNS data dictionary iew.
Dimension Views
Dimension and hierarchy iews both represent data in dimensions. Lach style iew
presents the dimensions somewhat dierently and an application may use either, or
both, style iews depending on the needs to the application.
Dimension iews represent all dimension members - detail and summary, rom all
hierarchies - in a single iew. 1he rows include both detail and summary members.
1here is a single key column. Additional columns contain attributes o the
dimension member in the key column.
A typical dimension iew might hae the ollowing columns:
Name Type
------------------------------ -------------

The OLAP Option to OracIe Database 11g Page 22
1he DIM_KL\ column is the primary key o the iew and contains dimension
members ,again, both detail and summary leel members,.
1he LLVLL_NAML column contains the leel o the member. In this example,
1O1AL leels,. 1he LLVLL_NAML column allows applications to easily indicate
what leel o summarization the query requires.
1he SlOR1_DLSCRIP1ION and LONG_DLSCRIP1ION columns contain
descriptie names o the dimension members.
1he _ID columns contain the summary leel members o the DIM_KL\ column.
1hese are useul or inding the ancestor or descendants o a dimension member.
Note - 1he roles and descriptions o dimension iew columns are aailable in the
xxx_DIMLNSION_VIL\_COLUMNS data dictionary iew.
Hierarchy Views
1here will be one hierarchy iew or each hierarchy o a dimension. lierarchy
iews are the same as dimension iews, with three exceptions:
lierarchy iews only contain rows or members that belong to that hierarchy.
lierarchy iews include a PARLN1 column that returns the parent o the
dimension member ,in the DIM_KL\ column,.
lierarchy iews include two columns representing each leel, one or the
original key and another or the surrogate key that might hae been generated
in the dimension as part o the process o loading data rom the dimension
table to the OLAP dimension.

1he hierarchy iews are particularly useul or queries that drill up or down within a
hierarchy and that join the cube to source tables.

Surrogate keys can be generated in the OLAP dimension or cases where dimension
members are not unique across leels in the source tables.
The OLAP Option to OracIe Database 11g Page 23
A typical hierarchy iew might contain the ollowing columns:
Name Type
------------------------------ -------------

Note - 1he roles and descriptions o dimension iew columns are aailable in the
xxx_lILRARCl\_VIL\_COLUMNS data dictionary iew.
Query ExampIes
1he ollowing query examples continue on the preious example where there are
our dimensions ,1ime, Product, Customer and Channel, and a cube ,Units Cube,.
1he 1ime dimension has two hierarchies, Calendar and liscal. 1he Customer
dimension has two hierarchies, Shipments and Segment. Both the Product and
Channel dimensions hae a single hierarchy, both named Primary. 1his model will
result in eleen iews:
The OLAP Option to OracIe Database 11g Page 24
1he ollowing query is the equialent to the example used in the materialized iew
SELECT t.time_calendar_quarter_id time,
p.product_class_id product,
cu.customer_region_id customer,
f.sales sales
FROM time_view t,
product_view p,
customer_view cu,
channel_view ch,
units_cube_view f
WHERE t.dim_key = f.time
AND p.dim_key = f.product
AND cu.dim_key = f.customer
AND ch.dim_key = f.channel
AND t.level_name = 'CALENDAR_QUARTER'
AND p.level_name = 'CLASS'
AND cu.level_name = 'REGION'
AND ch.level_name = 'TOTAL';

1his query ollows the style o a star query, but diers rom the materialized iew
example in the ollowing ways:
It does not require an aggregation operator in the act column SALLS.
It does not require a GROUP B\ clause because an aggregation operator is
not used.
It includes ilters on the LLVLL_NAML columns.
It includes a join between the ClANNLL_VIL\ iew and the
Lach o these changes is made possible by the innoatie cube iew that includes
both detail and summary leel data. Because the iew includes summary leel data,
the application can query it directly. 1his allows or the elimination o both the
aggregation operator and the GROUP B\. 1he leel ilters are used to indicate
desired leel o summarization.
1he join between ClANNLL_VIL\ and the
UNI1S_lAC1_VIL\ is used so that the query utilizes the 1O1AL alue o the
channel dimension, which is the equialent o aggregating across all detail rows o
1he undamental principle illustrated by this example is that the query can utilize
the aggregations that are proided by the cube. 1here is no need to re-aggregate

Note that the inclusion o SUM and GROUP B\ would not change the results o this
query because it already returns summary data. Lach row is unique and the GROUP
B\ has no practical eect in this example.
The OLAP Option to OracIe Database 11g Page 25
the data within the query. Complex aggregations and other calculations simply
made aailable by the cube, allowing ery simple SQL to be used to query the cube.
1his simple SQL can signiicantly improe deeloper productiity
1he alue o presenting both detail and summary leel data in the cube iew is seen
when querying certain types o data that is calculated within the cube. 1he most
common cases are when the cube:
Calculates summary data using an aggregation operator unique to the cube.
lor example, a hierarchical weighted aerage.
Aggregation operators dier across hierarchies. lor example, aggregating a
leadcount measure using SUM oer Organization and LAS1 oer 1ime.
Calculates certain types measures that cannot be aggregated. lor example,
ranking and percent change measures cannot be aggregated rom one leel to
another. 1hey must be calculated at the desired leel ater data are
\hat is common to these types o calculations is that they cannot be simply
aggregated using SUM ,or another aggregation unction, and GROUP B\. 1hey
can be easily deined and executed within the cube, but they should not be
aggregated in SQL.
Consider the ollowing example that selects sales, sales year to date and sales
percent change year to date rom the year ago:
SELECT t.time_calendar_quarter_id time,
f.sales sales,
f.sales_ytd sales_ytd,
ROUND(f.sales_pctdiff_ytd_yr_ago,1) pct_chg_ytd
FROM time_view t,
product_view p,
customer_view cu,
channel_view ch,
units_cube_view f
WHERE t.dim_key = f.time
AND p.dim_key = f.product
AND cu.dim_key = f.customer
AND ch.dim_key = f.channel
AND t.level_name = 'CALENDAR_QUARTER'
AND p.level_name = 'TOTAL'
AND cu.level_name = 'TOTAL'
AND ch.level_name = 'TOTAL'
and t.time_calendar_year_id in ('CY2005','CY2006')
ORDER BY time;

The cube automaticaIIy resoIves issues
reIated to the order in which caIcuIation
must be resoIved. AppIications simpIy
query the resuIts.
The OLAP Option to OracIe Database 11g Page 26
--------- ------------- -------------- -----------
CY2005.Q1 31381338.07 31381338.07 -4.8
CY2005.Q2 37642741.22 69024079.29 0.4
CY2005.Q3 32617248.57 101641327.86 -0.6
CY2005.Q4 35345244.10 136986571.96 -5.1
CY2006.Q1 36154818.61 36154818.61 15.2
CY2006.Q2 36815657.09 72970475.70 5.7
CY2006.Q3 32318934.94 105289410.64 3.6
CY2006.Q4 34848910.74 140138321.38 2.3

In this example, PC1_ClG_\1D or Quarter leel cannot be calculated by
aggregating the PC1_ClG_\1D rom Month leel data. 1his measure needs to
be calculated ater data are aggregated to Quarter. A single unction in the cube to
calculate PC1_ClG_\1D can replace ery complex SQL ,including a partitioned
outer join, and the application can simply select the measure at the desired leel o
As inal query examples, consider a drill down and drill up ,collapse, style queries.
Gien that the cube`s natie storage or hierarchies is parent and that this parent-
child relationship is reealed in the hierarchy iews, drill down and drills up queries
are both easy and eicient.
1he ollowing query illustrates drilling down to the quarters within a year. Note
that in this example the query returns measure data or both the year that was
drilled on and it`s children. 1his is ery easy when querying a cube iew.
ChiId-parent (vaIue based) hierarchies are
compIeteIy naturaI with the cube, making
driIIing and ancestor/descent-based query
simpIe and efficient.
The OLAP Option to OracIe Database 11g Page 27
SELECT t.dim_key time,
f.sales sales,
f.sales_ytd sales_ytd,
ROUND(f.sales_pctdiff_ytd_yr_ago, 1) pct_chg_ytd
FROM time_calendar_view t,
product_view p,
customer_view cu,
channel_view ch,
units_cube_view f
WHERE t.dim_key = f.time
AND p.dim_key = f.product
AND cu.dim_key = f.customer
AND ch.dim_key = f.channel
AND p.level_name = 'TOTAL'
AND cu.level_name = 'TOTAL'
AND ch.level_name = 'TOTAL'
AND(t.dim_key = 'CY2006' OR t.parent = 'CY2006')
ORDER BY time;

----------- -------------- ------------- -----------
CY2006 140138478.38 140138478.38 2.3
CY2006.Q1 36154975.61 36154975.61 15.2
CY2006.Q2 36815657.09 72970632.70 5.7
CY2006.Q3 32318934.94 105289567.64 3.6
CY2006.Q4 34848910.74 140138478.38 2.3

1his query simply selects the members that hae a particular parent. Since the
hierarchy iew has members or all leels as rows, this query works or children o
any member. ,Note that a leel ilter is not required in this query.,
The OLAP Option to OracIe Database 11g Page 28
A similar query can be used to ind the parent o a member.
SELECT t.dim_key time,
f.sales sales,
f.sales_ytd sales_ytd,
ROUND(f.sales_pctdiff_ytd_yr_ago,1) pct_chg_ytd
FROM time_calendar_view t,
product_view p,
customer_view cu,
channel_view ch,
units_cube_view f
WHERE t.dim_key = f.time
AND p.dim_key = f.product
AND cu.dim_key = f.customer
AND ch.dim_key = f.channel
AND p.level_name = 'TOTAL'
AND cu.level_name = 'TOTAL'
AND ch.level_name = 'TOTAL'
AND t.dim_key = (SELECT DISTINCT parent
FROM time_calendar_view
WHERE dim_key ='CY2006.Q2')
ORDER BY time;

1hrough these examples, it can be seen how SQL based applications can use
columns with hierarchical attributes to easily query cube iews in the style o an
interactie OLAP application.
At this point, it should be clear that the cube proides signiicant perormance and
analytic content beneits to SQL based business intelligence applications. Although
cubes might seem exotic to someone who is accustomed to relational data types
and data warehousing, they are not diicult to create and maintain.
1here are two phases to the creation o a cube-based solution. lirst, there is the
process o designing the cube. 1he design process will be drien by reporting and
analysis requirements and is usually implemented using the OLAP administration
tool, Analytic \orkspace Manager. Second, there is the periodic reresh o the
cube with new data. 1his can be drien rom Analytic \orkspace Manager and,
new to Oracle Database 11g, the materialized iew reresh system.
The OLAP Option to OracIe Database 11g Page 29
AnaIytic Workspace Manager
Analytic \orkspace Manager is designed to allow the Oracle application deeloper,
database administrator or tech say line o business worker create and manage a
cube. Using Analytic \orkspace Manager, the user works interactiely and directly
with the dimensional model and cube. 1his is typically the case during prototyping
and application deelopment. 1he design ocus o Analytic \orkspace Manager is
ease o use, modeling, and the deinition o aggregations and other calculations.
Analytic \orkspace Manager allows the user to:
Deine the logical dimensional model ,dimensions, hierarchies and cubes,.
Map the model to relational data sources ,star, snowlake and other style
Deine aggregations and measure calculations.
Perorm periodic maintenance such as data loading and re-aggregation.
Support a collaboratie administratie process by allowing models, or parts o
models, to be shared with other users or applications ia templates.
1he typical process o creating a cube is as ollows:
Based on the reporting requirements o the user community, design the logical
dimensional model ,dimensions, hierarchies, cubes, base measures,. 1he
model can be updated at a later time as needed.
\here appropriate, map the logical model to sources in Oracle Database.
1hese sources might be tables, iews, lat iles as external tables or other
relational objects.
Build the analytic workspace or the irst time. 1his inoles loading data and,
i desired, aggregating some data as a perormance optimization.
Deine new measure calculations as needed.
Reiew the design in the context o the BI tool or application that will be used
to query the data.
Reise as needed.
Analytic \orkspace Manager supports this process rom beginning to end in a
single, dimensionally aware design enironment.
Cubes are easy to design using AnaIytic
Workspace Manager and even easier to
maintain using the materiaIized view
refresh system. The DBA responsibIe for
day-to-day administration of the data set
might not even have to know that
materiaIized view access data from a cube.
The OLAP Option to OracIe Database 11g Page 30

vabtivg tbe cvbeorgaviea vateriatiea rier for a cvbe v.ivg .vat,tic !or/.ace Mavager.
MateriaIized View Refresh of the Cube
Once the cube is designed, the primary ongoing cube management task is the
periodic update o data. 1his task can be accomplished using Analytic \orkspace
Manager or the materialized iew reresh system. It is likely that organizations will
choose to use the materialized iew reresh system in production enironments
because it is easily scripted and improes perormance o incremental rereshes.
1he materialized iew reresh system allows DBAs to reresh a cube-organized
materialized iew in the same way as a table based materialized iew, by calling the
DBMS_MVIL\.RLlRLSl program. DBMS_MVIL\.RLlRLSl takes the name o a
materialized iew as the primary argument. 1he database administrator does not
need to know that the materialized iew is cube-organized or een know that a
cube exists - they only know the object as a materialized iew. 1his makes cubes
completely transparent rom the perspectie o day-to-day management.
Like table based materialized iews, cube-organized materialized iews can be
rereshed ON COMMI1, ON DLMAND or on a schedule. Also like table based
materialized iews, they can be rereshed with a COMPLL1L reresh, a lAS1
reresh or a lORCL reresh. lor example, the ollowing command calls or a ast
reresh o the UNI1S_CUBL:
dbms_mview.refresh ('CB$UNITS_CUBE','F');
A lAS1 reresh reads materialized iew logs on the source tables or inserts,
updates and deletes. 1hese changes are applied incrementally to the cube. 1he
AnaIytic Workspace Manager is designed
for ease of use. AppIication deveIopers,
database administrators and Iine of
business power users wiII aII find AnaIytic
Workspace Manager very approachabIe.
The OLAP Option to OracIe Database 11g Page 31
cube is then incrementally pre-aggregated, with only the ancestors o new or
changed members being recalculated.
A COMPLL1L reresh will truncate act data in the cube, load all data rom the
source table and aggregate the cube
. 1his behaior is just like a table based
materialized iew.
A lORCL reresh, like with table based materialized iews, attempts to do a lAS1
reresh i possible and perorms a COMPLL1L reresh i a lAS1 reresh is not
possible. I the Database cannot do a lAS1 reresh it will perorm a complete load
o data rom the source table into the cube. 1he cube, howeer, can still be
incrementally pre-aggregated ater a COMPLL1L reresh rom the source table
At this point, it should be apparent that one o the main beneits o including cubes
in the Oracle database is the ability or one cube to play three dierent rules: a
summary management solution to SQL based applications, a content rich data
source to SQL based applications and a multidimensional serer to dimensionally
oriented applications. 1hese multiple uses, plus business intelligence metadata in
the data dictionary, allow organizations to leerage the inestment in the cube
across any number o tools and applications.
1he discussion about materialized iew reresh o the cube reeals the beneits o
OLAP integrated into Oracle Database rom the perspectie o the database
administrator. Materialized iew reresh o the cube is designed to both make the
cube more eicient to update ,with automatic incremental loads rom materialized
iew logs, and transparent to manage.
1ransparency o the cube in the database is a common theme. 1his can be seen in
SQL query and materialized iew reresh. It can also been seen in many other
aspects o database administration. Important highlights include:
OLAP is embedded within the Oracle instance. 1here is no separate
sotware to install or separate instance to manage. 1here is no requirement
or addition serer computers.
OLAP cubes are stored in Oracle data iles. Cubes are backed up and
restored along with all other data in the database. No separate processes or
special procedures are required.
OLAP users are simply database users. 1here are no separate users or
entities to create and manage.
Oracle cubes are secured using standard Oracle database eatures. SQL
GRAN1 and RLVOKL is used to grant access priileges to OLAP cube,
dimensions, cube iews, dimension iews and hierarchy iews. Virtual

Cubes are typically partially pre-aggregated as a perormance optimization. In most
cases, only a small amount o data is pre-aggregated and stored in the cube.
As a fuIIy embedded OLAP soIution, OLAP
cubes are secure and easy to manage.
Organizations can approach OLAP as an
incrementaI, Iow risk investment.
The OLAP Option to OracIe Database 11g Page 32
priate database can be used to control access to cube, dimension and
hierarchy iews. Deinitions o ine-grained cube security are managed within
the Oracle Lxtensible Data Security ramework.
OLAP is ully compatible with Real Applications Clusters and Grid
Computing - enhancing both reliability and scalability.
In short, OLAP cubes are simply another data type in the database and are
managed as such. A cube is a sophisticated data type that manages ast amounts o
summary data and perorms sophisticated calculations - and the design process
must take this into account. loweer, the database administrator that has no
speciic knowledge o the cube or OLAP easily accomplishes day-to-day
management o the cube.
OLAP cubes in Oracle Database 11g proide organizations with the means to
improe the business intelligence tools and applications they already use with
improed query perormance and analytic content. Using cube-organized
materialized iews, applications transparently access summary data managed within
the cube or an immediate improement in query perormance. SQL applications
can also be enhanced with the rich analytic content that is embedded within the
cube. Simple SQL access to the analytic content o the cube greatly improes
deeloper productiity and simpliies application deelopment.
1he OLAP Option is embedded within Oracle Database 11g that your organization
already uses. As an embedded solution, OLAP cubes beneit rom the architecture
and eatures that make Oracle the leading enterprise relational database. Oracle
cubes are highly secure, scalable and manageable. Organizations leerage the
database, serer computers and skills they already or an accessible and cost
eectie OLAP solution.

The OLAP Option to OracIe Database 11g
JuIy 2007
Author: Bud Endress

OracIe Corporation
WorId Headquarters
500 OracIe Parkway
Redwood Shores, CA 94065

WorIdwide Inquiries:
Phone: +1.650.506.7000
Fax: +1.650.506.7200

Copyright 2007, OracIe. AII rights reserved.
This document is provided for information purposes onIy and the
contents hereof are subject to change without notice.
This document is not warranted to be error-free, nor subject to any
other warranties or conditions, whether expressed oraIIy or impIied
in Iaw, incIuding impIied warranties and conditions of merchantabiIity
or fitness for a particuIar purpose. We specificaIIy discIaim any
IiabiIity with respect to this document and no contractuaI obIigations
are formed either directIy or indirectIy by this document. This document
may not be reproduced or transmitted in any form or by any means,
eIectronic or mechanicaI, for any purpose, without our prior written permission.
OracIe is a registered trademark of OracIe Corporation and/or its affiIiates.
Other names may be trademarks of their respective owners.