- What behavior should the analyst expect from the relationship?
Answer: Each measure is aggregated at its relevant table's level before Tableau combines the query results.
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.
- Which relationship design best satisfies the requirement?
Answer: Define relationship clauses for both Order ID and Region so both field comparisons must match.
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.
- Which modeling approach is most appropriate?
Answer: Use a physical join within a logical table because the required row-level structure is predetermined.
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.
- What is the most likely result under the default relationship behavior?
Answer: 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.
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.
- Why is this change risky?
Answer: 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.
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.
- Which statement best describes how Tableau uses the relationship for this worksheet?
Answer: Tableau can query Orders without bringing Customers into the worksheet query because Customers is not required.
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.
- How should the analyst interpret the filtered Sales result?
Answer: 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.
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.
- Which approach is most appropriate?
Answer: Union the files because the goal is to append rows from tables with the same transaction structure.
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.
- Which logical model best supports the analysis?
Answer: Use Customers as a shared logical table, with separate relationships to Orders and to Cases.
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.
- What is the best assessment of this configuration?
Answer: Query results can remain correct, but Tableau may be unable to apply optimizations that an accurate one-to-many cardinality declaration would have enabled.
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.
