Comments on: Does Qlikview need a DWH? The sage continues http://www.quickqlearqool.nl/?p=568 it's all about QlikView Fri, 03 Sep 2010 05:31:37 +0200 hourly 1 http://wordpress.org/?v=3.0.1 By: Christian Bader http://www.quickqlearqool.nl/?p=568&cpage=1#comment-600 Christian Bader Sat, 13 Jun 2009 21:10:58 +0000 http://www.quickqlearqool.nl/?p=568#comment-600 Hi, QlikView is great for data analysis and a small company could start without a underlying data warehouse. You could even build your data warehouse with QVD files, but you would need to build a lot of functionality (eg. transactions, updates, etc) yourself. Common DBMS are delivering this. Another problem is, that QlikView is not easibly able to deliver data via ODBC/OLEDB/WebService, etc. for other application, which a normal DWH is typically doing. I would suggest the following architecture. First you are storing your data in a simplified DWH (eg. large tables, no extensive precalculations, no star/snowflake schema, etc.) and then you are loading your data to QlikView (QVD and QVW). I think, that this is the most valuable approach for end users and other applications. Regards Christian Hi,

QlikView is great for data analysis and a small company could start without a underlying data warehouse. You could even build your data warehouse with QVD files, but you would need to build a lot of functionality (eg. transactions, updates, etc) yourself. Common DBMS are delivering this. Another problem is, that QlikView is not easibly able to deliver data via ODBC/OLEDB/WebService, etc. for other application, which a normal DWH is typically doing.

I would suggest the following architecture. First you are storing your data in a simplified DWH (eg. large tables, no extensive precalculations, no star/snowflake schema, etc.) and then you are loading your data to QlikView (QVD and QVW). I think, that this is the most valuable approach for end users and other applications.

Regards
Christian

]]> By: Gilles http://www.quickqlearqool.nl/?p=568&cpage=1#comment-595 Gilles Fri, 12 Jun 2009 06:40:27 +0000 http://www.quickqlearqool.nl/?p=568#comment-595 Juan, I can agree with you for the biggest part of your reaction. I cannot agree with you on your last paragraph where you can think of a situation where some QV apps consume data from outside the warehouse. I can think of that as a temporary solution, but we all know that temporary solutions in the end will become permanent solutions. Which will result in an explosion of QV applications and then, what's the difference with Excel. In my opinion you should always try to make the datawarehouse the single entry point to information. The datawarehouse is the place where you can maintain sound definitions, make sure that data quality is high enough to base decisions on, data is clean, etc. etc. I do agree with you that the dwh could become the monster preventing quick and simple solutions, but that has a lot to do with good architecture and design of your warehouse. Two good articles on architecture (and a third coming up) is available for download here: http://www.prudenza.nl/nl/library/ Cheers, Gilles Juan,

I can agree with you for the biggest part of your reaction. I cannot agree with you on your last paragraph where you can think of a situation where some QV apps consume data from outside the warehouse. I can think of that as a temporary solution, but we all know that temporary solutions in the end will become permanent solutions. Which will result in an explosion of QV applications and then, what’s the difference with Excel.

In my opinion you should always try to make the datawarehouse the single entry point to information. The datawarehouse is the place where you can maintain sound definitions, make sure that data quality is high enough to base decisions on, data is clean, etc. etc.

I do agree with you that the dwh could become the monster preventing quick and simple solutions, but that has a lot to do with good architecture and design of your warehouse. Two good articles on architecture (and a third coming up) is available for download here: http://www.prudenza.nl/nl/library/

Cheers,
Gilles

]]> By: Juan http://www.quickqlearqool.nl/?p=568&cpage=1#comment-591 Juan Thu, 11 Jun 2009 13:36:59 +0000 http://www.quickqlearqool.nl/?p=568#comment-591 Great post Gilles. In my opinion the discussion of whether QlikView can replace a warehouse or not must be put in perspective to what is actually happening right now in the market. More often than not companies that get started with QlikView have already invested in a DWH so it doesn't make any sense to reinvent the wheel. In those cases QlikView is the perfect match for extracting the data within the warehouse an making it available to everybody in the most cost/effective way. For companies that are just getting started with BI (rarely big companies), it is a question of volumes. How much history and detail to store and the particulars of the industry in which the company is operating are factors to consider. If the volumes are easy enough to handle then a QlikView solution without a DWH may work well. But if the complexities of keeping/storing historical data, and the requirements of data integrity (ie consolidating data from various source systems) are too difficult to handle with scripting and QVDs then a warehouse might be desirable. All this back-end talk is independent of the specific reporting/analysis needs of the end users. We can think of a situation where some QlikView apps consume data from the DWH while others don't need the warehouse at all, and may extract data directly from a particular source system/s. This a very flexible approach, because it frees the DWH from becoming a unnecessary monster or bottleneck to deploy simple solutions quickly. Great post Gilles. In my opinion the discussion of whether QlikView can replace a warehouse or not must be put in perspective to what is actually happening right now in the market. More often than not companies that get started with QlikView have already invested in a DWH so it doesn’t make any sense to reinvent the wheel. In those cases QlikView is the perfect match for extracting the data within the warehouse an making it available to everybody in the most cost/effective way.
For companies that are just getting started with BI (rarely big companies), it is a question of volumes. How much history and detail to store and the particulars of the industry in which the company is operating are factors to consider. If the volumes are easy enough to handle then a QlikView solution without a DWH may work well. But if the complexities of keeping/storing historical data, and the requirements of data integrity (ie consolidating data from various source systems) are too difficult to handle with scripting and QVDs then a warehouse might be desirable.
All this back-end talk is independent of the specific reporting/analysis needs of the end users. We can think of a situation where some QlikView apps consume data from the DWH while others don’t need the warehouse at all, and may extract data directly from a particular source system/s. This a very flexible approach, because it frees the DWH from becoming a unnecessary monster or bottleneck to deploy simple solutions quickly.

]]> By: Gilles http://www.quickqlearqool.nl/?p=568&cpage=1#comment-538 Gilles Thu, 04 Jun 2009 09:17:07 +0000 http://www.quickqlearqool.nl/?p=568#comment-538 And here is Ronald's reaction: http://prudenza.typepad.com/dwh/2009/06/the-qlikview-chronicles-the-sage-continues-ii.html And here is Ronald’s reaction: http://prudenza.typepad.com/dwh/2009/06/the-qlikview-chronicles-the-sage-continues-ii.html

]]>