Is it that Informatica needs a frontend or that Qlikview needs a datawarehouse?

Posted by Gilles on 06/03/2009 under Articles, News | 6 Comments to Read

In this press release: http://www.prweb.com/releases/informatica/zyme/prweb2209914.htm you can read that a channel intelligence solution from Zyme uses qlikview in combination with informatica for its solution.

Qliktechs aggressive marketing and sales always told me that there’s no need for a datawarehouse when using qlikview. So it seems strange that Zyme chooses to do so. Or is it that Informatica doesn’t have a solid solution for analyzing business data? But then again why not only use qlikview?

Maybe (and I think you do!) you do need a platform which can handle data from heterogenous sources, which can transform your data to uniform definitions, which can treat history, which can do cleansing and enrichment of your data and then you use qlikview for your analysis and some other product in conjunction for your reports!

So that’s where I position qlikview, as a frontend solution, for analyzing data that’s in a solidly built datawarehouse.

Please feel free to share your insights on this! Where do you position Qlikview? As the all in one solution (DWH and BI) or as a frontend BI tool?

Share and Enjoy:

Tags: article, front end, informatica, qlikview

Jerome Pineau said,

Well, QV truly rocks but its inherent “problem” is that it’s an in-memory solution. So at best it can extract and load chunks of data but not, say, an entire 50TB warehouse. So IMHO it’s a front-end tool which can serve as a “warehouse” for mid-market shops but not in the really big honking database apps.
Gilles said,

Thanks Jerome for your reply. I’m very curious about the behavior of qlikview on a “Big Honking Database”. Analysis of the in-memory data could be a problem, the problem probably will arise even earlier when loading into memory.

Do you have any personal experiences with Qlikview?
Ogooglad said,

Qliktech doesnt need a DW but it is to simplify the world when they claim that qlikview makes a DW unnecessary. Depending on the goals of your business intelligence solution (i.e if you need historic management, slowly changing dimensions) you might or might not need some kind of storage other than the source system itself.
You can do this without a database, but that is not as easy to manage as it is with a database soultion (ie a data warehouse)

Then you have size and complexity – which is also easier to manage in a database than in qlikview, QVD-files or text-files. One problem with the qlikview approach is that many organisations will have 15 different qv-application that all go directly against the sourcesystems which means it will in part use the same code to transform and extract the data and this will be hard to manage from a system developers point of view.

Well, that is it – I would recommend a database as middlestorage – although informatica might be a too complex solution.
Gilles said,

Thanks Ogooglad for your reaction. I think that, in most cases, you will need a middle layer. If that should be a full blown multi layered datawarehouse depends on several factors, for instance the maturity of the organization with intelligence in general. If it’s just the business manager with a few lags in his information need, that’ll do with qlikview or a spreadsheet. But then the next manager and the next et cetera. And indeed you’ll end up with 14 qlikview applications. For the single manager with his own application no problem at all, but to maintain a dreadful job. The next thing that’ll happen is that business manager 1 starts comparing his figures with business manager 2 and sees differences in results.

That’s where some form of a middle layer is needed. Where you can do your cleansing, enrichment, single definitions, history treatment et cetera. And then it comes in handy that you had those 14 or more qlikview applications. Every business manager with an information need (and who hasn’t) has thought about his requirements.

If your middle layer should be a Datavault, Kimball model or inmon model is a whole other discussion.

Anyway, thanks for your reaction!
Cotiso said,

Hi Gilles,
Hi everyone,

There might be another approach for some data sizes: use script-only QVWs to develop intermediary sets of data saved in QVDs. Use those QVD afterwordsto feed various reports for various managers/departments.

It’s true that some issues are rising to keep under control a set of reloads that becomes too complicated, especially if complicated dependencies are affecting the quality of the final reports based on this multi-layer reloads.

We have encounter such issues several times and developed some QVWs to monitor status.

We are considering to transform this knowledge into another QQtool later this year. What do you think, will it be worthy of something ?

Sempre fi,
Cotiso
Juan said,

Hi Gilles,

Further on Cotiso’s comment: we usually regard as a best practice having all QlikView applications reading from QVDs from an ‘intermediate’ layer, produced by these script-only QVWs. Eventually, this intermediate layer can be divided in two: the first one containing the raw data (tables without any transformation) and the second one including new QVDs after applying merging/filtering/transformations/flags.
When you build new applications, chances are they will use the same QVDs from the first layer, eliminating the possibility of duplicated loads.

Regarding DW, I’ve used QVDs effectively to create and store historical data/slowly changing dimensions in companies starting from scratch, but this is rarely the case. More often than not companies (especially the big ones) already have a warehouse. In those cases QlikView fills the gap making the data available for everyone within the organization. In my experience this combination (DW+QV) is terrific.