Tableau Quiz: Relationships
10 questions · exam conditions
0:00
RelationshipsQuestion 1 of 10

An Orders logical table contains one row per order and a Sales measure. A Shipments logical table contains one row per shipment. Some orders have multiple shipments. The tables are related by Order ID. A worksheet displays only SUM(Sales) and COUNT(Shipment ID), with no dimensions in the view.

What behavior should the analyst expect from the relationship?

Sales is repeated once per shipment because the relationship always creates a row-level inner join.
Each measure is aggregated at its relevant table's level before Tableau combines the query results.
Shipment count is reduced to one per order because Orders defines the relationship's primary grain.
Only one measure can be accurate because related logical tables must share the same level of detail.
← Back to quizzes

Tableau Quiz

Tableau Quiz: Relationships

Practice Relationships in Tableau with focused quiz questions that help you check what you know, review explanations, and build confidence with test-style prompts.

What this quiz covers

This quiz focuses on Relationships, giving you a quick way to practice the rules, question types, and explanations that matter most for Tableau.

How to use this quiz

Try each quiz question before looking at the correct answer. Use the explanations to review missed ideas, then come back to similar questions until the pattern feels familiar.

All questions

Question 1

An Orders logical table contains one row per order and a Sales measure. A Shipments logical table contains one row per shipment. Some orders have multiple shipments. The tables are related by Order ID. A worksheet displays only SUM(Sales) and COUNT(Shipment ID), with no dimensions in the view.

What behavior should the analyst expect from the relationship?

  1. Sales is repeated once per shipment because the relationship always creates a row-level inner join.
  2. Each measure is aggregated at its relevant table's level before Tableau combines the query results. (correct answer)
  3. Shipment count is reduced to one per order because Orders defines the relationship's primary grain.
  4. Only one measure can be accurate because related logical tables must share the same level of detail.
Explanation: When you see a question about multi-table analysis in Tableau, think about how relationships differ fundamentally from traditional joins. Tableau's relationship model is designed to keep each logical table's grain intact, querying each table independently and combining aggregated results — not merging raw rows before aggregation. This is exactly what makes B correct. When your view contains SUM(Sales) and COUNT(Shipment ID), Tableau issues separate queries: one against the Orders table to compute SUM(Sales) at the order level, and one against the Shipments table to compute COUNT(Shipment ID) at the shipment level. The results are then stitched together at the aggregation layer. Neither table's rows are inflated or collapsed to match the other's grain, so both measures remain accurate simultaneously. A is wrong because relationships do not default to row-level inner joins. That's the behavior of traditional joins in Tableau, where joining Orders to Shipments at the row level would duplicate Sales values for orders with multiple shipments. Relationships were specifically designed to avoid this problem. C incorrectly assumes that one table "dominates" the grain and forces the other to conform to it. Relationships have no concept of a primary grain that suppresses rows from the other table — each table is queried at its own native level of detail. D is a tempting distractor if you're thinking about join-based logic, but it's false for relationships. Tableau's relationship model exists precisely because measures at different grains can coexist accurately in the same view. As a study tip: whenever a question mentions related logical tables and multiple measures, ask yourself — "does Tableau aggregate each table separately?" For relationships, the answer is always yes.

Question 2

Customers and Orders are related by Customer ID. Several customers have never placed an order. An analyst creates a worksheet using Customer Name from Customers and SUM(Sales) from Orders, without filtering out null measures.

What is the most likely result under the default relationship behavior?

  1. Customers without orders can appear in the view with a null Sales value, because the customer domain from the Customers table is relevant to the worksheet. (correct answer)
  2. Customers without orders are always removed from the view, because Tableau applies an inner join whenever a measure from a related table is displayed.
  3. Customers without orders appear with zero Sales, because Tableau automatically substitutes zero for any unmatched measure values across related tables.
  4. Customers without orders appear in the view only after the analyst manually replaces the relationship with a fixed physical left join in the data source.
Explanation: When you see a question about Tableau relationships and nulls, focus on how the Relationships data model differs from traditional joins. Unlike physical joins, relationships preserve each table's domain — meaning Tableau can display records from one table even when no matching records exist in a related table, similar to a context-aware outer join. This is exactly what makes A correct. When you place Customer Name (from Customers) and SUM(Sales) (from Orders) on a worksheet using the Relationships model, Tableau recognizes that the customer domain is the relevant context. Customers without any matching orders will appear in the view with a null Sales value — Tableau doesn't silently discard them just because the measure returns nothing. B is wrong because Tableau's Relationships model does not default to an inner join. That's the key misconception this distractor exploits. Inner joins would eliminate non-matching rows, but relationships are specifically designed to avoid that data loss by adapting the join type based on the fields used in the view. C is wrong because Tableau does not automatically substitute zero for unmatched measure values. The result is null, not zero. You would need to explicitly handle this with something like ZN() or a calculated field. D is wrong because no manual intervention is required. The default relationship behavior already handles this scenario gracefully — you don't need to drop down to the physical layer and hardcode a left join. Study tip: Remember this mantra — relationships preserve domain, joins can destroy it. On the Tableau exam, any answer suggesting relationships behave like inner joins is almost certainly a trap.

Question 3

Orders is related to Customers by Customer ID. Some historical orders contain customer IDs that no longer exist in Customers. An analyst changes the referential-integrity option from "Some records match" to "All records match" because most orders have a matching customer.

Why is this change risky?

  1. Tableau may insert placeholder records into the Customers table to represent the missing customer IDs, permanently altering the underlying data source.
  2. Tableau may treat every order as having a valid customer match and apply query optimizations that cause unmatched historical orders to be silently omitted in some views. (correct answer)
  3. Tableau automatically substitutes Customer Name as the relationship key whenever an order row lacks a corresponding Customer ID in the Customers table.
  4. Tableau blocks aggregation of Sales values and refuses to return results until every unmatched historical order is manually corrected in the data source.
Explanation: When you see a question about referential integrity settings in Tableau relationships, focus on what Tableau assumes about your data — and what happens when that assumption is wrong. Referential integrity tells Tableau how confidently it can join tables. When set to "All records match," Tableau assumes every order has a valid matching customer, so it's permitted to apply inner-join-style query optimizations. This is the source of the risk: those optimizations can silently drop rows that don't have a match, meaning historical orders tied to deleted customer IDs simply disappear from certain views — no warning, no error, just missing data. That's exactly what B describes, and it's the correct answer. The remaining choices describe behaviors Tableau doesn't actually perform. A is wrong because Tableau never writes data back to your source or inserts placeholder records — it's a read-based analytics tool that doesn't modify underlying tables. C is wrong because Tableau doesn't automatically swap relationship keys; the join key is defined by you during data modeling, and Tableau won't silently substitute a different field like Customer Name when a match fails. D is wrong because Tableau doesn't block aggregations or freeze results pending manual corrections — it will still return numbers, which is precisely what makes the "All records match" setting so dangerous: you get results that look complete but are quietly incomplete. A useful rule of thumb: treat "All records match" as a performance optimization that carries a data-integrity cost. Only enable it when you're certain your data has no orphaned foreign keys — otherwise, choose "Some records match" to preserve all rows safely.

Question 4

An analyst has an Orders table and an Order Adjustments table. Every downstream analysis must use a fixed row-level result containing all orders, matching adjustment columns, and a calculated adjusted amount for each joined row. The row-level structure must remain the same regardless of fields placed in a worksheet.

Which modeling approach is most appropriate?

  1. Use a relationship because it always materializes a fixed row-level left join before worksheet queries run.
  2. Use a physical join within a logical table because the required row-level structure is predetermined. (correct answer)
  3. Use a relationship and set its cardinality to one-to-one so unmatched adjustments become joined rows.
  4. Use two unrelated logical tables because Tableau combines all unrelated measures at the workbook level.
Explanation: When Tableau questions describe a fixed, predetermined row-level structure that must persist regardless of what fields are dragged into a worksheet, they're testing your understanding of the difference between physical joins and relationships. In Tableau's data model, a physical join lives inside a single logical table and is resolved before any worksheet query runs — the join is baked in, permanent, and identical for every view. That's exactly what the scenario demands: all orders, matched adjustment columns, and a calculated adjusted amount, locked at the row level. Using a physical join within a logical table (answer B) gives you precisely this behavior. The joined structure is fixed upstream of any analysis. Answer A is a common trap. Relationships do not materialize a fixed left join ahead of time. They are query-time constructs — Tableau dynamically generates joins based on which fields are actually used in a worksheet. The row-level structure therefore changes depending on context, which violates the scenario's requirement. Answer C misunderstands cardinality settings. Cardinality in a relationship controls how Tableau handles aggregation (to avoid double-counting), not whether unmatched rows become joined rows. Adjusting cardinality to one-to-one won't force unmatched adjustment records to appear as joined rows. Answer D is incorrect because unrelated logical tables don't combine at the row level at all — Tableau blends their aggregated results only when measures from both appear in the same view, making row-level joins impossible. Study tip: Watch for phrases like "fixed row-level structure" or "predetermined join" — these are signals that a physical join is required, not a relationship.

Question 5

A retailer receives one Sales file per month. Every file has the same columns and represents additional transactions. An analyst considers relating the January and February files by Product ID so both months can be analyzed together.

Which approach is most appropriate?

  1. Relate the files by Product ID because relationships append matching transaction rows while preserving monthly detail.
  2. Physically join the files by Product ID because a join stacks records from matching monthly structures.
  3. Relate the files by transaction amount because measures provide a more reliable cross-month matching key.
  4. Union the files because the goal is to append rows from tables with the same transaction structure. (correct answer)
Explanation: When Tableau questions describe multiple files with identical column structures containing additional rows of data, your instinct should immediately jump to one concept: Union. The key diagnostic question is, "Am I combining more rows of the same kind of data, or am I combining different attributes about the same entities?" Here, January and February files share the exact same transaction columns — they're simply different batches of the same data. A Union stacks those rows vertically into one continuous dataset, letting you analyze all transactions together while preserving each row's monthly detail. That makes D the correct approach. A is tempting but fundamentally misunderstands what a Relationship does. Relationships in Tableau link tables so that measures aggregate contextually — they don't append rows. Relating two monthly transaction files by Product ID would try to associate products across files, not combine all transactions into one list. You'd also lose granularity at the transaction level. B makes a similar structural mistake. A physical join combines columns from two tables based on a matching key — it doesn't "stack" records. Joining the files by Product ID would produce a cross-product of matching rows, likely duplicating or distorting your transaction data rather than simply appending February's rows after January's. C introduces an additional error on top of B's flaw: using a measure (transaction amount) as a join or relationship key is unreliable and conceptually wrong. Keys should be unique identifiers, not numerical values that naturally repeat across transactions. Study tip: When you see "same columns, additional rows," think Union. When you see "different columns, shared identifier," think Join or Relationship.

Question 6

A data source contains Customers and Orders as separate logical tables related by Customer ID. A worksheet uses only Order Date and Sales from Orders. No field from Customers is used in the view, filters, calculations, or other worksheet dependencies.

Which statement best describes how Tableau uses the relationship for this worksheet?

  1. Tableau must join Customers to Orders because every logical relationship is resolved when the data source opens.
  2. Tableau queries Customers first because the related dimension table controls the domain of every worksheet.
  3. Tableau can query Orders without bringing Customers into the worksheet query because Customers is not required. (correct answer)
  4. Tableau converts the relationship to a physical left join and caches the joined rows for later worksheets.
Explanation: When you see a question about Tableau relationships and query behavior, the core concept being tested is context-aware querying — Tableau's ability to only involve the tables a worksheet actually needs. In Tableau's logical layer, relationships are not pre-executed joins. Instead, they're deferred: Tableau evaluates each worksheet independently and determines which logical tables are truly required. For this worksheet, only Order Date and Sales are used — both live in Orders. Because no field, filter, calculation, or dependency pulls from Customers, Tableau simply queries Orders alone. This is exactly what C describes, and it's the heart of Tableau's "smart" relationship model — unused tables stay out of the query entirely, which improves performance and avoids unintended row duplication or filtering side effects. A is wrong because relationships are not resolved eagerly when the data source opens. That would defeat the entire purpose of the logical layer. Tableau waits until query time, not load time, to decide which tables to touch. B is wrong because no table automatically "controls the domain" of a worksheet. Tableau doesn't assume dimension tables are always primary or always queried. Domain control only becomes relevant when both tables are actually involved in a view. D is wrong because Tableau doesn't silently convert relationships to physical joins or cache joined results for reuse across worksheets. Physical joins are a separate, explicit choice made in the physical layer — relationships deliberately avoid this behavior. Your study tip: remember the phrase "only what the worksheet needs." When a question asks about relationships and query behavior, ask yourself which tables the view actually touches — if a table contributes nothing, Tableau leaves it out.

Question 7

Two logical tables both contain Order ID and Region. Order ID values restart in each region, so Order ID alone is not globally unique. The analyst wants Tableau to match records only when both the order number and region agree.

Which relationship design best satisfies the requirement?

  1. Define relationship clauses for both Order ID and Region so both field comparisons must match. (correct answer)
  2. Relate only on Order ID and mark both tables as many-to-many to account for the regional duplicates.
  3. Relate only on Region and allow Tableau to infer the correct order number from fields used in each view.
  4. Create separate relationships for each region and manually select the applicable relationship in every worksheet.
Explanation: When building relationships in Tableau, the core question is always: what combination of fields uniquely identifies a matching record across both tables? If a single field contains duplicate values because of a logical grouping (like region-specific order numbering), you must include that grouping field as an additional relationship clause — otherwise Tableau cannot distinguish which records truly belong together. This is exactly what answer A solves. By defining relationship clauses for both Order ID and Region, you're telling Tableau: "Only match a row from Table 1 to a row from Table 2 when the order number and the region are identical." This compound matching condition reconstructs the true composite key and produces accurate join behavior across the two tables. B is tempting but wrong. Marking tables as many-to-many doesn't fix the ambiguity — it just changes how Tableau handles aggregation and duplicate counting. The root problem is an incorrect matching field, and many-to-many cardinality won't resolve that. C is a misconception about how Tableau relationships work. Tableau does not infer missing match conditions from fields you drop into a view. The relationship definition is set at the data source level and doesn't adapt dynamically to worksheet context. D describes a workflow that doesn't exist in Tableau. You cannot manually switch which relationship is active per worksheet — relationships are defined once in the data model and apply globally. A useful pattern to remember: whenever Order ID (or any ID) resets within a category, that category field is part of the composite key and must appear as a relationship clause alongside the ID.

Question 8

A company wants to analyze Sales Orders and Support Cases by customer region. Orders contains multiple rows per customer, and Cases also contains multiple rows per customer. The analyst needs SUM(Sales) and COUNT(Case ID) in the same regional view without multiplying order and case rows.

Which logical model best supports the analysis?

  1. Physically join Orders directly to Cases by Customer ID, then relate the joined result to Customers.
  2. Union Orders and Cases into one table, using nulls for fields that are not shared between the record types.
  3. Use Customers as a shared logical table, with separate relationships to Orders and to Cases. (correct answer)
  4. Relate Orders directly to Cases and declare the relationship one-to-one despite repeated customer IDs.
Explanation: When you see a question about combining multiple many-to-many data sources in Tableau, the core concept being tested is Tableau's logical layer and how relationships prevent row multiplication. Ask yourself: "Will joining these tables fan out my data and inflate aggregations?" The cleanest solution here is C — using Customers as a shared "anchor" logical table, with independent relationships to Orders and Cases. In Tableau's relationship model, each related table is queried separately and joined only at the level of aggregation needed. This means SUM(Sales) pulls only from Orders rows, and COUNT(Case ID) pulls only from Cases rows, with Customers tying them together regionally. No cross-joining occurs, so neither metric gets inflated. A fails because physically joining Orders to Cases by Customer ID creates a many-to-many cross join at the row level. A customer with 5 orders and 3 cases produces 15 rows, causing both SUM(Sales) and COUNT(Case ID) to be wildly overcounted before aggregation even happens. B creates a union, which stacks rows from both tables vertically. This forces shared column names with nulls filling the gaps, making clean separate aggregations awkward and the data model semantically confusing. Unions are designed for appending similar data, not mixing orders and cases. D is logically invalid. Declaring a one-to-one relationship when Customer IDs repeat in both tables doesn't make it true — Tableau's relationship engine won't compensate for misrepresented cardinality, and results will be unpredictable. Study tip: When two fact tables share a dimension, always route them through that shared dimension as the anchor — this is the "star schema" pattern Tableau relationships are built to support.

Question 9

An analyst relates Products to Sales by Product ID. Product ID is unique in Products but repeats in Sales. In the relationship performance options, the analyst leaves the cardinality at many-to-many even though the actual relationship is one-to-many.

What is the best assessment of this configuration?

  1. The relationship is invalid, and Tableau will block all worksheet queries against these tables until the cardinality is corrected to match the actual data structure.
  2. The data will be automatically deduplicated, because the many-to-many cardinality setting instructs Tableau to retain only distinct key values from both tables.
  3. The relationship always produces a full outer join result, because the many-to-many cardinality setting determines a fixed join type for every worksheet query.
  4. Query results can remain correct, but Tableau may be unable to apply optimizations that an accurate one-to-many cardinality declaration would have enabled. (correct answer)
Explanation: When you see a question about Tableau relationship cardinality settings, remember that these settings are hints to the query engine, not data transformation rules. They tell Tableau how to optimize query generation — they don't restructure, filter, or validate your underlying data. With that framing, D becomes clear. Cardinality in a Tableau relationship is a performance declaration. When you accurately specify one-to-many, Tableau knows the "one" side key is unique and can safely skip certain deduplication steps, potentially generating leaner SQL. If you leave it at many-to-many when the data is actually one-to-many, Tableau simply plays it safe — it applies more conservative (but still correct) query logic. Your results won't be wrong; you just forfeit potential optimizations. That's exactly what D describes. A is wrong because Tableau never blocks queries due to a mismatched cardinality setting. Cardinality is advisory, not enforced — Tableau won't throw an error or lock your worksheets. B is wrong because many-to-many cardinality does not trigger deduplication. Tableau doesn't interpret this setting as an instruction to collapse duplicate keys. Deduplication is a separate, explicit operation — this setting has nothing to do with it. C is wrong because cardinality settings don't determine join type. Tableau's relationship engine dynamically generates joins (inner, left, etc.) based on what fields a viz actually uses — not based on a fixed cardinality declaration. Study tip: On Tableau exam questions, watch for distractors that confuse metadata hints (cardinality, referential integrity) with data operations (joins, deduplication, filtering). These settings influence optimization, never data correctness or query structure directly.

Question 10

Orders and Returns are separate logical tables related by Order ID. A worksheet displays SUM(Sales) from Orders. The analyst then adds a filter on Return Reason from Returns and selects "Damaged."

How should the analyst interpret the filtered Sales result?

  1. It represents Sales from Orders that have at least one matching return record where Return Reason is Damaged, based on how the relationship context resolves the filter. (correct answer)
  2. It remains total Sales for all orders because filters on fields from a related logical table cannot propagate to influence measures in another table.
  3. It represents only the monetary value stored in the Returns table, because placing a filter on Returns causes Tableau to replace the Orders Sales measure with a Returns measure.
  4. It converts Orders and Returns into a permanently inner-joined physical table for all subsequent worksheets in the workbook, narrowing Sales accordingly.
Explanation: Whenever you see a question involving Tableau's data model with related logical tables, think about how relationships (not joins) govern which rows participate in a calculation. Tableau's relationship model is context-sensitive: it only joins tables when fields from both tables appear in the same view or filter context. Here's what happens in this scenario. When you drag Return Reason onto the filter shelf and select "Damaged," Tableau recognizes that this field lives in the Returns logical table. To resolve the filter, Tableau performs a join between Orders and Returns using the Order ID relationship key — but only for this worksheet's context. The result is that SUM(Sales) reflects only orders that have at least one matching return record where Return Reason is "Damaged." That makes A correct: the filter propagates across the relationship and narrows the Orders measure accordingly. B is wrong because it describes a hard boundary between tables that doesn't exist in Tableau's relationship model. Filters on related-table fields absolutely do influence measures from the other table — that's a core feature of relationships. C reflects a fundamental misunderstanding: adding a filter on Returns doesn't swap or replace the Sales measure; the measure still pulls from the Orders table, just scoped by the filter context. D is wrong on two counts — relationships never permanently convert to physical joins, and the change would never persist across other worksheets; each sheet resolves its own context independently. A useful mental model: think of Tableau relationships as "smart, lazy joins" — they only connect tables when the view demands it, and they do so per-worksheet, never globally.