Data Modeling: Associations, Joins, Synthetic Keys, Circular References, Star and Snowflake Schemas
Start from the grain
Qlik Sense does not enforce a schema; it infers associations from identically named fields. That freedom is exactly what the exam tests. A well-modeled app is usually a star schema: one fact table at the finest grain of the business event, surrounded by dimension tables, each connected through a single, well-named key. A snowflake normalises a dimension into sub-dimensions; it is valid but adds hop-by-hop work and more keys to maintain.
Two tables that share more than one field name have all their common fields collapsed into a synthetic key ($Syn 1). A synthetic key is not an error - the app still calculates - but it bloats memory, obscures the real key, and usually signals unintended duplicate field names. Fix it by renaming or dropping fields, or by building an explicit link table. A circular reference (a loop of associations) is a hard problem: Qlik cannot decide which path to use, so a table becomes loosely coupled. Break the loop by removing a field, aliasing a key, or introducing a bridge table.
Know the script verbs: JOIN merges two tables (risking row multiplication if keys are not unique), KEEP filters one table by another without merging, CONCATENATE stacks rows with matching field sets, and QUALIFY prefixes field names so keys do not associate accidentally.
Rule of thumb: every field ending in ID or KEY should exist in exactly two tables. If it appears in three or more, you likely need a bridge table or a renamed alias.
Worked example: Orders (OrderID, CustomerID, Date) and Customers (CustomerID, CustomerName) share only CustomerID - a clean star. Add CustomerName to Orders and you create a second common field, so Qlik builds $Syn; drop the redundant name from the fact table.