10:1 rule for skip - level aggregation

Question

Hy.
I'm new in OLAP. I'm using AWM on 10gR2 and could somebody explain to me what does mean 10:1 rule. I know that is ratio of children to parent level which is 10:1, but example that i study doesn't show me that.
Example:
(from Oracle 10g documentation, data warehousing, OLAP Application Developer's Guide, part 7 Aggregating Data, Case Study: Aggregating a Moderately Sparse or Dense Cube)
SELECT COUNT(DISTINCT ship_to_id), COUNT(DISTINCT warehouse_id),
COUNT(DISTINCT region_id),COUNT(DISTINCT total_customer_id),
COUNT(DISTINCT account_id), COUNT(DISTINCT market_segment_id),
COUNT(DISTINCT total_market_id), FROM global.customer_dim;
Global is a very small data set, so few adjacent levels have the desired 10:1 ratio of children-to-parent dimension members. Table 7-4 and Table 7-5 identify the appropriate levels to be calculated and stored for the two hierarchies. Only eight members are stored out of a total of 45 aggregate members.
On the Summarize To page for the Units Cube, select the precalculated levels for Customer, and select all levels for Time, Product, and Channel.
Table 7-4 Precalculated Levels in the Customer Shipments Hierarchy
Level Members Precalculate?
Total_Customer 1 No
Regio 3 Yes
Warehouse 11 No
Ship_To 61 Yes
Level Members Precalculate?
Total_Market 1 No
Market_Segment 5 Yes
Account 24 No
Ship_To 61 Yes
If I use rule 10:1 child to parent member why Warehouse and Account doesn't have precalculate set to Yes If they have 10 or more child values below.
Please help!!!!

Answer 1

It is a long time since I used the global schema and at the moment I am using the BI common schema so I am trying to quote from memory here regarding the data. The figures you have outlined below are number of members at each level, a better calculation would be the average number of children that would be returned when drilling from one level to the next. In this case there are 3 regions and 11 warehouses, so drilling from region to warehouse is likely to return at most 4 warehouses on average.
To quote from the OLAP documentation:
This 10:1 rule is best applied with some judgment. You might want to permit a higher
ratio for levels that you know are seldom accessed. Or you might want to store levels
at a lower ratio if you know they have heavy use.
The key for pre-aggregation is understanding expected usage patterns of your users. In this case for the global schema I expect it is optimised for demo purposes and the levels that are precomputed are those most likely to be used in a demo.
In your case you need to understand where your users will most likely start there analysis and make sure that combination of levels is precomputed to ensure fast response times for the first query and then monitor usage patterns and get feedback from users over time.
If you are using Discoverer OLAP Plus client you could export the Discoverer catalog and analyse the XML for each report to determine which values are being created. I don't think there is an easy way to monitor OLAP queries at the moment (I could be wrong but I have not seen anything in Enterprise Manager that would help in this area). You could quickly create a program in PL/SQL or OLAP DML that would help analyse the XML for Disco reports. If you are using BI Beans you can scan the XML from the BI Beans catalog for each report.
For the OLAP Spreadsheet Addin it might be necessary to create a program to scan the $V_SQL/V$SESSION tables to work out which data points are being requested by users.
Of course you could just try pre-computing every other level which I think was/is the default aggregation plan generated by OWB and AWM.
Hope this helps
Keith