I was on a short vacation in Miami and couldn’t approve / reply to comments or post new things. Thank you for your interesting comments. I’ll definitely try to reply to everyone. I’m going to deal with pressing issues and then post new things about OBIEE.
Meanwhile – I suggest you read this article by Adrian Ward – http://majendi.blogspot.com/2009/06/state-of-obiee-market.html
Have a great day!
Even though I’m hanging on the bottom of Top 10 users, I still managed to make it to Pro Level today 
Now I have a nice silver icon to my name (or maybe it’s platinum, since the previous one looked like gold). Now, after giving myself pat on the back – let’s continue.
I still think the point system for the forum is mostly benefiting 2 sides – the forum itself & novices trying to make it to the market and not taking their due diligence to make simple forum or google search / RTFM. It’s encouraging me and fellow experienced colleagues to answer really rudimentary questions (“what is RPD? my AdminTool doesn’t work – oops I didn’t install it; I need to format my report a certain way – how do I change cell background?” . There’re several major flaws of the point system on any forum – first, a lot of stupid questions and second, it’s bringing competition spirit and making experienced folks answering those. Does “Pro” status mean anything? I’m not sure -since there’re probably many experienced consultants out there who’re just readers or perhaps they don’t want to be bothered with silly questions. I don’t see Jeff actively participating on OTN forums (even though I think he had some postings in the past) – probably for that same reason.
Thank you everyone listed below! Excellent job! Best of luck to all of you! I also want to mention David T. and anyone else not listed.
 |
Kishore Guggilla (1775) |
|
Stijn Gabriels (1080) |
|
John Minkjan (990) |
 |
Madan Thota (950) |
|
Turribeach (920) |
|
Christian Berg (635) |
|
Naresh Meda (625) |
|
gerardnico (605) |
|
mma1709 (590) |
|
wildmight (505) |
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.
I found an answer to something that bothered me for a while.
In setting up a Time dimension, there are requirement of the physical Tables that can be used, for e.g. Time Dimension table cannot join any physical table other than the fact table Time Dimension sources on the physical layer cannot be part of a complex join In the BM layer any logical Dimension defined as a Time Dimension cannot be part of any other logical tables . In the current 7.9.5 rpd the Date Dimension does not meet some of these requirements So if we were to designate the out of the box OBIApps rpd Date dimension as time dimension we can not have complex join to w_day_d in the physical layer. Currently out of the box OBIApps rpd has several complex join defined with the w_day_d_common alias table which is the detailed level LTC in the Date logical dimension. This issue causes error if you then try to check the time dimension flag and do a consistency check.
A comment on this from one of our Consultant as below “apps 7.9.5 was not ready to convert it to a true time dim. If you check the checkbox you will see all of the consistency errors. Part of it is due to the date fields being used in the inner joins of LTSs on other Dims and Facts which is a no-no for the Time Dim. It is easier just to create your own Time Dim that is used for the Time Series formulas. Or you could configure time series the old school way.” However the OBI 7.9.6 apps does have the Date Dimension checked as a Time Hierarchy. Also an additional response from Engineering as below
==================== The simple answer was that we didn’t use the OBIEE Time Series functions in BI Apps 7.9.5, and used them in BI Apps 7.9.6, hence configuring the Date dimension as a time dimension. In BI Apps 7.9.5, none of the new OBIEE Time Series functions were used. This was because the functionality was immature and had many bugs. These bugs were fixed in OBIEE 10.1.3.4.1 and BI Apps 7.9.6 has uptaken and used the new Time Series functions quite a bit. So for correct functionality of BI Apps 7.9.6, OBIEE 10.1.3.4.1 is a must.
This is interesting. My favorite part is “In BI Apps 7.9.5, none of the new OBIEE Time Series functions were used. This was because the functionality was immature and had many bugs. These bugs were fixed in OBIEE 10.1.3.4.1″ – soif you’re on 10.1.3.2. – you should upgrade as soon as possible (although this might mean months). I knew time dim was broken for a while – it’s just an official confirmation.
It’s Tuesday, and there was a big tragedy in DC that everyone knows about. I ride on Red Line every day – and now I’m starting to think that I’m not riding in front car anymore. However, it’s quite possible that I’d have been riding the same train.
Official info about BI nomination is here – http://www.oracle.com/webapps/dialogue/dlgpage.jsp?p_ext=Y&p_dlg_id=7687732&src=6642150&Act=335
Probably the most interesting category for blog’s readers is this:
Using Oracle BI EE Plus to deliver intelligence and analytics from data spanning multiple sources and applications.
The criteria’s don’t seem too difficult – I suggest you at least forward the link to your manager – supervisor.The only thing that is not clear is whether the award is for 1 person, 10 people total, or 10 teams. Please let me know if you can figure it out.
Summer was slow for many business intelligence blogers – Adrian Ward posted something a humorous albeit interesting story – “Don’t Try This At Home Kids” . John Minkjan came up with some cool scripts, such as Getting All Users and Roles from RPD
Other interesting findings – I found a post about all OBIEE and legacy products versions – http://blogs.oracle.com/bi/2009/06/ships_in_the_night.html by Darryn Hinett.
Something I just learned by an accident - Venkatakrishnan J (one of the most respected Oracle BI experts and an author of authoritative OBIEE blog http://oraclebizint.wordpress.com/) joined Rittman Mead consulting. Congratulations and Best wishes for all parties involved. You can read about it here – http://www.rittmanmead.com/2009/06/22/my-first-post-here-joining-rittman-mead/
Please stay safe