Reporting tool knowledge

I’m finding myself in a situation where my knowledge of the organization’s BI/reporting tools are highly restricted. So, I’m just taking survey, how knowledgeable of an organization’s BI and reporting tools should the tools’ EDW modeler be?

KS_EDW wrote:I’m finding myself in a situation where my knowledge of the organization’s BI/reporting tools are highly restricted. So, I’m just taking survey, how knowledgeable of an organization’s BI and reporting tools should the tools’ EDW modeler be?

It helps but good knowledge of BI concepts, methodology, and approach is more important. Sometimes intimate knowledge, especially isolated, of any one BI tool can be detrimental, when I hear architectural decisions were made in the DW to accommodate nuances of BI tool 'x' I consider that a warning signal. The DW should be BI tool agnostic.

Then you get into reporting and analytics where it is certainly useful to have specific tool knowledge but again if you understand the best practices of any mainstream BI tool the core principles remain the same. Hope that helps.

It would help if you identified the organisations BI tool. If it is one of the in-memory players well that can open up a pandoras box, but if it is microsoft, cognos. BO, Microstrategy, etc. then I believe these comments are valid.

Very valid question…

Some modeling history - For five years I worked with SAS 9 – 9.1 (BI), Crystal 6.5 (Reports) and SPSS (Reports), then I have two years with OBIEE (BI). Over the last year I’ve played with MicroStrategy, Tableau, and Pentaho (limited editions and limited time). My current employer is using BO… I’ve been modeling for this tool… just over a year now.

Anyway, I’ve been using REALLY generic models – nothing fancy or elaborate, mainly because I wasn’t’ sure if I was doing BO a favor or not (and feedback/guidance is nil – no, “well, it would have helped if...” or “you could do this for that requirement…”). We are upgrading to BO 4.0 in a few months AND I’m gearing up to remodel a large majority of the EDW. With these two ideas… I felt it best that I get to know the new/upgraded BO tool’s features.

Don’t get me wrong… I’m comfortable with what I’m doing, but I’d be super-comfortable if I knew the tool better.

It's always helpful if you could engage a specialist BO resource for a short strategy and alignment session.

That’s a very good and desirable situation… I’ll keep it on my list of possibilities. Our shop only has one BO administrator, having a little over a year’s experience with the tool and little/no prior BI experience (and almost no metadata management experience). There are two report developers who came from PC support/setup a year ago… also, no prior experience. We do have a contract for support hours… I will see if I can get some of that time for the session you suggested.

Thanks for your help! I really appreciate the feedback!

I certainly think that whenever possible data modelers and ETL developers should be familiar with the BI tools that will be used. There are limitations and peculiarities with each BI suite, and those can drive what is needed design-wise and data-wise in the DW.

I have found that when reports are developed by developers writing hand-coded SQL, I can just follow DW dimensional modeling best practices and not worry (too much) about the output. But when using a BI tool to support ad hoc reporting, analytics, or dashboarding, I do need to take the peculiarities of the tool into account when building the DW.

For example, I have introduced some snowflaking into my current DW project to support drilling across fact tables at different grains using Business Objects. Just yesterday I built a test Business Objects universe on a development DW to test out a particular design concept and confirm the users would get the desired results in WebI (Web Intelligence) before building out the final DW tables and ETL load logic.

Data warehousing is all about the output… is it easy to use, fast, and do the users get correct results? Designing DW tables and developing ETL logic without awareness of the BI tools and resulting output would be working in a “black box”. You probably wouldn’t be taking full advantage of the BI platform, might limit the users’ potential queries, and run the risk of setting up a model that yields incorrect results in a particular tool.

A common request I receive when building models is make it "bi friendly" or "cube friendly". Unfortunately, that's about the extent of the request provided. At the end of the day, the data structure must provide response times in the database. If the SQL used to report facts and dimensions is slow in the database, it most likely will be slow in the BI tool. When working with Microstrategy, a common request is snowflaking dimensions. This is a result of the desire to avoid distinct counts. I've yet to snowflake a dimension due to performance. My strategy is the same strategy I've employed in building OLTP databases. Build a model based on best practices and then tune as needed. As you build more and more models, you'll understand the performance problems before they're performance problems.

KS_EDW,

In my opinion, it takes years learning and practicing to become a good modeler while it takes only days playing with tools to be comfortable with it.

However the market is so hyped with tools that DW is somehow about knowing about tools. I think this vendor driven market trend is quite dangerous and is recipe for failure as the employers may likely get the wrong people who have only played with the tools without really understanding about DW fundamentals. Guess what? Vendors win and projects lose.

My current employer is using BO… I’ve been modeling for this tool… just over a year now.

If it's dimensional modeling, how could you model your DW system for the tool? I can say OLAP cube is a generic concept of data presentation and hence the dimensional model is the most native format for its source.

If you feel like you need to change your model to suit the tool, I would highly recommend to review and rectify the model based on Kimball methodology, not new BO or any other tools. The key point is, do the modelling right at database level not reporting level.

Having said that, learning new tools may increase your employability for your next job because of the market hype. So I would not mind spending a few days getting my hands on the tools. But just remember that it does little to improve your modelling skills even though it may fool the users into thinking the BI system has got a perfectly workable underlying structure.