Tableau Relationships: What the Noodle Actually Does

1. What the noodle is

Before the explanation: you drag a second table onto the canvas and a curved line appears between the two. At that moment, has Tableau combined your data yet?

No, and that is the entire idea. Tableau's documentation calls a relationship "a contract between two tables." You are describing how the tables relate, using a shared field. You are not telling Tableau to merge them.

People call that curved line the noodle, and its flexibility is a good visual joke. A join line is a rigid statement about what the combined data looks like. The noodle is a looser promise: these two tables can be matched on this field when a view needs them matched.

The combining happens later, one view at a time. When you build a chart, Tableau looks at which fields you actually used, then writes a query for that specific question. Drag different fields out and it writes a different query. The documentation puts it plainly: Tableau "adjusts join types intelligently and preserves the native level of detail in your data."

Native level of detail is the important phrase, and it means what one row of a table represents. One row of an orders table is one order line. One row of a targets table is one month for one region. Those are different things, and a relationship keeps them different instead of forcing them into one shape.

2. The inflated total, and why a relationship fixes it

Before the explanation: your region has a sales target of $50,000 for January. You join targets to orders, put the target on a chart, and it reads $4,150,000. Where did that number come from?

From the join repeating it. The targets table has one row per region per month. The orders table has thousands of rows per region per month. Joining them writes the January target onto every single order line, and there were 83 of them. Then SUM adds up all 83 copies.

Nothing errored. The chart drew. The number is off by a factor of 83, and only someone who knows the real target will spot it. This is the same duplication covered in SQL joins, and it is the single most common wrong number in business intelligence work.

A relationship removes it, and the mechanism is worth understanding rather than trusting. Because the tables were never merged, Tableau aggregates each one at its own level of detail first, then brings the results together. It totals the targets among the targets, where each month appears once. It totals the sales among the orders. Then it lines the two answers up.

Say out loud why aggregating first and combining second gives a different answer from combining first and aggregating second, before you read on. That order is the hinge of this whole guide.

The reason is that duplication is created by the combining step. If you aggregate before that step, you are summing the original rows, and there is only one January target to sum. If you aggregate after, you are summing whatever the combining step produced, copies included. Same data, same SUM, different answer, and only one of them is the target.

There is a second gain in the same mechanism. With a join, a row that matches nothing can vanish from your analysis. With a relationship, Tableau's documentation states that "unmatched measure values aren't dropped," so a region with no target still shows its sales rather than quietly disappearing.

3. The two layers, and how to reach the join one

Before the explanation: relationships are the default now. Does that mean joins are gone from Tableau?

They are not. They moved down a level, and knowing where they went is most of what confuses people returning to Tableau after a few years.

The data source canvas has two layers.

So the answer to the prequestion is that a logical table can itself be built from several physically joined tables. Double-click any table on the top canvas and you drop into its physical layer, where you can join or union as before. Close it, and the result behaves as one logical table that other tables can relate to.

That is also where unions live, and unions answer a different question from either. A join or a relationship adds columns by matching on a key. A union stacks rows. If you have a January sales table and a February sales table with identical columns, and you want one table containing all of it, that is a union every time. No matching, no key, just more rows.

4. When you still want a join

Before the explanation: if relationships avoid duplication and avoid dropping rows, why would anyone deliberately choose a join?

Because sometimes you want the flattened table, and stating so up front is clearer than leaving it flexible. Three cases where a join is the right call.

You genuinely want rows removed. A relationship's habit of keeping unmatched rows is usually a feature and occasionally not what you want. If your analysis is defined as "only orders that were returned," an inner join in the physical layer says that once, permanently, rather than relying on every view to filter correctly.

The tables are at the same level of detail. If both tables have one row per order, no duplication is possible, and a join is simple and predictable. The relationship model is solving a problem you do not have.

You are building a deliberately flat extract. Sometimes you want one wide table, materialised and fast, for a dashboard that many people open. Making that explicit is reasonable engineering.

Here is the short decision.

That last row is worth naming so it does not ambush you. Relationships, joins and unions all combine tables inside one data source. Blending combines two different data sources, aggregates each separately, and matches the results on a linking field. Different tool, different canvas, and the one most likely to be confused with a relationship because the outcome sounds similar.

5. The performance settings, and what they promise

Before the explanation: Tableau asks you to describe your data's cardinality and referential integrity. If you get one of those answers wrong, what happens?

Click a noodle and you get Performance Options. Both settings default to the cautious answer, and both are promises you are making to Tableau about your data.

Cardinality asks how many rows match. One region has many orders, so that side is many. Telling Tableau a side is "one" lets it skip the work of removing duplicates it would otherwise have to guard against.

Referential integrity asks whether every record on one side always has a match on the other. If every order always has a valid region, Tableau can use a simpler and faster join internally instead of carefully preserving unmatched rows.

So the answer to the prequestion is that a wrong setting does not throw an error. It changes your numbers. Promise that every order has a region when 400 orders have a blank one, and those 400 can silently drop out of your totals. The default settings are slower and safe, which is the right default.

6. Edge cases and things that surprise people

Before the explanation: you build a view using fields from only one of your two related tables. Does Tableau query the other one?

Six things worth knowing.

Unused tables are not queried. This is the answer to the prequestion, and it surprises people who expect the whole model to load. If a view only uses order fields, Tableau does not touch the targets table at all. That is why a large relationship model can still be fast.

The same measure can total differently in two views. Once you accept that each view gets its own query, this stops being alarming and starts being the point. It does mean you cannot assume a number matches another sheet just because the field name is the same.

Grand totals can look wrong when they are right. With unmatched values preserved, a total may include records that no row in your table displays. Usually that is honest, and it is worth a note on the dashboard rather than a fix.

Relationships need a shared field, and it has to actually match. Same values, compatible types. An id stored as text in one table and a number in the other matches nothing, exactly as in SQL.

You can relate on more than one field. If a row is only identified by region plus month together, add both to the relationship. A single-field relationship there would match far too much.

Workbooks built before 2020.2 still use the old model. Opening one shows a single physical-layer table, not a noodle. Nothing breaks, and nothing upgrades itself. Rebuilding the data source is a deliberate act.