WHen you author a QlikView app you create and save 3 things:
- a reusable data load script
- the last associative data set loaded by the script . See the following to understand its exact structure (The data scalability of Qlik's in-memory associative data model)
- the design of the UI
The business value is not just in the visual aggregation, but also in the associative way Qlik exposes the relationships of data to the users. There are also business problems to be solved by sourcing and integrating data from multiple sources in a reusable script as well sa performance gains to be had from using a great in-memory engine. The data is stored compressed on disk and loaded in memory when the dashboard is being used. The scalability is also excellent (see above note as well) and you can really push it by being attentive to data uniqueness of your fields.
The data set maintains transactional level details, at least to the granularity that was loaded in the load script. You can aggregate the data using GROUP BY and aggregation functions, but there is a lot of reason to keep the detail.
The UI objects contain expressions that typically aggregate the numeric values (sales, revenue etc..) into text or date based buckets . Basically any field is a dimension that will break down the numeric aggregation.
When a user drills down it just reaggregates at a finer level.
Eventually you can actually drill between 2 distinct applications doing document chainining and/or drill to an application that is formed using direct discovery (that does not pre-load all the data). Those are more advanced topics.
