An Interesting Case of An Essbase Dimension and its Attributes in RDBMS

Being a BI Consultant, I often browse through a number of BI forums for a quick glance on the things going on and to offer some peer help. I have recently come across an interesting case on oracle OBIEE forums, where there was a dimension in Essbase but its attributes are in a relational database and the numbers have to be reported using the attributes too apart from the dimension members. I have given it a thought, and it certainly seemed to be a good candidate to be in my blog.

Aggregate storage applications ignore update to derived cells…

Today, was yet another interesting day in our cube design, this time it was when loading to an Essbase’s ASO. We have some numbers that are relevant to only some dimensions and so, I had to come up with a rules file to load these numbers to my ASO cube. In my data loading wizard header section, I included Generation 1 members of these irrelevant dimensions, and validated the rules file to be correct.

However, when I was loading data using this rules file, I consistently hit at the error ” “Aggregate storage applications ignore update to derived cells. [] cells skipped”. I have been through Essbase error message descriptions for this message again and again to read that data cannot be loaded at non level-0 members and members with formula. However, I noticed that the same rules file could load data to a BSO, and was wondering why it fails for ASO. After going through my outline, design, etc, I realized one costly mistake in my rules file. The essbase error messages list clearly said, data cannot be loaded to Non Level 0 and members for formula. However, in my rules file I set the header to Generation 1 Members of my irrelevant dimensions and this was the cause. 

So, to work around this constraint all I had to do, was create a level 0 member in these irrelevant dimensions (Just say a member : Unidentified ) and set this member in the rules file data loading header section.