Defining relationships between datasets in a Topic
| Applies to: Enterprise Edition |
| Intended audience: Amazon Quick administrators and authors |
Relationships tell Quick Sight how to join datasets when a question or visual spans multiple tables. You define relationships by specifying join keys between dataset pairs using a JSON configuration file.
The relationship graph must be a directed acyclic graph (DAG) — circular relationships are not supported. We recommend modeling your datasets in a star schema with one or more central fact tables joined to shared dimension tables.
To define relationships between datasets
-
Open the Topic that you want to configure.
-
Navigate to the Relationships tab.
-
Choose Upload file or Create manually.
-
Upload a JSON file defining your relationships (see the following example). After uploading, the relationship graph displays visually at left and the join key details appear at right. Select a join to verify the relationship mapping.
-
To edit a relationship, choose Edit, update the join columns using the dropdown selectors, and choose Save.
Relationship JSON format
The following example shows a star schema configuration with a central SALES_FACT table joined to dimension tables:
{ "datasetPairs": [ { "datasetLeft": { "datasetName": "SALES_FACT", "joinColumnNames": ["CUSTOMER_ID"] }, "datasetRight": { "datasetName": "CUSTOMER_DIM", "joinColumnNames": ["CUSTOMER_ID"] } }, { "datasetLeft": { "datasetName": "SALES_FACT", "joinColumnNames": ["PRODUCT_ID"] }, "datasetRight": { "datasetName": "PRODUCT_DIM", "joinColumnNames": ["PRODUCT_ID"] } }, { "datasetLeft": { "datasetName": "SALES_FACT", "joinColumnNames": ["STORE_ID"] }, "datasetRight": { "datasetName": "STORE_DIM", "joinColumnNames": ["STORE_ID"] } } ] }
Each entry in datasetPairs specifies a pair of datasets and the
columns used to join them. Composite keys are supported by including multiple
column names in the joinColumnNames array.
Best practices for relationships
-
Start with a star schema. A central fact table surrounded by dimension tables minimizes join complexity and maximizes query performance.
-
Use clean join keys. Use integer surrogate keys where possible. Confirm matching data types on both sides. Remove null values from join key columns (nulls never match in inner joins).
-
Validate referential integrity. Every foreign key in the fact table should exist in the dimension table.
-
Avoid circular joins. The relationship graph must be acyclic. If your model creates a cycle, break it by removing one leg and denormalizing the redundant path.
-
Pre-join snowflake chains when feasible. If a dimension has sub-dimensions (for example, Customer → Geography → Region), consider flattening them into a single dimension dataset to reduce join hops.
Current limitations
The following limitations apply to defined relationships:
-
Relationships use inner join semantics for analysis sheets. Only rows with matching keys in both datasets appear in results.
-
The relationship graph must be acyclic (no circular joins).
-
Self-relationships (a dataset related to itself) are not supported.
-
All datasets in a Topic must use the same query mode (SPICE or Direct Query).
-
A Topic cannot exceed 12 datasets.
Note
When using Topics in Amazon Quick chat, the LLM-powered chat agent is not limited to inner joins. It can generate SQL with left joins, outer joins, unions, and subqueries based on your custom instructions. These join-type limitations apply only to the analysis sheet consumption path.