QSDA key terms

An extra field Qlik creates automatically when two tables share more than one field name; the shared fields are combined into a composite key, which usually signals a model that needs redesigning.

A loop formed when three or more tables are associated so that data can travel from a table back to itself; it makes selections ambiguous and forces Qlik to guess which path to use.

A model with one central fact table holding keys and measures, surrounded by dimension tables that each connect to it through a single shared key field.

A star schema where dimension tables are normalised into further related tables, so a lookup must pass through more than one table before reaching the fact.

A script prefix that merges two loaded tables into one wider table, matching rows on shared field names and keeping columns from both sides.

A script prefix that filters one table against another using their shared key fields, leaving both tables separate instead of merging them into one.

A script statement that links a point value such as an event timestamp to a table of numeric intervals, expanding the point across every interval that contains it.

A table containing only key fields that sits between fact and dimension tables to break circular references or to resolve many-to-many relationships.

One shared date key built from several differently named date fields in the source, so every event associates to a single reusable calendar dimension.

A load prefix that prefixes every field name with its table name, preventing accidental associations between tables that reuse generic names such as Date or ID.

Appending the rows of one table to another with the same structure; Qlik performs this automatically when field names and field counts match exactly.

A prefix that prevents Qlik from performing an automatic concatenation, keeping a newly loaded table separate even though its fields match an earlier table.

Loading data from a table already held in memory rather than from the source system, typically to derive fields or reshape data without another extraction.

Stacking several LOAD statements so that each reads from the one written below it, layering transformations that read naturally from top to bottom.

A pattern that appends only new or changed records to an existing store, using a high-water mark such as the largest key or timestamp already loaded.

A script function that replaces values in a field using a previously loaded mapping table, avoiding a join when you only need to translate codes into labels.

A two-column table declared with the MAPPING keyword, holding from-to pairs that ApplyMap uses to translate or clean field values.

A function that returns one field value from a specified row of an already loaded table, often used to carry a value across loop iterations.

A function that tests whether a value already appears in a loaded field, commonly used to load only the records that are not yet in the model.

A load prefix that turns a spreadsheet-style matrix, with values spread across many columns, into a normalised table of row, column and value.

Loading the complete data model of another Qlik app, letting a downstream app reuse an already transformed model without repeating the source extraction.

Substituting a variable's value into the script text before it executes, enabling parameterised file paths, cut-off dates and reusable code fragments.

A dimension whose attributes change over time, handled either by keeping history rows with valid-from and valid-to dates or by overwriting with the current value.

Treating blank field values deliberately, because unmatched keys appear empty and silently drop out of sums, counts and associations.

The level of detail at which a table stores its rows, such as one row per order line rather than per order; mixing levels inflates totals.

Making sure the same entity carries identical key values in every table, matching data type, case, padding and trimming so associations resolve correctly.

Script steps that correct values before they reach the model, such as trimming spaces, standardising case, fixing data types and mapping codes to readable labels.

The guarantee that every key in a fact table exists in the matching dimension; orphan keys otherwise produce blank dimension values and lost measures.

Qlik's own columnar file format, written with the store statement and read very quickly, forming the standard building block of a layered data architecture.

Reading a QVD with a plain load that leaves fields untouched, which Qlik can decompress directly; adding expressions or renaming fields forces a much slower path.

Script statements that remove unused columns or intermediate tables from the model, cutting memory use and speeding up reloads and calculations.

A load prefix that caches the result of a slow source query to a local file, so repeated development reloads skip the expensive extraction step.

Summarising a large table to the level of detail actually needed before it enters the model, reducing row counts, memory use and calculation time.

A security table loaded with the SECTION ACCESS statement that limits which rows and fields each named user or group can see when the app opens.

Removing rows from the data model at open time according to the signed-in user's section access entry, so different users see different subsets of one app.

A section access list of field names that are hidden entirely from certain users, so sensitive columns never reach their client.

A container in a Qlik Sense deployment that groups published apps and controls which user groups are allowed to see them.

A scheduled job in the management console that runs an app's load script at defined times, optionally chained to tasks that must finish first.

Splitting a solution into stacked QVD layers for extraction, transformation and presentation, so each layer reloads independently and changes stay contained.

A management console rule that grants users access to apps, streams or data connections based on attributes such as group membership or user name.