DEV Community: Neema Kirui

Python Loops: Teaching Your Program to Repeat Itself (Without Repeating Yourself)

Neema Kirui — Thu, 17 Sep 2026 20:10:50 +0000

Conditionals taught your program to choose between paths. Loops teach it to do something more than once without you writing the same line over and over. This post covers for loops, while loops, break and continue, and enumerate(), the small tool that makes numbered lists genuinely easy.

1. Looping Over Things You Already Have

A for loop runs its block once for every item in something, a list, a range of numbers, even the letters in a word.

fruits = ["mango", "banana", "pineapple"]

for fruit in fruits:
    print(f"I like {fruit}")

That prints one line per item in fruits automatically, instead of you writing print() three separate times by hand. When you just need to repeat something a set number of times rather than loop over an existing list, range() generates the numbers for you:

for i in range(5):
    print(f"Count: {i}")

GOOD TO KNOW
range(5) counts 0, 1, 2, 3, 4, five numbers total, not 1 through 5. Python counts from zero almost everywhere, and this is one of the first places that catches people off guard.

2. When You Don't Know How Many Times, Use while

A for loop is for when you know how many times you're repeating something. A while loop is for when you don't, you just want to keep going until some condition stops being true.

balance = 100

while balance > 0:
    balance -= 20
    print(f"Balance is now {balance}")

There's no fixed repeat count written anywhere in that loop. It just keeps subtracting until balance > 0 becomes false, then stops on its own.

GOLDEN RULE
Something inside a while loop has to actually move it toward becoming false. Forget to update the condition, and you've written an infinite loop, one of the most common ways a beginner's first program freezes solid. If your program hangs and never finishes, this is the first thing to check.

Sometimes you don't know in advance how many times something should repeat at all, you just want "keep going until the user says stop." That's while True, paired with break:

while True:
    answer = input("Type 'quit' to stop: ")
    if answer.lower() == "quit":
        break
    print(f"You typed: {answer}")

while True never becomes false by itself, so break is the only way out. That's not a hack, it's a completely normal pattern for menus and games, anywhere "keep going until told otherwise" is exactly the behaviour you want.

3. Cutting a Loop Short: break and continue

break exits a loop immediately, skipping everything left inside it. continue skips just the current pass and moves straight to the next one, without leaving the loop entirely.

for number in range(1, 11):
    if number == 5:
        break
    print(number)
# prints 1, 2, 3, 4, then stops entirely

for number in range(1, 11):
    if number % 2 == 0:
        continue
    print(number)
# prints only the odd numbers: 1, 3, 5, 7, 9

COMMON BUG
break says "stop everything now." continue says "skip this one, but keep going." Mixing the two up is an easy mistake, and it usually shows up as a loop that either stops too early or never skips what you expected it to.

4. Numbering a List Without Doing the Counting Yourself

Displaying a numbered list is such a common need that Python has a built-in tool for it. Without enumerate(), you'd have to track the count yourself:

items = ["Bread", "Milk", "Eggs"]

count = 1
for item in items:
    print(f"{count}. {item}")
    count += 1

That works, but it's more bookkeeping than the task deserves. enumerate() hands you the position and the value together, in one clean loop:

items = ["Bread", "Milk", "Eggs"]

for index, item in enumerate(items, start=1):
    print(f"{index}. {item}")

Both print the same thing:

1. Bread
2. Milk
3. Eggs

WHY IT MATTERS
The start=1 argument tells enumerate() to begin counting from 1 instead of its default of 0. Leave it out, and your nicely numbered menu starts at "0. Bread", which is technically correct and completely unnatural to read. Any time you're building a menu a person will actually look at, start=1 is what you want.

5. A Small Menu Program That Uses All Four

Here's everything from this post, while, for, enumerate(), and break, working together in one small menu-driven program.

snacks = ["Chips", "Chocolate", "Juice", "Crisps"]

while True:
    print("\n--- Snack Menu ---")
    for index, snack in enumerate(snacks, start=1):
        print(f"{index}. {snack}")
    print("0. Exit")

    choice = input("Enter choice: ")

    if choice == "0":
        print("Goodbye!")
        break

    if not choice.isdigit() or not (1 <= int(choice) <= len(snacks)):
        print("Invalid choice, try again.")
        continue

    print(f"You picked: {snacks[int(choice) - 1]}")

while True keeps the menu showing up until the user chooses to leave. The for loop with enumerate() numbers the snacks freshly every time the menu prints. continue sends an invalid entry straight back to the top of the menu instead of crashing or continuing with a bad value. And break is the one clean way out, once the user actually asks to exit.

The Loop You'll End Up Using Without Even Noticing

Almost every program you've ever used has a loop in it somewhere, a feed that keeps scrolling, a game that keeps asking for input, a form that keeps validating until you get a field right. Loops are what let a program handle "I don't know how many times this needs to happen" gracefully, instead of you trying to guess and hardcode a number.

This is also usually the point where beginners hit their first real debugging wall, not because the syntax is hard, but because tracing a loop in your head takes practice. If a loop doesn't behave the way you expected, the fix is almost always the same: drop a print() inside it and watch the values change on each pass. You'll see exactly where it went off script, and that single habit will save you more time than anything else in this post.

Python Operators and Conditionals: Teaching Your Program to Make Decisions!!

Neema Kirui — Thu, 17 Sep 2026 19:34:42 +0000

If you've been following along, you already know how to store a value and get information in and out of a program. That's still a program that just does one fixed thing, though. Operators are how Python compares and combines values, and conditionals are how it uses those comparisons to actually choose what to do next. Put together, they're the first real building block of a program that behaves differently depending on the situation.

1. Arithmetic Operators: The Math You Already Know, Plus Two You Might Not

Most of these look exactly like the math you already know:

Operator	Meaning	Example	Result
`+`	Add	`5 + 2`	`7`
`-`	Subtract	`5 - 2`	`3`
`*`	Multiply	`5 * 2`	`10`
`/`	Divide	`5 / 2`	`2.5`
`//`	Floor division	`5 // 2`	`2`
`%`	Modulus (remainder)	`5 % 2`	`1`
`**`	Exponent (power)	`5 ** 2`	`25`

// and % are the two that usually feel new. Floor division divides and throws away anything after the decimal point, and modulus gives you what's left over after that division. They show up together constantly, splitting something evenly and figuring out the remainder:

total_items = 17
per_box = 5

boxes = total_items // per_box   # 3 full boxes
leftover = total_items % per_box  # 2 items left over

print(f"{boxes} full boxes, {leftover} items left over")

GOOD TO KNOW
% is also the easiest way to check if a number is even or odd. number % 2 == 0 is true for even numbers, since dividing an even number by 2 always leaves a remainder of zero.

2. Comparison Operators: Questions With Only Two Possible Answers

Every comparison in Python returns exactly one of two things: True or False. Nothing in between, nothing partial.

age = 20
score = 75

print(age == 20)    # True  (equal to?)
print(age == 25)    # False
print(age != 18)     # True  (not equal to?)
print(score > 70)   # True
print(score < 50)   # False
print(score >= 75)  # True
print(score <= 74)  # False

Each line is just a yes-or-no question that Python answers instantly. age == 20 is asking "is age equal to 20?", not assigning anything, which is exactly where the most common beginner slip happens.

COMMON BUG
= assigns a value. == asks a question. if score = 75 is not the same thing as if score == 75, and mixing them up inside a condition is one of the most common early mistakes there is. Python usually stops you with a clear error if you try it, so treat that error as a hint, not a disaster.

Strings can be compared too, and it's worth knowing this catches people off guard the first time: comparisons are case-sensitive.

print("Alice" == "alice")   # False, capital A isn't the same as lowercase a
print("A" < "B")            # True, alphabetical order works here too

3. Logical Operators: Combining More Than One Condition

and, or, and not let you combine multiple conditions into a single decision instead of nesting a pile of separate if statements.

account_type = "basic"
amount = 85000

if account_type == "basic" and amount <= 70000:
    print("Transaction approved")
elif account_type == "basic" and amount > 70000:
    print("Limit exceeded for basic account (max Ksh 70,000)")
elif account_type == "premium" and amount <= 300000:
    print("Transaction approved")
else:
    print("Check account rules")

and needs both sides to be true before the whole condition counts as true. Trace it through: account_type == "basic" is true, but amount <= 70000 is false, since 85,000 is well over that. Both need to hold for the first line to match, so Python moves down to the next check instead.

WHY IT MATTERS
and requires everything to be true. or only needs one side to be true. not flips whatever comes after it, not True becomes False. This is real logic banks and apps actually run on, "approve this transaction only if the account type matches AND the amount is within its limit" is exactly the kind of rule and was built for.

4. if / elif / else: Turning Questions Into Actions

Comparisons and logical operators are how you ask a question. if, elif, and else are how your program actually acts on the answer.

score = 68

if score >= 80:
    print("Grade: A")
elif score >= 60:
    print("Grade: B")
elif score >= 40:
    print("Grade: C")
else:
    print("Grade: F")

Python checks each condition top to bottom and stops at the very first one that's true. score = 68 fails the first check (not 80 or above), matches the second (60 or above), and never even evaluates the rest. Order matters a lot here, if you accidentally put the loosest condition first, everything below it becomes unreachable.

5. Putting It Together: A Loan Eligibility Checker

Here's everything from this post, arithmetic, comparisons, logical operators, and conditionals, working together in one small program.

income = float(input("Enter your monthly income (Ksh): "))
existing_debt = float(input("Enter your existing monthly debt payments (Ksh): "))
requested_loan = float(input("Enter requested monthly loan payment (Ksh): "))

total_debt = existing_debt + requested_loan
debt_ratio = total_debt / income

print(f"\nYour debt-to-income ratio would be {debt_ratio:.2%}")

if debt_ratio <= 0.3 and income >= 20000:
    print("Loan approved.")
elif debt_ratio <= 0.3 and income < 20000:
    print("Loan denied: income below minimum threshold.")
elif debt_ratio > 0.3:
    print("Loan denied: debt-to-income ratio too high.")
else:
    print("Unable to process application.")

That debt_ratio <= 0.3 check is a comparison, debt_ratio <= 0.3 and income >= 20000 is a logical combination of two comparisons, and total_debt / income is plain arithmetic feeding directly into the decision. The elif chain is doing exactly what a loan officer's rulebook would do, checking conditions in order and applying whichever one matches first.

Why This Part Matters More Than It Looks Like It Does

Every "smart" behaviour you've ever seen in an app, a form rejecting an invalid entry, a discount applying automatically, a login failing on the wrong password, is some combination of an operator asking a question and a conditional deciding what to do with the answer. There's no deeper magic underneath it.

This is also usually where people first genuinely feel like they're programming, rather than just typing instructions in a straight line. That feeling is worth paying attention to. Comparisons and conditionals are the first moment your code actually reacts to the world instead of just repeating a script, and almost everything more advanced you'll build later is this same idea, asked more times, in more combinations.

Python Basics: The Fundamentals That Let You Build Something Real in Week One

Neema Kirui — Thu, 10 Sep 2026 20:08:10 +0000

Introduction

Here's the truth nobody tells you when you start learning Python: you don't need to finish a course before you build something real. You need print(), a few variables, an understanding of what's actually being stored, a way to talk to the user, some basic syntax rules, and a little patience, and you can already write a program that does something real. This post walks through all of that, starting from the very first line you'll ever type.

READING TIP
Type every snippet yourself instead of copying it. Typing builds memory. Copying just builds a scrollbar.

1. Your First Python Program

Every Python journey starts the same way, with print():

print("hello world")
print("this is my first python program")

print() displays whatever you put between the parentheses. The text inside the quotes is called a string. Python reads your file top to bottom, so the second line runs right after the first one finishes.

hello world
this is my first python program

That's it. That's a real, complete Python program. It doesn't need to be more complicated than that to count.

IMPORTANT
A string has to open and close with the same kind of quote. "hello" is fine. "hello' (mixing a double quote with a single quote) raises an error. And print always needs its parentheses, even for something this small.

2. Variables: Giving a Value a Name

A variable is just a name pointing at a value. That's it, that's the whole concept, everything else is details.

balance = 200
name = "Amina"
is_member = True

What makes Python forgiving here is that a variable isn't locked to one type forever. You can point balance at a number, then later point it at something else entirely:

balance = 200
balance = "two hundred"   # totally legal, if a little confusing

That flexibility is nice, but it's also exactly how bugs sneak in. Which brings us to the rule that will save you more headaches than anything else in this post.

GOLDEN RULE
input() always returns a string, even if the person typed a number. total = "5" + 5 raises a TypeError. Always wrap input() in int() or float() before doing math with it. This one habit prevents dozens of crashes.

3. Data Types: What's Actually Inside the Name

Every value has a type, whether you think about it or not. The ones you'll reach for constantly:

Type	Example	What it's for
`int`	`42`	Whole numbers
`float`	`3.14`	Numbers with decimals
`str`	`"hello"`	Text
`bool`	`True`, `False`	Yes/no, on/off
`list`	`[1, 2, 3]`	An ordered, changeable collection

You can check what you're actually holding with type(), which is one of the first honestly useful debugging habits:

price = 200
print(type(price))       # <class 'int'>

price = 200.00
print(type(price))       # <class 'float'>

GOOD TO KNOW
Dividing two whole numbers in Python always gives you a float back, whether you wanted one or not. 700 / 3 prints 233.33333333333334, not a clean 233. That's not a bug, it's just how division works here, formatting is a separate step.

4. Input and Output: Making Your Program Talk Back

A program that just prints the same thing every time gets boring fast. The moment it actually asks you something and reacts to your answer is the moment it starts feeling like a real program. Here's a small booking script that pulls together everything so far:

passenger_name = input("Enter passenger name: ")
route = input("Enter route: ")
fare = int(input("Enter fare (Ksh): "))

booking_fee = 10
total = fare + booking_fee

print()
print("=" * 40)
print("            TICKET")
print("=" * 40)
print(f"Passenger   : {passenger_name}")
print(f"Route       : {route}")
print(f"Fare        : Ksh {fare}")
print(f"Booking Fee : Ksh {booking_fee}")
print("-" * 40)
print(f"TOTAL       : Ksh {total}")
print("=" * 40)

Three small ideas are doing all the work in that script: input() collects text, int() converts the fare so it can be added to booking_fee, and the f-strings (f"Fare : Ksh {fare}") drop each variable straight into the printed text without any clumsy string-joining. That "=" * 40 trick is a nice bonus, too, repeating a character to build a clean divider line for free.

MINI-CHALLENGE
Add a luggage fee of Ksh 50 to the total. Only two lines actually need to change, try it yourself before peeking.
booking_fee = 10
luggage_fee = 50
total = fare + booking_fee + luggage_fee

5. Basic Syntax: The Rules That Bite You Under Pressure

Python doesn't use curly braces to mark a block of code, it uses indentation. That means a misaligned line isn't just messy, it can change what your program actually does, or crash it outright.

age = 20

if age >= 18:
    print("You're an adult.")
else:
    print("You're a minor.")

Everything indented under if only runs when the condition is true. Everything under else only runs when it isn't.

COMMON BUG
== compares two things. = assigns a value. Writing if age = 18 instead of if age == 18 is one of the most common mistakes beginners make, and Python will usually stop you with a clear error if you do it inside a condition, so don't panic if it happens to you.

Comments start with # and get skipped entirely when the program runs, handy for leaving yourself a note about why something is written a certain way:

# Convert Celsius to Fahrenheit
fahrenheit = (celsius * 9/5) + 32

6. Putting It All Together: A Small Practical Example

None of this means much sitting alone, so here's everything from this post in one small program, a grocery total calculator that keeps running until you tell it you're done.

items = []
total = 0.0

print("Enter your grocery items. Type 'done' when finished.\n")

while True:
    name = input("Item name: ")
    if name.lower() == "done":
        break

    price = float(input(f"Price of {name}: Ksh "))
    quantity = int(input(f"Quantity of {name}: "))

    subtotal = price * quantity
    items.append((name, quantity, subtotal))
    total += subtotal

print("\n--- Receipt ---")
for name, quantity, subtotal in items:
    print(f"{name} x{quantity}: Ksh {subtotal:.2f}")

print(f"\nTotal: Ksh {total:.2f}")

Every idea from this post shows up in those twenty lines. total and items are variables getting reassigned as the loop runs. str, float, int, and list all show up as the actual data types doing the work. input() and print() handle the whole back-and-forth with the user. float() and int() convert raw text into numbers you can actually do math with. And indentation is quietly deciding what belongs inside the loop and what runs after it.

WHY IT MATTERS
This isn't a toy example for its own sake. Swap "grocery items" for "bus tickets" or "airtime bundles" and you've got the skeleton of half the beginner projects out there, a loop that keeps taking input, a running total, and a receipt at the end.

You're Closer Than You Think

It's tempting to rush past print() and variables to get to the "real" programming, loops, functions, whatever the next shiny topic is. But almost every early beginner mistake traces back to one of these fundamentals being slightly off: forgetting that input() returns a string, dividing two integers and being surprised by a float, an indentation slip that quietly changed what a block of code actually did, a mismatched quote mark crashing the very first line you ever wrote.

None of that means you're bad at this. It means you're doing exactly what everyone does on the way to getting comfortable. And these basics aren't a phase you outgrow once you get to "real" programming, they're the building blocks everything else in Python is made of. Loops are just variables changing inside a block of indented code. Functions are just input and output wrapped up with a name. Every library and framework you'll eventually touch is still, underneath, print(), variables, and a few types of data, just arranged in more elaborate ways. Get genuinely comfortable with these now, and the rest of Python stops looking like new material and starts looking like the same five or six ideas wearing different clothes.

If you've followed along and typed the code yourself, from that first print("hello world") all the way to the grocery receipt, you already have everything you need to build something small and real this week. Go build it.

From SQL Views to a Boardroom Dashboard: Presenting SafariConnect in Power BI

Neema Kirui — Tue, 08 Sep 2026 20:59:45 +0000

Cleaning the SafariConnect data and answering the six business questions in SQL was one project. Turning those answers into something a CEO could actually look at during a board meeting was a completely different skill, and honestly the one I was less prepared for. This is the follow-up to my SQL cleanup post: how the same data ended up as a four-page Power BI dashboard, what it showed, and what presenting it actually taught me.

Power BI Only Saw What SQL Already Fixed

I didn't point Power BI at the raw bookings table. By the time the SQL project was done, I already had a handful of views built specifically to answer each business question, v_route_performance, v_driver_performance, v_monthly_revenue, v_cancellation_analysis, v_passenger_insights, and the base v_clean_trips view underneath all of them.

CREATE OR REPLACE VIEW v_route_performance AS
SELECT
    route_code,
    route_from || ' → ' || route_to AS route,
    COUNT(*) AS total_bookings,
    SUM(seats_booked) AS total_seats,
    SUM(total_fare) AS total_revenue,
    ROUND(AVG(fare_per_seat), 2) AS avg_fare,
    ROUND(AVG(trip_rating), 2) AS avg_rating
FROM v_clean_trips
GROUP BY route_code, route_from, route_to
ORDER BY total_revenue DESC;

Connecting Power BI to those views instead of the raw table meant a lot of the aggregation logic (revenue by route, cancellation rate by route, driver rankings) was already sitting one layer below the dashboard, done once in SQL instead of being rebuilt as DAX measures for every visual. The dashboard's job wasn't to calculate the numbers, it was to display numbers that had already been calculated correctly.

I also added indexes on the columns I knew Power BI would be filtering and grouping by constantly, departure_date, route_code, driver_name, booking_status, since a dashboard that gets refreshed and filtered repeatedly is a very different access pattern from a one-off analytical query.

CREATE INDEX idx_bookings_depdate ON bookings (departure_date);
CREATE INDEX idx_bookings_route   ON bookings (route_code);
CREATE INDEX idx_bookings_driver  ON bookings (driver_name);
CREATE INDEX idx_bookings_status  ON bookings (booking_status);

Not Every Reader Needed the Same Page

The report ended up as four pages, each built for a different reader in the room.

Executive Revenue Insights was the landing page, and it had to work for someone who might only look at it for thirty seconds. Six KPI cards sat across the top: Ksh223.97K total net revenue, 248 completed bookings, a 3.53 average trip rating, a 4.27 average driver rating, a 12.37% overall cancellation rate, and Ksh17.24K in total revenue lost. Below that, a revenue-by-route bar chart, a monthly revenue trend, a treemap of revenue by passenger city with Nairobi dominating everything else on the map, and a payment method breakdown showing M-Pesa well ahead of cash and card.

Driver Performance & Trip Insights was the operational page, filterable by route, vehicle type, passenger city, and driver name. It had a revenue-by-driver bar chart, a trips-by-driver chart, a seat class split (Economy at 79% against Business at 21%), and a day-by-hour booking heatmap that made the busiest and quietest periods immediately obvious just from the shading, no need to read a single number to see that Tuesday was busy and Sunday wasn't.

Insights was a plain-text page, deliberately not another chart. Just the key findings written out in full sentences, because sometimes the fastest way to communicate a finding is to just say it instead of asking someone to read it off a bar chart.

Recommendations closed out the report, translating each finding into an actual next step instead of leaving the board to draw its own conclusions.

Seeing It on a Screen Changed What Stood Out

A few findings only became obvious once they were sitting next to each other visually, in a way they hadn't been in a plain SQL result set.

RT001 was the best route and one of the biggest problems at the same time. It brought in the most revenue on the network, KES 51,600, but it also lost the most to cancellations of any route, KES 5,169. Seeing the revenue chart and the cancellation chart on the same page made that connection obvious in a way that scrolling between two separate query results never would have.
Driver rating and passenger rating told two different stories. Isaac Korir led on revenue, Hassan Abdi led on passenger satisfaction, and the platform's own driver ratings didn't reliably predict either one. Putting both metrics side by side on one page, instead of just reporting a single "top driver," was the only way to show that nuance honestly.
The booking heatmap did more work than any number could. Tuesday's 49 bookings and Sunday's 10 look like a mild difference as two numbers in a sentence. On a shaded grid across the week, the contrast is immediate, and it turns into an obvious operational question: why are we running the same vehicle allocation on Sunday as we are on Tuesday?
Nairobi wasn't just the top city, it was most of the map. The treemap made the scale of that dominance visual instead of just numeric, KES 110,410 sitting in one city versus everywhere else combined.

Charts, Then Findings, Then Actions

The Insights and Recommendations pages ended up being the most important pages in the whole report, and they're the two pages with the fewest charts on them.

Every chart on the first two pages answers a "what happened" question. The Insights page exists to answer "so what," written as plain findings instead of forcing the reader to interpret a bar chart themselves: RT001 is the top-performing route but also the most cancellation-prone, Nairobi generates the most revenue of any town, M-Pesa is the dominant payment method. The Recommendations page goes one step further and answers "now what": investigate the shared cause behind cancellations on RT005 and RT006, study Isaac Korir's approach for repeatable best practices, check whether Peter Ngugi's lower numbers are a driver issue or a route issue before responding to either.

That structure, chart pages, then a findings page, then a recommendations page, was deliberate. A director skimming for thirty seconds gets the KPI cards. Someone with five minutes gets the Insights page. Someone who actually has to decide something gets the Recommendations page. Not every reader needs the same depth, and building the report in layers meant I didn't have to guess which one any given person would want.

The Real Lesson Wasn't in the SQL

The SQL side of this project was about getting the numbers right. The BI side was about deciding what to do with numbers that were already right, and that turned out to be a genuinely different skill.

A correct number in the wrong format doesn't communicate anything. "12.37% cancellation rate" sitting quietly in a query result is not the same thing as a KPI card in red at the top of a dashboard next to "Ksh17.24K lost." Same number, completely different amount of attention it earns in a room.

I also learned that a dashboard isn't finished when the charts render correctly. It's finished when someone who never saw the SQL, never saw the messy CSV, and doesn't especially care how any of it works, can look at page one for thirty seconds and walk away knowing whether the business is doing well. Getting there took more thought about layout, hierarchy, and what to leave off the page than it took to write any of the underlying queries. Cleaning the data made the numbers trustworthy. Building the dashboard is what made them usable.

"SQL, a Messy CSV, and a CEO Waiting for Answers: The SafariConnect Project"

Neema Kirui — Tue, 08 Sep 2026 20:27:56 +0000

Introduction

A few weeks ago, as part of learning SQL, we were given a project built around a fictional company called SafariConnect, a Nairobi bus and matatu booking platform. The scenario: you're the newly hired Data Analyst, the company's been growing fast, and nobody actually knows which routes make money, which drivers are worth promoting, or why cancellations feel so high. All they have is a 290-row CSV export from a shared Excel sheet, and a board meeting on the calendar with the CEO expected to ask questions.

No pressure. Just clean the data, load it, analyse it, and have real answers ready.

The Mess

The CSV looked like it had been typed by six different people on six different days, because it basically had been. Same fields, wildly inconsistent values:

Names in ALL CAPS, some in lowercase, some with random leading spaces
Phone numbers as 0712-345-678, some as +254712345678
Three different date formats sitting in the same column
Gender as 'male', 'MALE', 'M', and 'F'
Fares stored as text, some with 'KES' glued to the front
One booking_id duplicated, one row with -1 seats booked
A handful of trip ratings that were somehow 0 or 6, on a 1-5 scale

Before touching any of it, I dumped everything into a staging table where every column was just TEXT. No point enforcing types on data I hadn't even looked at yet.

CREATE TABLE bookings_staging (
    booking_id       TEXT, passenger_name TEXT, passenger_phone TEXT,
    passenger_gender TEXT, passenger_city  TEXT, route_code      TEXT,
    departure_date   TEXT, seats_booked    TEXT, total_fare      TEXT,
    booking_status   TEXT, trip_rating     TEXT
    -- (plus the rest of the columns)
);

Fixing It

Names, cities, and driver names all got the same treatment:

UPDATE bookings_staging
SET passenger_name = INITCAP(TRIM(passenger_name))
WHERE passenger_name != INITCAP(TRIM(passenger_name));

The messy categorical columns (gender, payment method, seat class, booking status) all had the same problem: too many spellings of the same real value. CASE WHEN cleaned them all up the same way:

UPDATE bookings_staging
SET payment_method = CASE
    WHEN UPPER(TRIM(payment_method)) IN ('MPESA','M-PESA','M PESA') THEN 'M-Pesa'
    WHEN UPPER(TRIM(payment_method)) = 'CASH' THEN 'Cash'
    WHEN UPPER(TRIM(payment_method)) = 'CARD' THEN 'Card'
    ELSE payment_method
END;

The dates were the annoying one. Three formats, no flag saying which was which, so I had to separate them by shape first:

-- DD/MM/YYYY - has a slash
UPDATE bookings_staging
SET departure_date = TO_DATE(departure_date,'DD/MM/YYYY')::TEXT
WHERE departure_date LIKE '%/%';

-- MM-DD-YYYY - the "day" part is over 12, so it can't be DD-MM
UPDATE bookings_staging
SET departure_date = TO_DATE(departure_date,'MM-DD-YYYY')::TEXT
WHERE departure_date LIKE '%-%'
  AND LENGTH(departure_date) = 10
  AND SPLIT_PART(departure_date,'-',2)::INTEGER > 12;

That "day part over 12" trick was the only way to tell MM-DD-YYYY apart from DD-MM-YYYY, since for the first twelve days of any month, both formats look identical.

The duplicate booking_id and the negative-seats row both got dropped outright rather than fixed. Postgres doesn't let you compare a row to itself directly, so ctid (the row's physical location) became the tiebreaker for the duplicate:

DELETE FROM bookings_staging
WHERE ctid NOT IN
    (SELECT MIN(ctid) FROM bookings_staging GROUP BY booking_id);

Once everything was clean, it moved into a properly typed bookings table with real DATE, NUMERIC, and INTEGER columns, going from 290 messy rows down to 283 trustworthy ones.

Actually Answering the Business Questions

This is the part where the project actually clicked for me. All that cleaning wasn't the point, it was just the cost of entry. The real value showed up here: turning "which routes make money" and "should we promote this driver" into an actual SELECT statement, and getting a real, defensible answer back. That's the whole point of data analysis, not writing queries for their own sake, but using them to answer questions a business genuinely needs answered.

With clean data, the six business questions turned into short queries. Route performance, for instance:

SELECT route_code, route_from || ' → ' || route_to AS route,
       SUM(total_fare) AS total_revenue,
       ROUND(AVG(trip_rating), 2) AS avg_rating
FROM v_clean_trips
GROUP BY route_code, route_from, route_to
ORDER BY total_revenue DESC;

Running that query against the cleaned data gave a clear leader and a clear laggard: Nairobi to Mombasa pulled in KES 51,600, close to a quarter of total company revenue, while Nairobi to Machakos brought in just KES 6,900. Same query, same columns, wildly different outcomes depending on the route, which is exactly the kind of gap a director can act on. A follow-up version of the same query, dividing revenue by seats sold instead of just summing it, told a slightly different story too: RT001 earned the most per seat at KES 1,258.54, while RT005 barely cleared KES 122.90, a reminder that total revenue and efficiency per seat aren't always the same route. Sliced by vehicle type instead of route, matatus came out as the most profitable overall at KES 85,135, edging out buses despite carrying fewer total seats.

I wrapped each business question in a view (v_route_performance, v_driver_performance, v_monthly_revenue, and so on) so the analysis wasn't a one-time thing, it's queryable going forward.

The month-over-month revenue trend needed a window function, since "compare this month to last month" isn't something a plain GROUP BY can do on its own:

WITH monthly AS (
    SELECT TO_CHAR(departure_date, 'YYYY-MM') AS month,
           SUM(total_fare) AS revenue
    FROM v_clean_trips
    GROUP BY TO_CHAR(departure_date, 'YYYY-MM')
)
SELECT month, revenue,
       LAG(revenue) OVER (ORDER BY month) AS prev_month,
       ROUND((revenue - LAG(revenue) OVER (ORDER BY month))
           / NULLIF(LAG(revenue) OVER (ORDER BY month), 0) * 100, 1) AS change_pct
FROM monthly
ORDER BY month;

LAG() just reaches back one row to grab the previous month's revenue, sitting right next to the current one, which made the percentage change a one-line calculation instead of a separate query.

What the Queries Actually Turned Up

Total net revenue across the network landed at Ksh223.97K from 248 completed bookings, KES 223,970 that only existed as scattered, dirty rows a few queries earlier.

The one that actually surprised me: drivers the platform rated 4.5 and above averaged a lower passenger satisfaction score (3.34) than "standard" drivers did (3.64). The company's own rating system wasn't predicting happier passengers. If anything, it was pointing the wrong way. That's the kind of thing you'd never catch just skimming the spreadsheet, and exactly the kind of finding a director actually wants walking into a board meeting.

The driver question needed more than a simple GROUP BY too, since "who's the best driver" isn't just about overall revenue, it's also about how each driver stacks up within their own vehicle type. RANK() with PARTITION BY handled both at once:

WITH driver_totals AS (
    SELECT driver_name, vehicle_type,
           COUNT(*) AS total_trips,
           SUM(total_fare) AS total_revenue
    FROM v_clean_trips
    GROUP BY driver_name, vehicle_type
)
SELECT driver_name, vehicle_type, total_trips, total_revenue,
       RANK() OVER (ORDER BY total_revenue DESC) AS overall_rank,
       RANK() OVER (PARTITION BY vehicle_type ORDER BY total_revenue DESC) AS vehicle_rank
FROM driver_totals
ORDER BY overall_rank;

PARTITION BY restarts the ranking within each group instead of across the whole table, so a driver could be the top performer for matatus specifically, even without being the top driver network-wide. Overall, Isaac Korir came out on top by revenue at KES 32,505, while Hassan Abdi had the best average passenger rating at 3.9, two different drivers topping two different leaderboards, which is exactly why "who should we promote" needed more than one query to answer properly.

Cancellations turned out to be a real problem, not just a feeling. A view built on booking_status made it easy to check per route:

SELECT route_code,
       ROUND(SUM(CASE WHEN booking_status IN ('Cancelled','No Show')
            THEN 1 ELSE 0 END) * 100.0 / COUNT(*), 1) AS cancel_rate_pct
FROM bookings
GROUP BY route_code
ORDER BY cancel_rate_pct DESC;

Across the network, the overall cancellation rate sat at 12.37%, and that translated to Ksh17.24K in lost revenue. RT005 (Nairobi-Thika) and RT006 (Mombasa-Malindi) had the highest combined cancellations and no-shows, five apiece. But the one that actually mattered most in KES terms was RT001, the network's single best-performing route by revenue also lost the most money to cancellations, at KES 5,169. Being the top earner didn't make it immune, if anything it meant every cancellation there cost more.

Booking patterns by day filled in the operational side, and this one was a straightforward EXTRACT and COUNT:

SELECT TO_CHAR(departure_date, 'Day') AS day_name,
       COUNT(*) AS total_bookings
FROM v_clean_trips
GROUP BY TO_CHAR(departure_date, 'Day'), EXTRACT(DOW FROM departure_date)
ORDER BY EXTRACT(DOW FROM departure_date);

Tuesday was the busiest day on the network at 49 bookings, followed by Monday at 45 and Thursday at 43. Sunday was the quietest by a wide margin, just 10 bookings, which on its own is a fairly clear signal for where NOT to over-allocate vehicles. Economy seats made up the vast majority of bookings too, 79% against 21% for Business, so most of the fleet's day-to-day demand is coming from the budget end.

Passenger patterns filled in the rest, and this is where HAVING earned its keep, filtering the grouped results down to cities with enough bookings to actually mean something:

SELECT passenger_city, COUNT(*) AS total_bookings,
       SUM(total_fare) AS total_revenue
FROM v_clean_trips
GROUP BY passenger_city
HAVING COUNT(*) >= 3
ORDER BY total_revenue DESC;

Nairobi dominated as a home city by a wide margin over Mombasa, Kisumu, and Thika, generating KES 110,410 on its own. M-Pesa was the clear preferred payment method at 53% of transactions, with cash and card splitting the remainder. And revenue by gender came out almost even, 53.97% male to 46.03% female, nothing dramatic enough to change a business decision on its own, but useful context for the passenger profile the director asked for.

What I'd Tell Someone Starting This

Load messy data into a TEXT-only staging table first. Don't fight the types until you've seen the mess.
Run SELECT DISTINCT on every categorical column before assuming you know what's in it.
If two date formats look identical for part of the month, find the one field that breaks the tie (day > 12, in this case) instead of guessing.
Wrap your answers in views. The director didn't just want six numbers, they wanted queries they could re-run next month.

Cleaning took longer than the actual analysis. But the analysis was only trustworthy because of it, and "trustworthy" is the whole job when there's a CEO in the room asking where the numbers came from. Every finding here fed straight into a set of actual recommendations, root-causing why RT009 underperforms instead of just flagging it, tightening cancellation policy on the worst offenders, and figuring out whether Peter Ngugi's lower numbers are a driver problem or a route problem before deciding how to respond.

That's the bit that actually stuck with me from this project. It's easy to think of SQL as just a way to retrieve data. This was the first time it clearly showed me the other half: SQL as the actual mechanism for answering a business question, GROUP BY turning raw rows into a route ranking, CASE WHEN turning a numeric score into a driver category, a window function turning a flat table into a month-over-month trend. None of it was retrieval for its own sake. Every query existed because someone in a boardroom needed a specific question answered, and that, more than any single command, is the whole point of data analysis.

All of this eventually fed into a dashboard the director could actually hand to the board:

More on how that got built in a follow-up post.

SQL for Beginners: Building a Mini School Database from Scratch!

Neema Kirui — Wed, 22 Jul 2026 17:42:13 +0000

SQL for Beginners: Building a Mini School Database from Scratch

If you're learning SQL, the fastest way to make it stick is to build something real not just read boring theory. In this post, I'll walk through a small project assignment I built while learning PostgreSQL over the weekend: a mini database for a fictional school called Greenwood Academy.

We'll go from an empty schema to a fully populated database with students, subjects, and exam results then run queries to answer real questions about the data. Along the way, we'll cover:

Creating tables (DDL)
Inserting, updating, and deleting data (DML)
Filtering with WHERE
Range, membership, and pattern-matching operators
Counting rows with COUNT
Categorizing data with CASE WHEN

Let's dive in.

Setting the Scene

Greenwood Academy needs three things tracked: students, the subjects they take, and their exam results. That's a clean, realistic setup for practicing relational database basics one table naturally connects to the others through IDs.

1. Building the Database (DDL)

First, we create a dedicated schema so everything for this project stays organized and separate from other databases:

CREATE SCHEMA greenwood_academy;
SET search_path TO greenwood_academy;

Then we define our three core tables.

Students the people at the center of everything:

CREATE TABLE students (
    student_id INT PRIMARY KEY,
    first_name VARCHAR(50) NOT NULL,
    last_name VARCHAR(50) NOT NULL,
    gender VARCHAR(1),
    date_of_birth DATE,
    class VARCHAR(10),
    city VARCHAR(50)
);

Subjects what's being taught:

CREATE TABLE subjects (
    subject_id INT PRIMARY KEY,
    subject_name VARCHAR(100) NOT NULL UNIQUE,
    department VARCHAR(50),
    teacher_name VARCHAR(100),
    credits INT
);

Exam results the link between students and subjects:

CREATE TABLE exam_results (
    result_id INT PRIMARY KEY,
    student_id INT NOT NULL,
    subject_id INT NOT NULL,
    marks INT NOT NULL,
    exam_date DATE,
    grade VARCHAR(2)
);

Schemas aren't set in stone once created. A great early lesson is learning to evolve a table with ALTER TABLE adding a column you realize you need, renaming one that's poorly named, and dropping one you don't:

-- Add a column
ALTER TABLE students ADD COLUMN phone_number VARCHAR(20);

-- Rename a column
ALTER TABLE subjects RENAME COLUMN credits TO credit_hours;

-- Remove a column
ALTER TABLE students DROP COLUMN phone_number;

This mirrors real life requirements change, and your schema needs to keep up without you having to drop and rebuild the whole table.

2. Filling the Database (DML)

With the structure in place, it's time to add data. INSERT statements can take multiple rows at once, which keeps things concise:

INSERT INTO students
(student_id, first_name, last_name, gender, date_of_birth, class, city)
VALUES
(1, 'Amina', 'Wanjiku', 'F', '2008-03-12', 'Form 3', 'Nairobi'),
(2, 'Brian', 'Ochieng', 'M', '2007-07-25', 'Form 4', 'Mombasa'),
(3, 'Cynthia', 'Mutua', 'F', '2008-11-05', 'Form 3', 'Kisumu');
-- ...and so on

The same pattern applies to subjects and exam_results. Once the tables are populated, a quick sanity check confirms everything landed correctly:

SELECT * FROM students;
SELECT * FROM subjects;
SELECT * FROM exam_results;

Data isn't static, though. People move, mistakes happen, and records get cancelled. That's where UPDATE and DELETE come in:

-- Correct a student's recorded city
UPDATE students
SET city = 'Nairobi'
WHERE student_id = 5;

-- Fix a marking error
UPDATE exam_results
SET marks = 59
WHERE result_id = 5;

-- Remove a cancelled exam result
DELETE FROM exam_results
WHERE result_id = 9;

Pro tip: Always pair UPDATE and DELETE with a WHERE clause. Forgetting it means updating or deleting every row in the table, a classic (and painful) beginner mistake.

Respect the WHERE clause. Forget it on an UPDATE or DELETE and you're not fixing one row you're rewriting the whole table.

3. Querying the Data with WHERE

Now for the fun part, asking questions. The WHERE clause is how you filter rows to get exactly what you need.

-- Students in Form 4
SELECT * FROM students WHERE class = 'Form 4';

-- Subjects in the Sciences department
SELECT * FROM subjects WHERE department = 'Sciences';

-- Exam results with marks of 70 or higher
SELECT * FROM exam_results WHERE marks >= 70;

You can combine conditions with AND and OR to ask more specific questions:

-- Form 3 students who live in Nairobi
SELECT * FROM students
WHERE class = 'Form 3' AND city = 'Nairobi';

-- Students in Form 2 OR Form 4
SELECT * FROM students
WHERE class = 'Form 2' OR class = 'Form 4';

AND narrows the results (both conditions must be true), while OR widens them (either condition can be true) a distinction that trips up a lot of beginners at first.

4. Range, Membership & Search Operators

Plain equality checks only get you so far. SQL gives you more expressive tools for common patterns.

BETWEEN for ranges (inclusive on both ends):

-- Marks between 50 and 80
SELECT * FROM exam_results
WHERE marks BETWEEN 50 AND 80;

-- Exams that happened in a date range
SELECT * FROM exam_results
WHERE exam_date BETWEEN '2024-03-15' AND '2024-03-18';

IN and NOT IN for membership checks much cleaner than a chain of ORs:

-- Students living in specific cities
SELECT * FROM students
WHERE city IN ('Nairobi', 'Mombasa', 'Kisumu');

-- Students NOT in Form 2 or Form 3
SELECT * FROM students
WHERE class NOT IN ('Form 2', 'Form 3');

LIKE for pattern matching % is a wildcard for "any characters":

-- First names starting with A or E
SELECT * FROM students
WHERE first_name LIKE 'A%' OR first_name LIKE 'E%';

-- Subjects containing the word "Studies"
SELECT * FROM subjects
WHERE subject_name LIKE '%Studies%';

'A%' means "starts with A," while '%Studies%' means "contains Studies anywhere in the string." Small syntax, huge flexibility.

5. Counting with COUNT

Sometimes you don't need the rows themselves, just how many there are. That's what COUNT(*) is for:

-- How many students are in Form 3?
SELECT COUNT(*) AS total_form3_students
FROM students
WHERE class = 'Form 3';
-- Result: 4

-- How many exam results have marks of 70 or above?
SELECT COUNT(*) AS total_marks_70_or_above
FROM exam_results
WHERE marks >= 70;
-- Result: 6

COUNT combined with WHERE is one of the most common patterns you'll write in real reporting queries "how many of X meet condition Y" comes up constantly.

6. Categorizing Data with CASE WHEN

This is where SQL starts to feel genuinely powerful. CASE WHEN lets you create new, human-readable categories right inside a query, there is no need to pull data into another language just to label it.

Grading exam performance:

SELECT
    result_id,
    student_id,
    marks,
    CASE
        WHEN marks >= 80 THEN 'Distinction'
        WHEN marks >= 60 THEN 'Merit'
        WHEN marks >= 40 THEN 'Pass'
        ELSE 'Fail'
    END AS performance
FROM exam_results;

Classifying students by seniority:

SELECT
    first_name,
    last_name,
    class,
    CASE
        WHEN class IN ('Form 3', 'Form 4') THEN 'Senior'
        WHEN class IN ('Form 1', 'Form 2') THEN 'Junior'
        ELSE 'Unknown'
    END AS student_level
FROM students;

CASE WHEN evaluates top to bottom and stops at the first matching condition so order your conditions from most specific to least specific (or in this case, from highest marks to lowest).

Wrapping Up

In just six sections, we went from an empty schema to a working mini-database that can answer real questions: Who's in Form 4? Which exams need attention? Who's a top performer?

The core lesson here isn't really about school records, it's that a small set of SQL fundamentals (CREATE, INSERT, WHERE, BETWEEN, IN, LIKE, COUNT, CASE WHEN) can already answer a surprising number of real-world questions. Everything more advanced joins, subqueries, window functions builds directly on top of this foundation.

A Few Things I'd Tell Someone Starting Out

Run your INSERTs, then immediately double-check with SELECT COUNT(*).
Read every WHERE clause twice before hitting run on an UPDATE or DELETE.
IN and BETWEEN will save you from writing long, ugly chains of OR.
Order your CASE WHEN conditions carefully, it stops at the first match.

If you're learning SQL, I'd genuinely recommend building something similar: pick a small, relatable domain (a school, a shop, a gym), design two or three connected tables, and just start asking it questions.

Here is a github link to the assignment if you wanna check it out : (https://github.com/Neema-Kirui/sql-week2-assignment-neema/tree/main)

Happy querying!

From My Machine to the Cloud: Connecting Power BI to SQL Databases; PostgreSQL (Local vs Aiven)

Neema Kirui — Sat, 04 Jul 2026 21:26:12 +0000

Introduction

I used to think "connecting to a database" was one skill. Turns out it's two: connecting to a database chilling quietly on your own laptop, and connecting to one living in the cloud, behind a login, in this case, an SSL certificate that will not let you in until you treat it with respect.

This week I did both. Same tool (Power BI), same dataset, two very different vibes.

Grab a coffee, here's the full walkthrough local PostgreSQL first, then Aiven's cloud version, side by side, screenshots and all.

Part 1: Local PostgreSQL → Power BI

Step 1 : Create a schema

Nothing fancy, just giving my table a home:


CREATE SCHEMA powerbi;

Step 2 : Import the dataset

Right-click the new schema → Import Data in DBeaver, point it at your CSV, and let the wizard do its thing.

Step 3 : Check the table landed properly

A quick peek at the columns to make sure nothing got mangled on the way in.

Step 4 : Connect Power BI

In Power BI Desktop: Get Data → Database → PostgreSQL database.

In the Server field, type localhost (or 127.0.0.1) and your database name.

localhost

Choose Import, hit OK, and log in with your local username and password.

Click Load. That's it. That's the whole local experience.

Part 2: Aiven PostgreSQL (Cloud) → Power BI

Now for the part that actually taught me something.

Step 1 : Grab your connection details

Everything you need lives on Aiven's Overview page: Host, Port, Database name, User, SSL mode.

Your service URI will look something like this (don't worry, this isn't a real password, Aiven masks it in the console):

postgres://avnadmin:••••••••@pg-xxxxxxxx-yourproject.c.aivencloud.com:22016/defaultdb?sslmode=require

Step 2 : Import the dataset into Aiven

Same DBeaver wizard as before, just pointed at the Aiven connection instead of local.

CREATE SCHEMA powerbi;

Step 3 : Aiven's certificate.

Download the CA cert from the Overview page:

Now here's the part that actually tripped me up: Power BI's PostgreSQL connector doesn't have a field where you paste in a certificate file path (DBeaver does, Power BI doesn't). Instead, on Windows, you install the cert into Windows' own certificate store, since Power BI leans on the OS to handle SSL validation.

Once Windows trusts it, Power BI trusts it too. No settings to toggle inside Power BI itself.

Step 4 : Connect Power BI to Aiven

Same dialog, new server string:

pg-xxxxxxxx-yourproject.c.aivencloud.com

Database: defaultdb

Log in with your Aiven username and password. Since the cert is already trusted system-wide, no extra SSL prompts show up it just connects.

Local vs Aiven: Side by Side

Step	Local PostgreSQL	Aiven PostgreSQL
Server address	`localhost`	Full Aiven host string
Port	Default `5432`	Custom port from Aiven console
SSL/certificate setup	None	Download CA cert, trust it via Windows Certificate Manager
Power BI dialog	Identical	Identical
Credentials prompt	Username/password	Username/password (SSL handled invisibly behind the scenes)

Same tool, same steps on the surface. The only real difference is one extra layer of trust you have to set up before the cloud database will even talk to you and once it's set up, it disappears completely. You never think about it again.

The Day I Realized Power BI Isn't Just Pretty Excel: Understanding Data Modelling

Neema Kirui — Thu, 25 Jun 2026 18:01:47 +0000

When I first opened Power BI, I thought it was just a prettier Excel. Then I hit data modelling and it looked me dead in the eye and said "not today."

Data modelling is the backbone of any Power BI report. It decides how your tables connect, how fast your visuals load, and whether your numbers are actually trustworthy. It's what allows Power BI to understand that a sale belongs to a product, a customer belongs to a region, and a date belongs to a calendar.

Without a proper model, your visuals might look impressive while quietly lying to you. Once you get it? Everything clicks. Let me break it down simply.

Relationships: Getting Your Tables to Actually Talk

A relationship connects two tables through a shared column called a key. If your Sales table and Products table both have a ProductID column, that's your link right there.

Every relationship starts with two important columns:
Primary Key (PK) – a column whose values are unique. Think ProductID in a Products table where every product appears once.
Foreign Key (FK) – a column that references the primary key from another table. Think ProductID in a Sales table where the same product

The primary key identifies the record. The foreign key points to it. Together, they allow Power BI to connect the dots.

Type	What it means	Example
*One-to-Many (1:)**	One row on one side, many on the other	One product → many sales
Many-to-Many (:)	Both sides have repeats	Students ↔ Courses

  Products Table  ─────────────────  Sales Table
  ┌─────────────┐                   ┌─────────────┐
  │ ProductID   │──────── 1 : * ────│ ProductID   │
  │ ProductName │                   │ SaleAmount  │
  │ Category    │                   │ SaleDate    │
  └─────────────┘                   └─────────────┘

Relationships also have a filter direction.Think of it as a one-way street. Filters travel from the one side to the many side.

One thing I learned very quickly is that relationships matter more than you think. Without them, Power BI sees your tables as separate islands. That's why you might click a product in one visual and wonder why absolutely nothing happens in the others.

Star Schema vs Snowflake Schema

Your schema is the overall layout of your data model basically how all your tables are arranged and connected to each other.

Star Schema - The One You Want

              ┌─────────────┐
              │   DimDate   │
              └──────┬──────┘
                     │
  ┌────────────┐  ┌──▼─────────┐  ┌─────────────┐
  │DimCustomer │──│  FactSales │──│  DimProduct │
  └────────────┘  └──┬─────────┘  └─────────────┘
                     │
              ┌──────▼──────┐
              │  DimRegion  │
              └─────────────┘

One central fact table (your numbers in terms of sales amounts, quantities) with dimension tables around it (your context: dates, customers, products). Clean, fast, and exactly what Power BI is optimised for. DAX, Power BI's formula language, was designed with this layout in mind.

One thing that surprised me was how much Power BI prefers a star schema. At first, I wanted to keep breaking tables into smaller and smaller pieces because it felt more organised. But Power BI works best when dimensions stay relatively flat and connect directly to a central fact table. Fewer relationship paths mean faster calculations and fewer headaches when writing DAX.

Snowflake Schema - The Complicated One

  ┌────────────┐   ┌────────────┐   ┌────────────┐
  │ DimProduct │──▶│ DimCategory│──▶│DimSuperCat │
  └─────┬──────┘   └────────────┘   └────────────┘
        │
  ┌─────▼──────┐
  │ FactSales  │
  └────────────┘

This keeps splitting dimension tables into smaller sub-tables (e.g. Product → Category → Super Category). It looks tidy but makes your model slower and your DAX measures harder to write.

Joins: Combining Tables in Power Query

Joins happen in Power Query before data even reaches your model. You're deciding which rows from each table make the cut. The easiest way to picture this is with Venn diagrams:

Join Type	What you get
Inner Join	Only rows that match on both sides
Left Outer Join	All left rows + right matches
Full Outer Join	Every row from both tables

I once used the wrong join and ended up with sales figures in the millions when they should've been in the thousands. The data wasn't wrong I was just inviting the wrong rows to the party.

What Data Modelling Actually Taught Me

The biggest lesson wasn't how to create relationships or choose the correct join.

It was understanding that dashboards are only as good as the model underneath them.

A beautiful report built on a bad model will still give bad answers.

After working with relationships, schemas, joins, keys, and cardinality, I realised that data modelling isn't something you do before analysis. It is part of the analysis.

My biggest takeaways:

Build your model before building visuals.
Use a Star Schema whenever possible.
Understand your keys before creating relationships.
Be intentional with joins in Power Query.
If your numbers look wrong, check the model first. The chart may be what people see, but the model is what makes it trustworthy.

Data modelling isn't the flashiest part of Power BI nobody's putting their model diagram on a mood board. But get it right, and your visuals, your numbers, and your whole report will thank you.

How Excel is Used in Real-World Data Analysis

Neema Kirui — Fri, 05 Jun 2026 12:10:31 +0000

Introduction to Excel

In simple terms Excel is a spreadsheet program developed by Microsoft which is designed to organize, calculate, and analyze data. Excel is very collaborative when one is working with other tools in data analysis. It is also very effective when handling large datasets.

Ways Excel is used in real-world data analysis

In the real world, Excel is used for financial modeling, auditing, marketing performance,sales forecasting, business decisions among others.
Let's get into a few of them:

1. Financial Modeling
Excel serves as a a digital blueprint to map out the future of a business. Most institutions use Excel to strictly monitor their cash inflows and outflows, ensuring they always have enough money to pay bills while planning for future growth.
2. Business Decisions
Excel acts like a digital testing ground for business owners. You can change your sales and cost numbers on the screen to see how they affect your profits, helping you choose the best plan before spending real money.
3. Performance Tracking
Excel works as a digital report card for everyday operations. It stores daily sales data and uses built-in charts to show managers at a glance if the team is hitting targets or falling behind.

Features and Formulas

Conditional Formatting:
This feature automatically changes the color of a cell based on its value. For example, you can set Excel to turn a cell bright red if a project goes over budget, or green if sales goals are met, helping you spot critical details instantly.
Data Validation:
This feature sets strict rules for what users can type into a cell. You can use it to create drop-down menus or restrict cells to only accept specific items like dates or positive numbers preventing mistakes before they happen.
COUNTIF Function:
This tool counts cells only if they meet a specific rule. For example, it can look at a list of orders and count exactly how many times the word "Completed" appears.

Reflections

To be honest,knowing more about Excel has completely changed how I look at numbers. Playing with large data sets and making massive changes with just a single click is also really cool! It just shows me how fun it can be to play around with data, test out different features, and see what the numbers are trying to tell us. At the same time, it makes you realize how this work can be used for the greater good because data is really powerful! Yay!