QlikView App Dev

Discussion Board for collaboration related to QlikView App Development.

Announcements
Action-Packed Learning Awaits! QlikWorld 2023. April 17 - 20 in Las Vegas: REGISTER NOW
cancel
Showing results for
Did you mean:
Creator III

What is meant by "Granularity of data"?

Hi all,

Can anybody please tell me what it means by "granularity of data" in QlikView?

I often hear it being mentioned I am confused on what it actually means

8 Replies
Specialist

The level of detail.

Invoices, for example:

- you can have the following columns: Customer, Invoice, Date, Value

or

- you can have:Customer, Invoice, Date, Product, Value

The second case is more granular than the first case. More details, more rows.

MVP
Champion III

Or a very simple scenario - Data could have a granularity of say, Hourly, Daily, Monthly, Yearly etc.............

It defines the aggregation level of data. For example, in retail shop transactions happen every minute of the day.

There are different users at different level would like to visualize the data on day basis, or month basis or quarter basis. So granularity can be at  day, month or Quarter level etc. All transaction values need to be aggregated ( sum, avg as per the need) based on the defined granularity of data.

Creator III
Author

So is Year a high granularity data compared to a date which is low granularity?

Specialist

No, the other way: the more you go into details, the more granular data you have.

Think about a pile made of grains of sand. The more grains you have, more granular is your pile.

Champion III

High granularity is what defines data to the most precision, so in my scenario Hourly is the highest granularity, then Daily next highest, Monthly next after that and Yearly the lowest granularity.

Hence the higher the granularity the more data rows you will have.

Partner - Champion

Why not just Google it! Like I did:

Granularity is usually mentioned in the context of dimensional data structures (i.e., facts and dimensions) and refers to the level of detail in a given fact table. The more detail there is in the fact table, the higher its granularity and vice versa. Another way to look at it is that the higher the granularity of a fact table, the more rows it will have.

Let me illustrate with the following example: Say we have a data mart with a single fact (Sales) and three dimensions (Time, Organization and Product). The fact table contains three metrics (Unit Price, Units Sold and Total Sale Amount). The Time dimension consists of four hierarchical elements (Year, Quarter, Month and Day). The Organization dimension consists of three hierarchical elements (Region, District and Store). The Product dimension consists of two hierarchical elements (Product Family and SKU).

As always, the metrics in the Sales fact table must be stored at some intersection of the dimensions (i.e., Time, Organization and Product). Hence, in this data mart, the highest granularity that we can store Sales metrics is by Day/Store/SKU (i.e., the lowest level in each dimensional hierarchy). Conversely, the lowest granularity that we can aggregate Sales metrics to in this data mart is by Year/Region/Product Family (i.e., the highest level in each dimensional hierarchy). We may also (for a variety of performance reasons) choose to store Sales metrics at some intermediate level of granularity (e.g., by Month/District/SKU).

Community Browser