QlikView Tools

I am doing little research on QlikView toolsets. I would really appreciate input/feedback on these toolsets. I have also read that these tools can be depolyed without having a DW at the backend.

DilMustafa wrote:I am doing little research on QlikView toolsets. I would really appreciate input/feedback on these toolsets. I have also read that these tools can be depolyed without having a DW at the backend.

I am not familiar with QlikView, but the bit about being able to deploy it without a DW at the back end is hardly a product differentiator. I cannot recall ever working with a BI tool that could not be put on top of an operational database. But given that you could does not mean that you should.

Thank you. I fully agree with you, but I do see various vendors sloganing Operational BI and pitching it in a way that It would not require a DW as a backend.

Hi,
you can deploy QlikView without DB. Just install it and then every QV file can be opened and analyse data in it. This is happened because all data is stored in QV internally, also in QV file is all reports and charts ... and all objects. But then your data will be static. And if you want to get fresh data QV file must be reloaded. If you have correct connections (odbs, ole of files paths) then file will be reloaded and fresh data appears. QlikView is made in this way because if you travelling (or just far from connection) you can open file and analyse data or make a presentation (or something else :-))

In memory tools like these (+Visokio, Tableau etc) are great for quick visualisation, but what happens if you do not have conformed dimensions that enable you to say link PayrollID in the HRSAP system, to empNo in the sales CRM? You need a good underlying warehouse/mart structure to enable any meaningful analysis

sdhayes wrote:In memory tools like these (+Visokio, Tableau etc) are great for quick visualisation, but what happens if you do not have conformed dimensions that enable you to say link PayrollID in the HRSAP system, to empNo in the sales CRM? You need a good underlying warehouse/mart structure to enable any meaningful analysis

The target of these tools is not the "enterprise" market. QlikView is targeted at departmental solutions, where cross-department analysis is not a requirement. And in this area, as much as it pains me to admit it, QlikView really does shine. It allows for very well-performing "guided analytics", without requiring a DW underneath. Of course, the data will only be as clean as the data in the source system.

And, of course, you can always put it on top of a data warehouse, and just use it as a presentation layer as well.

Qlkview seems to be a great tool for prototyping but I wonder what the impact would be on the support team if every one starts to use it.
Everybody is able to create its private ETL, that seems to be support knightmare, not
How do you control that every Qlkview developer uses the same business rule?

Sponko wrote:Qlkview seems to be a great tool for prototyping but I wonder what the impact would be on the support team if every one starts to use it.
Everybody is able to create its private ETL, that seems to be support knightmare, not
How do you control that every Qlkview developer uses the same business rule?

Now we been told that enterprises went from spreadsheet-hell to Qlikview-hell. We have looked into server based QV implementation but we will end up with proprietary QV-mart(s). The drawbacks of QV architecture will be next topic to discuss;

Hi All,

I have done Large deployments using QlikView. Its a really great tool with overcomes traditional BI implemetation. It has its own ETL and Reporting with Reach GUI and In Memory Analysis.

Regards,
Amit