Video | Tableau | Data visualisation | Data prep | Analytics

Master the Tableau Data Model & Relationships featuring Kirk Munroe

Kirk Munroe and I take you through the Tableau data model end to end, from your first relationship to multi-fact analysis.

Part ofTableau Data Model Masterclass Tableau Key ConceptsGuest Appearences
Watch on YouTube
  • Relationships form a logical model you can build without writing SQL, while joins and unions sit at the physical layer inside a logical table and combine before any question is asked.
  • Only convert a relationship to a physical join when both tables share the same number of rows at the same grain, so Tableau doesn't needlessly join at runtime.
  • Leave the relationship performance options at default unless you hit performance issues, as overriding Tableau's heuristics restricts the questions you can answer.
  • Layout is just a visual representation, but with more than one fact table you should make each fact table a base table to use multi-fact relationships and compare unrelated data through shared dimensions.
  • Use COUNT of rows from a table rather than COUNTD on a dimension to confirm uniqueness and get the same answer with a far lighter calculation.

I couldn’t think of anyone better to run a Tableau data model masterclass with than Kirk Munroe, who has spent the best part of three years refining how he explains this stuff. Together we built a model from scratch using the Bookshop dataset and worked through every concept you need to use the data model with confidence. You can download the Bookshop data from the Tableau website and follow along.

Where the data model lives

The data model happens in the connection window. After opening the main Bookshop Excel file, you land straight in this canvas, which behaves much like a worksheet: you can drag and drop tables or simply double-click them. As long as the fields you want to relate on share exactly the same name, double-clicking builds the relationship for you. I double-clicked Book, and then Edition, and Tableau immediately created a connection between the two.

Relationships and the logical model

1.00

That connection is a relationship with related fields, and once you have it you have a data model — specifically a logical data model. Kirk’s point is that you can build this without understanding SQL at all. Crucially, the two tables aren’t doing anything together at this layer; you’ve only told Tableau what is common between them. It’s like having your ingredients laid out on the kitchen table: distinct items waiting for you to cook. The work only happens once you drag fields onto a sheet.

Know your data first

You don’t need SQL to be good at Tableau, but you do need to understand your data well to be a good analyst. Hovering over a table reveals a small preview icon that opens a modal view of the underlying data. Scanning the tables up front pays off: it’s intuitive to assume books relate to sales, but it’s actually editions that sell, not books. Double-clicking helps here too — if Tableau can’t make a connection it drops the table in as a base table, which is your cue to investigate.

Understanding base tables

1.00

When I double-clicked Publisher before the Edition table existed, Tableau dropped it in as a base table with a warning, because it had no way to relate publisher to book. The alert tells you that you have two unrelated tables. Publisher only connects through the common field it shares with the Edition table, and Edition then brings the books along with it. Once the right intermediate table is present, the relationship resolves.

Relating on multiple fields

Editing a relationship is done at the bottom left of the canvas. You can relate on more than one field, change the operator (the available operators depend on the data type of the fields involved), and even pass a filter into the relationship using something like a less-than on dates. Kirk’s guidance on adding multiple field pairs is to reserve it for genuine compound keys, such as matching on first name and last name where both must be true.

Unioning the sales data

1.00

Sales arrives as separate quarterly files with identical structures, so they need unioning. There are several routes: drag all the sales tables on together and Tableau will union them automatically and still work out the relationship; drop them onto an existing sales table; or right-click and edit the union. Kirk’s preferred method is a wildcard union — something like *sales* — so any future quarter is picked up without touching the model. It’s hidden from view, which is why I tend to avoid it, but it’s a genuinely smart default.

Logical versus physical tables

The terms come from data modelling: there are logical models and physical models. A logical model is exactly what you see on the canvas, where an analyst draws tables and states how they relate. Traditionally you’d hand that to a data engineer to write the SQL; with relationships, Tableau dynamically creates what it needs at runtime. Tableau borrowed the terms one level down, so a table is a physical table and the canvas object is a logical table. A union is always physical because it adds rows under shared columns and there’s no sense in deferring that to runtime, whereas a join adds columns. Double-clicking a logical table opens its physical layer.

Joins and join calculations

1.00

To bring book information into the Book logical table, I opened it and dragged Info onto the physical layer, which gives the familiar four-way join interface. The book ID came in two parts here, so rather than fixing it in SQL beforehand, I used the create join calculation option to concatenate Book ID 1 and Book ID 2. I then chose a left join to keep every book even where information is missing. Kirk’s rule: only convert a relationship to a join like this when both tables have the same number of rows — here 58 rows in each — so you pre-join rather than forcing Tableau to join at runtime. Where row counts differ, leave it as a relationship to avoid exploding the data.

Naming tables and sources

You can rename a logical table (Book and Info, for example), and any icon shown before a logical table’s name signals that physical tables are being combined inside it via a join or union. Just as important, rename the data source itself — Tableau names it after whatever field you dropped first, which means published metadata ends up littered with confusing duplicate names. I named ours Bookshop Data Model.

Finishing the model

1.00

With the structure in place I double-clicked through the rest — author, awards, checkouts, ratings and series — each one mapping to the correct ID because the dataset is set up cleanly. Even when double-clicking works, it’s worth checking each relationship is doing what you expect. The finished model has books as the base table with a series of related tables hanging off it.

Relationship performance options

Clicking a relationship line highlights the connected logical tables. The performance options sit here too, and both Kirk and I touch them at a rate approaching zero. Tableau’s heuristics are clever: pull dimensions from two tables and it inner-joins them; pull a measure and it effectively outer-joins so unmatched rows return nulls. Overriding these with cardinality or referential integrity settings means telling Tableau something that might not be true in your data, which leads to answers you didn’t want. Only reach for them on very large models with genuine performance issues.

Layout, star schemas and base tables

Layout is purely a visual representation — a left-to-right arrangement is the same as a star. What Kirk dislikes is that Tableau won’t nudge you toward the better structure. To answer questions correctly you sometimes need fields from intermediate tables on the view so Tableau can create the join. With multiple fact tables you should build something that behaves like a star: the centre is made of base tables (Tableau’s term for fact tables), with shared dimension tables hanging off them.

Swapping base tables

The swap with base table option reorganises the canvas without changing the underlying model. Swapping in Checkouts moved it to the left and rippled the other tables across the columns exactly as predicted. The key insight is that this is functionally identical — a fully built dashboard would not change at all, unlike changing a join, which can blow away your worksheets and metadata. So with a single fact table, arrange the model however suits your analysis; with more than one fact table, make each fact table a base table.

Building views in the sheet

Going to Sheet One shows the classic Tableau workspace, where the tables sit on the left as distinct items again — except for the sales union and the Book and Info join, which were combined before you did anything. With flat files you’ll also see Sheet (for Excel) or File Names (for CSVs) as useful metadata about where rows originate.

Extract storage settings

Creating an extract exposes a choice between storing one table per logical table or one per physical table. It only matters where you’ve created a physical join — in our case the Book and Info join. The toggle decides whether hyper pre-joins and stores them as one table or keeps them separate, trading disk space against an exploded table. Either way Tableau generates SQL as if it were pre-joined. On a tiny dataset it makes no difference; on a big one the only reliable way to know which is faster is to try both.

Simple analysis and performance tips

To show the model in action I grabbed book titles and counted editions. My instinct was to drop Edition ISBN on detail and use COUNTD, but Kirk pointed out a lighter approach: pull the edition count (count of rows) directly from the relevant table. COUNT of rows is far cheaper than COUNTD on a big dataset and gives the same answer. The data model also let me count publishers per title with no level-of-detail workaround — exactly the kind of friction a join would have introduced.

Kirk’s multi-fact model

Kirk’s model looks different because it predates the advice Tableau still publishes — multi-fact relationships changed the recommended approach. The Bookshop is best understood like Amazon: it sells books by edition, but checkouts (think Audible or Kindle) happen at the book level and ignore the edition. By placing both Sales and Checkouts as base tables, the relationship graph shows what each can answer: sales can answer anything except checkouts, and checkouts can’t reach editions or publishers because that information simply isn’t in the table. The real power of multi-fact is comparing two unrelated fact tables — sales and service in a CRM, say — through the dimensions they share, such as customer and product.

Date relationship calculations

1.00

To compare sales and checkouts over time, Kirk added a 365-row date table and noodled it to each fact table. Because the two sources aren’t at the same grain — checkouts arrive aggregated to month-end, sales are per transaction — he built relationship calculations: a MAKEDATE rolling checkout month to the first of the month on one side, and a date truncation on the other. The strength here is that relationships don’t require both sides to share the same level of aggregation, so you can align mismatched dates without restructuring your data. Always start from the questions you want to answer, and let the model serve them.