Introduction
I've seen it happen more times than I can count — someone builds a gorgeous Power BI dashboard, spends hours tweaking the colors and layout, writes some clever DAX... and the numbers are just wrong. Not dramatically wrong, either. Subtly wrong. The kind of wrong that makes people quietly stop trusting the report.
Nine times out of ten, the problem isn't the DAX. It's the data model underneath.
Data modeling is really about how you organize and connect your tables so Power BI can do its job properly. It's what determines how filters move through your report, how aggregations get calculated, and whether your numbers actually mean what you think they mean. Get this right, and everything else falls into place. Get it wrong, and you'll spend your weekends debugging formulas that should have been straightforward.
In this article, I'm going to walk through the core building blocks of Power BI data modeling — SQL-style joins, relationships, fact vs. dimension tables, schema patterns, and the common mistakes I see people make all the time. I'll keep it practical with examples and tell you exactly where to click in the Power BI interface.
Part 1: What Is Data Modeling, Really?
At its core, data modeling is just deciding how your tables are structured and how they talk to each other. In Power BI, your data model is everything — the tables, the relationships between them, and the calculated columns and measures you build on top.
When you get it right, three things happen. First, your numbers are correct — filters propagate the way they should, so when someone slices by a customer name, the totals actually reflect that customer's data. Second, things are fast — Power BI's VertiPaq engine loves well-structured models and can compress and query them efficiently. Third, it's intuitive — people building reports can just drag and drop fields without needing a PhD in your data architecture.
When you get it wrong? You end up with ambiguous relationships, row counts that don't add up, circular dependency warnings, and DAX formulas that look like they were written by someone having a bad day. I've been there. It's not fun.
Part 2: SQL Joins — Combining Data Before It Hits the Model
Before your data even makes it into the Power BI model, you often need to combine tables from different sources. That's where joins come in.
A join is basically asking: "For each row in this table, what matching rows exist in that other table?" The answer changes depending on what kind of join you pick.
One thing that trips up beginners: joins happen in Power Query Editor — the transformation layer — not in the model itself. You're physically mashing tables together before they load.
2.1 INNER JOIN
This one's the strictest. It only gives you rows where both tables have a match. No match? That row gets tossed.
Say you've got an Orders table and a Customers table. If you do an INNER JOIN on CustomerID, you'll only see orders from customers who actually exist in your Customers table. Got an order from customer C3, but C3 isn't in your customer list? Gone.
Orders Table Customers Table
┌──────────┬────────┐ ┌──────────┬──────────┐
│ OrderID │ CustID │ │ CustID │ Name │
├──────────┼────────┤ ├──────────┼──────────┤
│ 1001 │ C1 │ │ C1 │ Alice │
│ 1002 │ C2 │ │ C2 │ Bob │
│ 1003 │ C3 │ │ C4 │ Diana │
│ 1004 │ C5 │ │ C5 │ Eve │
└──────────┴────────┘ └──────────┴──────────┘
INNER JOIN Result (on CustID):
┌──────────┬────────┬──────────┐
│ OrderID │ CustID │ Name │
├──────────┼────────┼──────────┤
│ 1001 │ C1 │ Alice │
│ 1002 │ C2 │ Bob │
│ 1004 │ C5 │ Eve │
└──────────┴────────┴──────────┘
→ Order 1003 (C3) is dropped: no match in Customers.
→ Customer C4 (Diana) is dropped: no matching Order.
plaintext
Use this when you only care about records that exist on both sides and you're fine losing the stragglers.
2.2 LEFT (OUTER) JOIN
This is probably the join I use most. You keep every row from the left table, and if there's a match in the right table, great — those columns get filled in. If not, you get nulls, but the row stays.
Going back to our example — if you LEFT JOIN Orders onto Customers, you'll see all four orders. Order 1003 will have a null for the customer name because C3 doesn't exist in the Customers table, but the order itself isn't thrown away.
LEFT JOIN Result (Orders LEFT JOIN Customers on CustID):
┌──────────┬────────┬──────────┐
│ OrderID │ CustID │ Name │
├──────────┼────────┼──────────┤
│ 1001 │ C1 │ Alice │
│ 1002 │ C2 │ Bob │
│ 1003 │ C3 │ null │ ← No match, but order sticks around
│ 1004 │ C5 │ Eve │
└──────────┴────────┴──────────┘
→ All 4 orders are preserved. Diana (C4) does not show up, because she has no orders.
plaintext
This is your go-to when the left table is the important one and you want to enrich it with extra info from somewhere else.
2.3 RIGHT (OUTER) JOIN
Basically a LEFT JOIN flipped. Everything from the right table stays, and matching rows from the left come along for the ride. Unmatched left-side stuff shows up as null.
If you wanted to see every customer — even those who've never bought anything — you'd use this. Diana would appear with null for OrderID.
RIGHT JOIN Result (Orders RIGHT JOIN Customers on CustID):
┌──────────┬────────┬──────────┐
│ OrderID │ CustID │ Name │
├──────────┼────────┼──────────┤
│ 1001 │ C1 │ Alice │
│ 1002 │ C2 │ Bob │
│ null │ C4 │ Diana │ ← No order, but she stays
│ 1004 │ C5 │ Eve │
└──────────┴────────┴──────────┘
→ Order 1003 (C3) is dropped because C3 is does not exist in Customers.
plaintext
Honestly, most analysts I know just swap the table order and use a LEFT JOIN instead. Same result, easier to keep track of.
2.4 FULL OUTER JOIN
The "keep everything" option. Every row from both tables makes it into the output. Where there's a match, columns merge. Where there isn't, you get nulls on whichever side is missing.
This is handy when you're doing data reconciliation — trying to figure out what's in Table A that's not in Table B, and vice versa.
FULL OUTER JOIN Result:
┌──────────┬────────┬──────────┐
│ OrderID │ CustID │ Name │
├──────────┼────────┼──────────┤
│ 1001 │ C1 │ Alice │
│ 1002 │ C2 │ Bob │
│ 1003 │ C3 │ null │ ← Order with no customer
│ null │ C4 │ Diana │ ← Customer with no order
│ 1004 │ C5 │ Eve │
└──────────┴────────┴──────────┘
→ Nothing gets dropped. Both orphaned sides are preserved.
plaintext
I mostly pull this out during data quality audits, or when I'm first exploring a new dataset and want to see what matches up and what doesn't.
2.5 LEFT ANTI JOIN
This one's a personal favorite for data validation. It gives you only the rows from the left table that don't have a match on the right. Think of it as the opposite of an INNER JOIN.
Want to find orders that reference a customer ID that doesn't exist? Left anti join. Boom — orphaned records.
LEFT ANTI JOIN Result:
┌──────────┬────────┐
│ OrderID │ CustID │
├──────────┼────────┤
│ 1003 │ C3 │ ← This order has no matching customer
└──────────┴────────┘
Super useful for catching data integrity problems early.
2.6 RIGHT ANTI JOIN
Same idea, other direction. Gives you rows from the right table that have no match in the left.
Classic use case: finding customers who have never placed a single order.
RIGHT ANTI JOIN Result:
┌────────┬──────────┐
│ CustID │ Name │
├────────┼──────────┤
│ C4 │ Diana │ ← Never ordered anything
└────────┴──────────┘
Great for identifying inactive customers, unused products, or anything that "should" be connected but isn't.
2.7 How to Actually Do Joins in Power BI
All of this happens in Power Query Editor, through the Merge Queries feature. Here's the play-by-play:
Step 1: Open Power BI Desktop. Hit Transform Data on the Home ribbon — that drops you into Power Query Editor.
Step 2: In the Queries pane on the left, click the table you want as your "left" table.
Step 3: On the Home ribbon inside Power Query, click Merge Queries. (If you'd rather keep the result as a separate table, go with Merge Queries as New.)
Step 4: The Merge dialog pops up. Your left table is already pre-selected at the top. Pick your right table from the dropdown below it. Click the matching column in both table previews — like CustID in each. Then, at the bottom, choose your Join Kind: Inner, Left Outer, Right Outer, Full Outer, Left Anti, or Right Anti.
Step 5: Click OK. A new column shows up containing nested tables — that's the merged data.
Step 6: Click the expand icon (those little arrows ↔) on the new column header and pick which columns from the right table you want to bring in.
Step 7: Hit Close & Apply and the merged result loads into your model.
Not too bad once you've done it a couple times.
Part 3: Power BI Relationships — The Logical Connections
Here's where things differ from joins in a really important way. Joins physically smash two tables into one. Relationships keep the tables separate but create a logical link between them inside the model. They tell Power BI how to filter across tables and aggregate data without actually merging anything.
So: joins happen during data loading (in Power Query). Relationships exist within the model, after the data's already loaded. This distinction matters.
3.1 Cardinality — How Rows Match Up
Cardinality is just a fancy word for "how many rows on one side can match rows on the other."
One-to-Many (1:M) — This Is What You Want
By far the most common type, and the one you should aim for. One row in the "one" table matches zero, one, or many rows in the "many" table.
Think of it this way: one customer can have many orders, but each order belongs to exactly one customer.
Customers (1 side) Orders (Many side)
┌────────┬────────┐ ┌──────────┬────────┬────────┐
│ CustID │ Name │ │ OrderID │ CustID │ Amount │
├────────┼────────┤ ├──────────┼────────┼────────┤
│ C1 │ Alice │───1:M──▶│ 1001 │ C1 │ 50 │
│ │ │ │ 1005 │ C1 │ 120 │
│ C2 │ Bob │───1:M──▶│ 1002 │ C2 │ 80 │
└────────┴────────┘ └──────────┴────────┴────────┘
Why is this the gold standard? Because filters flow cleanly. Pick "Alice" in a slicer, and Power BI knows exactly which orders to show. Aggregations just work.
Many-to-Many (M:M)
This happens when neither table has unique values in the join column. Multiple rows match multiple rows on both sides.
A classic example would be students and courses — each student takes several courses, each course has several students. If you connect these directly without a bridge table, you've got an M:M relationship on your hands.
The problem? Filters can get weird. You might see double-counting or totals that are bigger than they should be. Power BI technically allows M:M relationships, but in my experience they're usually a sign that you're missing a bridge table in between.
One-to-One (1:1)
Each row matches exactly one row in the other table. Both sides have unique values.
This typically shows up when someone has split a single table into two for organizational reasons — maybe separating sensitive personal data from the rest. In those cases, I'd honestly ask whether you just need to merge them back together.
3.2 Cross-Filter Direction
This controls which direction filter selections travel between related tables.
Single Direction (the default, and usually the right choice)
Filters go from the "one" side to the "many" side. That's it. One-way street.
Customers ──filter──▶ Orders
(Pick a customer → their orders get filtered)
Orders ──X──▶ Customers
(Pick an order → doesn't filter the Customers table)
This keeps things predictable. Dimension tables filter fact tables, not the other way around. Exactly what you want for most reports.
Bidirectional
Filters travel both ways. Selecting something in either table filters the other.
Customers ◀──filter──▶ Orders
I'd say use this sparingly. There are legit scenarios — certain M:M bridge table setups need it — but when people start flipping everything to bidirectional, things get messy. Performance takes a hit, and you can end up with filter behavior that nobody on your team can explain.
My rule of thumb: start with single direction. Only switch to bidirectional when you've got a concrete reason and you've tested the impact.
3.3 Active vs. Inactive Relationships
Power BI only lets you have one active relationship between any two tables at a time. If you've got multiple connections between the same pair of tables, pick one as active — the rest become inactive.
Here's where this comes up constantly. Your Sales table has OrderDate, ShipDate, and maybe DeliveryDate. All three should connect to your Calendar table. But only one relationship can be active at a time.
Calendar (Date)
│
├── Active Relationship ──── Sales[OrderDate]
│
└── Inactive Relationship ─ ─ ─ Sales[ShipDate] (dashed line)
The active relationship is what DAX uses by default. When you need the inactive one, you call USERELATIONSHIP:
Ship Date Sales =
CALCULATE(
SUM(Sales[Amount]),
USERELATIONSHIP(Sales[ShipDate], Calendar[Date])
)
Not the most elegant solution, but it works. I'll talk about some alternative approaches in the role-playing dimensions section later.
3.4 Creating relationships-step by step
You've got three ways to do this.
Method 1: Drag and Drop in Model View
Click the Model View icon on the left sidebar (the one that looks like three connected boxes). You'll see all your tables laid out. Just click a column in one table and drag it to the matching column in another. Done. Power BI auto-detects the cardinality and filter direction — double-click the line to tweak those settings.
Method 2: Manage Relationships Dialog
Go to Home (or Modeling) ribbon → Manage Relationships. Click New, pick your tables and columns from dropdowns, set cardinality and filter direction, choose whether it's active, and hit OK.
Method 3: Let Power BI Auto-Detect
When you first load data, Power BI takes a shot at guessing your relationships based on column names and data types. It does an okay job for simple stuff, but I always check what it came up with. Go to Manage Relationships and verify. I've seen auto-detect create some pretty questionable connections.
Part 4: Joins vs. Relationships — What Is the Difference?
This confuses a lot of people when they're starting out, so let me be clear:
| Aspect | Joins (Power Query) | Relationships (Model) |
|---|---|---|
| Where | Power Query Editor | Model View / Manage Relationships |
| When | During data loading | After data is in the model |
| What happens | Tables physically merge into one | Tables stay separate, linked logically |
| Row count | Can change (more or fewer rows) | Tables keep their original row counts |
| When to use | Enriching or cleaning data | Enabling cross-table filtering and aggregation |
| Performance | Makes tables bigger | VertiPaq handles it efficiently |
| DAX | Merged columns are all in one table | Uses RELATED/RELATEDTABLE to traverse |
My general rule: use joins (Merge in Power Query) when you need to physically combine or clean stuff — adding a lookup value, deduplicating, that sort of thing. Use relationships for pretty much everything else. Keeping tables separate and letting Power BI handle the filtering is almost always the better approach.
Part 5: Fact Tables vs. Dimension Tables
If there's one concept that makes everything click, it's understanding the difference between facts and dimensions. This is the foundation.
Fact Tables
These hold the events — the things that happened. A sale, a shipment, a website click, a support ticket. Each row is a transaction.
What makes a fact table a fact table:
- It has measures — numbers you want to add up (revenue, quantity, cost, duration)
- It has foreign keys — pointers to dimension tables (CustomerID, ProductID, DateKey)
- It's tall — lots of rows, not too many columns
- It grows — new transactions keep getting added
Think: Sales, Orders, WebClicks, SupportTickets, Shipments.
Dimension Tables
These provide the context — the who, what, where, when, and why behind your transactions.
What makes a dimension table a dimension table:
- It has descriptive columns — names, categories, regions, dates
- It has a primary key — a unique identifier for each row
- It's wide — many columns, relatively fewer rows
- It changes slowly — a customer's name or address doesn't change every day
Think: Customers, Products, Calendar, Geography, Employees, Stores.
How They Fit Together
┌──────────────┐ ┌──────────────────────────────┐ ┌──────────────┐
│ Customers │ │ Sales (Fact) │ │ Products │
│ (Dimension) │ │ │ │ (Dimension) │
├──────────────┤ ├──────────────────────────────┤ ├──────────────┤
│ *CustomerID │◀─1:M│ SaleID │M:1─▶│ *ProductID │
│ Name │ │ CustomerID (FK) │ │ ProductName │
│ City │ │ ProductID (FK) │ │ Category │
│ Segment │ │ DateKey (FK) │ │ Price │
└──────────────┘ │ Quantity │ └──────────────┘
│ Amount │
└──────────────────────────────┘
│
M:1
│
┌─────────┐
│Calendar │
│(Dim) │
├─────────┤
│*Date │
│ Month │
│ Quarter │
│ Year │
└─────────┘
The asterisk marks the primary key. Filters flow from the dimension tables (the "one" side) into the fact table (the "many" side). Pick a customer, a product, or a date — and the sales figures update accordingly. That's the whole magic trick.
Part 6: Schema Designs
Schema is just a word for the overall shape of your model — how you've arranged your fact and dimension tables.
6.1 Star Schema
If you take one thing away from this entire article, let it be this: use a star schema. It's what Power BI was designed for.
The idea is simple. You've got a fact table in the center, and your dimension tables connect to it directly — like points on a star.
┌────────────┐
│ Calendar │
└──────┬─────┘
│
┌────────────┐ ┌────────┴────────┐ ┌────────────┐
│ Customers ├────┤ Sales (Fact) ├────┤ Products │
└────────────┘ └────────┬────────┘ └────────────┘
│
┌──────┴─────┐
│ Stores │
└────────────┘
Each dimension connects directly to the fact table — one hop. The dimensions themselves are denormalized, meaning you pack all the descriptive attributes into a single table even if there's some redundancy. Your Products table has ProductName, SubCategory, Category, and Department all in one place, even though that hierarchy could technically be normalized into separate tables.
Why bother with the redundancy? Because it's worth it. Power BI's VertiPaq engine is optimized for exactly this pattern. Filters travel one hop from dimension to fact — no detours. DAX behaves predictably. Report builders can find what they need without playing detective.
I use star schemas on basically every project. It should be your default.
6.2 Snowflake Schema
A snowflake schema is what happens when you take a star schema and normalize the dimensions — splitting them into chains of sub-tables.
┌──────────────┐ ┌──────────────┐ ┌──────────────────┐
│ Department ├────┤ Category ├────┤ Products │
└──────────────┘ └──────────────┘ └────────┬─────────┘
│
┌────────┴────────┐
│ Sales (Fact) │
└────────┬────────┘
│
┌──────┴─────┐
│ Calendar │
└────────────┘
Instead of one Products table with everything, you've got Products → Category → Department as separate tables in a chain.
In a traditional SQL data warehouse, this can save storage space. But in Power BI? The VertiPaq engine already compresses data incredibly well, so those storage savings are basically meaningless. Meanwhile, you've introduced extra hops for filters to travel through, made DAX trickier to write, and confused anyone who tries to build a report.
My advice: if your source data arrives snowflaked (and it often does from enterprise data warehouses), flatten those dimension chains in Power Query before you load them. Merge the sub-tables back together. Turn it into a star.
6.3 Flat Table
This is the "dump everything into one giant table" approach. Facts, dimensions, all of it — one wide table with no relationships because there's nothing to relate to.
┌─────────────────────────────────────────────────────────┐
│ FlatSalesTable │
├─────────────────────────────────────────────────────────┤
│ SaleID │ Date │ CustomerName │ City │ ProductName │ ... │
│ Amount │ Quantity │ Category │ Segment │ StoreName │ ... │
└─────────────────────────────────────────────────────────┘
Look, we've all done this. You export something from Excel, load it straight into Power BI, and start building visuals. For a quick personal analysis with a few hundred rows, it works fine.
But the moment you scale up, things fall apart. Customer names and addresses get repeated on every single row. The file balloons in size. Compression suffers. DAX gets weird because there's no clear distinction between a measure and a descriptive attribute. And heaven help you if you need to update a customer's address — you'd have to change it on potentially thousands of rows.
Use flat tables for quick throwaway analysis. For anything beyond that, take the time to separate your facts and dimensions.
6.4 Quic comparison
| Star Schema | Snowflake Schema | Flat Table | |
|---|---|---|---|
| Complexity | Low | Medium-High | Lowest |
| Power BI Performance | Best | Decent ( extra hops) | Poor at scale |
| Data redundancy | Some (in dimensions) | Low | Very high |
| ** DAX friendliness** | Very friendly | Trickier(multi-hop) | Unpredictable |
| Scalability | Excellent | Good | Poor |
| My Recommendation | default choice | Flatten it first | Small stuff only |
Part 7: Role-Playing Dimensions
Here's a scenario that comes up constantly. You've got a Calendar table, and your Sales fact table has multiple date columns — OrderDate, ShipDate, DeliveryDate. All three logically connect to the same Calendar table, but they each represent a different analytical perspective.
That's a role-playing dimension. One dimension table wearing multiple hats.
How to Handle it
Option A: One Calendar, Multiple Relationships
Create one Calendar table and set up three relationships to Sales. Make one active (usually OrderDate since it's the most commonly used) and leave the others inactive. When you need ship date analysis, use USERELATIONSHIP in DAX:
Shipped Amount =
CALCULATE(
SUM(Sales[Amount]),
USERELATIONSHIP(Sales[ShipDate], Calendar[Date])
)
This keeps things tidy — one calendar to maintain. The downside is that report builders need to know about USERELATIONSHIP, and only the active relationship works by default.
Option B: Duplicate the Calendar Table
Create separate calendar tables in Power Query — OrderCalendar, ShipCalendar, DeliveryCalendar — each with its own active relationship to the corresponding date column.
More tables in the model, yes. But now every relationship is active, you don't need USERELATIONSHIP, and you can drop independent slicers for each date role without any DAX gymnastics.
I tend to go with Option A when the secondary date roles are rarely used in reports. If stakeholders regularly need to slice by ship date and delivery date alongside order date, Option B saves a lot of headaches.
Part 8: Common Data Modeling mistakes and How to fix Them
Let me run through the issues I see most often.
Ambiguous Relationships
What you'll see: An error about a relationship already existing between tables, or something about "ambiguous paths."
What went wrong: You've got multiple active paths between two tables, and Power BI can't figure out which one to use.
The fix: Make sure only one active relationship connects any pair of tables. Put the extras on inactive and use USERELATIONSHIP when you need them.
Circular Dependencies
What you'll see: Power BI refuses to create a relationship and warns about circular dependencies.
What went wrong: Your relationships form a loop — A connects to B, B connects to C, C connects back to A. Power BI can't determine which way filters should flow in a circle.
The fix: Break the loop. Usually this means removing a redundant relationship or merging tables to eliminate the circular path.
Many-to-Many Without a Bridge Table
What you'll see: Totals that seem inflated or just don't add up.
What went wrong: Two tables are connected M:M because neither has unique values in the join column. Filters propagate in ambiguous ways, and you end up double-counting.
The fix: Add a bridge table (also called a junction or associative table) that sits between the two. Each row in the bridge table represents one valid combination, turning your M:M into two clean 1:M relationships.
Before (problematic):
Students ──M:M──▶ Courses
After (correct):
Students ──1:M──▶ Enrollments ◀──M:1── Courses
plaintext
Issue 4:Bidirectional Filtering Everywhere
What you'll see: Weird filter behavior, sluggish performance, or filters "leaking" into parts of the model where they shouldn't.
What went wrong: Someone set cross-filter direction to "Both" on a bunch of relationships, probably because a specific visual wasn't working right.
The fix: Reset everything to single direction. Turn bidirectional back on only where you have a specific, tested reason to do so.
Descriptive Columns Stuffed Into Fact Tables
What you'll see: A bloated model that's slow to refresh and doesn't compress well.
What went wrong: Customer names, product categories, addresses, and other descriptive data are sitting in the fact table instead of in their own dimension tables.
The fix: Pull those descriptive columns out into proper dimension tables. Your fact table should really only have keys (CustomerID, ProductID, DateKey) and measures (Amount, Quantity, Cost).
Missing or Broken Date Table
What you'll see: Time intelligence functions — TOTALYTD, SAMEPERIODLASTYEAR, and the like — either don't work or return nonsense.
What went wrong: You either don't have a dedicated date table, or the one you have has gaps in it.
The fix: Build a Calendar table that spans the full range of your data with no missing dates. Mark it as a Date Table in Power BI (select the table → Modeling ribbon → Mark as Date Table). Make sure it has a Date column with unique, contiguous values. This trips up more people than you'd expect.
Part 9: Putting It All Together — A Modeling Workflow
Here's the process I follow when building a new Power BI model. Nothing revolutionary — just a sequence that keeps me from painting myself into corners.
Step 1: Figure out what the business needs. What questions do stakeholders want answered? Revenue by region? Support tickets by priority? These questions tell you what facts and dimensions you need.
Step 2: Identify your fact and dimension tables. Facts are the measurable events. Dimensions are the descriptive context around them. Draw a line between the two.
Step 3: Clean and transform in Power Query. This is where joins happen. Enrich your data, flatten any snowflaked dimensions, drop unnecessary columns, and make sure your data types are right.
Step 4: Load into the model and set up relationships. Switch to Model View. Create 1:M relationships between dimensions (one side) and facts (many side). Keep cross-filter direction on single unless you've got a good reason not to.
Step 5: Organize for usability. Hide foreign key columns from Report View — nobody building a report needs to see CustomerID. Create display folders if you've got a lot of measures. Add descriptions to key columns.
Step 6: Build measures and test. Write your DAX, then actually test it. Click through slicers. Check if the numbers make sense. Don't assume — verify.
Step 7: Optimize. Remove columns you're not using. Check your model size. Profile query performance. Make sure that date table is properly marked.
Conclusion
Data modeling isn't the glamorous part of Power BI — nobody's going to screenshot your Model View and post it on LinkedIn. But it's the part that determines whether everything else works.
Here's what I'd want you to remember:
Joins physically combine tables during loading. They happen in Power Query. Use them for enrichment and cleanup work.
Relationships are the logical connections in your model. They're how Power BI knows to filter one table based on selections in another. They're the backbone of everything.
Star schemas are what Power BI was built for. Fact table in the center, denormalized dimensions around it. Use this unless you have a very good reason not to.
Cardinality should be one-to-many whenever possible. If you're hitting many-to-many, you probably need a bridge table.
Cross-filter direction should default to single. Bidirectional filtering is powerful but dangerous — use it like hot sauce, not ketchup.
Role-playing dimensions solve the multiple dates connecting to one calendar problem. Choose between shared calendar with USERELATIONSHIP or duplicated calendars based on how heavily each date role gets used in reports.
Top comments (0)