The topic of “Your Data Is Talking. . . Is Power BI Listening?” is currently the subject of lively debate — readers and analysts are keeping a close eye on developments.
This is taking place in a dynamic environment: companies’ decisions and competitors’ reactions can quickly change the picture.
A plain-English guide to the concepts that make your reports actually make sense.
The numbers add up. The chart renders. The dashboard looks exactly like what your manager asked for.
The visuals did not break. The model underneath them was never right to begin with.
This is the silent killer of Power BI reports.
Not bad data.
Not weak DAX.
Not a missing chart type.
A model that was never properly built — because nobody showed you how, and Power BI lets you skip that step entirely.
Search “Power BI tutorial” right now. Every top result goes straight to visuals — drag a field, pick a chart, add a slicer, publish.
What they skip is the 20 minutes of work that determines whether any of those visuals will ever, be trustworthy:
How your tables connect. What role each one plays. Which relationships are active. Which schema holds the whole thing together.
Why one analyst’s numbers are always right and another’s are always almost right.
This is not a survey of concepts. It is a complete, ground-up guide — written for anyone who has heard the words “data modeling” and felt the floor shift slightly under their feet.
We go from “I’ve heard of Power BI” to “I can model data with confidence” — and we do it in plain language, with real examples, at every step.
Data modeling is one of those subjects where the first explanation you receive tends to shape everything that follows.
A bad one makes it feel harder than it is. A good one makes you wonder why it ever seemed complicated.
In the first one, ingredients are everywhere. Flour is next to the dish soap. The eggs are behind the blender. Nothing is labeled. You could cook in there — but every meal starts with a 20-minute search.
In the second kitchen, everything has a place. Spices are grouped. The fridge is stocked logically. You walk in, and cooking just flows.
Data modeling is how you turn the first kitchen into the second — before you cook a single report.
Data modeling is the process of deciding how your tables connect, what role each one plays, and how they talk to each other inside Power BI.
It is not about the visuals. It is not about colors or charts. It is the invisible structure that makes everything on the surface work correctly.
When it is not modeled? Your slicer filters one table and ignores the rest. Your totals are wrong. Your date table does nothing.
Model View is your kitchen layout tool. It is where you draw the lines between tables, define how they relate, and set the rules that every visual on every page will follow.
A well-built model makes DAX easier, reports faster, and dashboards that actually answer the right questions. A broken model creates workarounds that stack on top of each other until the whole thing collapses.
You do not need to be an expert to model data well. You need to understand a handful of core concepts — and that is exactly what the rest of this article covers.
Sometimes that means combining two tables into one. That is what a join really does.
A join answers one question: when two tables share a common column, which rows make the cut?
The answer depends on which join you use. There are six of them. Each one has a different rule about who gets included — and who’s left out.
We will use the same scenario for every join so the differences are crystal clear.
Real life: You are hosting a dinner party. Only guests who both RSVP’d and show up get a seat.
C04’s order disappears — no matching customer. David disappears — no matching order. Only the overlap survives.
Real life: Every customer is listed. If they placed an order — great. If not, they appear with a blank order.
David now appears — he is in the right table. C04 is gone — no customer record on the right.
💡 Honest note: In practice, most analysts reorder their tables and use a Left Join instead of a Right Join. The result is identical — it is just easier to reason about “all rows from my main table.”
The rule: Return all rows from both tables. Match where possible. Fill blanks everywhere else.
Real life: The most inclusive guest list under the sun. Every order and every customer appears — matched or not.
Use it when: You need a complete picture — every record from both sides, matched or not. Great for auditing data gaps.
The rule: Return rows from the left table that have no match on the right. Matched rows are excluded.
Real life: Find every order that has no customer record. These are your data gaps.
Use it when: You are hunting for missing or unmatched records. A data quality goldmine.
The rule: The mirror version of the Left Anti. Return rows from the right table with no match on the left.
Use it when: You want to find records that exist on one side but are completely absent from the other. Useful for finding inactive users, unassigned records, or orphaned data.
Joins in Power BI live inside Power Query, under the Merge Queries feature. Here is how to use it:
Step 1 — Open Power Query
In Power BI Desktop, click Transform Data in the Home ribbon. Power Query Editor opens.
Step 2 — Select your primary table
In the Queries panel on the left, click the table you want as your left table — in our example, Orders.
Step 3 — Open Merge Queries
In the Home ribbon, click Merge Queries. A dialog box opens.
Step 5 — Expand the joined columns
After clicking OK, a new column appears in your table. Click the expand icon (two arrows) in the column header to choose which fields from the right table to bring in.
Step 6 — Close and Apply
Click Close & Apply in the Home ribbon. Your merged table loads into the model.
You just learned how joins work. But Power BI has another way to connect tables — Relationships — and they are not the same thing.
A relationship is a phone line — two tables stay separate but can talk to each other.
Knowing which one to use, and when, is one of the most important modeling decisions you will make.
We cover Relationships fully in Section 4. For now, remember this distinction — it will matter.
Get them wrong and your schema, your relationships, and your DAX all suffer for it.
The scoreboard tracks the action — points scored, time of possession, fouls committed, shots attempted. Every event gets recorded with a number and a timestamp.
The player cards tell you everything else — a player’s name, position, team, height, jersey number, hometown. Context. Description. Identity.
One records events and measures. The other provides the context that makes those events meaningful.
A Fact table records transactions, events, or measurements. Each row is one thing that happened.
A Fact table is typically long and narrow — many rows, relatively few columns. It grows every time something happens.
Dimension tables are typically short and wide — fewer rows, more descriptive columns. They grow slowly, if at all.
When you are staring at a table and not sure which type it is, ask these three questions:
1. Does each row represent a single event or transaction?
→ If yes, it is probably a Fact table.
2. Are most columns numeric and meant to be summed or averaged?
→ If yes, it is probably a Fact table.
3. Does the table mostly describe something — a person, a product, a place?
→ If yes, it is a Dimension table.
If you build reports in Power BI, you will eventually need a Date table — and it is the single most important dimension in most models.
Because Power BI’s time intelligence functions — TOTALYTD, SAMEPERIODLASTYEAR, DATESYTD — only work reliably when you have a proper, unbroken Date table connected to your Fact table.
💡 Pro tip: Mark your Date table as an official date table in Power BI. Right-click the table in Model View → Mark as Date Table. This unlocks full time intelligence support.
You cannot build a clean Star Schema without knowing which tables are facts and which are dimensions.
You cannot set up relationships correctly without understanding which table holds the many side and which holds the one side — and that comes directly from this fact/dimension split.
You cannot write efficient DAX without knowing where your measures live (Fact tables) and where your filters come from (Dimension tables).
In short: every concept that follows in this article is built on top of what you just learned.
Right now, someone you know is staring at a broken Power BI report right now wondering why their slicer does not work.
Next in this series → **DAX Fundamentals: writing measures, calculated columns, and time intelligence — built on top of the model you just learned to build.
Relationships do something different — and in most Power BI models, more powerful.
Instead of merging tables, relationships keep tables separate while letting them communicate.
Use a join when you need to reshape your data.
Use a relationship when you need your tables to talk to each other during analysis.
Most real models use both — joins in Power Query to clean and prep, relationships in Model View to connect.
Every relationship in Power BI is described by four properties. Understanding each one is non-negotiable.
Cardinality describes how many rows on one side of a relationship match rows on the other side.
Example: One customer can place many orders. The Customers table has one row per customer. The Orders (Fact) table has many rows per customer.
This is the relationship type you will use most. It is clean, performant, and exactly what a Star Schema is built on. When in doubt, aim for 1:M.
Example: One product can appear in many orders. One order can contain many products.
💡 Best practice: Before accepting an M:M relationship, ask if a bridge table can resolve it into two clean 1:M relationships. It usually can — and your model will thank you.
1:1 relationships are uncommon. When you see one, ask whether the two tables should simply be merged into one.
Use 1:1 only when keeping the tables separate serves a clear purpose — security, source system constraints, or deliberate separation of concerns.
The active relationship is the default. It is the one Power BI uses automatically when you build visuals and write measures. It appears as a solid line in Model View.
An inactive relationship is a backup — it exists in the model but does nothing until you explicitly call it. It appears as a dashed line in Model View.
The most common example: a Date table connected to a Sales Fact table on both Order Date and Ship Date. Power BI can only activate one at a time. So you make Order Date the active relationship and Ship Date the inactive one — then call it when needed using USERELATIONSHIP() in DAX.
We cover this fully in Section 6 on Role-Playing Dimensions. For now, just remember: solid line = active, dashed line = inactive.
When you select a value in a slicer or filter a visual, Power BI applies that filter across related tables. Cross-filter direction controls which way that filter travels.
Example: Filtering the Customers table (one side) filters the Orders table (many side). But filtering Orders does not filter back into Customers.
This sounds convenient — and sometimes it is. But bidirectional filtering introduces a real risk: filter ambiguity. When multiple paths exist for a filter to travel, Power BI can produce unexpected or incorrect results.
⚠️ Rule of thumb: Start with Single. Switch to Both only when you have a specific reason — and test your numbers carefully when you do.
Bidirectional filters in M:M relationships are especially prone to silent errors.
When you look at Model View, the lines between tables are not just decorative. They tell you everything about the relationship at a glance:
Learn to read these at a glance and Model View becomes a diagnostic tool, not just a canvas.
There are two ways to create relationships in Power BI. Use whichever fits your workflow.
This method is better for editing existing relationships or when your model has many tables and drag-and-drop becomes difficult to manage.
That arrangement has a name — a schema. Think of it as the floor plan of your data model. The tables are the rooms. The relationships are the doorways.
Choosing the wrong one does not necessarily break your model immediately — it just makes everything harder over time.
The Star Schema is the most widely used structure in Power BI and business intelligence. If you only learn one schema, make it this one.
The structure:
One Fact table sits at the center. Dimension tables surround it, each connected by a single 1:M relationship. When you draw it out, the shape looks exactly like a star.
Every Dimension table connects directly to the Fact table. No Dimension connects to another Dimension.
The honest limitation:
Star Schemas require some denormalization — meaning you may store repeated values across Dimension tables rather than normalizing them out.
The Snowflake Schema is a Star Schema where the Dimension tables have been normalized — broken down further into their own related tables.
Where a Star Schema has one Products table, a Snowflake might split it into Products → Subcategory → Category. Each level becomes its own table, connected in a chain.
Mostly when your data comes from a normalized relational database — like an enterprise data warehouse — and restructuring it into a flat Star Schema is not practical. The Snowflake preserves the source structure.
💡 The Power BI reality: Power BI is optimized for Star Schemas. Snowflake models work — but every extra hop between tables is an extra relationship for the engine to traverse.
If your source data arrives as a Snowflake, consider flattening the sub-dimension chains in Power Query before loading.
The Flat Table is exactly what it sounds like. All your data lives in one wide table.
Every column — measures, descriptions, dates, customer names — is in a single sheet.
⚠️ The flat table trap: Many beginners bring an Excel file into Power BI and start building visuals directly on top of it.
If your dataset will grow, or if you need to join additional sources later, invest the time to model it properly from the start.
The Star Schema is not just a best practice recommendation — it is the shape Power BI’s engine is built to work with. When your model looks like a star, Power BI performs at its best.
Build your model like a star. Your reports — and your future self — will thank you.
That is a role-playing dimension — and the Date table is almost always the one wearing multiple hats.
Each column is a date. Each one means something different. And your business needs to analyze by all three — orders placed by month, shipments by week, deliveries by quarter.
You have one Date dimension table. You need it to serve three different relationships.
In Model View, create your first relationship:
Date[Date] → Orders[OrderDate]
Set this as the active relationship.
Create a second relationship:
Date[Date] → Orders[ShipDate]
Power BI will automatically mark this as inactive (dashed line).
Now, by default, every date-related visual uses OrderDate — the active relationship does its job quietly in the background.
When you need to analyze by ShipDate or DeliveryDate, you activate the relevant relationship inside a DAX measure using USERELATIONSHIP().
USERELATIONSHIP() tells Power BI: “For this specific calculation, ignore the active relationship and use this inactive one instead.”
You are not changing the model. You are temporarily swapping which relationship is active for that one measure only. Everything else in your report keeps using OrderDate.
💡 This is why inactive relationships exist. They are not broken or forgotten relationships. They are deliberate standbys, ready to be called when the calculation needs them.
For complex models, some analysts create separate Date tables — one for each role:
Each one is a full copy of the same Date table, each connected to its respective column in the Fact table with its own active relationship.
The benefit: every relationship is active. No DAX switching required. Simpler measures.
The trade-off: three tables to maintain instead of one. If your Date table needs updating — a new column, a fiscal year change — you update it in three places.
For most use cases — start with one Date table and inactive relationships. It keeps your model lean and your Model View readable. Reach for multiple Date tables only when your time intelligence needs are complex enough to justify the overhead.
A role-playing dimension is not a workaround. It is a deliberate modeling pattern used by professionals across the industry.
When you see a Fact table with multiple date columns, you now know exactly what to do: one Date table, one active relationship, inactive relationships standing by, and USERELATIONSHIP() ready to call them into action.
It whispers. A total that looks slightly off. A slicer that filters one visual but ignores another.
A report that works perfectly — until someone adds a second page and everything falls apart.
What happens:
You load your data, land in Report View, and start dragging fields onto the canvas. Things look fine — until they don’t.
Totals are wrong. Cross-filtering breaks. You start writing complicated DAX to fix problems that a clean model would have prevented.
The fix:
Before building a single visual, open Model View. Check your relationships. Confirm your schema.
What happens:
Power BI detects a relationship between two tables but cannot determine which side is “one” and which is “many” — so it creates an M:M relationship.
Why it happens:
The column you are joining on has duplicate values on both sides.
For a clean 1:M relationship, the “one” side must have unique values — no repeats.
Example:
Joining Orders to Products on ProductName instead of ProductID. If product names are not unique — two products called “Wireless Mouse” in different categories — Power BI cannot resolve the relationship cleanly.
What happens:
Cross-filter direction is set to Both on one or more relationships. Filters start flowing in unexpected directions. A visual that should show all products now shows only a subset. Totals shift depending on what else is filtered on the page.
Why it happens:
Bidirectional filtering sounds more powerful — and sometimes it is. But in models with multiple relationship paths, it creates filter ambiguity: Power BI has more than one route to travel and picks one, silently, without telling you.
What happens:
You import one wide table and build your report on top of it. Early on, everything works. Then the dataset doubles. Then someone asks for a new filter by region, and there is no clean Region column — just a City column with 400 unique values. Performance slows. Maintenance becomes painful.
The fix:
If your dataset has clear descriptive attributes — customer details, product categories, geographic hierarchies — split them into dimension tables.
Even a simple three-table Star Schema (Fact + two Dimensions) is dramatically easier to work with than one sprawling flat table.
What happens:
Your relationship looks correct in Model View, but your measures are overcounting. A revenue total is double what it should be. A customer appears twice in a slicer.
Why it happens:
The “one” side of your relationship has duplicate values in the join column. When Power BI tries to resolve the relationship, it finds multiple matches and multiplies the result.
Example:
Your Customers dimension table has two rows for CustomerID C01 — one from an original import and one from a refresh that appended instead of replaced.
What happens:
You use the date column directly from your Fact table for time-based analysis. Some things work. But DAX time intelligence functions (TOTALYTD, SAMEPERIODLASTYEAR, DATESYTD) behave inconsistently or return blanks. Fiscal year filtering is impossible.
Why it happens:
Power BI’s time intelligence functions require a dedicated, contiguous Date table — one row per day, no gaps, marked as a Date table — to work reliably.
What happens:
You create a relationship, Power BI detects a conflict with an existing one, and quietly marks the new relationship as inactive.
Your visual filters by the wrong date column — or does not filter at all — and you spend an hour debugging DAX before realising the relationship was never active.
Why it happens:
Power BI creates inactive relationships silently. No alert. No warning. Just a dashed line you might not notice in a busy Model View.
A model that clears this list is a model you can hand to someone else with confidence.
Fact tables. Dimension tables. Relationships. Star Schema. Role-playing dimensions. Joins in Power Query. You have learned each one individually. Now we put them together — step by step, start to finish — and build a real, working data model in Power BI.
Your job: connect these four tables into a clean Star Schema, handle the role-playing date dimension, and leave the model ready to report on.
💡 Use Transform Data, not just Load. Clicking Transform Data opens Power Query Editor first, giving you a chance to check column types, spot errors, and remove duplicates before anything reaches your model. Make this your default.
When everything looks clean, click Close & Apply on the Home ribbon. Power Query closes and your data loads into the model.
Click the Model View icon on the left sidebar — it looks like three connected shapes stacked vertically.
You will see your four tables laid out on the canvas, possibly in a cluttered arrangement. Power BI may have already detected and created some relationships automatically based on matching column names.
This step is visual but important. A readable Model View is a maintainable model.
Your canvas now physically resembles a star. That visual clarity is intentional — it makes relationships easier to create, easier to review, and easier to hand off to someone else.
Right-click the Date table in Model View.
Select Mark as Date Table.
In the dialog, select the Date column as the date column.
Click OK.
Power BI now recognizes this as an official Date table. Time intelligence functions — TOTALYTD, SAMEPERIODLASTYEAR, and others — will work correctly from this point forward.
Everything checks out. Your Star Schema is built, your role-playing dimension is in place, and your Date table is marked and ready.
If the matrix populates correctly — months on rows, product categories on columns, revenue figures in the cells — your model is working. Filters are flowing from Dimensions to Fact exactly as designed.
They build a few visuals, hit a wall when the numbers stop making sense, and quietly decide that data work is “not for them.”
Not know that the wall they hit was not a skill ceiling. It was a missing foundation — the one you just spent this entire article building.
You look at a schema and know — immediately — whether it will hold under pressure or collapse the moment someone adds a new data source.
It is the difference between someone who uses Power BI and someone who understands it.
Those two people sit in the same meetings, look at the same dashboards, and carry very different levels of quiet confidence.
Here is what the tutorials, YouTube videos, and certification courses rarely say out loud:
You learned them today. What is harder — and what actually separates good analysts from great ones — is the discipline to model before you build.
Take any dataset you have — an Excel file, a work report, anything — and open Power BI.
Build, even if its a simple three-table Star Schema. Create the relationships deliberately. Mark your Date table.
That first deliberate model is where everything you read today stops being knowledge and starts being skill.
Each one builds directly on what you learned here. The model is the foundation. It always was.
Go back to the beginning of this article for a moment — not to re-read it, just to remember where you started.
You came in because something was broken or unclear.
A report that did not behave. A concept that never quite landed. A feeling that everyone else understood something you had not learned yet.
The broken slicer, the wrong totals, the filter that goes nowhere — you know what causes those now.
More importantly, you know how to build something that does not have those problems in the first place.
That knowledge does not expire. It does not get patched out in the next Power BI update.
The Star Schema you built today is the same Star Schema that runs inside the dashboards at companies you have heard of. The relationship principles you learned are the same ones a senior BI developer applies on day one of any new project.
Right now, someone you know is staring at a broken Power BI report right now wondering why their slicer does not work.
Next in this series → **DAX Fundamentals: writing measures, calculated columns, and time intelligence — built on top of the model you just learned to build.
Tags: #PowerBI #DataModeling #DataAnalytics #BusinessIntelligence #SQL #StarSchema #DAX #PowerQuery #BeginnerToAdvanced #DataEngineering
Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment’s permalink.
For further actions, you may consider blocking this person and/or reporting abuse
Built on Forem — the open source software that powers DEV and other inclusive communities.
Why it matters
News like this often changes audience expectations and competitors’ plans.
When one player makes a move, others usually react — it is worth reading the event in context.
What to look out for next
The full picture will become clear in time, but the headline already shows the dynamics of the industry.
Further statements and user reactions will add to the story.