DEV Community: Abdi Omari

Uploading Dashboards to the Web: A Beginner's Guide

Abdi Omari — Tue, 07 Apr 2026 11:51:14 +0000

Your Power BI report looks great on your desktop and your boss just asked you to share the report. His laptop does not have Power BI installed, He also wants to see his report changing and adjust values during his next presentation so your pdf won't do.

This is a classic case that Power BI solves by creating interactive and shareable reports that will leave your boss impressed.

Power BI is a Microsoft Business Intelligence tool used by data analysts to clean, organise and analyse large datasets and present findings in interactive dashboards and reports.

In this Article we will explore how to create an organisations workspace for specific reports, how to publish to the workspace and embedding the Reports.

Step 1: Creating a Workspace

Why it Matters: A workspace is your report's home, it is where you manage, share and control access to specific reports.

Log into Power BI Service
Click Workspaces -> Create a workspace
Choose a meaningful name and Description(Optional)

Click on Create

Step 2: Uploading and Publishing your Report

Why it matters: This moves your report from your local machine into the cloud, making it accessible and shareable.

In Power BI Desktop go to Home -> Publish
Sign in with your Microsoft account if prompted
Select the workspace you created

Once done click the link to open the report in power bi service

Step 3: Generating the Embed Code
Why it matters: The embed code helps you to display PowerBi on a website. it is a snippet of a HTML file that renders a live, interactive report in any webpage.

Open the Published report in Power BI service
Click File -> Embed report -> Website or Portal

A dialog appears with an snippet and a link. Copy the entire code.

This will display your dashboard publicly so remember to double check for sensitive information about the organisation.

Step 4: Embedding the Report on a Webiste

Why it Matters: This is where the report goes live.
Paste the into your HTML where you want the report to appear as such

You can then use free hosting services to deploy your html page online. If you have a live website you can also publish to the website.

That's it
You have successfuly impressed your boss by creating a live, interactive report and embedded it directly in the organisation website. It can update automatically as the underlying data changes.

Understanding Data Modeling in Power BI

Abdi Omari — Mon, 30 Mar 2026 09:22:28 +0000

Data modeling is the invisible foundation underneath every Power BI report. Get it right, and your visuals are fast, accurate, and easy to maintain. Get it wrong, and you spend hours debugging numbers that don't add up and reports that take three minutes to load.

This article is a complete guide to data modeling in Power BI. By the end, you will understand:

What data modeling is and why it matters
All six SQL join types — with examples and diagrams
The difference between joins and Power BI relationships
Every relationship property: cardinality, cross-filter direction, active vs inactive
Fact tables, dimension tables, and why the distinction matters
Star, Snowflake, and Flat Table schemas — with real use cases
Role-playing dimensions
The most common modeling mistakes and how to fix them

Dataset used in this article is a basic excel file for a small retailer with only 5 tables.Feel free to download and follow along.

link to drive
link to github

Section 1 - What is Data Modeling?

Data Modeling is the process of organising tables and defining how they relate to each other so that an analysis tool like powerbi can correctly combine data in reports.

In Power BI, data modeling happens in three places:

Power Query (Query Editor) — where you clean, transform, and sometimes physically combine tables using joins before loading them into the model.
Model View — where you define logical relationships between tables using the drag-and-drop relationship diagram.
DAX (Data Analysis Expressions) — where you write measures that navigate relationships at query time to produce calculated results.

A well-built model is:

Accurate — your numbers are correct because filters flow through relationships properly
Fast — fewer redundant columns mean smaller file sizes and quicker refresh
Scalable — adding a new report page doesn't require restructuring the entire model

The three pillars of Power BI modeling are joins, relationships, and schemas. Let's tackle each one.

Section 2 - SQL Joins

Before a table loads in your Power BI model, you may need to combine it with another table in Power Query. This is done using joins operations. This is a merge option where you decide, based on the join type used, which rows from each table make it into the resulting table.

Load Data in Power BI In Power BI Desktop, connect the Excel Workbook as a data source, open the ShopEase file,select all the sheets and click the Transform Data button on Dialogue box. The Power Query Editor window opens.

Select your LEFT table in the left panel - click on the table you want to be on the left side of the join (e.g. Customers). It becomes the base table — all rows from it are your starting point.

Merge Queries Click Home -> Merge Queries -> Merge Queries

A dialog box opens. Your current (left) table is shown at the top.

Select the RIGHT table and matching columns.
Use the dropdown to pick your second (right) table (e.g. Sales). Then click the matching column in the top table, then click the same column in the bottom table. Both should now be highlighted.
For ShopEase: click CustomerID in Customers, then click CustomerID in Sales.
Pick the Join Kind from the dropdown
At the bottom of the dialog there's a Join Kind dropdown. This is where you choose INNER, LEFT OUTER, etc. Click OK.
Join Kind:

Expand the merged column

A new column appears called Sales (or whatever your right table is named) with a table icon. Click the expand icon (two arrows) in that column header, uncheck any columns you don't need, and click OK. The right table's columns now appear.

This process is repeated for all joins in this article.Feel free to repeat with the different join types explained in this section.Use Sales Table and Customer Table with the different joins.

Inner Join — The Intersection

what it returns: **Only rows that have a matching value in **both tables.
It answers a question such as Which orders have a known customer record?

LEFT OUTER JOIN — Keep Everything on the Left

What it returns: All rows from the left table, plus matching rows from the right. Where there's no match, right-side columns are null.

Real-life question: Show me all customers, and include their orders if they have any. Show customers even if they haven't ordered yet.

RIGHT OUTER JOIN — Keep Everything on the Right

What it returns: All rows from the right table, plus matching rows from the left. Where there's no match, left-side columns are null.

Real-life question: Show me all orders, and include customer details if available — even if an order has no customer record.

This is the mirror of a LEFT JOIN. In practice, you can always replicate a RIGHT JOIN by swapping the table order and using a LEFT JOIN, which is why many analysts use LEFT JOINs exclusively.
>

FULL OUTER JOIN — Keep Everything from Both

What it returns: All rows from both tables. Matched where possible; null fills in where there's no match on either side.

Real-life question: Give me a complete picture — every customer and every order — whether or not they match.

LEFT ANTI JOIN — What's Missing on the Right

What it returns: Only the rows from the left table that have no match in the right table. This is the opposite of a JOIN — it finds the gaps.

Real-life question: Which customers have NEVER placed an order?

RIGHT ANTI JOIN — What's Missing on the Left

What it returns: Only the rows from the right table that have no match in the left table.

Real-life question: Which orders have no matching customer record? (Potential data integrity issue!)

Section 3 — Power BI Relationships vs. SQL Joins

This is the most important conceptual distinction in this entire article. Many Power BI users use these terms interchangeably — they are not the same thing.

Joins: Physical Combination

When you merge two tables in Power Query, you create one new table by stitching columns together. This happens once at refresh time. The result is stored in memory. This is great when you genuinely need data from another table as a column — for example, adding CustomerName to your Sales table.

But if you merge every table into one giant flat table, you lose all flexibility. You can't filter a slicer on the Customers table if Customers doesn't exist as a separate table in your model.

Relationships: Logical Links

When you create a relationship in Model View, the two tables remain completely separate. Power BI simply knows that the CustomerID in Sales points to the CustomerID in Customers. When a user clicks a slicer or drops a field from either table into a visual, Power BI uses the relationship to propagate filters dynamically at query time.

This is what makes Power BI so powerful for reporting — your Customers table can filter your Sales table, your Products table, and your Returns table simultaneously, all through relationships, without ever merging anything.

When to Use Which

Use a join (Power Query merge) when you need a column from another table baked into your fact table (e.g., adding a category name directly to Sales for a calculated column).
Use a relationship (Model View) for everything else — filtering, slicers, cross-table aggregations.

Section 4 — Power BI Relationships Deep Dive

4.1 Cardinality

Cardinality describes how many rows on one side of a relationship can match rows on the other side.

One-to-Many (1:M) — The Workhorse

One row in the dimension table matches many rows in the fact table.

The "one" side (Customers) is the dimension — it contains unique values per key.

The "many" side (Sales) is the fact — it contains repeated keys with transactional data.

This is the most common and recommended relationship type. It's clean, unambiguous, and performs well.

Many-to-Many (M:M)

Many rows in table A match many rows in table B.

Example: If a single order could contain multiple products AND a product could appear in multiple orders — without an intermediate table — you'd have M:M. Power BI does support M:M relationships, but they come with performance costs and can cause unexpected filter behavior.

One-to-One (1:1)

One row in table A matches exactly one row in table B.

Example: A separate CustomerDetails table with extended profile information, where each customer appears exactly once in both tables.

In practice, 1:1 relationships are rare and usually signal that the two tables should simply be merged into one. Use them only when you have a deliberate reason to keep tables separate (e.g., different refresh schedules, security purposes).

4.2 Cross-Filter Direction

Cross-filter direction controls how filters flow across a relationship — specifically, which table's selections affect the other.

Single Direction (Recommended Default)

Filters flow from the "one" side to the "many" side only.

In the Customers → Sales relationship with Single direction:

Selecting a customer in a slicer will filter the Sales table
A filter on Sales will not automatically filter the Customers table

This is the correct behavior for most reporting scenarios. Filters flow "downstream" from dimensions to facts — exactly how you want slicers and visuals to work.

Both Directions (Bidirectional)

Filters flow in both directions between the two tables.

This sounds convenient — and occasionally it is — but it introduces serious risks:

Ambiguity: When multiple relationship paths exist, Power BI may not know which path to use
Circular dependencies: Bidirectional relationships can create loops that Power BI can't resolve
Unexpected filter behavior: A filter on one table may unexpectedly filter other tables

When bidirectional is acceptable:

Many-to-Many relationships (with a bridge table) sometimes need it
Specific calculated measures where you need reverse filtering

4.3 Active vs. Inactive Relationships

Only one relationship can be active between any two tables at a time. This creates a challenge when you need to connect two tables via multiple paths.

The classic ShopEase problem:

Our Sales table has two date columns: OrderDate and ShipDate. Our Date dimension table needs to connect to both. But Power BI only allows one active relationship.

Solution:

Create an active relationship between Date[DateKey] and Sales[OrderDate]
Create an inactive relationship between Date[DateKey] and Sales[ShipDate]

In Model View, active relationships appear as solid lines. Inactive relationships appear as dotted lines.

Section 5 — Fact Tables vs. Dimension Tables

Every well-structured Power BI model is built around a clear distinction between two types of tables.

Fact Tables

A fact table contains measurable, transactional events. Each row represents something that happened — a sale, a return, a login, a payment.

Characteristics:

Contains numeric measures (Quantity, TotalAmount, Revenue, Cost)
Contains foreign keys that point to dimension tables
Usually has many rows (thousands to millions)
Relatively few columns

Dimension Tables

A dimension table contains descriptive attributes used to filter, group, and label your facts.

Characteristics:

Contains a unique primary key (one row per entity)
Contains many descriptive columns (names, categories, addresses)
Usually has fewer rows than fact tables
Wide tables are fine here

Section 6 — Schemas

A schema is the overall shape of your data model — how tables are organized and connected. There are three main patterns.

6.1 Star Schema

The star schema places a single fact table at the center, surrounded by flat (denormalized) dimension tables — like a star.

Key rules of a star schema:

Dimension tables are flat — no dimension links to another dimension
Each dimension has a single primary key
All joins go through the fact table

Advantages:

Simple to understand — even non-technical stakeholders get it
Maximum DAX performance — filter paths are short and unambiguous
Easy to add new dimensions without restructuring
Slicers and cross-filtering work predictably

Use when: Building any report-ready Power BI model. This should be your default.

6.2 Snowflake Schema

The snowflake schema normalizes dimension tables — meaning dimension attributes are broken into sub-tables, which branch off like a snowflake.

Advantages:

Reduces data redundancy (the word "Electronics" is stored once, not repeated per product)
Mirrors normalized source systems (SQL Server databases often look like this)
Easier to maintain category hierarchies

Disadvantages:

More tables, more relationships = more complexity in Model View
Slightly slower DAX queries (more hops for the filter engine)
Harder for end users and new team members to navigate

Use when: Your source data warehouse is already normalized and restructuring it in Power Query isn't practical. Or when you have deep hierarchies (Region → Country → Province → City) that genuinely benefit from normalization.

6.3 Flat Table / Denormalized Table (DLAT)

A flat table (also called a DLAT — Denormalized, Large, All-in-one Table) puts everything into one wide table with no relationships at all.

Advantages:

Extremely simple — no relationship configuration needed
Easy to understand for non-technical users
Quick to set up for simple, single-subject reports

Disadvantages:

Massive redundancy — "Alice Mokoena" and "Johannesburg" are repeated in every one of her rows
Large file sizes and slow refreshes
Impossible to reuse dimension data across multiple fact tables
Slicers can produce incorrect counts (e.g., a customer appears 3 times in a list)

Use when:

Quick one-off prototypes
Very simple, single-table dashboards
Sharing data with users who need to work in Excel

Section 7 — Role-Playing Dimensions

A role-playing dimension is a single dimension table that's used multiple times in the same model, each time serving a different purpose — a different "role."

The most common example is the Date dimension. In ShopEase, our Sales table has two date columns:

OrderDate — when the order was placed
ShipDate — when the order was dispatched

Both dates are meaningful for reporting. But we only want to maintain one Date dimension table (with Year, Month, Quarter, etc.) — not two identical copies.

When to use which approach:

Duplicate table — when your users need to use both date hierarchies side-by-side in the same visual (e.g., slicing by Order Month AND Ship Month simultaneously)
Inactive + USERELATIONSHIP — when you want a clean, memory-efficient model and the alternate date is only needed in specific measures

Conclusion

Data modeling in Power BI is not a step you do once and forget — it's a discipline that shapes every number your reports produce and every second your refresh takes.

Here's the hierarchy to keep in mind:

Joins (Power Query): Combine tables physically when you need columns from different sources baked into one table. Use the right join type for the right question.
Relationships (Model View): Link tables logically so filters can flow between them at report time. Keep them directional and cardinality-correct.
Schemas: Organize your tables into a Star Schema wherever possible. It's the fastest, simplest, and most maintainable structure for Power BI.
DAX: Navigate and manipulate relationships in your measures when the model structure alone isn't enough.

The golden rule is simple: model for clarity and performance, not convenience. The temptation to dump everything into a flat table is real — it feels fast in the moment. But the debt compounds quickly. A well-structured star schema takes an afternoon to set up and saves you months of debugging.

Your next steps: load the ShopEase tables into Power BI, recreate the star schema from this article, experiment with each join type in Power Query, and try building a Sales by Ship Date measure using USERELATIONSHIP(). The concepts click fastest when your hands are on the keyboard.

How Linux is Used in Real-World Data Engineering

Abdi Omari — Sat, 21 Mar 2026 05:25:02 +0000

Linux stands out as a usefool tool in data engineering because of it's unique features: the Command Line interface CLI, Compatibility with most Data Tools, Security and Scalability as well as cost effectiveness due to being an open source platform. These attributes make the work of an individual or organisation in Data Engineering easier.
As a beginner here are some of the things to look out for as you start your journer in Data Engineering.

Using the CLI

The Command Line Interface is a tool used to interact with programs using commands, more like shortcuts to get things done faster.
It involves typing reserved words(Commands) in an interface that does not allow use of other input devices such as a mouse. While most beginners find this unconventional, mastery of the CLI will make you realise it is one of the easiest and most convenient tools moreso in Data Engineering.

The CLI can be used to:

Manage files and folders better known as directories
Manage processes and running applications
Configure and manage your network
Check system information
Process,compress and archive data
Create scripts and many more

Here is what you need to get started:

Navigating the CLI

While the CLI usually seems intimidating to a new user, familiarity and ease builds up by knowing the right tips and tricks.

Get used to using the keyboard only.
To run a command type the command and hit enter(the cli will respond by running the command or give you an error
To clear your screen - use a command clear or ctrl + l
To use a recently used command - use the up arrow key
To interrupt a process before it completes - ctrl + c
To autocomplete use tab key
to Copy or paste text - ctrl + shift + c/v
To open a new tab - ctrl + shift + T

Basic commands that you need to know for Data engineering basics

Commands in file management
mkdir <directory name> - Create a directory
pwd - print working directory
ls -List directory contents
cd - change directory
rm - remove an empty directory
cp - copy files or directories
scp - securely copy files to a server
mv - move or rename files 
touch - create an empty file
cat - concatenate and display contents in a file

File management is important to allow or deny different users to make changes to your files.

Think of 3 people working on a document where Person A is allowed to view, edit and process the document, Person B can only do two of the activities and person C can only do one.
this protects the document from unintentional distortion or unwanted changes.
A rule of thumb is the principle of least privilege where a user is given only the level of access they need.

File permissions 
ls -l - view permissions
chmod - modify permissions for users

wget - download files from the web
curl - transfer data from or to a server
ssh - connect to a remote server securely 
scp - securely copy files to a server

Let us look at an example of how to work with terminal as a data engineer

Create a directory, navigate to the directory and create a new file. -file.txt
Add some text to the file using vi or nano (inbuilt editors)

Check file permissions

We can also download other tools using the CLI. An example is Docker - a containerization tool used by engineers to build, ship and run applications in lightweight packages called containers.

On a linux based terminal:

Download the script curl -fsSL https://get.docker.com -o get-docker.sh
Run the script
sudo sh get-docker.sh
Check if Docker is successfully installed

docker --version or docker version for extra details