Dense dimension aggregation

Hi All,
Is it possible to only aggregate and avoid calculation on dense dimension. I just want to get the aggregated values at the top level and avoid calculation.
AGG("Account"); is not working. essbase is accepting only CALC DIM.
Is there any command which only aggregates dense dimension?

Ah, OK. Is the dense member you have problems with a dynamic calc member, or is it a stored formula member? In either case, is the formula sensitive to month (i.e. why does it calculate a different value in Jan vs Dec, despite the fact that you have copied the same data)?
Incidentally, the reason I was talking about performance etc is that improved calculation performance is the usual motivation to use AGG vs CALC DIM.

Similar Messages

How to make a calc script on a dense dimension ?

Dears,
I want to make a calculation script on a dense dimension where :
- I want to get an input from a member, then make a mathematical calculation , then populate the result in another member at the same dimension .
For More Clarification :
I have the following fix
CALC ALL ;
FIX ("SAR","Working.V01","Budget2012","FY12","G_10","NM_CAT01","Employee General","BegBalance")
"Internal Transportation" = "Monthly Transportation"*30 ;
ENDFIX
-Internal transportation and monthly transportation are 2 members on FB_account dimension (dense dimension) .
Waiting for your response, Thanks in advance.

Dear ,
I appreciate your feedback . But, My problem is that after executing the calc script , No calculation happens .
by another means ,
-If I wrote "Internal transportation" = 500 ; --> It put 500 in it
-If I wrote "Internal transportation" = "Internal transportation" * 100 ; --> No calculation happened but it executed successfully
-if I wrote "Internal transportation" = "Monthly transportation" = 500; --> No calculation happened but it executed successfully
I don't know Why ???

Why to open Block only with Dense dimension Member ???

Hi All,
I want to understand the logic behind opening the block with dense member. Generally we open the block with member of dense dimension by fixing the sparse members
e.g. below considering C1, P1,Working,Actual are members of sparse dimension customer, product, Version, Scenario.
Fix(C1,P1,Working,Actual)
Jan
IF(Some condition)
Calculation on Account Member
ENDIF
Now if i change the code as below making Jan in FIX and opening the block with Actual. How it will affect the performance. The Number of iterations in total number of datacells will be same in bothe cases above and below then why to give priority to dense dimension member for opening the block.
Fix(C1,P1,Working,Jan)
Actual
IF(Some condition)
Calculation on Account Member
ENDIF
ENDFIX
I know the logic behind keeping sparse dimension member in FIX but here i think keeping 'Actual' member for opening the block is also a type of fix which will tell the code to do the calculation only for blocks of 'Actual'.
In 1st case i have fixed the number of blocks containing members C1,P1,Working,Actual and by keeping Jan for opening block means Jan is also fixed for the particular application means code will not run for feb march etc.
Means code will run for C1->P1->Working>Actual->Jan
In 2nd case also i have fixed C1,P1,Working,Jan and by keeping Actual for opening block means Actual is also fixed for the particular application means code will not run for other members of Scenarion dimension.
Means code will run for C1->P1->Working>Jan->Actual
Then what is the difference??? Why it will effect performance???

when using an IF statement in a calc script you have to specify a member to associate it with for the calc member block. This is like temporarily assigning it to that member as a formula in the outline. In most cases calculations on dense dimensions can work faster as the block is in memory. Remember that a block statement can have multiple calculation statements in it. When this occurs, having the calculations on a dense member can speed it up as it may not have to swap blocks to do the calculation.
Also consider that if a sparse combination of members does not exist, the block will not exist and there will be no attempt to do the calculations. If a sparse member is on the calc member block, it will cycle through all of the sparse members looking to do the calculation.

OBI EE 10g: Bridge tables and Based on Dimensions Aggregation

hi experts,
i am working on OBI EE 10 g (10.1.3.4)
The BM&M layer consist of:
1) Logical fact table "Sale_Indicators"
Fields: SALE_ID (PK, FK),
D1_ID (FK),
D2_ID (FK),
Indicator1 (measure, level of granularity: SALE_ID),
Indicator2 (measure, level of granularity: SALE_ID),
Indicator3 (measure, level of granularity: SALE_ID)
2) Logical dimension table
"Sales" (PK: SALE_ID),
"D1" (PK: D1_ID),
"D2" (PK: D2_ID),
"Customers" (PK: SALE_ID, CUST_ID) - bridge table!
"Products" (PK: SALE_ID, PROD_ID) - bridge table!
3) Dimensions: SalesDim, D1Dim, D2Dim, CustomersDim, ProductsDim
If fact table is joined with bridge table, the number of rows in fact table is multiplied, for example:
D1_ID | SALE_ID | CUST_ID | Indicator1
777 | 1 | 14 | 10
777 | 1 | 17 | 10
777 | 2 | 15 | 12
888 | 3 | 16 | 20
888 | 3 | 17 | 20
888 | 4 | 19 | 30
I need to get report:
D1_ID | Indicator1 (SUM)
777 | 22
888 | 50
and with filter by customer, for example (CUST_ID = 17):
D1_ID | Indicator1 (SUM)
777 | 10
888 | 20
i am trying to use "based on dimension" aggregation, for example (Indicator1):
Dimension Formula
CustomersDim MIN
ProductsDim MIN
Others SUM
The generated physical SQL performs joining EVERY dimension to the fact table, even though they are not included in the final result set.
Is there any way to tweak logical or physical model in order to eliminate excessive joins?
Thanks in advance!
Edited by: 859688 on 31.10.2011 4:04
Edited by: 859688 on 31.10.2011 4:06
Edited by: 859688 on 31.10.2011 4:08

I found this text on the help, but I didn't understand, because when I check the "based on dimensions" check box, I can choose aggregation rules for each dimension, not only the time dimension.
Also, I found in the help menu:
"In the Aggregation tab, select the Based on dimensions check box.
The Browse dialog box automatically opens.
In the Browse dialog box, click New, select a dimension over which you want to aggregate, and then click OK.
In the Aggregation tab, from the Formula drop-down list, select a rule."
I did the same steps suggested by the text above, but it didn't work.

Based on dimension aggregation

I have a fact table with 2 sources. One of these sources has only one measure and I am having problems with it.
This measure must use based on dimension aggregation, but it don't work. When I set this option, the measure shows a blank value in Answers, but when I switch to a default aggregation rule (not based on dimension), like sum or max, the value is shown correctly in Answers.
My doubt is: is it necessary any other configuration on dimensions or fact tables in order to use based on dimensions aggregation? I just change the value in the aggregation tab of the measure, is there any other step necessary?
Thanks

I found this text on the help, but I didn't understand, because when I check the "based on dimensions" check box, I can choose aggregation rules for each dimension, not only the time dimension.
Also, I found in the help menu:
"In the Aggregation tab, select the Based on dimensions check box.
The Browse dialog box automatically opens.
In the Browse dialog box, click New, select a dimension over which you want to aggregate, and then click OK.
In the Aggregation tab, from the Formula drop-down list, select a rule."
I did the same steps suggested by the text above, but it didn't work.

Populated dense dimension member failed ?

Hi,
I have a scenario dimension which is dense with this member : Actual and Budget, and I would like to copy Budget to Actual.
Actual member are already populated on month M1, M2, M3
ACTUAL BUDGET
M1 100
M2 200
M3 300
I wrote a HBR like this :
Fix(M1:M3,other sparse dimension member)
Budget = Actual
ENDFIX
but only M3 has been populated
ACTUAL BUDGET
M1 100
M2 200
M3 300 300
I don't understand why because datablock already exist for M1, M2, M3.
I tried to use CREATEONMISSINGBLOCK ON but didn't change anything.
So I changed my script with a datacopy like this :
Fix(M1:M3,other sparse dimension member)
Datacopy Actual to Budget;
ENDFIX
And now it work
ACTUAL BUDGET
M1 100 100
M2 200 200
M3 300 300
But I don't understand why my first script failed ?
Regards
Benjamin

when using an IF statement in a calc script you have to specify a member to associate it with for the calc member block. This is like temporarily assigning it to that member as a formula in the outline. In most cases calculations on dense dimensions can work faster as the block is in memory. Remember that a block statement can have multiple calculation statements in it. When this occurs, having the calculations on a dense member can speed it up as it may not have to swap blocks to do the calculation.
Also consider that if a sparse combination of members does not exist, the block will not exist and there will be no attempt to do the calculations. If a sparse member is on the calc member block, it will cycle through all of the sparse members looking to do the calculation.

Member block component only select dense dimension members

I used Calculation Manager to create Business Rule for Planning app. The Member Block component only show dense dimensions. Why?

Its trying to force you to write the calculation optimally. Calculations with sparse member blocks are much slower than dense dimension blocks. Even if you cannot select, you can always type in the sparse dimension member name. You dont need to use member selector.

Is having large no. of child in dense dimension ideal?

we have a BSO application in which some of the dense dimension have over 1500 members in them, is it ideal?
the hierarchy is not too flat but still there are some parents which have over 200 children.. i read somewhere that BSO throws error if the no. of children exceed 100.. is that statement true?

It doesn't throw an error, it throws a 'warning', which you can ignore. In a dense dimension it is unlikely be a performance problem (sparse is a bigger deal), but it might be hard for users to navigate.
A dense dimension with 1500 members is not problem in itself. Whether it's ideal or not is pretty hard to answer from what you've posted. How did you decide which dimensions to make dense? Do you actually have a performance problem or are you asking out of curiosity (not that there's anything wrong with that)?

Are there any implications on changing a dense dimension to sparse?

We have some calculation performance issues where our calc is taking a long time to run. We have 6 dimensions, Scenario, Period/Months, Years, Currency, Market, and Accounts. Market and Accounts are the only Sparse members. We tried to make Years sparse (through research, although all the years have data), and the calculation time improved significantly. My question is, will this change have any implications on retrieval or data load?
Here's our calc:
Agg(Accounts, Market)

The short answer is 'yes', it may have implications, and you will have to test to figure out what they are.
'Years' is a classic candidate to be a sparse dimension (as is 'Scenario'). But your cube design sounds unusual, at least in my experience, which may or may not be for good reasons. So it's all but impossible to make predictions or recommendations without knowing more about the cube and the input dataset.
Incidentally, the simple fact that all years have some data doesn't in itself make Years a candidate for a dense dimension (which is what you seem to be implying). Within reasonable limits of block size, you want to select dense and sparse dimensions such that when data exists at a sparse intersection, the largest possible proportion of dense combinations are populated. Just for example, if you have Product, Region, Account and Period dimensions and your company sells only a small proportion of Products in any given Region, Account and Period are likely good candidates to be Dense dimensions: Where data does exist for a Product / Region combination, many Account / Period combinations are filled. Region and Product are likely poor candidates for Dense dimensions, because almost all Region / Product combinations are empty even where data exists for an Account / Period. So the simple fact that all Products have some data doesn't make Product a good dense candidate.
Hope this is of some use... :)

Outline Ordering of Dense Dimensions

To optimize your cube I understand that you first have your dense dimensions at the top of the outline then your sparse with few members, then sparse with most members and last your attribute dimension. But didn't find any provision of which order a dense dimension should be? Should the dense dimension with few members be at the top or dense dimension with most members?TIA

The recommended configuration is the "hourglass" shape - largest dense to smallest, smallest sparse to largest. Personally, I can understand the sparse dimension ordering - it has an impact on the efficiency of the calculator cache, but I have not seen any documentation or experienced significant performance gains by changing the order of dense dimensions.That being said, changing the order of dense dimensions WILL have an impact on the calculation order, which may be important if you have certain types of formulas or dependencies in your dense dimensions.The thing to keep in mind about optimization is that the order of the dimensions in your outline is probably lower on the list of priorities, behind the sparse/dense settings, optimizing scripts, using dynamic calcs, intelligent calc, etc.Regards,Jade---------------------------------Jade ColeSenior Business Intelligence ConsultantClarity [email protected]

Filters on Dense Dimensions

In the past I have always stayed away from creating filters ondense dimensions. My fear is that it will severy slow downthe response time to the database. I apologize for any spelling inssues as my browser is not likingthe java application that runs this forum. 

Hi sweeks, I use filters on accounts dimension, which is normally densedimension. I had not seen any sluggish behaviour in response timeof database after placing filter on dense dimension. I am eager to know if any one has this issue. ----------- [email protected]

Problem with time dimension aggregation

I have a time dimension with 2 columns:Year and week
I've created a hierarchy in it to drill down from the year to the week.
when I report the sales in week level I have the right values but when I report the sales value in year level I don't have the right aggregation.Even if the year Level is a grand Total in the hierarchy.
The problem is that for all the years I have the same value but when I add the week level to the report Then I have the right values.
What could be the problem

Hi,
1.Actually the drill down Route path is not properly generated with your given key columns in herarchies.
need to give correct key columns
like year(YYYY)-->Week(wee should be the unique column for each and evry year)
suppose:
2000-sunday
2001-sunday should be different
so mostly the problem at your week column make the unique yearweek column as the key identifier at that level
Every Week is unique cause the logical key is a combination of the year and the weeknumber
2.if not you need to set individual levels for measures in content tab...
you mean by the content tab the level tab when you doubleclick into the measure???
Thanks

Aggreation Based on Dimensions - Aggregation rule: Evaluate_Aggr

Hello Experts,
Can any of you explain to me how do you use the Logical Column Aggregation based on dimensions?. If you can set up a simple example would be great. Also, what is the definition of the aggregation rule : Evaluate_Aggr?, please give a simple example
Thanks for your time
Pablo.

And it's not the same than a level based measure :
The definition of a level based measure :
http://gerardnico.com/wiki/dat/obiee/bi_server/design/fact_table/level_based_measure_calculations
An example with evaluate (lag analytic function)
http://gerardnico.com/wiki/dat/obiee/presentation_service/obiee_period_to_period_lag_lead_function
Check the two and you will see the difference in the definition.

Based on Dimension Aggregation method - OBIEE 11G

Hi,
I have a fact table with one measure value and 3 dimensions (Time, Issue, status). Fact table is loaded monthly data for different issues and with status and a corresponding value.
I want my report to show always issues that is latest of that period and then status of the same.
Lets say:
Fact table has data like this:
31/Jan/2011 - Issue1 - Open - 10
28/Feb/2011 - Issue1 - WIP - 20
31/Mar/2011 - Issue1 - WIP - 30
30/Apr/2011 - Issue1 -WIP - 40
31/May/2011 - Issue1 -Closed - 50
31/May/2011 - Issue2 -Open - 60
31/May/2011 - Issue3 - Open - 20
Now I want to see the report by status and value and it should show me the latest of that time period.
For Quarter1 :
WIP - 30
For Quarter2:
Open - 80
Closed - 50
If I take Year then it should show me :
2011 - Open - 80
2011 - Closed - 50
I tried using aggregation "Based on dimension" option in BMM layer and put Others - Sum() and LAST against time dimension.
But in that case it is giving me the results by status what is latest for the time period. So it is ding sum by other dimension first and then applying LAST method.
In that case result of Quarter -1 will be :
Open - 10
WIP - 30
If I can change the order of aggregation method like first apply LAST method and then do sum then I think desired result will come. But I am not able to change the order.
Is there any other of doing this solution?
Any help is highly appreciated.
Thanks

Hi,
There will be multiple records for an entire month as there are many issues. For a particular Issue it will be one with one particular status for a particular month.
The join is based on the date colum of fact table and the dimension table.
Regards,
SS

Aggregating Cube dimensioned by Compressed Composite

What is the optimum way to aggregate cubes dimensioned by compressed composites using DBMS_AW.EXECUTE? I am not able to figure out why the DBMS_CUBE package performs better then DBMS_AW.
Test results from the sample Global Schema:
Load 5 records and run the Aggregation using the following method (takes 2 seconds):
exec DBMS_CUBE.BUILD('GLOBAL.UNITS_CUBE USING(SOLVE)','C',false,1,true,true,false);
Load 5 records and run the Aggregation using the following method (takes 17 seconds):
exec DBMS_AW.EXECUTE('aggregate units_cube_stored using units_cube_solve_aggmap;');
Page 853 in OLAP DML Reference 11g Guide states:
Aggregating Variables Dimensioned by Compressed Composites
Keep the following points in mind when designing an aggregation specification for a
variable dimensioned by a compressed composite:
■ RELATION statements in the aggregation specification must be coded following
the guidelines given in "RELATION Statements for Compressed Composites" on
page 9-52.
■ There is no support for parallel aggregation. Instead, use multiple sessions to
compute variables or partitions that have their own compressed composites.
■ If possible, Oracle OLAP automatically performs incremental aggregation when
you reaggregate a variable dimensioned by the compressed composite. In other
words, Oracle OLAP determines what changes have occurred since the last
aggregation, determines the smallest region of the variable that needs to be
recomputed, and recomputes only that region.
Consequently, there is no support for explicit incremental aggregation. You cannot
aggregate a variable dimensioned by a compressed composite if the dimension
status of the variable is limited. The status of the variable's dimensions must be
ALLSTAT for the aggregation to succeed. You can, however, partition using a
dense dimension with local compressed composites. In this way you can
aggregate only those partitions that contain new data.

One difference is that DBMS_CUBE will look to see if the cube needs solving before calling aggregate. So if you call
exec DBMS_CUBE.BUILD('GLOBAL.UNITS_CUBE USING(SOLVE)','C',false,1,true,true,false);
several times in a row, I could believe that it would become faster after the initial solve.

Dense dimension aggregation

Similar Messages

Maybe you are looking for