This blog post is about OBIEE reporting. Specifically, it is about skipping the data warehouse and reporting from the transactional database instead. Oracle’s OBIEE, like most BI reporting tools, is designed to use star/snowflake schemas as the underlying structures to report from. Additionally, OBIEE’s metadata layer is very rich and extensively well thought out, allowing for a great deal of flexibility. Oracle’s metadata tool (Admin Tool) allows us to leverage this flexibility and features to bridge the gap between an OLTP and an OLAP model. I am not negating the need for a data warehouse, I am just wondering if all BI reporting projects merit one.
So the question to ask is: Is OBIEE up to the task?
[nQSError: 15019] Table Calendar is functionally dependent upon level Month, but a more detailed child level has associated columns from that same table or a more detailed table.
One of the many benefits of working at Oracle is access to Oracle University. I just found out about this new feature in a recent class I was able to take.
With the release of OBIEE 18.104.22.168, Oracle now provides basic SVN integration in Admin Tool. It seems Oracle is moving away from storing RPD content as a binary file (wishful thinking). I think this is a step in the right direction and would like to be able to merge and diff RPD work from Admin Tool or versioning system of choice. I am assuming SVN integration in Admin Tool is just as good as in SQL Developer Data Modeler . Just like Data Modeler, you still have the option of not enabling SVN integration and using your versioning system of choice. This is what I am going to do. It gives me more choice such as which versioning system to use and independence from Oracle’s SVN feature set included in tool which is a subset of SVN anyways.
Moving development form database to database, I frequently end up with Warning: "OBIEE RPD – The feature in Database do not match the defaults. This can cause problems." I assume this can be attributed to all these database (and servers) having slightly different settings, defaults, connections properties. Sometimes I move databases and it does warning does not show up. Sometimes it does.
One of OBIEE’s idiosyncrasies is that, by default, only the user that installed the product can start the server from the Window’s Start menu. For more information on this, please read this old post.
The solution outlined on that post enables ADDITIONAL users to start OBIEE. This is still borderline unacceptable on a production environment. Ideally, we want OBIEE to start with the Windows Server.
What we want is OBIEE to start as a service on boot up. The only original information I’ve found on this comes from Oracle itself.
Everything else ‘on the tubes’ so far is a copy/paste job from Oracle doc. However, I have found no success stories from anyone. I could not get this to work either for OBIEE.
This is where Windows Scheduler comes in. Using Windows Scheduler, I was able to set OBIEE to start on system startup without any trouble.
Talk about running behind. I recently found out that Oracle does offer a client tools ONLY set for OBIEE. As of this writing (22.214.171.124.0), you can head over here and grab Oracle Business Intelligence Developer Client Tools Installer.
At a bit larger than 300 MBs, this download is a walk in the park compared to them 25 GBs.
I am successfully running Admin Tool now sans server on local box but I ran into a few odd things along the way.
You finish revising RPD for project and, upon checking global consistency, you get the following error(s):
 Physical tables "<TABLE_ONE>" and "<TABLE_TWO>" have multiple joins. Delete new foreign key object if it is a duplicate of existing foreign key.
Each of these errors points to different tables but they are all of the same type. Sensibly, error states that the tables in question have more than one join between them.