TL;DR: The Key Takeaways

Q: What Are Synthetic Keys in Qlik Sense?

Synthetic Keys are anonymous fields that Qlik Sense creates automatically when two or more tables share multiple common fields. These keys represent all possible combinations of the composite key fields. How Do Synthetic Keys Form? When Table A and Table B both contain the fields ProductID AND CategoryID, Qlik Sense creates a Synthetic Key that represents all combinations of these two fields. Example: How Synthetic Keys Are Created Table: Sales├── ProductID├── CategoryID├── Revenue└── Date Tab

Q: Why Are Synthetic Keys a Problem?

Although Synthetic Keys work technically, they can cause significant performance and memory issues, especially with large data volumes.

Q: How Does Script-Based Detection Work in Qlik Sense?

// Synthetic Key Detection Script // List all table names (including Synthetic Keys) FOR i = 0 TO NoOfTables() - 1 LET vTableName = TableName($(i)); // Check if it is a Synthetic Key (starts with $Syn) IF Left('$(vTableName)', 4) = '$Syn' THEN TRACE 'WARNING: Synthetic Key found: $(vTableName)'; ENDIF NEXT i // Analyze field overlaps between tables FOR i = 0 TO NoOfTables() - 1 FOR j = $(i) + 1 TO NoOfTables() - 1 LET vTable1 = TableName($(i)); LET

Q: How Do I Rename Fields in Qlik Sense?

Implementation: Using the AS Keyword // Before the fix: Both tables contain ProductID and CategoryID // Sales table - rename CategoryID Sales: LOAD ProductID, CategoryID AS SalesCategoryID, // Rename to avoid Synthetic Key Revenue, Date FROM [lib://DataFiles/Sales.xlsx]; // Products table - keep CategoryID as-is Products: LOAD ProductID, // Remains as the link field CategoryID, // Unique name in this table ProductName,

Q: How Do You Create Compound Keys in Qlik Sense?

Implementation: Creating Composite Keys // Compound Key for unique identification Sales: LOAD ProductID & '-' & CategoryID AS ProductCategoryKey, // Compound Key ProductID, CategoryID, Revenue, Date FROM [lib://DataFiles/Sales.xlsx]; Products: LOAD ProductID & '-' & CategoryID AS ProductCategoryKey, // Identical Compound Key ProductID, CategoryID, ProductName, Price FROM [lib://DataFiles/Products.xlsx]; // Result: Unique connection v

Q: How Do I Implement a Star Schema in Qlik Sense?

Implementation: An Optimal Data Model Structure // Star Schema: One central Fact Table + Dimension Tables // Central Fact Table FactSales: LOAD ProductID, // Link to DimProducts CustomerID, // Link to DimCustomers DateID, // Link to DimDate Revenue, // Measure Quantity, // Measure Discount // Measure FROM [lib://DataFiles/Sales.xlsx]; // Dimension Tables (separate connections) DimProducts: LOAD ProductID, // Primary

Q: How Do You Use the QUALIFY Statement in Qlik Sense?

Implementation: Automatic Field Qualification // QUALIFY statement for automatic field renaming // Prefix all fields with the table name QUALIFY *; Sales: LOAD ProductID, // Becomes Sales.ProductID CategoryID, // Becomes Sales.CategoryID Revenue, // Becomes Sales.Revenue Date // Becomes Sales.Date FROM [lib://DataFiles/Sales.xlsx]; Products: LOAD ProductID, // Becomes Products.ProductID CategoryID, // Becomes Products.Categor

Q: What Are the Best Practices for the Star Schema?

The star schema is the optimal data model structure for Qlik Sense and avoids Synthetic Keys by design. For comprehensive guidance on data modeling patterns, see the Qlik data modeling best practices documentation.

Synthetic Keys appear when two or more tables share multiple common fields and can drastically hurt performance. Fix strategies: field renaming, compound keys, star schema, and qualified fields. A clean star schema with a central fact table reduces memory usage by up to 70% and improves query performance by 3-5x.

What Are Synthetic Keys in Qlik Sense?

Synthetic Keys are anonymous fields that Qlik Sense creates automatically when two or more tables share multiple common fields. These keys represent all possible combinations of the composite key fields.

How Do Synthetic Keys Form?

When Table A and Table B both contain the fields ProductID AND CategoryID, Qlik Sense creates a Synthetic Key that represents all combinations of these two fields.

Example: How Synthetic Keys Are Created

Table: Sales
├── ProductID
├── CategoryID
├── Revenue
└── Date

Table: Products
├── ProductID
├── CategoryID
├── ProductName
└── Price

→ Synthetic Key: ProductID + CategoryID

Why Are Synthetic Keys a Problem?

Although Synthetic Keys work technically, they can cause significant performance and memory issues, especially with large data volumes.

How Do Synthetic Keys Affect Performance in Qlik Sense?

Memory usage: Up to 300% higher with complex Synthetic Keys

Query speed: 3-10x slower with multiple chained Synthetic Keys

Reload time: 50-200% longer data loading with Synthetic Key chains

Critical Problems with Synthetic Keys

Exponential memory consumption: Each additional Synthetic Key multiplies memory requirements
Cascade effects: Chained Synthetic Keys can destabilize the entire data model
Unpredictable performance: Response times vary depending on user selections
Difficult troubleshooting: Performance issues are hard to identify and trace

How Do You Identify Synthetic Keys in Qlik Sense?

How Do I Use the Data Model Viewer?

The Data Model Viewer for diagnosing synthetic keys is your primary tool for identifying and understanding data model issues.

Step-by-Step Identification in the Data Model Viewer

Open Data Manager: Navigate to Data Manager → Data model viewer
Look for Synthetic Keys: Anonymous tables named $Syn 1, $Syn 2, etc.
Analyze connections: Which tables are linked via Synthetic Keys?
Check field overlaps: Which fields are involved in creating the Synthetic Key?

How Does Script-Based Detection Work in Qlik Sense?


// Synthetic Key Detection Script

// List all table names (including Synthetic Keys)
FOR i = 0 TO NoOfTables() - 1
    LET vTableName = TableName($(i));

    // Check if it is a Synthetic Key (starts with $Syn)
    IF Left('$(vTableName)', 4) = '$Syn' THEN
        TRACE 'WARNING: Synthetic Key found: $(vTableName)';
    ENDIF
NEXT i

// Analyze field overlaps between tables
FOR i = 0 TO NoOfTables() - 1
    FOR j = $(i) + 1 TO NoOfTables() - 1
        LET vTable1 = TableName($(i));
        LET vTable2 = TableName($(j));

        // Count common fields
        LET vCommonFields = 0;
        FOR k = 0 TO NoOfFields('$(vTable1)') - 1
            LET vField = FieldName($(k), '$(vTable1)');
            IF FieldIndex('$(vField)', '$(vTable2)') >= 0 THEN
                LET vCommonFields = $(vCommonFields) + 1;
            ENDIF
        NEXT k

        IF $(vCommonFields) > 1 THEN
            TRACE 'WARNING: $(vCommonFields) common fields between $(vTable1) and $(vTable2)';
        ENDIF
    NEXT j
NEXT i

How Do You Apply Fix Strategies for Synthetic Keys in Qlik Sense?

How Do I Rename Fields in Qlik Sense?

Implementation: Using the AS Keyword


// Before the fix: Both tables contain ProductID and CategoryID

// Sales table - rename CategoryID
Sales:
LOAD
    ProductID,
    CategoryID AS SalesCategoryID,   // Rename to avoid Synthetic Key
    Revenue,
    Date
FROM [lib://DataFiles/Sales.xlsx];

// Products table - keep CategoryID as-is
Products:
LOAD
    ProductID,                       // Remains as the link field
    CategoryID,                      // Unique name in this table
    ProductName,
    Price
FROM [lib://DataFiles/Products.xlsx];

// Result: Only ProductID is shared → No Synthetic Key

How Do You Create Compound Keys in Qlik Sense?

Implementation: Creating Composite Keys


// Compound Key for unique identification

Sales:
LOAD
    ProductID & '-' & CategoryID AS ProductCategoryKey,  // Compound Key
    ProductID,
    CategoryID,
    Revenue,
    Date
FROM [lib://DataFiles/Sales.xlsx];

Products:
LOAD
    ProductID & '-' & CategoryID AS ProductCategoryKey,  // Identical Compound Key
    ProductID,
    CategoryID,
    ProductName,
    Price
FROM [lib://DataFiles/Products.xlsx];

// Result: Unique connection via ProductCategoryKey

How Do I Implement a Star Schema in Qlik Sense?

Implementation: An Optimal Data Model Structure


// Star Schema: One central Fact Table + Dimension Tables

// Central Fact Table
FactSales:
LOAD
    ProductID,       // Link to DimProducts
    CustomerID,      // Link to DimCustomers
    DateID,          // Link to DimDate
    Revenue,         // Measure
    Quantity,        // Measure
    Discount         // Measure
FROM [lib://DataFiles/Sales.xlsx];

// Dimension Tables (separate connections)
DimProducts:
LOAD
    ProductID,       // Primary Key
    ProductName,
    CategoryID,
    CategoryName,
    Price
FROM [lib://DataFiles/Products.xlsx];

DimCustomers:
LOAD
    CustomerID,      // Primary Key
    CustomerName,
    Region,
    Country
FROM [lib://DataFiles/Customers.xlsx];

DimDate:
LOAD
    DateID,          // Primary Key
    Date,
    Year,
    Quarter,
    Month
FROM [lib://DataFiles/Calendar.xlsx];

// Result: Clean 1:n relationships, no Synthetic Keys

How Do You Use the QUALIFY Statement in Qlik Sense?

Implementation: Automatic Field Qualification


// QUALIFY statement for automatic field renaming

// Prefix all fields with the table name
QUALIFY *;

Sales:
LOAD
    ProductID,       // Becomes Sales.ProductID
    CategoryID,      // Becomes Sales.CategoryID
    Revenue,         // Becomes Sales.Revenue
    Date             // Becomes Sales.Date
FROM [lib://DataFiles/Sales.xlsx];

Products:
LOAD
    ProductID,       // Becomes Products.ProductID
    CategoryID,      // Becomes Products.CategoryID
    ProductName,     // Becomes Products.ProductName
    Price            // Becomes Products.Price
FROM [lib://DataFiles/Products.xlsx];

// Define the shared link field
UNQUALIFY ProductID;   // ProductID in both tables without prefix

// Result: Only ProductID is shared, all other fields are qualified

What Are the Best Practices for the Star Schema?

The star schema is the optimal data model structure for Qlik Sense and avoids Synthetic Keys by design. For comprehensive guidance on data modeling patterns, see the Qlik data modeling best practices documentation.

What Are the Advantages of the Star Schema in Qlik Sense?

3-5x faster query performance through fewer table hops

40-70% lower memory usage through optimized associations

Easier to understand for developers and end users

Simpler to maintain and extend the data model

How Do You Implement a Star Schema in Qlik Sense?

Component	Purpose	Fields	Best Practice
Fact Table	Central transaction data	Foreign Keys + Measures	A single large fact table
Dimension Tables	Descriptive attributes	Primary Key + Attributes	Normalized, smaller tables
Date Dimension	Time-based attributes	DateID + Calendar hierarchies	Always as a separate dimension
Bridge Tables	Many-to-many relationships	Foreign Keys	Only when absolutely necessary

How Do I Optimize a Data Model Optimization Workflow in Qlik Sense?

The 8-Step Optimization Process

Analysis: Open the Data Model Viewer and identify Synthetic Keys
Documentation: Document all affected tables and fields
Business Logic Review: Are all relationships logically correct?
Choose a fix strategy: Field renaming vs. compound keys vs. star schema
Script backup: Save the existing script before making changes
Implementation: Apply the chosen solution step by step
Testing: Compare memory usage and performance before and after
Validation: Verify the factual correctness of results

How Do I Monitor Performance in Qlik Sense?

Key Performance Indicators (KPIs) to Monitor

Memory Usage: Target below 2 GB for standard apps
Reload Time: Target below 5 minutes for typical ETL processes
Query Response: Target below 2 seconds for standard charts
User Experience: Smooth navigation with no noticeable delays

What Common Mistakes Should You Avoid with Qlik Sense Synthetic Keys?

The Top 5 Data Modeling Mistakes

Descriptive fields as keys: Fields like «Comment» or «Description» should not be used as join fields
Multiple fact tables: Avoid complex multi-fact schemas without a star schema design
Circular references: Loops in the data model lead to unpredictable results
Unqualified auto-joins: Qlik Sense automatically creates associations for fields with matching names
Missing data governance: Consistent naming conventions and documentation are often absent

How Do You Apply Proactive Prevention Strategies?

Best Practices for Clean Data Models

Naming conventions: Use clear and consistent field names
Documentation: Document every table and relationship
Regular reviews: Conduct monthly data model audits
Automated testing: Script-based validation of model quality
Team training: Regular training sessions on data modeling best practices

How Does Performance Compare Before and After Optimization?

Metric	With Synthetic Keys	After Star Schema	Improvement
Memory Usage	8.5 GB	2.8 GB	-67%
Reload Time	25 minutes	8 minutes	-68%
Chart Response	8-15 seconds	1-3 seconds	-75%
User Satisfaction	65%	92%	+42%

What Further Resources Are Available on Qlik Sense Synthetic Keys?

Related Qlik Sense Guides

Why Clean Data Models Are the Key to Performance in Qlik Sense

Synthetic Keys are a sign that a data model needs attention. By consistently applying star schema principles, clean field renaming, and strategic compound keys, you can drastically improve the performance of your Qlik Sense applications.

Goal: No Synthetic Keys through optimal star schema design

Result: 3-5x better performance and 40-70% lower memory usage

Benefit: Better user experience and easier maintenance

Invest in data model quality from the start — the performance gains and reduced maintenance costs justify the initial effort many times over.

Sources and References for Qlik Sense Synthetic Keys

Source	Title	URL
Qlik Help	Synthetic keys	help.qlik.com/synthetic-keys
Qlik Community	How to solve synthetic key in Qlik Sense	community.qlik.com/synthetic-key-solutions
Ometis	Synthetic Keys in Qlik Sense	ometis.co.uk/synthetic-keys
Qlik Help	Viewing and transforming the data model	help.qlik.com/data-model
Ometis	Data Modelling Best Practices	ometis.co.uk/data-modelling-best-practices

klarmetrics

Qlik Sense Synthetic Keys: How to Identify and Fix Data Model Problems