The picture above is an example of minimalist design. It features an uncluttered and simplistic visual scheme that is almost relaxing to the eye and mind. Optional or unnecessary elements are removed. It focuses on only the bare essential elements – the essence of the building or room’s function. Notice there isn’t even a towel rack.
It’s not really for me – it reminds me too much of a concrete future dystopia that I’ve seen too many times in sci-fi movies. It also doesn’t look comfortable at all. But hey that’s just me; I could be wrong.
However when it comes to OBI report design, minimalist is the only way to go when it comes to the Criteria Tab. Whereas architecture and design are subjective, when it comes to keeping the criteria tab minimalist there is a strong, demonstrable benefit to this philosophy. It’s so important that this is the very first thing I look for when I am called in for a performance healthcheck review.
This post will take a quick look into why. Read the rest of this entry
Every single BI system has a time/date/period/calendar hierarchy in it. If you use the BI Apps, it actually comes with 2 different tables for this purpose alone, along with a ton of OOB capability. However, when you are faced with a pure custom system from scratch, how do you build one? What does it look like? What sort of data should it have in it?
I’m going to lay out what a decent Time Hierarchy looks like from an OBI and data model perspective. From there I’ll then demonstrate how to actually build one yourself instead of relying on complex code. Along the way we’ll mix in some best practices and theory as well.
Your mileage may vary depending on the specifics of your system, but my goal is to make the design and building of your hierarchy take only 3 hours and last the lifetime of your project (or career). Read the rest of this entry
I’ve always felt that traditional approaches to developing BI content left much to be desired. Going through a traditional requirements approach with users to determine what reports should do, then spending a significant amount of time documenting them, only to finally show them to users after development and find out they aren’t happy with the result is something that I suspect most of you have encountered. I believe a better way to come to a solution that makes users happy is by starting right away with a Prototype. In this article I’ll discuss the generals of prototyping, and specifically how OBI is well suited to this approach.
This is a very common RPD modeling question on IT Toolbox – it comes up every week it seems. The problem is stated something like this:
I have 2 fact tables and 3 dimension tables. One of the dimension tables doesn’t work with Fact #2 while the other 2 dimension tables work with both facts. When I make a report with all 3 dimensions and both facts, Fact #2 is incorrect or missing. Read the rest of this entry
There are still slots open for my KPI Partners webinar on High Performance OBI next Tuesday at 1pm EST. I hope to see you there!
In the past I’ve written and presented on OBI performance from the ‘before perspective’: before you begin development, what are the things you should plan on and how should you implement them. This paper however is with the ‘after perspective’; what to do if you are stuck with a performance problem that you need to solve quickly. It will use the Financial Analytics (All versions) application from Oracle’s BI Applications (aka the BI Apps) to walk through a plan of attack and demonstrate specific changes using the Oracle Database 10x. Thus, this paper has two purposes:
- Specifically to document actual changes for Financial Analytics
- Generally to walk through a performance tuning effort that you yourself may undertake
Note: You do not need to be working on Financial Analytics or even the BI Apps for the concepts in this article to apply. It merely uses Financial Analytics as its example, and where appropriate I will explain the model.
I’m going to do something a bit different with this article in that I will tell the story of a recent performance tuning project for a client. A previous integrator had delivered Financial Analytics and it was up and running in a production environment, but the performance was terrible. Many queries were over 8 minutes. We were asked to tune the GL Transactions star, but the lessons learned here will work for all modules of Financial Analytics, regardless of version. In fact, implementing them for only one star actually boosted the performance of the other Financial Analytics Subject Areas. Read the rest of this entry