DEV Community: Yop Gony Dak

How I Modelled My Power BI Data — Data Modelling, Relationships & Joins (Kenya Crops Dataset)

Yop Gony Dak — Mon, 14 Sep 2026 17:42:08 +0000

Introduction

Power BI is Microsoft's tool for turning raw data , an Excel file, a database, into interactive dashboards and reports, without needing to write much code. You connect a data source, clean it up, build relationships between tables, and then drag fields onto charts that anyone can click through and filter.

What makes it powerful, from what I've seen building this project, is that it isn't just a chart-maker. It handles genuinely large datasets without any struggles , it can refresh itself automatically once published to the cloud, and DAX (a formula language) ,lets you build calculations far beyond what a spreadsheet can do ,year-over-year comparisons, running totals, conditional logic, all recalculating instantly as someone filters the report. And because it's free to start with (Power BI Desktop costs nothing), the barrier to trying it is basically zero. For a dataset like mine , a few hundred farm records ,it's overkill in raw power, but that's exactly why it scales so well once a project grows past a class assignment.

Data Modeling

Before I built a single chart, I had to decide how my tables should be organized . That decision ,data modelling is easy to skip past, but it quietly controls four things later:

How fast my reports load — a messy model makes Power BI do more work for every click.
How easy my formulas are to write — a clean model means shorter, simpler DAX.
How well the model grows — can I add a new county or crop next season without breaking everything?
How easy it is for someone else to follow — a teammate (or future me) should be able to open my file and understand it in minutes.

So before touching visuals, I worked through the three common ways to organize tables in Power BI: a flat table, a star schema, and a snowflake schema — and looked at which one actually fits my project.

1.The Flat Table

A flat table is the simplest possible design: everything lives in one wide table. Every fact (like revenue or yield) sits in the same row as every descriptive detail (like the farmer's name, the county, the crop type, the season).

This is exactly how I built my Kenya Crops Power BI file , one single table called Kenya Crops Data set , with columns for the farmer, county, crop type, season, soil type, dates, yield, revenue, cost, and profit, all in the same table.

What I like about it

It's very easy to follow ,what I see is what I get.
No relationships to set up. Nothing to link.
It was the fastest way to get my data in and start building measures and visuals early on.

What bothers me about it

There's a lot of repetition. If "Kericho" is the county for 500 of my records, the word "Kericho" is physically stored 500 times instead of once.
As I add more rows, the file gets heavier and slower to work with.
If I ever needed to correct a county's spelling, I'd risk missing some of the rows it appears in.
I can't easily reuse my "County" or "Crop Type" list in another table if I add one later.

Why I still went with it for now For a project this size ,a single class dataset , a flat table was genuinely a reasonable starting point, which is why I built it this way first. I don't think it would hold up well if I connected more data sources or scaled this into a real reporting tool, but for getting the measures and visuals working, it did the job.

On performance: I noticed flat tables are simple to build but get slower to use as the data grows, because DAX has fewer shortcuts to lean on when everything sits in one giant table.

2. The Star Schema (what I'd redesign it into)

A star schema splits the same information into two kinds of tables:

One central table of events (a fact table)
-in my case, one row per farm's crop record: yield, revenue, cost, profit.
Several smaller tables around it that describe things about those events (dimension tables) ; one table for farmers, one for crop types, one for counties, one for dates.

Each dimension table connects straight to the fact table, like the points of a star. (See Diagram 2 below for how I'd redesign my own data this way.)

What I like about this design

No repeated text ;"Kericho" would be stored once in DimCounty, and every fact row just points to it.

It's fast. Power BI and DAX are built to work brilliantly with this shape.
Filtering becomes simple ,dragging "County" onto a chart automatically filters my fact table correctly.
Anyone looking at the model diagram could immediately understand what connects to what.

The trade-off

It's more setup work upfront ;I'd have to split my one flat table into several related tables, which takes planning.
A little duplication within a dimension table is normal and fine (that's the trade-off for speed).

Why I'd choose this if I rebuilt the project If I were taking this dataset further , this is the design I'd commit to. It's the standard choice for a proper Power BI report.

3. The Snowflake Schema

A snowflake schema takes a star schema one step further: one or more dimension tables gets split again into smaller, more detailed tables.

For my data, I could split my DimCounty table further ;pulling "Region" out into its own DimRegion table connected to DimCounty. (See Diagram 3 below.)

*What it would give me
*
Even less repeated data ; a region name stored once, not once per county.
It would make sense if "Region" was a big, shared list reused across several fact tables.

Why I'm not going this route

Power BI has to "hop" through an extra table to answer some questions, which adds a bit of complexity and can slow things down slightly.
It's more tables for me to manage and a busier model diagram, for a benefit I don't really need on a project this size.

My take: for my Kenya Crops project specifically, I decided snowflaking isn't worth it ; my dimensions (farmer, crop, county, date) aren't big or reused enough to justify the extra hops.

Quick comparison , how I'd weigh my three options

Flat Table (what I have)|Star Schema (what I'd move to) |Snowflake Schema
Setup effort Lowest Medium Highest

Report speed Slows down as I add data Fast Fast, with tiny extra hops

Data repetition High Low Lowest

Easiest for me to read Yes, for now Yes, overall Gets busy fast
Best fit for my project Early exploration If I scale this up Not needed here

4. Fact Tables vs Dimension Tables, in my own data

Once I split away from my flat table, everything in my model would fall into two roles:

A fact table stores the numbers that happened ;
the measurable events. In my dataset that's Yield (Kg), Revenue (KES), Cost of Production (KES), and Profit (KES). Common naming elsewhere: FactSales, FactOrders, FactTransactions ;mine would be FactCropProduction.

A dimension table stores the descriptions ;who, what, where, when ;the things I'd use to slice, filter, or label a report. Mine would be DimFarmer, DimCropType, DimCounty, DimDate.

The way I remember it: numbers I add up belong in the fact table; words I filter by belong in dimension tables.

One more idea I had to get straight for myself: grain. The grain of my fact table is the answer to "what does one row actually represent?" For my data, that's one farmer's one crop record for one season ,not one farmer, and not one county on its own, but that specific combination. Every measure I write assumes that grain, so I made sure I understood it before writing any DAX.

The practical picture of my fact table connected to its dimension tables is the same star layout as Diagram 2 below.

5. Relationships — how I'd connect my tables

A relationship is a link between two tables that tells Power BI "these two are connected, and here's how." I'd need relationships the moment I split my flat table into a star schema, so Power BI knows how to bring everything back together for a report.

There are three kinds, based on cardinality — how many matching rows sit on each side. (See Diagram 4 below for how I'd map each type onto my own tables.)

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

the one I'd use almost everywhere. One row in a dimension table matches many rows in my fact table. In my case: one crop type ("Maize") would appear on many of my farm records.

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

rare, and I don't actually need it in this project, but I'd use it only if I ever split off a DimFarmerContact table from DimFarmer, where each farmer has exactly one contact record.

Many-to-Many (:)

I'd avoid this unless I truly needed it. An example from my own domain: if a farm could hold several certifications, and a certification could apply to several farms, that relationship would need to be many-to-many. I don't have this in my current data, so I wouldn't add it just to have it.

Why Primary Keys, Foreign Keys, and uniqueness mattered to me here

A Primary Key (PK) -is the column that uniquely identifies each row in a dimension table — no duplicates.
In my DimCounty, CountyID would be unique: each county appears exactly once.

** A foreign key** is the matching column in my fact table that points back to that primary key — and it's expected to repeat. CountyID would show up once for every single farm record in that county.
This is exactly why, in my data, CountyID would be unique in the dimension table but appear many times as a foreign key in the fact table — that repetition is what makes the "many" side of my one-to-many relationship work.

Referential integrity means every foreign key in my fact table actually has a matching row in the dimension table — I wouldn't want a farm record pointing at a county that doesn't exist anywhere in DimCounty.
Active vs inactive relationships: Power BI only lets one relationship between two tables be "active" at a time. If I needed a second connection — say, filtering by both Planting Date and Harvest Date against the same date table — the second one would be created inactive, and I'd only switch it on inside a specific formula when I needed it.

6. Filter Direction — the part I had to slow down and think about

Once my tables are connected, Power BI needs to know which way a filter is allowed to travel through that connection. (See Diagram 5 below.)

Single-direction filtering (the default, and what I'd keep almost everywhere): picking a value in a dimension table filters my fact table, but not the other way round. If I picked "Maize" in a DimCropType slicer, it would filter FactCropProduction down to maize rows only — predictable, and exactly what I'd want.

Bidirectional (both) filtering: the filter can travel both ways. I'd only switch this on deliberately, and only if I had a genuine reason.

Why I'd be careful with it

It can create ambiguous filter paths
if two routes exist between two tables, Power BI might not know which one to use, and can refuse to calculate correctly.

It adds hidden complexity
— a report could start behaving oddly because a filter is quietly touching a table I didn't expect it to affect.

It makes troubleshooting harder.
My plan is to leave relationships single-direction unless I hit a specific case that needs otherwise.

*7. Joins — what I'd use in Power Query to combine tables
*
Everything above happens inside the data model. But there's an earlier stage — Power Query — where I can also combine tables using a Merge. This is Power BI's version of a "join."

To explain this to myself, I used two simple tables from my own domain: a Farmers table (farmer name, county, crop) and a CountyInfo table (county, region, soil type). (See Diagram 6 below for all six join types laid out.)

Inner Join — keeps only rows that exist in both my tables. If a farmer's county isn't listed in CountyInfo, that farmer would be dropped from the result.

Left Outer Join — keeps every row from my first (left) table, and adds matching details from the second table where available. Unmatched rows just get blanks. This is the one I'd reach for most, since I never lose data from my main table.

Right Outer Join — the mirror image: keeps every row from the second (right) table, adding details from the first where they match.

*Full Outer Join *— keeps every row from both tables, matched where possible, kept even where there's no match on either side.

Left Anti Join — keeps only the rows from my first table with no match at all in the second. I could use this to check: "which of my farmers have a county that isn't in my reference list?"

*Right Anti Join *— the mirror image: "which counties in my reference list have no farmer records at all?"

A practical example from my own data: if I merged Farmers with CountyInfo using a Left Outer Join on County, I'd get every farmer, now with Region and Soil Type added as new columns — and any farmer whose county wasn't in CountyInfo would just show blanks for those two columns instead of disappearing.

***8. Power Query Joins vs Power BI Relationships* — clearing this up for myself
**
This was the part I had to slow down on the most, so I'm explaining it the way I'd want it explained to me.

A Power Query merge physically combines data. If I merge Farmers with CountyInfo, Power Query actually copies the matching columns (Region, Soil Type) into my Farmers table. I end up with one new, wider table. This happens before the data even reaches my data model — it's part of loading and cleaning.

A Power BI relationship doesn't combine anything. It just tells my model "these two tables are related." The tables stay separate; Power BI knows how to look across them when a report needs to. No columns get copied anywhere.

**Power Query Merge |Power BI Relationship**

Happens at, Data loading / cleaning stage Inside the data model, after loading

Result One new, combined table Two tables stay separate, just linked

Effect on my data size, Makes tables wider No change to table size

I'd use it for ,Pulling in one or two lookup columns I need permanently Connecting my fact and dimension tables for reporting

*When I'd choose a merge instead of a relationship:
*
mainly when I need one column from another table baked directly into my main table — for example, pulling a single "Region" column in so it shows up in one specific visual, without building a whole separate dimension table just for that.

*Why I wouldn't just merge everything:
*
if I merged all my tables into one giant table "just in case," I'd really just be rebuilding my flat table — and I'd lose everything a star schema gives me: the repeated data comes back, the file gets heavier, and I couldn't reuse a clean DimCounty table if I added a second fact table later.

*Why I'd keep my fact and dimension tables separate: *

each piece of information gets stored once, relationships handle the joining automatically and efficiently at report time, and my model stays flexible — I could plug in a new fact table (say, FactFertiliserUsage) later and reuse the same DimCounty and DimFarmer tables without touching them.

9. My recommendation

If I were rebuilding this for a real, ongoing project rather than a one-off Task, I'd move to a star schema, with:

Relationships:
one-to-many, from each dimension table to my fact table (DimFarmer → FactCropProduction, DimCropType → FactCropProduction, and so on).

Filter direction:

single-direction by default, flowing from my dimension tables toward the fact table. I'd only turn on bidirectional filtering for a specific report that genuinely needed it, and only after checking it doesn't create conflicts.

**Power Query:

**I'd use it to clean and shape each table individually (fix data types, trim text, handle blanks) — not to merge everything into one big table.

Here's my reasoning, factor by factor:

Query and report performance — a star schema is what Power BI's engine is built to optimise for, so my reports would stay fast even as I add more data.
DAX simplicity — measures like SUM(Revenue) filtered by county or crop would "just work" through the relationships, instead of me writing complicated formulas to compensate for a messy structure.
Model readability — anyone opening my model view could see the star shape and understand what connects to what, which my current flat table doesn't give them.
Scalability — adding a new dimension later (say, DimWeather) or a new fact table wouldn't require me to rebuild anything that already exists.
Data redundancy — county names, crop types, and farmer details would be stored once each, not once per transaction row like they are now.
Maintainability — fixing a typo in a county name would mean editing one row in DimCounty, not hunting through thousands of fact rows.
Ease of building reports — dragging fields from clearly-named dimension tables onto a visual is far more intuitive than digging through my one giant flat table.
Filter propagation — single-direction filters flowing from my dimensions into the fact table would behave predictably, which is what I'd want for most of my reports.
Model complexity — a star schema keeps my complexity manageable; I'd only introduce snowflaking or heavier merging if I hit a specific reason that actually needed it.

My honest conclusion:

keeping my current flat table was a fine way to get this task moving quickly, but it's not the design I'd defend for anything beyond that. Given what I now understand about performance, maintainability, and how DAX actually behaves, a star schema is the model I'd choose if I took this project further.

"Getting Started with Excel for Data Analytics: From Basics to Data Cleaning."

Yop Gony Dak — Sat, 29 Aug 2026 23:28:22 +0000

Excel for Data Analytics

Excel isn't just for typing lists or making simple budgets ,as i once thought. Data analytics means looking at data to understand it, find patterns, and answer questions ,like ,"which department has the highest average salary?". Excel is one of the tools people use to do that.
From Basics to Data Cleaning ,this tells you the journey: you can't jump straight to analyzing data. You start with the basics ,how Excel works, how to enter and format data, and only once you understand those, you move to data cleaning .fixing a dataset's mistakes, missing pieces, and inconsistencies so it's actually trustworthy to analyze.

I will explain the basics from how i understood them, then show, step by step, how I used them to clean a real, messy dataset.

To practice, I used a sample HR dataset with 869 employee records ;names, departments, salaries, hire dates, and so on. It was deliberately messy: missing cells, spelling mistakes, inconsistent formatting, duplicate records. That messiness is exactly what made the concepts click.

Part 1;
The Excel interface ,what am I even looking at?

When you open Excel, you see a grid with some tools around it. In simple terms:

Workbook ; this is just the whole file you're working in.

Worksheet ; a workbook can have several of these; they're the tabs at the bottom ,Sheet1, Sheet2 e t c.

Ribbon ; the toolbar across the top. It's organized into tabs such as;

home tab
insert tab
data tab

each tab holds a different set of tools.

Formula Bar ;

a bar above the grid that shows exactly what's really inside the cell you clicked on , including the formula, not just the number it displays.

2.Name Box ;

a small box that just tells you which cell you currently have selected,e.g like A1.

3.Rows, columns, cells, and ranges
;the grid itself

A row runs sideways from left to right horizontally and has a number e. g Row 1, Row 2 .
A column runs up and down vertically and has a letter
e .g Column A, Column B

A cell is a single box, where one row and one column meet.

B2 means column B, row 2.

A range is just a group of cells together,
like A1:C3.

Data types ;

This was the concept that surprised me the most. I used to think a cell either "has something in it" or it's empty. Actually, Excel pays close attention to what kind of thing you typed:

Text — words, like "Nairobi"

Numbers — like 400 or 89.5

Dates — like 01/06/2025

Formulas — anything starting with =, like =A1+B1

Here's the simple but useful part: Excel actually shows you the type visually. Numbers and dates line up on the right side of a cell by default. Text lines up on the left. Once I noticed this, it became a quick way to catch mistakes ,if something that's supposed to be a date is sitting on the left instead of the right, it's not really being treated as a date at all.

Entering and editing data

Simple mechanics: click a cell, type a value, then press Enter (moves down) or Tab (moves right). To fix something already there, double-click the cell, or select it and press F2.

Moving around quickly

Arrow keys move one cell at a time.
Ctrl + Arrow key jumps straight to the end of your data.
Ctrl + S saves the file.

Formatting — making data easy to read

Formatting doesn't change the value in a cell, only how it looks:

Text formatting (Home > Font) — bold, italic, underline, font, size, colour.

Alignment (Home > Alignment) — left/centre/right, top/middle/bottom, Wrap Text (so long text shows on multiple lines instead of spilling over), Merge & Center.

Number formatting (Home > Number) — shows the same value as a plain number, currency, percentage, or date, without changing what's actually stored.

Borders & fill colour — useful mostly for making header rows stand out.
Saving and opening a file

File > Save As, pick a folder, give it a name, make sure the file type is Excel Workbook (.xlsx), and click Save. Or just press Ctrl + S. To open a file again later: File > Open, then browse to it.

Sorting — putting data in order

Sorting rearranges your rows into a specific order. Text sorts A to Z (or Z to A), numbers sort smallest to largest (or the reverse), and dates sort oldest to newest (or the reverse). Steps: select your data, go to Home > Sort & Filter (or Data > Sort), and pick the order you want.

Filtering — temporarily hiding what you don't need

Filtering is different from sorting — instead of reordering the rows, it hides any row that doesn't match a rule you set, without deleting anything. Steps: click inside your data, turn on Filter (Home > Sort & Filter > Filter, or Data > Filter), then use the small dropdown arrows that appear on each column header to choose what to show.

Freeze Panes — keeping your headers visible

Once a dataset gets long, scrolling down means you lose sight of the column headers. Freeze Panes fixes that: click the row just below your headers (usually Row 2), then go to View > Freeze Panes > Freeze Panes. Now the header row stays on screen no matter how far down you scroll.

Data Validation — controlling what people can type

Data Validation limits what's allowed in a cell, so people can't type just anything. The most common use is a dropdown list: select the cells, go to Data > Data Validation, set Allow to List, and type your allowed values (e.g. Apples, Oranges, Bananas) under Source. Now the cell only accepts one of those options.

Conditional Formatting — letting Excel highlight problems for you

Conditional Formatting automatically colours or highlights cells that meet a rule you set — for example, values below a certain number, or specific text. It's under Home > Conditional Formatting. This turns out to be extremely useful before you start cleaning anything, because it shows you where the problems are without you having to hunt for them manually.

Removing Duplicates — a built-in cleanup tool

Remove Duplicates (under the Data tab) is not a formula — it's a built-in feature. Select your data, choose which columns to check, click OK, and Excel deletes the repeated rows and tells you exactly how many it removed.

Text functions — small tools for fixing text

These are the functions I found most directly useful for cleaning messy text:

Function In plain language
UPPER() Makes text ALL CAPS
LOWER() Makes text all lowercase
PROPER() Capitalizes the First Letter Of Each Word
TRIM() Removes extra spaces before, after, or between words
LEFT() Grabs a number of characters from the start of the text
RIGHT() Grabs a number of characters from the end of the text
MID() Grabs characters from somewhere in the middle
LEN() Tells you how many characters are in the text
FIND() Tells you the position of a specific character or word inside the text
SUBSTITUTE() Swaps one specific piece of text for another
Basic formulas and calculation functions

A formula always starts with =. It can combine plain numbers, cell references (like A1), math operators (+ - * / and ^ for powers), and functions. Excel does mathematics in a specific order — multiplication and division happen before addition and subtraction , so =5+2*3 gives 11, not 21.

The core calculation functions from this week were : SUM() adds numbers up, AVERAGE() finds the mean, MIN() and MAX() find the smallest and largest values, and COUNT() counts how many numeric values are in a range. AutoSum ,the ∑ button on the Home tab, is a shortcut that inserts SUM() for you automatically.

Copying formulas, and the difference between reference types

Once a formula works in one cell, you can drag its little bottom-right corner (called the fill handle) down or across to copy it instantly to other cells. But there's a catch: a normal cell reference like A1 is relative — it shifts automatically as you copy the formula. Sometimes you don't want that. An absolute reference, written as $A$1, stays locked on that exact cell no matter where you copy the formula to. This matters most when one part of your formula (like a fixed rate, or a total) needs to stay the same in every copy.

Common formula errors — what they actually mean
Error What it means, simply

DIV/0! You're trying to divide by zero

REF! The formula is pointing at a cell that no longer exists
VALUE! You're using the wrong type of value — like text where a number was expected

NAME?

A function name is spelled wrong

Part 2: Using These Concepts on a Real, Messy Dataset

With all of that as background, here's how I actually applied it.

Scanning and flagging the raw data

Employee ID wasn't consistent ; some rows had EMP-10540, others just 10826 with no prefix. Out of 862 non-blank IDs, only 4 had the full EMP-XXXXX format; 858 were missing the prefix.

Department had the same department spelled many different ways: HR, H.R, Hr, Human Resource, Human Resources, Humman Res., Humna Resources. In total, 22 unique department labels represented only 6 real departments.
Gender had mixed case and a typo: Male, MALE, male, Femle, F, M.
Office Location had a typo — Londn ,instead of London.
Age had at least one row with the text "thirty" where a number should be. Sorting the column made it obvious, since Excel sorts numbers and text separately ,the text entry got pushed to its own end of the list.
One date, 2020/13/05, was clearly broken ,there's no 13th month. This is where the left/right alignment trick paid off: real dates in that column were right-aligned, but this one sat left-aligned, meaning Excel was storing it as plain text, not an actual date.

Removing duplicate records

I ran Remove Duplicates on the Employee ID column. Excel reported 10 duplicate IDs ,records that would have quietly inflated any headcount I calculated later.

Cleaning text with the right function for each problem

Once I knew exactly what was wrong, I matched each problem to a specific text function, since fixing 869 rows by hand isn't realistic

here's what I did and why:

PROPER() fixed inconsistent capitalization in one step — MALE became Male.

SUBSTITUTE() swapped a specific typo for the correct spelling — "Markting" became "Marketing". It's basically a formula version of Find & Replace, and it's useful because it leaves the original column untouched while producing a corrected one next to it.

LEN() helped me find the missing-prefix problem before fixing it: a correct ID like EMP-10540 has 9 characters, while the broken ones like 10826 only have 5. Checking the length instantly told me which group a row belonged to.

Joining text with & rebuilt the correct ID format once I knew which ones needed it: ="EMP-"&"10826" gives EMP-10826. This isn't one of the named functions, just the basic operator idea from Part 1, applied to text.

FIND() told me exactly where the dash sits inside a full ID like EMP-10540 — in this case, position 4.
RIGHT(), combined with LEN() and FIND(), let me pull out everything after that dash, giving me the plain numeric ID on its own.each function is simple by itself, but combining a few of them solves a much more specific problem.

I also ran TRIM() across the text columns as a general check. This particular file didn't actually have extra spaces, but that's exactly the kind of invisible issue TRIM() catches, and it costs nothing to run even when it finds nothing — so it's part of my routine now regardless.

Along the way, I ran into two of the errors from the table above for real: an early version of my extraction formula returned #VALUE! because it pointed at a blank cell instead of a text one, and later, dragging a formula down without locking the right reference caused a #REF! in a few rows further down. Both were fixed once I went back to the relative-vs-absolute reference idea and locked the reference that needed to stay fixed.

Standardizing categories

For the 22 department spellings, SUBSTITUTE() works well for one or two known typos, but with 22 variants mapping to 6 real departments, it was far more practical to use Find & Replace (Ctrl +H) directly, correction by correction. In hindsight, this is also the perfect argument for Data Validation: if the Department column had been a dropdown list from the start, none of these 22 spelling variants could have been typed in.

Summarizing with basic functions

Once the department names were standardized, I used Filter to isolate each department, then ran AVERAGE() and COUNT() on the visible salary values to get a headcount and average salary per department.

This made the value of cleaning very concrete: before standardizing the spellings, filtering for "HR" alone would have missed every row recorded as "Hr", "H.R", or "Human Resources" — quietly undercounting the department. Only after standardizing did the numbers become trustworthy.

What This Taught Me, In Simple Terms
Messy data is normal, not rare. Almost every column in this dataset had some kind of issue.

Cleaning is about making things consistent, not "correct" in some abstract sense. I wasn't trying to guess anyone's "true" department , I was making sure every entry followed the same format.
Small functions combine into real solutions. FIND(), LEN(), and RIGHT() are almost too simple to seem useful on their own , together, they solved a real problem.
How Excel displays data is a clue in itself. Left-vs-right alignment telling me a date wasn't really a date, or sorting pushing a stray value to one end ,these only stood out because I understood how Excel treats data types.

Flag first, then fix. Conditional formatting turned a blind search into a guided one.

Conclusion

I went into this course expecting "data analytics in Excel" to mean charts and dashboards straight away. What Week 1 actually showed me is that none of that means anything if the data underneath isn't clean. My dataset still needs more work , the Marital Status and Education Level columns need the same standardization, and I want to add proper Data Validation dropdowns so these problems can't come back. But the sequence I now understand ,learn the basics, flag problems, diagnose them, clean with the right tool, standardize, then summarize — is one I feel ready to use on the next messy dataset I come across.

My first GitHub Project; from a local folder to GitHub using Git and SSH

Yop Gony Dak — Sun, 23 Aug 2026 00:57:59 +0000

when i first heard about Git and GitHub ,I was really confused by the two terms .more words and concepts such as repository ,commit ,SSH key ,push ,pull, were even more confusing .Knowing the definition alone did not make me understand better .instead of just going through the document provided by my institution i decided to do it practically so that i could learn more on these concepts .this article will cover how i carried out the practical exercise on my computer ,the process ,steps and the commands i used ,and my personal understanding from each step.

Step 1: Setting Up Git Locally

Before anything else, ensure Git is installed on your computer. You can check by running:

bash
git --version

If it’s not installed, download it from a secure link.

Next, configure your identity so Git knows who you are:

bash
git config --global user.name "Your Name"
git config --global user .email "your.email@example.com"

This information will appear in your commit history.

Step 2: Initialize Your Local Project

Navigate to your project folder and initialize Git:

bash
cd my-first-project
git init

This command creates a hidden .git directory that tracks changes in your project.

Add your files to the staging area:

bash
git add .

Then commit them with a message:

bash
git commit -m "Initial commit"

Now your project is officially version-controlled!

Step 3: Connect to GitHub Using SSH

SSH (Secure Shell) allows you to connect to GitHub securely without typing your password every time.

Generate an SSH key:

bash
ssh-keygen -t ed25519 -C "your.email@example.com"

Copy your public key:

bash
cat ~/.ssh/id_ed25519.pub

Then go to GitHub → Settings → SSH and GPG keys → New SSH key, paste it, and save.

Test the connection:

bash
ssh-T git@github.com

If you see a welcome message, you’re good to go!

4: Create a Remote Repository

On GitHub, click New Repository, give it a name (e.g., my-first-project), and choose whether it’s public or private.

Copy the SSH URL—it should look like this:

git@github.com:username/my-first-project.git

Link your local folder to this remote repository:

bash
git remote add origin git@github.com:username/my-first-project.git

5: Push Your Code to GitHub

Finally, send your local commits to GitHub:

bash
git push -u origin main

After this, your project will appear online. You can now collaborate, track changes, and share your work with others.

my Key Takeaways

Git tracks your project history locally.
GitHub hosts your code online for collaboration.
SSH provides secure, password-free access.
The basic workflow is: init → add → commit → push.

my Final Thoughts

Setting up my first GitHub project is a milestone in my developer journey. Once i,ve done it, i realize how powerful version control can be—not just for saving my work, but for learning, collaborating, and growing.