In QlikView there is no hard and fast property or rule that defines this for all scenarios. It is definitely a 'thing' in the world of data modelling and it does translate into QlikView's associative model.
In your data model (to view it go to file -> Table viewer) you will see 1 or more tables. ( If you have 1 table then consider it a fact table. ) The tables with numeric values that you use for chart expressions can be thought of as your fact table . You can have more than one fact table in a data model , but often with this scenario in QlikView it is common to merge the 2 fact tables into one big table using joins or table concatenation. Fact tables are usually quite granular. They often have a date or time field in them for example. The individual rows in a fact table are called 'facts'
Examples of fact tables are :
- a list of sales orders (including Sale amount)
- a list of trades in the stock market
- a list of employee movements (status changes)
- a list of expense items
A table without a numeric field (that is, without a numeric field that will be used in an expression) you can think of as Dimension table. They usually provide additional descriptive information about the facts in a fact table. The fields in a dimension table are often used as chart dimensions, filters for list boxes / multiboxes etc and search boxes
Examples of dimension tables are:
- Customer ( The customers name, address, location etc..)
- Product ( The product's name , The product grouping, its color etc...)
- Employee ( Tenure , department etc..)
A common way to organize a data model is a star schema because it minimized the amount of rows and columns in a data model and still store all the infortmation. Its called a start because the middle is the fact table, and the fact is joined to more than one dimension table. Visually to show the links clearly between the fact table and all the dimension tables is to arrange the dimensions in a circle around the fact to look like a 'star' . Thats pretty much it.
If you had a list of sales orders as a fact. Each row or fact may have a customer ID, a Sales Rep ID, a product ID etc.. And then you would have 3 dimension tables. A customer table with customer ID, a Sales Rep table with Sales rep ID and a product table with product ID. it doesn't have to be ID, just something that links the tables together.
This is important because the user can now question the fact table from a customer standpoint , a rep performance standpoint or a product standpoint. They can analyze the data from any angle and get their answer quickly and have the ability to drill down to details and answer the next question. Its the key thing to turn your qlikview applications from a visual dashboards to an application that can provide root cause analysis and answers to unexpected questions.
one step further: a 'snowflake' is a star schema but when the dimension tables themselves have 1 or more extra dimensional table dangling off them. For example a customer table may have a list of customers and their addresses and cities, but a secondary table may have all the cities + their countries and regions. The Customer is the dimension table joined to the fact table, while the Customer Location table is 'snow flaked' off the Customer dimension table and it does not join directly to the fact table.
help ?
.png "Former Employee"){kind=icon}
