DEV Community: Judy Wambugu

Schemas and Data Modelling in Power BI: A Beginner-Friendly Guide

Judy Wambugu — Tue, 03 Feb 2026 15:47:41 +0000

When working with Power BI, one of the most important (and often overlooked) step is data modelling. A good data model makes your reports faster, easier to build and more accurate. A bad model can lead to slow performance, confusing visuals and incorrect results.

In this article we will explore:

What data modelling is
Fact and dimension tables
Common schema and model types such as Star schema and Snowflake schema
Relationships in Power BI
Why good data modelling is critical for performance and reporting accuracy

What is Data Modelling in Power BI?

Data Modelling is the process of organizing tables and defining relationships between them so that Power BI understands how data connects. Data modelling is not just a technical step, it directly affects performance, accuracy, and usability of Power BI reports.

A data model answers questions like:

How are sales linked to customers?
How do dates connect to transactions?
Which tables store descriptive data and which store numbers?

Power BI uses this model to:

Calculate measures correctly
Filter visuals properly
Optimize performance using its internal engine (Vertipaq). This engine performs best when data is structured in a simple and predictable way.

Fact Tables and Dimension Tables

Most Power BI models are built using fact tables and dimension tables.

Fact Tables

A fact table stores:

Numeric values (measures)
Business events or transactions

Examples of facts:

Sales amount
Quantity sold
Revenue
Cost
Profit

Typical characteristics:

Very large (many rows)
Contains foreign keys linking to dimension tables
Used for calculations and aggregations

Example fact table: Sales
| DateID | ProductID | CustomerID | SalesAmount | Quantity |
|------|----------|-----------|------------|----------|

Dimension Tables

A dimension table stores descriptive information that gives context to facts.

Examples of dimensions:

Customers
Products
Dates
Locations
Categories

Typical characteristics:

Smaller than fact tables
Contain unique values (one row per item)
Used for filtering, slicing, and grouping data

Example dimension table: Product
| ProductID | ProductName | Category | Brand |
|----------|------------|----------|-------|

Common schema and model types

What Is a Star Schema?

A star schema is the most recommended data model in Power BI.

In a star schema:

There is a single fact table sits at the center
There are multiple dimension tables that connect directly to the fact table. There is also no relationships between dimensions.
The model looks like a star

Some advantages of using a star schema model include:

Better/fast performance. A clean star schema reduces memory usage
Simple DAX formulas
Easier filtering and slicing
Fewer relationship issues. Poor models with unnecessary relationships slow everything down.

Some disadvantages of a star schema model include:

Data redundancy since dimension tables in a star schema are large and often store repeated descriptive values, for instance a product dimension can repeat category name and the brand name even though there may be a category or brand dimensions as well
More complex relationships
Harder DAX calculations
Less intuitive for report users

What Is a Snowflake Schema?

A snowflake schema is a more complex version of a star schema.

In a snowflake schema:

There is also a central fact table
There are also multiple dimension tables which are broken into multiple related tables. These dimensions connect to other dimensions instead of directly to the fact table

Advantages of a snowflake schema include:

Reduces data redundancy especially when the dimension tables are very large
Normalized structure (similar to databases)

Disadvantages of a snowflake schema include:

Slower performance in Power BI
More complex relationships
Harder DAX calculations
Less intuitive for report users

Relationships in Power BI

Relationships define how tables are connected.

Common Relationship Types

1. One-to-Many (1:*)

This is the default and most recommended relationship in Power BI. It is characterized by:
One dimension record which relates to many fact records For instance: One customer → many sales or One product → many transactions
It is the most preferred relationship type because it is simple, fast, easier to use for accurate filtering and works perfectly with a star schema.

2. Many-to-One(*:1)

This is the same relationship as one-to-many, just viewed from the other direction.

3. One-to-One(1:1)

It is characterised by one row in one tables matching exactly one row in another table. For instance: Employee table ↔ Employee details table.
It is mostly used when splitting a wide table into two or for security reasons.

4. Many-to-Many(:)

It is characterised by multiple rows in one table relating to multiple rows in another table. For instance: products belonging to multiple categories or customers in multiple segments.
Can cause ambiguity filtering and incorrect results if not handled carefully

Relationship Direction (Filter Direction)

Single direction: Filters flow in one direction only. A typical flow would be from dimension → fact (recommended). It is preferable because it is predictable, has better performance and there are fewer circular dependencies.
Both directions: Filters in both directions. For instance: Dimension ⇄ Fact. It is mostly used where there is many-to-many relationships and complex slicer interactions. It's downside is that it can cause confusing results and slower performance.

Why Good Data Modelling is critical for Performance and Reporting Accuracy

In conclusion, good data modelling is the foundation of every successful Power BI report. Even with clean data and beautiful visuals, a poorly designed data model can cause slow performance and incorrect results.
Power BI relies heavily on the structure of the data model to decide how data is filtered, aggregated, and calculated.
Good modelling helps performance because there are fewer tables and relationships to scan, there is reduced memory usage, faster query execution and smoother interactions (slicers, filters, visuals).

A Beginner-Friendly Guide to Git, GitHub, and Version Control

Judy Wambugu — Sun, 18 Jan 2026 10:03:45 +0000

Git for Beginners: What it is, Why it matters and how to use it with GitHub

If you are new to tech, data or programming, you've probably heard people talk about Git and GitHub a lot, and maybe felt a bit confused. I know I did.

This article explains Git in simple terms, why it's important and how to use it to:

Track changes in your code
Push your work to GitHub
Pull updates from GitHub
Avoid losing progress when things break

What is Git?

Git is a version control system.It is a local tool that tracks every change you make to your code. Think of it like "Track Changes" in Microsoft Word, but for code.

That means Git helps you:

Keep track of changes in your file
Save different versions of your work
Go back in time if something breaks
Work safely without losing progress
It also lets multiple people work on the same code without overwriting each other.

Git runs on your computer and works quietly in the background. Every time you make a change, Git can take a snapshot of your project. These snapshots are called commits.

The command-line program to interact with Git is called GitBash. Another GUI where you can also use Git is Visual Studio Code (VS Code)

Why is Version Control Important?

Before Git, people used to save 20 versions of a file, copy folders as backups and panic when something breaks.

Version control is a core skill in tech, data and software roles.

What is GitHub (and how is it different from Git)?

This part often confuses beginners.

Git → Tracks changes locally on your computer
GitHub → Stores your Git projects online

GitHub is a cloud platform where you:

Back up your code
Share projects
Collaborate with others
Build a public portfolio

GitHub works with Git, it doesn’t replace it.

Basic Git and GitHub Workflow (How Git, GitBash and GitHub intergrate)

Here’s the normal flow:

Write code on your computer using GitBash or VS Code which are the interface to Git
Git tracks the changes
You save a snapshot (commit)
You push it to GitHub which is your cloud storage
Others (or future you) can pull it later

How to Track Changes Using Git

Once Git is set up in a project folder, it automatically notices when files change.

Common Git actions:

Status → What changed?
Add → Select changes to save
Commit → Save a snapshot

Example:

bash git status

This command tells you:

Which files changed
Which files are ready to be committed
What Git is waiting for you to do next

Saving Changes (Add and Commit)

To save your work in Git, you usually do two things:

bash
git add
git commit -m "Describe what you changed"

git add → selecting files
git commit → clicking save

How to Push Code to GitHub

Once your changes are committed locally, you can send them to GitHub using the following code:

bash
git push origin main

This uploads your commits to the remote repository on GitHub.

Now your work is:

Backed up online
Visible to others
Safely stored even if your laptop breaks

How to Pull Code to GitHub

If you’re working on multiple devices, or collaborating with others, you’ll need to pull updates from GitHub:

bash
git pull origin main

This downloads the latest changes and updates your local project.