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
Over my OBI career I’ve had to review dozens of customer and consultant developed RPDs as part of either a formalized health check engagement or simply a developer code review. Frequently the customer has some problems that they can’t solve, or that they have solved with a work-around of some sorts. In some cases this is simply due to not fully understanding the concepts and what you can do with those concepts, but sometimes there is something far worse at play: bad advice from supposed experts.
Twice this year I have come across customers who have been told by other “experts” that Dimensional Hierarchies aren’t that important or they should leave the Content tab empty. One of these so called experts was even an actual Oracle employee! This is disastrous advice as I will demonstrate in this post.
This is my presentation from last week’s Rittman-Mead BI Forum in Atlanta. Incidentally it happens to be the same topic (similar slides) to the KPI Partners webinar from April and what I gave in Denver at Collaborate also in April. The webinar has been recorded, so you can hear my commentary and the QA session afterwards. If you get the chance, I’ll be doing the same preso at Kscope in New Orelans next month. Enjoy!
Ok so I put a provocative title on this post for a reason. This post will explore why some of Kimball’s concepts may be out dated when newer query generation or database capabilities are taken into account. Specifically, I’m going to discuss the OBI concept of Nested Aggregation, also known as Dimension Based Aggregation, in detail. Using this OBI Modeling technique you can relax a bit on one of the Kimball Dimensional Modeling rules. I’ll show how it works in a simplified manner, plus identify some things to be careful with and how it does not alleviate you from doing real modeling work. 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
I’ll be doing a webinar called Planning for High Performance OBI. I’ve given this preso a few times before, but it’ll be good to do it on the web for a change. I discuss some of the basics you should have when beginning your designs. It is not a performance tuning workshop, but rather what to do first to get it done properly the first time. Register through KPI Partners website.