Power BI Lesson 11 – Model View Basics | Dataplexa

Beginner Level · Lesson 11

Model View Basics

Loading data into Power BI is only half the job. The other half is telling Power BI how your tables are connected — which column in one table links to which column in another. This structure is called the data model, and getting it right before you build a single visual is what separates reports that work from reports that silently give wrong answers.

What Is a Data Model?

In most real reports you have more than one table. An orders table has order rows. A customers table has customer details. A products table has product names and categories. These tables are separate — but they share columns that link them together. The data model is the map of those links.

Without a model, Power BI treats each table as a complete island. A bar chart showing Revenue by Customer Name is impossible if Revenue lives in Orders and Customer Name lives in Customers — unless a relationship connects them. The relationship is how Power BI knows that CustomerID in Orders refers to the same customers as CustomerID in the Customers table.

No relationships defined

Each table is isolated. You can only see columns from one table per visual. Revenue by CustomerName is impossible. Filters applied to one table do not affect another. Every chart is limited to the data inside a single table.

Relationships defined

Tables are connected. A slicer filtering by Region affects visuals pulling from Orders, Products, and Customers simultaneously. You can build charts mixing columns from different tables freely. Filters propagate automatically across the model.

Opening Model View

Model View is the third icon in the View Switcher on the left side of Power BI Desktop — it looks like three connected rectangles. Click it and you see your tables laid out as boxes with lines connecting them. Each box shows the table name and all its columns. Each line represents a relationship.

Model View — Sales Data Model

Customers

🔑CustomerID

🔤CustomerName

🔤Region

🔤Email

🔤Segment

Orders

🔑OrderID

🔗CustomerID

🔗ProductID

📅OrderDate

1.2Revenue

123Quantity

🔤Status

Products

🔑ProductID

🔤ProductName

🔤Category

1.2UnitPrice

Calendar

🔑Date

123Year

🔤MonthName

123Quarter

🔑 Primary key (unique values)

🔗 Foreign key (links to another table)

— Relationship line · 1 = one side · * = many side

Primary Keys and Foreign Keys

Every relationship connects two columns — one from each table. The column on one side is a primary key and the column on the other side is a foreign key. Understanding these two terms is the entire foundation of data modelling.

🔑

Primary Key

A column where every value is unique — no duplicates, no nulls. It uniquely identifies each row in its table. In the Customers table, CustomerID is the primary key — there is exactly one row per customer.

Rule: Every lookup table must have a primary key. If it does not, the relationship will not work correctly.

🔗

Foreign Key

A column that refers to a primary key in another table. Values repeat — many orders can have the same CustomerID because the same customer can place many orders. CustomerID in the Orders table is a foreign key.

Rule: The foreign key column must have the same data type as the primary key it connects to.

Relationship Cardinality

Cardinality describes how many rows on each side of a relationship can match each other. Power BI displays this as numbers and asterisks on the relationship line. Getting cardinality right is not optional — the wrong cardinality setting causes incorrect filter behaviour and wrong aggregation results.

Cardinality	What it means	Real example	Use this?
One-to-Many (1:*) Most common	One row in Table A matches many rows in Table B. The "one" side has unique values (primary key). The "many" side has repeating values (foreign key).	One Customer → Many Orders. One Product → Many Order Lines. One Date → Many Transactions.	Always preferred
One-to-One (1:1) Rare	One row in Table A matches exactly one row in Table B. Both sides have unique values. Both columns are effectively primary keys.	Employee table ↔ Employee Details table where both use the same EmployeeID with no repeats on either side.	OK — usually merge instead
Many-to-Many (:) Avoid unless necessary	Many rows in Table A match many rows in Table B. Neither side has unique values. Power BI allows this but it produces ambiguous filter results and unexpected totals.	A student can enrol in many courses, and each course has many students. A product can belong to many categories and each category has many products.	Avoid — redesign model

Filter Direction

Every relationship has a filter direction — it controls which table passes filters to which. This is shown in Model View as an arrow on the relationship line. Understanding filter direction is critical for building correct slicers and cross-filtering between visuals.

Single direction (→) — recommended

Filters flow from the "one" side to the "many" side only. Selecting a customer in a slicer filters orders down to just that customer's orders. This is the standard and most predictable behaviour.

Customers → Orders
Products → Orders
Calendar → Orders

Both directions (↔) — use with caution

Filters flow in both directions. Selecting a product in a visual filters the Customers table too. This sounds useful but often produces circular filter paths and slow performance. Use only when a specific DAX scenario requires it.

Warning: "both" direction can cause ambiguous paths in complex models

Creating a Relationship Manually

Power BI attempts to auto-detect relationships when you load tables — if two tables both have a column named "CustomerID" with matching types, it draws a line automatically. But auto-detection is not always right, and you will often need to create or edit relationships yourself.

Open Model View Click the Model View icon (three rectangles) in the left View Switcher. You will see all loaded tables as boxes on a canvas.

Drag from the foreign key to the primary key Click and hold on the CustomerID column in the Orders table, then drag the mouse over to the CustomerID column in the Customers table and release. Power BI draws a relationship line between them.

Verify the cardinality and direction Power BI detects the cardinality automatically based on whether the columns have unique values or not. Check that it shows 1:* (one-to-many) and that the arrow points from Customers to Orders. If it shows *:* something is wrong — usually duplicates in what should be the unique side.

Edit or confirm in the Edit Relationship dialog Double-click any relationship line to open the Edit Relationship dialog. This shows both tables side by side, lets you change which columns are linked, adjust cardinality, and set filter direction. Always confirm that the highlighted columns are the correct pair.

Edit Relationship — Orders ↔ Customers

Orders (many side)

OrderID	CustomerID	Revenue
1001	C101	$1,200
1002	C102	$350
1003	C101	$85

Customers (one side)

CustomerID	CustomerName	Region
C101	Alice Brown	North
C102	Bob Singh	South
C103	Carol Lee	East

Cardinality

Many to one (*:1)▾

Cross filter direction

Single▾

Make this relationship active

Active

Cancel

Star Schema — The Right Way to Structure a Model

The star schema is the standard structure for Power BI data models. It has one central fact table surrounded by dimension tables connected to it. Every professional Power BI model is built around this pattern — and once you understand it, you will recognise it in every report you ever open.

Fact Table

The central table containing measurable events — transactions, orders, clicks, sales. It has many rows (one per event) and contains numeric columns you will aggregate (Revenue, Quantity, Cost) and foreign key columns that link to dimension tables.

Examples: Orders, Transactions, Sales, Events, PageViews

Dimension Tables

Lookup tables containing descriptive attributes about the entities in your fact table. They have fewer rows, a primary key column, and text or category columns used for grouping and filtering in reports.

Examples: Customers, Products, Calendar, Geography, Employees

Star Schema rules — memorise these:

1. One fact table at the centre
   - Contains numeric measures: Revenue, Qty, Cost, Clicks
   - Contains foreign keys: CustomerID, ProductID, Date
   - Has many rows (thousands to millions)

2. Dimension tables surround the fact table
   - Each has a primary key (unique, no nulls)
   - Connected to the fact table with a 1:* relationship
   - Filter direction: from dimension TO fact (single direction)
   - Has few rows compared to the fact table

3. Relationships only go from dimension to fact
   - Customers (1) → Orders (*)
   - Products  (1) → Orders (*)
   - Calendar  (1) → Orders (*)

4. Dimension tables do NOT connect to each other
   - Do not draw a line from Customers to Products
   - Cross-filtering between dimensions happens
     automatically through the fact table

5. No calculated columns in fact tables as relationships
   - Always relate on the raw key columns, never on
     columns created with DAX formulas

What filters can flow in this model

User clicks "North" in Region slicer

→ Filters Customers table to North customers → flows into Orders table → Revenue, Quantity totals now show North-only data

User selects "Electronics" in Category slicer

→ Filters Products table → flows into Orders → all visuals now show Electronics orders only

User selects Q1 2024 on date slicer

→ Filters Calendar table → flows into Orders → Revenue chart now shows Q1 2024 only

All three slicers active simultaneously

→ Orders table is filtered by all three dimensions at once — AND logic — correctly narrows to North + Electronics + Q1 2024 orders

Common Model Mistakes to Avoid

Mistake 1 — Relating on columns with different data types

CustomerID in Orders is a Whole Number (123) but CustomerID in Customers is Text ("C101"). Power BI will create the relationship but it will never match any rows — all visuals show blank or zero. Always check that both key columns have the exact same data type before creating a relationship.

Mistake 2 — Duplicate values on the "one" side

If your Customers table has two rows with CustomerID = C101, the relationship becomes many-to-many, which Power BI flags with a warning icon. Remove duplicates from your dimension table primary key in Power Query before creating relationships.

Mistake 3 — Connecting tables in a chain instead of a star

Customers → Orders → Products creates a chain — filter context becomes ambiguous and filters from Customers can block Products. Always connect all dimension tables directly to the central fact table, never through other dimension tables.

Mistake 4 — Leaving Auto date/time turned on

If Auto date/time is enabled (we turned it off in Lesson 4), Power BI creates a hidden Calendar table for every Date column in your model. This duplicates your date table and conflicts with any Calendar table you add yourself. Keep it off and manage your own Calendar dimension.

Teacher's Note: You will often hear the term "flat table" — a single wide table where everything is crammed into one place (CustomerName, ProductName, Region, Revenue all in one table). Flat tables feel simple but they break DAX, cause massive data redundancy, and make building correct totals nearly impossible. Always split your data into a star schema before building your report. The few minutes it takes to set up relationships correctly save hours of debugging wrong numbers later.

Practice

Practice 1 of 3

In a star schema, the central table that contains one row per transaction and holds numeric measures like Revenue and Quantity is called the ___ table.

Practice 2 of 3

A column that contains unique values and identifies each row in its table is called a primary ___. The corresponding column in the related table that references it is called a foreign ___.

Practice 3 of 3

In a one-to-many relationship, filters flow from the ___ side (the dimension table) to the ___ side (the fact table) in single-direction mode.

Lesson Quiz

Quiz 1 of 3

You create a relationship between Orders.CustomerID and Customers.CustomerID. Power BI marks it as a many-to-many relationship instead of one-to-many. What is the most likely cause?

The two columns have different names — Power BI requires them to be identically named for a one-to-many relationship The Customers.CustomerID column has duplicate values — it needs to be a unique primary key for the "one" side The Orders table has too many rows — relationships become many-to-many when one table is significantly larger than the other The relationship direction is set to "Both" — switching to "Single" will change the cardinality to one-to-many

Quiz 2 of 3

A slicer filtering by Product Category does not affect the Revenue total shown by a chart pulling from the Orders table. Both tables are loaded. What is the most likely reason?

The Orders table needs a Category column added before the slicer can filter it Slicers can only filter the table they are built from — cross-table filtering requires a DAX measure There is no active relationship between the Products table and the Orders table — the filter has no path to flow through The slicer needs to be set to "sync across pages" before it can filter visuals from other tables

Quiz 3 of 3

In a well-designed star schema, which of the following relationship structures is correct?

Customers → Orders ← Products, with Calendar → Orders — all dimensions connected directly to the fact table Customers → Orders → Products, where Orders connects dimension tables in a chain Customers ↔ Orders ↔ Products with bidirectional filters on every relationship for maximum flexibility A single flat table containing all columns from Customers, Orders, and Products combined

Next up — Lesson 12 moves into Report View Basics — how the report canvas works, how to add and arrange visuals, how pages work, and how to build your first complete page from a connected data model.

← Previous Course Index Next →

Power BI Course