Minimalist Design for the Criteria Tab

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.

Build Your Own Time Hierarchy

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).

QA for OBI (Part 2 – The Tests)

In the last post I discussed some general, overall topics to prepare you for a better QA cycle.  In this post I’d like to get into the details a bit more to discuss some of the actual tests you can perform across both ETL and OBI layers.  In particular I’m going to focus on data testing for ETL and OBI.

QA for OBI (Part 1 – Planning)

It seems that every client and every project (I think I’m in the 40’s now) has a different way of QA’ing their OBI system.  This holds true for whether you are doing a BI Apps deployment or simply a new deployment of a custom solution.  This post will set the foundation for the discussion of what needs to be QA’d and how to break the multi-layered solution into more manageable units.

I get the feeling sometimes that my customers are expecting QA to be something perfectly pre-canned that I can simply show up with, fill in the cells in a spreadsheet, and off we go.  The reality is that each project by nature is different, starting from a different place, executed in a different manner, and with different people involved.  It follows that some of the specifics of the QA cycle will therefore be different as well.

Prototyping with OBI

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.

Making Dims & Facts Work Together

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.

Advanced MetaData Presentation

I gave this presentation recently at Rittman Mead forum in Atlanta.  Its about some common MetaData problems that people encounter.  It even includes some 11g stuff in there, so its up-to-date.  This preso is more like a training deck than an overview of technology and features – I try to dig deeper into the Zen of Logical Table Sources a bit more.  Hope you enjoy!  McQuigg_Advanced MetaData Topics

Link to OBI Performance Webinar is Up

KPI Partners just posted my Webinar on High Performance BI.  Its free to watch, so take a look.  Or if you prefer, here is the slide deck called Planning for High Performance OBI – June 2011. Comment on this blog as opposed you YouTube if you want me to respond! – Jeff M.

 

Still room for next week’s Performance Webinar

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!

Performance Tuning and Financial Analytics

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:

1. Specifically to document actual changes for Financial Analytics
2. 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.