SUM over OTHER (all dimensions except TIME),
HLAST (LAST_VALUE) over TIME

Since the OLAP AW needs to be consistent with the relational MVs, they require the same aggregation operator along all dimensions of the cube (measure) and so we will not be able to model this.

Is it a fair to say that unless OLAP allows for a different aggregation operator (per dimension) for the cube, the query rewrite (from MVs to AW) feature will not be useful for end of period kind of calculations (stock information, say)?

To word the issue differently, without OLAP in the picture, How is Inventory data (E.g: stock on hand information which needs dimension specific aggregation), modeled with MVs to utilize Query Rewrite and speed up relational reporting?

Do the MVs (aggregate table definitions) required to simulate such calculations suffer from restrictions like
* MVs are not suitable for fast refresh
* MVs need to be rebuilt completely when base data changes
making them almost unusable (as MVs).

MV Definition would perhaps be something like
SELECT …, LAST_VALUE(fact_col) OVER TIME partition by …
FROM (
SELECT TIME, …, SUM(fact.col) fact_col
FROM FACT, TIME,
WHERE …joins…
AND …filters…
order by time asc
) join with

Aggregation and Partitioning

With cost-based aggregation, a setting of 0 means do nothing to optimized the aggregate space of the cube. Low cost on the build, not usually very useful for query. A setting of 1 causes the composite to be built in the aggregate space, but none of the measure values to be precomputed. Unless the cube is a small, what-if type cube you should always choose a value of 1 (or higher). Values between 2 and 100 simply precompute more of the aggregate space. A good starting point is 20 (50 is very high).

The value, by the way, really isn’t a true indication of the percentage of the cube being precomputed. It’s simply a relatively scale. It could just as well have been 0 to 50. (And, I agree, size or time constraints would be more understandable.)

It is important to understand the relationship between partitioning and cost-based aggregation. If you partition the cube, you will notice that there will be cost-based aggregation settings for both the bottom and top partitions. The bottom partition includes all the members of the partitioned dimension up to and including the partition level. E.g., if you partition on Quarter it will include Days through Quarter (and well as values from the other dimensions). The top partition will include levels above the partition dimension. E.g., Year.

The top partition can be very large (E.g., all years by all other dimension values). So, any significant pre-aggregation of the top partition can be expensive (lots of data in a single partition, which often get bogged down in I/O). I try to partition at as high a level as possible and set the top partition to 0 or 1.

Remember that the cube is incrementally aggregated within a partition during a refresh (unless you’ve chosen to clear values first), so it’s not necessary important to partition at a low level to isolate refreshed. Partitioning has more to do with parallel processing and keeping data in memory (and off disk).

Requirements for MVs

The requirements for MVs (levels, agg operators, etc.) are required to ensure that the cube matches the capabilities of SQL query because the data returned by the cube is compatible with what would be returned by the SQL statement had the query block actually executed the GROUP BY. In the case of requiring compressed cubes, the aggregation index of the compressed cube ensured correct looping within the cube and thus correct row counts for the cube MV.

Sparsity Advisor

It looks like you are using the Global data set. Global is actually very dense (so it’s easy to use in BI tools) and thus a compressed composite isn’t the best choice unless you need it for cube MVs. With real world data, the sparsity advisor will almost always choose compressed.

Cube Scripts

For MVs, the cube most be a load and aggregate. You can’t introduce calcs in to the cube which could cause it to be semantically inconsistent with the MV definition.

MV Advisor

No Enterprise Manager management packs are required to use the OLAP Option.

I just used SQL Developer, selected the MV and then clicked on the SQL tab – it then generated the SQL that is used to define the object, no issue with character length.

regards

Mark