DEV Community: Wendy Ochieng

Power BI: Data Modelling, Relationships & Joins

Wendy Ochieng — Sun, 13 Sep 2026 12:30:30 +0000

1. Data Modelling in Power BI

What is Data Modeling?
Data Modeling is how you organize and connect your tables in Power BI so they work together properly.

Data modelling is the discipline of not writing everything on one page. It's deciding where each piece of information belongs so it only must be written once, and everything else just points back to it.

In the Kenya Crops csv, "Kiambu" and "Potatoes" repeat on every row a Kiambu potato farmer shows up in. A well-designed model instead stores "Kiambu" once and "Potatoes" once. The harvest record in the fact table just holds a short reference (a key) back to each of them. That's the whole idea behind data modelling: separate the things that describe (farmer, county, crop i.e., who/what/where) from the things that happen (a harvest event with its yield, revenue, and cost), so each fact is stored once and reused everywhere it's needed.

If the data is all scrambled up, it may create problems when trying to find specific things. In Power BI, these problems include

Duplication
Difficulty in updating
Extra Large files

You can thus split a table into multiple smaller connected tables. These connections are called relationships which will be discussed later in this article.

Data modeling organizes data into a structured model by;

Organizing tables and columns
Defining relationships between tables
Setting cardinality and cross-filter direction
Supporting accurate calculations and reporting

Data Models

The underlying structure that organizes and relates data tables for analysis.

1. FLAT TABLE

Definition

A flat table is a data model in which most or all of the information required for analysis is stored in a single table. Instead of separating information into fact and dimension tables, descriptive attributes and numerical measures are stored together in the same table.

Structure

Advantages

Simple to understand and create.
No relationships between tables are required.
Suitable for small datasets and simple reports.
Easy to use for basic Power BI visualizations.

Disadvantages

Information can be repeated many times.
Can become large and difficult to maintain.
Less suitable for complex analysis.
Limited scalability as the dataset grows.

Appropriate situations

A flat table is suitable for small datasets, simple reports, prototypes, or one-off analysis.

Power BI implications

It has low modelling complexity because there are few or no relationships. However, a large flat table can contain significant repetition and become less efficient as the dataset grows.

2. STAR SCHEMA

Definition

A mature data modeling approach with a central fact table surrounded by dimension tables, like points on a star, optimized for performance and simplicity in reporting.

Structure:

Center: Harvest (fact table with harvest transactions. one row per farmer's harvest, holding the numbers: Yield (Kg), Revenue (KES), Cost of Production (KES), Profit (KES))
Points: Farmer, Crop, County, Date (dimension tables, the who/what/where/when)
Connections: Each dimension connects directly to Harvest
Key characteristic: Dimensions are denormalized (flat)

Advantages

Easy to understand
Fast performance. Queries run faster. Refreshes complete quicker.
Easy to maintain
User friendly.
Easily scalable. Works the same for data with 1000 rows or 1 million rows
Simple measures

Total Yield = SUM('Kenya_Crops_Dataset 5'[Yield (Kg)])

Disadvantages

More complex than a flat table.
Requires relationships between tables.
Requires understanding of keys, relationships and data granularity.

Appropriate situations

A star schema is particularly suitable for medium-to-large Power BI reports, business intelligence systems, and datasets requiring multiple types of analysis.

Power BI implications

The star schema is generally the preferred approach for Power BI. Its clear separation between measurable data and descriptive data supports efficient filtering, grouping and calculations.

3. SNOWFLAKE SCHEMA

An extension of a star, and includes relationships between dimension tables and related sub-dimension tables. In short, Dimension tables have their own dimension tables, creating branches like a snowflake.

Structure

Center: Harvest (same fact table)
Points: Farmer, Crop, Date, and County but County now points on to a further table
Extra point: Region, connected only to County (not directly to Harvest)
Connections: Farmer, Crop, and Date connect directly to Harvest, exactly like the star. County also connects directly to Harvest, but County itself connects to Region one level out.

Advantages

Reduces duplication.
Organizes hierarchical information clearly.
Can be useful when dimensions contain complex hierarchies.
Can reflect a normalized database structure.

Disadvantages

Requires more tables and relationships.
More difficult to understand and maintain.
Creates longer filtering paths.
Can increase Power BI model complexity.
May be less efficient than a star schema for reporting.

Appropriate situations

A snowflake schema may be appropriate when the source data is already highly normalized or when complex hierarchies and reduced data redundancy are important.

Power BI implications

Snowflake schemas can work in Power BI, but the additional relationships can make the model more complex. For many Power BI reports, a star schema is easier to use and maintain.

2. Fact Tables and Dimension Tables

Every table in your model falls into one of these categories

Fact Tables: The “What Happened” Tables

Fact tables contain measurable business events; the transactions, the actions, the things you want to count or sum.

Characteristics:

Mostly numbers and IDs (very little text)
Many rows (thousands to millions)
Each row is an event or transaction
Grows over time (new rows added constantly)
Contains the data you want to measure

For example, a sales fact table might contain:

Sale ID
Date ID
Customer ID
Product ID
Location ID
Quantity sold
Sales amount
Discount
Profit

The numeric values represent measurable business events. For example, Quantity Sold can be added to determine total units sold, while Sales Amount can be summed to calculate total revenue.

Common examples include FactSales, FactOrders, FactTransactions, and FactProduction.

Fact tables normally contains numeric values (measures) and foreign keys that connect the facts to relevant dimension tables. The dimension key columns determine the dimensionality of a fact table, while the dimension key values determine the granularity of a fact table.

Grain or Granularity

The grain of a fact table describes exactly what one row represents. Defining the grain is important because it determines what can be accurately measured.

For example, consider a fact table designed to store sale targets that has two dimension key columns; Date and ProductKey. It's easy to understand that the table has two dimensions. The granularity, however, can't be determined without considering the dimension key values. In this example, consider that the values stored in the Date column are the first day of each month. In this case, the granularity is at month-product level.

Dimension Tables: The Who, What, When, Where Tables

Dimension tables contain descriptive information that gives context to your facts. They’re the details that help you slice, filter, and group your measures. The most consistent table you'll find in a star schema is a date dimension table.

A dimension table contains a key column (or columns) that acts as a unique identifier, and other columns. Other columns support filtering and grouping your data

Characteristics:

Mostly text and categories
Fewer rows (dozens to thousands)
Relatively stable (changes infrequently)
Contains the attributes you filter and group by
Provides the “story” around the numbers

Examples include:

DimCustomer – Customer ID, customer name, gender, age group, city and customer segment.
DimProduct – Product ID, product name, category, brand and product type.
DimDate – Date ID, date, day, month, quarter and year.
DimLocation – Location ID, county, sub-county, region and country.

For example, a DimProduct table allows users to analyse sales by product, category or brand, while DimDate allows sales to be analysed by month, quarter or year.

How to Tell Them Apart

Ask yourself:

Does each row represent a transaction or event? Yes → Fact table No → Dimension table
Will this table grow significantly over time? Yes → Probably a fact table (new sales every day) No → Probably a dimension (your product list doesn’t double every week)
Am I measuring this or describing something? Measuring → Fact (measuring sales amounts) Describing → Dimension (describing what products are)
Does this table have mostly numbers or mostly text? Numbers → Fact Text → Dimension

A real scenario

You're building a report on Kenyan crop harvests. Here's the data:

1.Harvest records: 500 rows, growing every season as new harvests are logged. This is a fact table. Each row is a transaction, a farmer's harvest of a crop, with numeric outcomes like yield, revenue, cost, and profit.

2.Farmer list: grows slowly, but each farmer's name and contact only need to be stored once. This is a dimension table.

3.County list: around 12 counties, essentially fixed. This is a dimension table.

4.Crop catalog: crop type and crop variety, a short list that only changes when a new crop is introduced. This is a dimension table.

5.Seasonal price snapshot: if average market price per crop per county were captured at the start of every season, that's a recurring snapshot of a state at a point in time, similar to an inventory snapshot. It counts as a fact table, even though it's "just prices."

Table size doesn't decide fact vs dimension. DimFarmer could eventually hold more rows than a small fact table starts with, and it's still a dimension, because each farmer is described once. FactHarvest is a fact table because each row represents something that happened, not something being described.

The connection

Measures versus Descriptive Attributes

Fact tables contain numerical values or metrics used for summarization while Dimension tables contain descriptive attributes used for filtering or grouping

Fact tables sit at the center of the model. Dimensions surround them and provide the context to filter by.

Measure: Total Profit = SUM(FactHarvest[Profit (KES)])
Filter: County = "Kiambu" (from DimCounty)
Result: total profit earned by Kiambu farmers specifically

The relationship between FactHarvest and DimCounty is what makes that filter work. Without it, county would just be text sitting in the fact table with nothing to slice it by.

3. Relationships in Power BI

Relationships are the invisible bridges between your tables, letting Power BI treat them as connected without merging them into one table.
Without relationships, Power BI treats your tables as completely separate islands.

With proper relationships:

Filter by customer name → automatically filters their sales
Slice by product category → sees all products in that category
Your measures calculate correctly
Visuals respond to each other

In Excel, if you want to show customer names next to sales amounts, you use VLOOKUP. Then you copy that formula down 10,000 rows. If customer names change, your VLOOKUP might break. If you sort one column, the VLOOKUPs don’t update.

In Power BI, you create the relationship once. The relationship handles everything else. No copying formulas. No broken references when data update

Types of Relationships

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

One record on one side connects to many records on the other side. DimFarmer to FactHarvest is a good example: one farmer, many harvest records across seasons. The same applies to DimCounty and DimCrop connecting to FactHarvest. Use it whenever a dimension describes something the fact table records repeatedly.

2. One-to-one (1:1)

Each row on one side matches exactly one row on the other, with no repeats either way. This is uncommon in practice. An example here would be if Farmer Contact were split into its own table, with exactly one contact record per farmer, that would be 1:1. Usually it's a sign the two tables should just be combined instead.

3. Many-to-many (:)

Rows on either side can match multiple rows on the other. An example from this dataset would be Pest Control method versus Crop Type, where a crop can use several methods, and a method applies to several crops. This should be used carefully, since it can cause ambiguous filtering, and is often better resolved with a bridge table.

Keys:

Primary key: uniquely identifies each row in a dimension table, for example FarmerID in DimFarmer, appearing once.
Foreign key: the same column shown in the fact table, repeating once per event, for example FarmerID in FactHarvest appearing many times.
Cardinality: the relationship type, whether 1:*, 1:1, or :. tells you how many records on each side can match.
Referential integrity: every foreign key in the fact table must have a matching primary key in the dimension table, otherwise that row gets excluded from analysis.
Active and inactive relationships: Power BI only allows one active relationship between two tables at a time. If FactHarvest had both a Planting Date and a Harvest Date needing to relate to DimDate, only one would stay active by default, and the other would need USERELATIONSHIP() in DAX to be used.

4. Filter Direction In Power BI

What It Means

Controls how filters travel between tables.

"Both" lets filters flow both ways;
"Single" (or "One direction") only lets filters flow from the one-side (usually a dimension) to the many-side (usually a fact). 99% of the time you should have single direction filters.

Affects which visuals and slicers interact.

Bidirectional can make slicers reduce available values across unrelated tables, but it can also create ambiguous filter paths and wrong results. It's generally considered a bad practice as bi-directional relationships can create ambiguity between tables which can lead DAX measures to return false results.

Used only for special cases like many-to-many or bridging.

Some scenarios (bridge tables, many-to-many) require BOTH to get the expected slicer behavior, but it increases complexity and risk.

Why It Matters

Affects model correctness and predictability. Too many bidirectional filters create ambiguous paths and unpredictable results as the engine decides how to apply filters. Too many bidirectional filters and PBI will decide how to apply these filters, this might lead to un-predictable results.

Impacts performance and maintenance. Using measures or virtual filters instead of physical bidirectional relationships can work but adds complexity and may hurt performance.
There are DAX workarounds when BOTH is undesirable. Techniques like ISEMPTY, TREATAS, or measure-level logic can simulate slicer-to-slicer behavior without enabling bidirectional everywhere.

Practical Guidance

Default to single direction for star schemas. Keep dimensions filtering facts; avoid BOTH unless needed.

When to use Both:

Row-level security requirements
Specific many-to-many scenarios with bridge tables
You have a clear business reason and understand the impact
Use BOTH for true many-to-many or bridge-table patterns. When a bridge or many-to-many scenario requires slicers to cascade across facts, BOTH is acceptable but document and test carefully.

Why to avoid Both (Bi-Directional):

Slower performance
Unexpected filtering behavior that confuses users
Higher risk of circular dependencies
Harder to debug when things go wrong #####The rule: Always start with Single. Only change to Both if you have a specific, documented reason.

Prefer explicit DAX if you need controlled behavior. Use measures that check activity (ISEMPTY) or TREATAS to make filter logic explicit and avoid ambiguous model paths.

6.Joins in Power Query

In Power Query, joins combine two tables based on matching values in one or more columns. When the compared row values between two tables are identical, they are considered a match. The behavior that follows depends on the join type.

Merge Queries in Power Query

The easiest way to join tables in Power Query is by using merge queries.
To start, go to the Home tab in the ribbon and navigate to the Combine section. There you will find the Merge Queries button. There are two options as below:

Option 1: Merge Queries performs a join on your current table and adds the result of this merge in the same query. This means you can easily see the impact of the merge in a single place.
Option 2: Merge Queries as New performs the same join on your table but puts the result of the merge in a separate query. The benefit of this approach is that your starting query remains the same. This means that you can reference that starting query for other purposes.

JOIN TYPES

a) Left Outer Join

The most common join. It returns all rows from the left table. Then, by matching one or more column values with rows from the left table with similar columns from rows in the right table, the join returns the matching values of the right table.
The Left Outer Join is often used when combining information from different tables that have a unique key to match. Power Query uses JoinKind.LeftOuter

b) Right Outer Join

The Right Outer Join returns all values from the Right Table while only returning the matching values from the Left Table. Its behavior is very similar to the Left Outer join, except that its base table is the Right table instead of the Left. It uses JoinKind.RightOuter

c) Full Outer Join

The Full Outer Join tries to match column values from the left table with the right table and if successful, puts them next to each other. The values of the left table that don’t exist in the right table get their own row. Any rows without a match in the right table return null values for these rows. Similarly, the values of the right table that don’t exist in the left table also get their own row. For these rows, the missing columns from the left table get null values. To perform a Full Outer Join, you can make use of the join type JoinKind.FullOuter

d) Left Anti Join

The Left Anti Join only returns rows from the Left Table. Based on the key columns, the join searches for which values in the left table do not exist in the right table. It then only returns the unique values from the left table. The Left Anti Join is a great way to perform checks on your queries. You can instruct Power Query a Left Anti Join by using JoinKind.LeftAnti

e) Right Anti Join

The Right Anti-Join is the twin sister of the Left Anti-Join. It returns the rows from the Right Table which are not present in the Left Table. To do that, it uses JoinKind.RightAnti

When to use Left Anti Join or Right Anti Join

The choice of which of the two joins to perform depends on where in your queries you want to see the result. If you quickly want to compare which values of another table are not present in the current table, the Right Anti Join lets you do it right away.
Yet if you want to see which values of the current table miss in another, the Left Anti Join lets you hit the ground running.

f) Inner Join

The Inner Join is a useful join that returns only those rows that have matching values in both the Left Table and the Right Table. This can be useful when creating tables for your data model.

6. Power Query Joins vs Power BI Relationships

Joins

In Power BI, you can use joins to physically combine tables based on common columns. This approach is ideal for smaller datasets or when specific aggregations on combined data are required.

Pros of Using Joins:

Simplicity: Joins are straightforward to implement, especially for users with a SQL background.
Aggregations: Enables direct aggregations on denormalized data for certain analysis needs.

Cons of Using Joins:

Redundancy: Joins can lead to data redundancy and increased memory usage.
Limited Flexibility: May not be suitable for scenarios requiring a more normalized data model.

Power BI Relationships:

Power BI’s relationships offer a more sophisticated approach, allowing you to establish logical links between tables without physically combining them. This is particularly beneficial for larger datasets or when maintaining a normalized data model is essential.

Pros of Using Relationships:

Data Integrity: Relationships help maintain data integrity by avoiding unnecessary duplication.
Flexibility: Provides a more flexible data model, allowing for better scalability and adaptability.
Performance: Generally, relationships perform better with larger datasets.

Cons of Using Relationships:

Complexity: Setting up relationships might be more complex, especially for those new to Power BI.
Learning Curve: Understanding the nuances of relationships requires a learning curve for some users.

Choosing the Right Approach:
Consider Data Volume: For large datasets, relationships are generally more efficient in terms of performance and storage.
Normalization Matters: If your goal is to maintain a normalized data model for better integrity and flexibility, relationships are the preferred choice.
User Experience: Think about how end users will interact with the data. Relationships provide a seamless experience for drilling down into related data.
Analysis Requirements: If your analysis involves aggregations and calculations that necessitate a denormalized dataset, joining tables might be more suitable.

Therefore, In the dynamic landscape of Power BI, choosing between joins and relationships is a pivotal decision that shapes the efficiency and effectiveness of your data modeling.

Whether you opt for the simplicity of joins or the sophistication of relationships depends on the specific needs of your project.

By understanding the strengths and weaknesses of each approach, you can elevate your Power BI skills and create compelling, insightful reports.

7. Recommended Power BI Model

For most Power BI analytical and business intelligence projects, a Star Schema is generally recommended. It provides a clear separation between fact tables, which contain measurable business events, and dimension tables, which contain descriptive information.

A typical Power BI model may include:

FactSales – contains sales transactions, quantities, revenue, costs and other measurable values.
DimCustomer – contains customer information such as customer name, location and customer category.
DimProduct – contains product information such as product name, category, brand and product type.
DimDate – contains dates, months, quarters and years.
DimLocation – contains geographical information such as city, region and country.

The fact table is connected to the dimension tables through relationships, typically using a one-to-many relationship from each dimension to the fact table.

The star schema is recommended because it provides a good balance between performance, simplicity, scalability and ease of use. It also makes it easier to create Power BI reports, write DAX measures and allow users to filter and analyse business data.

A flat table may be suitable for small and simple reports, while a snowflake schema may be appropriate when highly normalized data structures or complex hierarchies are required. However, for most Power BI reporting scenarios, the star schema provides a more practical and user-friendly model.

Building an Interactive Excel Dashboard for E-commerce Product Analysis: A Case Study of Jumia Products

Wendy Ochieng — Sat, 05 Sep 2026 11:13:15 +0000

Introduction & Objective

E-commerce platforms generate a constant stream of pricing, promotion, and customer-feedback data. But raw data on its own doesn't tell a seller anything useful. For this project, I
built an interactive Excel dashboard using a Jumia product dataset to answer a set of
practical business questions:

Are larger discounts associated with more customer reviews?
Do highly rated products attract stronger engagement?
Do price and rating move together?
Which products are performing best, and which need a different pricing or marketing strategy?

Importantly, this dataset doesn't include units sold or revenue, so review count was used
throughout as a proxy for customer engagement and not as a stand-in for sales. That distinction
mattered for how I framed every insight later in the project.

Dataset Description

The source file, Excel_jumia_dataset.csv, contained the following fields:

Field	Meaning	Expected type
Product	Product name	Text
Current price	Selling price (KSh)	Number/currency
Old price	Price before discount (KSh)	Number/currency
Discount	Advertised % discount	Percentage
Review	Number of customer reviews	Whole number
Ratingd (sic)	Average rating out of 5	Decimal

Before touching anything, I ran a data-quality audit and found several issues typical of
scraped e-commerce data: a ## Introduction & Objective

Are larger discounts associated with more customer reviews?
Do highly rated products attract stronger engagement?
Do price and rating move together?
Which products are performing best, and which need a different pricing or marketing strategy?

Dataset Description

The source file, Excel_jumia_dataset.csv, contained the following fields:

Field	Meaning	Expected type
Product	Product name	Text
Current price	Selling price (KSh)	Number/currency
Old price	Price before discount (KSh)	Number/currency
Discount	Advertised % discount	Percentage
Review	Number of customer reviews	Whole number
Ratingd (sic)	Average rating out of 5	Decimal

Before touching anything, I ran a data-quality audit and found several issues typical of
scraped e-commerce data: misspelled header (Ratingd), blank cells in the review and
rating columns, negative review counts, at least one price expressed as a range instead of a
single number, and duplicate rows.

Data Cleaning & Preparation

I kept Raw_Data completely untouched as a permanent reference and did all cleaning in a
duplicated query, using Power Query for the transformations (with a few native Excel
formulas where they were simpler).

Key cleaning decisions, all logged in a Data_Dictionary sheet with an Issue → Rows
Affected → Decision → Reason structure:

Header fix: Ratingd renamed to Rating.
Currency cleanup: Stripped "KSh" and thousands-separator commas from price fields, then converted to Decimal Number.
Price range: One row contained a range (e.g. "1620 - 1980") instead of a single price. Rather than deleting or guessing, I used the midpoint — (1620+1980)/2 = 1800 — and documented the original value and decision in the cleaning log.
Discount: Power Query correctly auto-typed this column as Percentage, so no extra /100 conversion was needed.
Negative reviews: Treated the negative sign as a scraping artifact and converted to absolute values.
Missing values: Left genuinely blank ratings/reviews as blank rather than assuming zero or imputing an average.
Duplicates: Removed only rows that matched exactly across all relevant fields, so that legitimate same-name listings with different prices or feedback weren't accidentally dropped.

After cleaning, I ran validation formulas directly on the Excel Table (tblProducts) to catch
anything that slipped through:

=IF(OR([@Rating]<0,[@Rating]>5),"Check rating","OK")
=IF(OR([@Discount]<0,[@Discount]>1),"Check discount","OK")
=IF([@[Current Price]]>[@[Old Price]],"Check prices","OK")

Excel Techniques, Formulas & Analysis

With clean data in place, I enriched the table with derived fields and category flags, all
using fixed, stated thresholds rather than subjective judgment calls, so any result could
be reproduced by rerunning the same formulas:

Discount amount

=[@[Old Price]]-[@[Current Price]]

Rating category (Poor <3, Average 3–4.5, Excellent >4.5)

=IF([@Rating]="","Missing",IF([@Rating]<3,"Poor",IF([@Rating]<=4.5,"Average","Excellent")))

Discount category (Low <20%, Medium 20–40%, High >40%)

=IF([@Discount]="","Missing",IF([@Discount]<20%,"Low Discount",IF([@Discount]<=40%,"Medium Discount","High Discount")))

Price category, based on quartiles rather than arbitrary cutoffs:

Price_Q1 = QUARTILE.INC(tblProducts[Current Price],1)
Price_Q3 = QUARTILE.INC(tblProducts[Current Price],3)
=IF([@[Current Price]]="","Missing",IF([@[Current Price]]<=Price_Q1,"Low Price",IF([@[Current Price]]<=Price_Q3,"Medium Price","High Price")))

Engagement threshold, defined as the 75th percentile of review counts:

=PERCENTILE.INC(tblProducts[Review],0.75)

From there, I built four flag columns to surface specific, actionable product segments:

High Discount + Poor Rating. Discounting isn't fixing an underlying quality problem
High Discount + Weak Engagement. the discount isn't converting into visibility
Strong Engagement + Average Rating. popular but not loved, room for improvement
Strong Engagement + Excellent Rating. the benchmark performers worth promoting further

Correlation analysis

I tested three relationships using CORREL() and matching scatter plots with trendlines:

Relationship	Correlation (r)	R²
Discount vs. Reviews	-0.14	0.02
Rating vs. Reviews	0.06	0.00
Price vs. Rating	0.11	0.01

All three came back weak. It means price,
discount, and rating don't strongly predict customer engagement in this dataset, at least not in a simple linear way.

Ranked tables

I used SORT, FILTER, and LARGE to build ranked views: top/bottom 5 by rating, top 10 by
discount, top 10 by reviews, top 10 by rating, and lists of flagged products pulled directly
from the flag columns using FILTER().

Dashboard Creation Process

The dashboard sits on a single sheet, laid out to be readable without scrolling:

Title + Slicers
KPI cards (Total Products, Avg Price, Avg Discount, Avg Rating, Total Reviews)
Top 10 tables (by Rating, Reviews, Discount)
Scatter charts (Discount vs Reviews, Rating vs Reviews, Price vs Rating)
Mix charts (Rating Mix, Discount Mix) + Key Insights

A few build details worth mentioning:

I used rounded rectangle shapes for the KPI cards rather than plain cells, aligned and distributed evenly via Excel's Align tools.
Each KPI number is linked live to its source cell (via the Formula Bar, e.g. =Analysis!B2), rather than typed in manually — so the dashboard updates automatically if the underlying data changes.
Three slicers (Rating Category, Discount Category, Price Category) are connected to every relevant PivotTable and PivotChart via Report Connections, and tested individually and in combination.
Formatting followed a consistent standard throughout: KSh on prices, % on discounts, one decimal on ratings, thousands separators on reviews, no 3-D charts, and horizontal bars where product names were too long for vertical labels.
A small note box on the dashboard documents the category thresholds, and how missing values were handled.

Key Insights & Business Recommendations

Discount vs. reviews (r = -0.14, R² = 0.02): No meaningful relationship. Sellers shouldn't rely on deeper discounts alone to drive engagement other levers like listing quality, placement, or timing likely matter more.
Rating vs. reviews (r = 0.06, R² = 0.00): Essentially no relationship. A high rating alone doesn't appear to boost visibility; category demand and listing age may play a bigger role.
Price vs. rating (r = 0.11, R² = 0.01): Very weak positive relationship. Price shouldn't be treated as a proxy for perceived quality in pricing decisions.
High discount, low rating products: A specific subset of products combine heavy discounting with poor ratings. These are stronger candidates for a quality or listing review than for further price cuts.
Strong engagement, excellent rating products: These are the benchmark performers worth using as templates (pricing, description style, imagery) for underperforming listings in the same category.

A caveat that applies to every finding above: correlation is not causation. None of these
relationships account for factors the dataset doesn't capture such as listing age, category,
visibility, or promotional placement so they should inform further investigation, not stand
alone as proof of what's driving performance.

Wrap-up

This project reinforced something that's easy to forget when a dashboard looks polished: weak
correlations are still a real, useful finding and not a failed analysis. The value here wasn't in
forcing a dramatic story out of the data, but in cleaning it rigorously, documenting every
decision, and being honest about what the numbers do and don't support.

The full workbook, dataset, and dashboard screenshots are available in my GitHub repo linked
below.

🔗 [https://github.com/ochiengwendy21-gif/jumia-product-performance-dashboard]

A beginner's understanding of the Git Workflow

Wendy Ochieng — Mon, 24 Aug 2026 15:08:10 +0000

Git

This is a version control system that tracks changes to files in a project. It's a software that recalls the exact files that were edited, when these changes were made and by whom(if it's a team project) and stores the previous versions of the files.
It's quite useful especially for large projects with multiple developers.
Git saves your files locally(in your machine) and you can store your code online or share it with others through github, gitlab or bitbucket.

Git Core Concepts

1. Repository(Repo)
This refers to a project and its entire history of changes. It can be local or remote.

2. Git commits
These are like snapshots of the entire projects that records all the tracked changes in your directory. Git can sometimes bundle all the changes to a project from one version of the repository to another, instead of just blindly copying the entire directory every time you commit-it maintains a history of which commits were made when.
A new commit might have another commit above it, like a parent commit, which references which commit it was based off of.

3. Git Branches
These are simply pointers to a specific commit. They are independent lines of development that allows you to work on features or fixes without affecting others.

In the image, we have a branch called newimage that now refers to commit C1.

To create a branch called newimage and immediately switch to it, we can use this code;

git checkout -b newimage

To prevent having many branches, it's better to divide your work.

4. Merge
Merging brings changes from one branch into another.

Basic Git Workflow

Common commands used to manage projects and upload your work to github.
1. Working Directory
This is the local folder where you create, open and edit files. This directory can be observed but changes are not automatically recorded.

2. Staging Area
This is where you select the changes you want to include in your next commit. You may choose specific files or lines of code you want to bundle together before saving.

3. Local Repository
It's the internal git database inside the project folder. It's where you commit the staged changes and git permanently saves it as a secure snapshot in your local history.

4. Remote Repository
This is where commits are pushed so others can access them, eg Github.

Note;

You push projects from your local machine to Github
You pull projects from Github to your local machine

Conclusion

The workflow looks like this in a nutshell;
┌──────────────────┐
│ Working Directory│
│ (your files) │
└─────────┬────────┘
│
│ git add
│ git add.
▼
┌──────────────────┐
│ Staging Area │
│ (index) │
└─────────┬────────┘
│
│ git commit -m "message"
▼
┌──────────────────┐
│ Local Repository │
│ (your computer) │
└─────────┬────────┘
│
│ git push origin main
▼
┌──────────────────┐
│Remote Repository │
│ GitHub / GitLab │
└─────────┬────────┘
▲
│
│ git pull origin main
│ git fetch
│
└───────────────────────

Edit files in the Working Directory.
Use git add to move changes to the Staging Area.
Use git commit to save a snapshot in the Local Repository.
Use git push to send commits to GitHub.
Use git pull to get other developers' latest changes.

DEV Community: Wendy Ochieng

Power BI: Data Modelling, Relationships & Joins

1. Data Modelling in Power BI

Data Models

1. FLAT TABLE

Definition

Structure

Advantages

Disadvantages

Appropriate situations

Power BI implications

2. STAR SCHEMA

Definition

Structure:

Advantages

Disadvantages

Appropriate situations

Power BI implications

3. SNOWFLAKE SCHEMA

Structure

Advantages

Disadvantages

Appropriate situations

Power BI implications

2. Fact Tables and Dimension Tables

Fact Tables: The “What Happened” Tables

Characteristics:

Grain or Granularity

Dimension Tables: The Who, What, When, Where Tables

Characteristics:

How to Tell Them Apart

A real scenario

The connection

Measures versus Descriptive Attributes

3. Relationships in Power BI

Types of Relationships

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

2. One-to-one (1:1)

3. Many-to-many (:)

Keys:

4. Filter Direction In Power BI

What It Means

Controls how filters travel between tables.

Affects which visuals and slicers interact.

Used only for special cases like many-to-many or bridging.

Why It Matters

Practical Guidance

When to use Both:

Why to avoid Both (Bi-Directional):

6.Joins in Power Query

Merge Queries in Power Query

JOIN TYPES

a) Left Outer Join

b) Right Outer Join

c) Full Outer Join

d) Left Anti Join

e) Right Anti Join

When to use Left Anti Join or Right Anti Join

f) Inner Join

6. Power Query Joins vs Power BI Relationships

Joins

Pros of Using Joins:

Cons of Using Joins:

Power BI Relationships:

Pros of Using Relationships:

Cons of Using Relationships:

Choosing the Right Approach:

7. Recommended Power BI Model

Building an Interactive Excel Dashboard for E-commerce Product Analysis: A Case Study of Jumia Products

Introduction & Objective

Dataset Description

Dataset Description

Data Cleaning & Preparation

Excel Techniques, Formulas & Analysis

Correlation analysis

Ranked tables

Dashboard Creation Process

Key Insights & Business Recommendations

Wrap-up

A beginner's understanding of the Git Workflow