- 1tier is when you load data directly from the underlying files into your QlikView_app;
- 2tier is when you load the data, store it in a qvd and use that in one or several QlikView_apps;<
=> LOADing qvd_files is faster than LOADing the original files;
- 3tier is when you first load the data and store it in a qvd, then load n of these qvd_files in an app ("QlikMart") and lastly you load this QlikMart BINARY into one or several QlikView_apps => LOADing BINARY is the fastest way to load data
The n in n-tier refers to the number of data transfers between original source data and final report. DataNibbler already explained the most common ones. But which n-tier architecture should you choose for your QlikView environment?
Consider the following elements (slightly translated into QV concepts):
Data Source harassment: can you query the original database(s) at random times and intervals and over-and-over again? Or is access to be regulated due to load distribution requirements or simply because of strict access policies? Then consider creating an exact copy of the source data at a very specific point in time. Every other consumer will use data from this copy.
Data consistency: do reports have a free refresh cycle? What happens if users start comparing end-results in the two reports, though their updates happened at different points in time? Even an interval of a few hours may lead to different source data (cf transactions)
Efficiency: Do all reports that use common tables need to load these tables on their own all over again, or can a centralized extraction process provide them with a single local source and alleviate the data sources? Higher up the stack, the same question can be asked as well: if multiple reports need to combine local copies of multiple source tables into exactly the same aggregated tables, do we let them do that on their own all over again? Or can we provide a common aggregator that does the job only once for a multitude of reports?
Efficiency (2): do we need to extract historical data from the data sources again and again, although the data doesn't change anymore after a while (cf transactions). Then consider incremental loads that are accomplished only if some intermediate data level (sometimes very thin) is introduced.
Abstraction: do we present self-service BI end-users with the original data source structures and names, or do we create an abstraction layer that translates raw data into clear values, concepts and objects?