rolap
DESCRIPTION
ROLAPTRANSCRIPT
ROLAP
The biggest problem with MOLAP is the requirement of large main memory as the cube size
increases. There may be many reasons for the increase in cube size, such as increase in the
number of dimensions, or increase in the cardinality of the dimensions, or increase in the amount
of detail data or a combination of some or all these aspects. Thus there is an issue of scalability
which limits its applications to large data sets.
Despite advances in MOLAP technologies, high -end OLAP implementations will normally
require assistance from a relational database .Hence a ROLAP or Relational OLAP.ROLAP
tools will query the relational database using SQL generated to conform to a framework using the
facts and dimensions paradigm using the star schema
ROLAP as a "Cube"
OLAP data is stored in a relational database(e.g. a star schema)
The fact table is a way of visualizing as an "un-rolled" cube.
So where is the cube?
§ It's a matter of perception
§ Visualize the fact table as an elementary cube ( refer fig-1)
Recall from the last lecture that an implementation of the OLAP framework will be accepted as
OLAP after it passes the FASMI testi.e. it has to be Multi-dimensional. The question is "how to
Convert something into a cube" which is intrinsically not a cube. And more importantly, if
MOLAP has the space requirement limitations, and to overcome those limitations we areusing a
different implementation, then wouldn't the conversion back to a "cube" defeatthe purpose? This
is actually a very good question, and needs some detailed explanation. Fig -12.1 shows two rows
of a fact table, and the aggregates corresponding to the cells of the fact table are shown
correspondingly in a three dimensional cube.
How to create a "Cube" in ROLAP
Cube is a logical entity containing values of a certain fact at a certain aggregation level at
an intersection of a combination of dimensions.
The following table can be created using 3 queries
When we talked of a cube for a MOLAP, it was not actually a physical cube, but was a logical
entity. We continue with that concept ,and assume that what was stored in a cube at a certain
combination of indexes, corresponding to such a group of indices, we store the aggregates in a
two dimensional table, and we use such groups of tables to store the same data that was stored in
a MOLAP.The table shown in fig -12.2 is divided into three parts shown shaded and also shown
by dottedlines. Corresponding to each part of thetable, there is a query andconsequently the
tablecan actually be filled usingthree SQL queries as follows
For the table entries, without the totals
SELECT
S.Month_Id, S.Product_Id,
SUM(S.Sales_Amt)
FROM
Sales
GROUP BY S.Month_Id,S.Product_Id;
Forthe row totals
SELECT
S.Product_Id,SUM (Sales_Amt)
FROM
Sales
GROUP BY S.Product_Id;
§ Forthe column totals
SELECT
S.Month_Id, SUM (Sales)
FROM
Sales
GROUP BY S.Month_Id;
The first query can be used to fill Part -II of the table ,the second query used to fill Part -I of the
table, and the third query used to fill Part -III of the table, thus using these three queries, we create
a ROALP structure
Problem with simple approach
Number of required queries increases exponentially with the increase in number of
dimensions.
It's wasteful to compute all queries.
In the example, the first query can do most of the work of the other two queries
If we could save that result and aggregate over Month_Id and Product_Id, we
could compute the other queries more efficiently
R OLAP Issues
Maintenance.
Nonstandard hierarchy of dimensions.
Nonstandard conventions.
Explosion of storage space requirement.
Aggregation pit-falls
ROLAPIssue: Maintenance
Summary tables are mostly a maintenance issue (similar to MOLAP) than a storage issue.
Notice that summary tables get much smaller as dimensions get less detailed (e.g.,year vs.day).
Should plan for twice the size of the un –summarized data for ROLAP summaries in most
environments.
Assuming "to date" summaries, every detail record that is received into warehouse must aggregate into EVERY
summary table
ROLAP Issue: Hierarchies
Dimensions are NOT always simple hierarchies
Dimensions can be more than simple hierarchies i.e. item, subcategory, category, etc.
The product dimension might also branch off by trade style that cross simple hierarchy
Boundaries such as:
Looking at sales of air conditioners that cross manufacturer boundaries, such as COY1, COY2,
COY3etc.
Looking at sales of all "green colored"items that even cross product categories (washing
machine,refrigerator, split -AC,etc.).
ROLAP Issue: Storage Space Explosion
1. Summary tables required for non -standard grouping
2. Summary tables required along different definitions of year, week etc.
3. Brute force approach would quickly overwhelm the system storage capacity due to a
combinatorial explosion