Category Archives: Dimensional Modeling

Avoid Non-numeric facts!

Yes, I’ve done this mistake more than once, usually unwilfully. Using varchar columns in fact table.

Everyone knows that using anything but numeric facts is a bad idea. However, there’re situations when it might be deemed necessary, especially when dealing with reporting at the detailed level. For example, client once wanted Condition Grade for previous year using AGO function in Fact Table. There was a need for previous year reporting using AGO and TODATE functions. Also, there was a complex function evaluating variance in condition. Since there’re limited aggregation functions available for varchars in OBIEE  (FIRST and LAST..I don’t countCOUNT – since it doesn’t really do it for that report). And you need to set some aggergation, because otherwise, you can’t use those column in time-series functions since those require aggergated metrics.

Well, what do you know. Query performance for the whole dataset was very slow (it’s supposed to be, since nobody should get inital report of more than a page) . About 20 minutes. Setting up bitmap indexes reduced it to 4 minutes. And setting textual facts’ aggregation setting to “None” reduced that time further acceptable 20 seconds. However, time-series functionality was lost.

So, please don’t use textual facts – they won’t make you any good:

a) You can’t really get any meaning out of them except on the most detailed level. How do you measure A vs B ?

b) You run into performance issues.

What to do:

I guess it reallty depends on the situation and your gut feeling.  Ideally, you want to convert letter grades to numeric alternative.  Such as A=4, B=3, etc. then you can make all kinds of fun analysis with it.  If that’s not an option, then you should try  pushing that data to your dimension (using an aliased combo table if you don’t have that dimension). I understand there might be more viable solutions. I’m going to find my post and discussion on OTN.

Important skills for an OBIEE developer?

Part 1

Initially, I was going to write about whether or not the ETL skills are important for a BI developer, however, I’ve significantly broadened the focus of the post since.

There were few articles that have kept my attention for a while – discussion of the skill-sets that business intelligence developers should have. The articles are “Functional Expertise in a Technical BI Consultant” by Jeff McQuigg and “What Skills Does an Oracle BI Developer Need in 2009?” by Mark Rittman (I think I’ve mentioned that one before). I have a big respect and admiration of both experts and have found inspiration in their blogs and forum posts (both OTN and Toolbox). They both list multiple skills that intersect (such as ETL, database, and dimensional modelling). I think the difference between the articles is that Mark is putting the emphasis on application tools (Hyperion Applications, BI Applications, OWB, and others) while Jeff is emphasizing the importance of the general knowledge of BI and DWH concepts such as dimensional modelling and ETL backed up by OBIEE tools proficiency.

“Domain experience in BI, Data Warehousing, BI Tools, Dimensional Modeling, ETL, BI Apps, etc. is what you should be focusing on…”

I should add that Mark also mentions the importance of possessing various applicable skills, however, I felt that he was more elaborate about software applications.

“In addition to these product skills, you also needed to have a fair bit of database knowledge, partly because all of these tools worked directly with database data, so you had to know your indexing, materialized views, explain plans and so on…”

My only two additions to both lists would be web development and html/css skills for front-end OBIEE customization. It might not be very complex, but I’ve had a few instances where clients have asked me to work on such things as changing Answers text / links, modifying some style sheets, and revamping the Dashboard look.  The other skill is LDAP security and various SSO implementations.

One thing is clear – there’re many technologies, tools, and concepts that a good BI consultant should be comfortable with. Not only that, he/she should be proficient in critical thinking, information search, and just-in-time learning flexibility – being able to learn new tools/concepts on the fly.  I don’t even mention such items as communication skills, attention to detail, dressing appropriately – since those are given for those who’re working in an enterprise scene.

Christian Berg (an OBIEE and Hyperion expert)  has recently started a blog of his own and called it hekatonkheires, which apparently means “three giants who possessed a hundred and fifty hands”. I think it’s a very good description of someone working with OBIEE (Siebel Analytics).

(to be continued…)

Comments are appreciated as usual.

importance of defining dimensional hierarchies

Dimensional modeling is very important in OBIEE. Many mistakes happen because of incorrectly defined time dimension or other dimensions. This service request below is a demo of how an incorrectly defined key in the beginning can block the development efforts in the future.


Modified rpd and added a new dimension for Key Accounts (Sales.”Key Account”.”Key Acct”) into the Sales subject area . After this change when building a report with Sales.Brand and drillingdown on Brand to show Brand_SKU ( a different dimension throws an error in Answers.

[nQSError: 14020] None of the fact tables are compatible with the query request Brand.Brand.

By following these steps the issue can be reproduced:

1. Add dimension called Sales.”Key Account”.”Key Acct into sales subject area in rpd
2. save rpd and checkin changes
3. create answers report with a different dimension Brand.
4. Drilldown on Brand to show the next level “Brand”.”Brand_SKU”.
5. Get the error mentioned above

The report should work fine because the “Brand”.”Brand_SKU” was not modified at all.

Business Impact
This is a very important issue that is holding up all BI projects. You cannot move forward until this issue is fixed.

The error thrown when drillingdown from Brand to Brand_SKU is caused because of incorrect definition of level keys in your rpd. The issue is, that by definition, a key is the lowest level of a table. Any higher levels are made up of aggregating the lowest or detail level. Since Brand and Product have the same detail key, there should be some consistency between the detail or lowest level of their respective hierarchies. There is not. The lowest level of the Brand hierarchy has a level key of CHILD_KEY_WID. The lowest level of the Product hierarchy has a level key of ‘SKU Nbr’ which is mapped to LVL6_KEY. It seems that the navigator is expecting the same detail key but is not seeing it. This seems to be the cause of the navigation error.

As confirmed by reviewing your rpd inhouse, the level keys are not properly defined for Brand and Product dimensions.
The levels were not defined according to best practices. The document from Engineering that lists the issues in your rpd that dont meet best practice is attached to the SR.

Please follow these steps in order to fix the error “[nQSError: 14020] None of the fact tables are compatible with the query request Brand.Brand”

1) Open rpd using Admin tool
2) Select BMM layer and delete the current hierarchy created for Brand
3) Make the following change to Product Dimension

–Dimension –Logical File –Physical File
Product Product HSAMI_SKU_DH and

The Product Dimension has two hierarchies, CMDYGRP and BRAND:

So now both hierarchies are constructed in one dimension over
one logical dimension table, with multiple phyiscal source tables.

4) Save changes to rpd
5) Test in Answers by creating report with Brand and Product columns
6) Navigation/Drilldown from brand and product should work fine.

Review of the hottest OBIEE topics on Oracle’s forum

I’ve decided I’m going to put review of the most useful and most hot topics from the Oracle’s discussion.

#1. “Thread: Whats Business Inteligence Suite?”

OBIEE Kenobi is giving a good amount of resources for starters, including Mark Rittman’s blog. Definitely worth giving a look, if you’re new to bi solutions or obiee.

#2. Calculations using Physical Tables vs Logical Tables asked by Mark Thomspon
Kishore Guggilla and wobiee1 answered the question almost at the same time. I really liked the short and consise description of ” The Physical vs Logical has an impact as you already described:
Logical will first aggregate and then calculate. This is the case with a lot of measures just as your example sales/profit.”

#3. What are time-series?

This is one of the most common questions – setting up time series functions.  Few experts are giving their few to what they consider to be time series in OBIEE. They also portray examples of such functions as AGO and TODATE. OBIEE has several options for implementing time , however, I recommend canonical time – it’s slightly more difficult to implement – but is more  beneficial for your bi system.

Hierarchy – order of displaying lowest level attributes

There was a problem in drill down in one of the hierarchy with the order it displays the lowest level attributes.

When drilling down on a certain category – “Organization”, Answers always shows columns in the following order:
Organization Name,Department Name, Sub-Department Category, Org Detail Number, Org Detail Name

The desired order is:
Organization Name,Department Name, Sub-Department Category, Org Detail Name, Org Detail Number

The hierarchy was defined as following in the RPD (please note that Org Detail Name and Org Detail Number are at the same lowest level defined as keys):

Organization Name
Department Name
Sub-Department Category
Org Detail Name | Org Detail Number

It has been found that it doesn’t sort alphabetically.

With Oracle’s OBIEE support and help – the solution has been found:

1. Use the Query Repository feature under Tools menu in the RPd to do a search of these 2 columns in the RPD.
2. In the Query Repository window note down the IDs for these 2 columns. Please check which one is bigger than the other.
3. The logical table, delete the 2 columns (Org Detail Name and Org Detail Number) and add them again in the desired order. Make sure you add them in the correct order. Query for the columns again, the IDs should be in the reverse order as step 2.
4. Add them in the hierarchy again
5. Change the order of level keys in Dimension hierarchy
6. Save the changes and test again.

After RPD re-deployment – it was working.

There must be an easier way to change order of composite key (complex key) columns.