I went to QlikView (QV) training last week and I am sure some people might be wondering how it stacks up against MicroStrategy just as I was curious. Well, for starters I should say I am impressed with its presentation layer (a.k.a the reporting layer). Its very sleek and crisp and the whole graph building and design is much easier and very intuitive as compared to MicroStrategy (MSTR).

Traditional MSTR application developers will need ’some’ getting used to the presentation layer of QV because the interface of the application is very different. For example QV doesn’t have a schema layer. Yes, you read it right, no schema layer. No Attributes, No Facts, No Transformations, etc. Skeptical? I was too until I took the classes.

Everything in QV is at the Document layer (which is similar in concept to MSTR Documents but different in the way its implemented and works). Documents have ‘1-n’ sheets where each sheet acts as a report with many charts, graphs, tables (note that table in QV is similar to a report in MSTR). These sheets also contain control objects like List Objects that list elements and Multi-Boxes that list elements from multiple fields (Fields = Attributes in MSTR). You click on the List object element and the charts/graphs/tables change accordingly; you click on particular element (or list of elements) on the chart/graph/table and presentation layer changes accordingly. This helps in the end users assimilating info much faster.

How does QV achieve all this without having the schema layer? The trick is QV also plays in the ETL layer, unlike MSTR, and builds it own database, that it calls “Associative Database” which the QV developer is responsible for building. This associative db, which includes the logical model and the actual data, resides in-memory on the QV server. As a result, when the end-user clicks on element(s) in the List Object or multiple elements in Multi-Box objects the sheet information changes accordingly based on the element(s) selected without having to re-run or refresh like we traditionally do in MSTR. Hence the name QlikView. You click it and view it.

Please understand that QV has much much more to offer than List Objects and Multi-Box objects. I am only mentioning these two because of time constraints involved in explaining entire QV presentation layer functionality.

Once the associative db is built (involves ETL’ing the data with scripts ), all the tables and its fields are available for the developers and users to start building the presentation layer. The associative db is ‘NOT’ cube based. QlikView recommends using Star and Snow Flake models but it works with any model. The idea is to connect one table to another based on associations between them, in essence connecting based on a primary key. An important side note here is that the column names have to be homogeneous. NO HETEROGENEOUS column names, period.

One thing I really like about QV is that we can pull data from multiple data sources via ODBC, OLE DB, CSV, Excel, XLM, etc into one associative db. So for example assume you have sales data in an oracle db and employee data (or any User Defined Data) in excel, and the requirement is that you need reporting by employees; then all you need to do is first pull the sales data into the associative db followed by the employee info from excel and boom it starts working as long as there is a logical association between sales and employee tables. Note that the order in which you pull tables into associative db doesn’t matter. Another important feature of QV is that it doesn’t have Filters, Metrics, Prompts, Custom Groups, and most of the ‘Application Objects’ of MSTR nor does it have a Metadata. Therefore, the deployment of the presentation layer is pretty fast. I know it sounds weird for us MSTR consultants, but it’s true and it works seamlessly.

Oh, and a very useful thing I found in QV is that you can change the field names of tables whenever you want which MSTR doesn’t allow us to do.

For all its good presentation layer and innovative ‘Associative DB’ concepts I do thing its not very scalable. Instructors in the class did say that with the current QV8.5 version the application can scale up to databases with 2 billion records and that the new version (version 9) goes beyond that limit.

Conclusion:
1) QV has really good presentation layer. I hate to say it, but much better than MSTR
2) I think its not very scalable.
3) Good for Data marts and Departmental BI that need fast deployment. Of course effort is needed in building a robust ETL layer (that leads to a good Associative DB)

Disclaimer: I have been working with MSTR for the last 7 years. I have known QV for only 3 months and its internal workings since only last week. So digest what I said about QV with a grain of salt since I don’t have hands-on working experience with it.

UPDATE: since my original post, our company  participated in a real-life POC, we loaded over a terabyte of data for  a social networking company on a server with 32Gb of memory.  This feat was possible because of how amazingly well QlikView  compresses data.  If moores law holds true, we will see the size of ram increase  exponentially as the price per GB drops.

sravan BI Industry, MicroStrategy QlikTech, qlikview, qlikview vs microstrategy