DEV Community: Brian Kiprop

LEARNING SQL

Brian Kiprop — Mon, 20 Jul 2026 01:32:07 +0000

So, I Had to Run a School This Weekend (A SQL Story)
Here's the thing. I am not a database administrator. I'm just a student with a laptop, a slightly questionable internet connection, and a growing obsession with making tables do exactly what I want. But this weekend? Greenwood Academy in Nairobi gave me the keys to their digital kingdom. My job was to build their entire school database from scratch and start querying it.

No pressure, right?

Here is how it went down. The wins, the face-palm moments, and why CASE WHEN is officially my new favorite thing.

Step 1: The Setup (DDL - Building the Sandbox)
Before I could do anything cool, I had to actually build the container for all this data. That meant creating a schema called greenwood_academy and setting up three tables: students, subjects, and exam_results.

Writing out all those CREATE TABLE statements was pretty straightforward. I just followed the specs: student_id as the primary key, VARCHAR for names, INT for marks.

But then, plot twist. Just after I finished, the school realized they forgot phone numbers. Classic. So I had to whip out the ALTER TABLE command to add a phone_number column. Then they changed their minds again. "Actually, scrap that. Drop it." So I did. Dropping a column felt a bit risky, like deleting a file off your desktop, but hey, it worked. I also renamed credits to credit_hours, which just felt like good housekeeping.

Takeaway: Building a database isn't a one-and-done deal. You have to be flexible because schools (or bosses) will always change their minds.

Step 2: Inserting the Data (DML - The Real Work)
This is where I got a bit jittery. Copy-pasting 10 students, 10 subjects, and 10 exam results into a terminal feels like you're typing out a nuclear launch code. One missing comma and everything blows up.

I got to meet the students, though. Amina Wanjiku, Brian Ochieng, Esther Akinyi. I started rooting for them. But honestly? I messed up. Twice.

Esther's City: I inserted her with a city of "Nakuru". The spec said she moved to Nairobi. So I had to run an UPDATE on student_id = 5 to fix her address.

The Marks Blunder: For result_id 5, I typed "49" instead of "59". Ouch. One UPDATE later, I saved that student from a low grade. It felt weirdly satisfying to correct my own sloppy paperwork.

Oh, and I had to DELETE result_id 9 entirely because the exam got cancelled. Felt a bit harsh, but rules are rules.

Step 3: The Fun Part - Asking Questions (WHERE & Operators)
Once the data was solid, I finally got to do what SQL is actually for: querying.

The WHERE clause became my best friend.

"Show me all the Form 4 students." Done.

"Who's in Form 3 and from Nairobi?" Got them.

"Find the Science subjects." Easy peasy.

I hit Q21 and Q22, and things got technical. Using BETWEEN for marks (50 to 80) and dates (15th to 18th March) felt like I was slicing data with a laser beam. Then Q23 asked me to find students in Nairobi, Mombasa, or Kisumu. I used IN for the first time, and it just felt so clean compared to writing city = 'Nairobi' OR city = 'Mombasa' OR city = 'Kisumu'.

But the search operators (LIKE) threw me a curveball. Q25 asked for names starting with 'A' or 'E'. I nearly forgot the % wildcard. And looking for subjects containing "Studies"? LIKE '%Studies%' nailed it.

Step 4: The Grand Finale - COUNT and CASE WHEN
Q27 and Q28 were simple counting exercises. How many Form 3s? (3). How many marks above 70? (6). Easy math.

But then came Q29 and Q30. The CASE WHEN questions.

Honestly, this is where I fell in love with SQL a little bit.

For Q29, I had to label exam results as "Distinction", "Merit", "Pass", or "Fail". I wrote a CASE statement that looked at the marks column and spat out a text label. Here's the magical part. I didn't have to create a new column in the database. I just used the CASE logic inside my SELECT query, and the performance label appeared like magic in my result grid. No ALTER TABLE, no UPDATE. Just pure logic on the fly.

For Q30, I did the same thing for the students. If they were in Form 3 or Form 4, they were 'Senior'. If they were in Form 2 or Form 1, they were 'Junior'. It felt like giving out honorary titles.

Final Thoughts
If you're just starting with SQL, don't overthink it. It's basically just telling the computer:

"Hey, look at this table. If X is true, call it Y. If it's false, call it Z. And only show me the rows where the city is Nairobi."

Honestly, making mistakes (like putting Esther in the wrong city) helped me learn more than getting it right on the first try.

Tomorrow, I'm zipping this all up, pushing it to GitHub (look for my sql-week2-assignment repo), and submitting the link. If you're reading this and struggling with your own CASE WHEN, keep going. That "Aha!" moment is just one query away.

POWER BI - FIRST FLIGHT

Brian Kiprop — Mon, 29 Jun 2026 22:40:45 +0000

First of all, let me apologize to my viewers out there, wherever you are, existent or non-existent. I haven't been active here, but let's change that, shall we?

This week I started learning Power BI, and one thing became clear almost immediately: data is everywhere. It's living, breathing, moving, talking. Every interaction, transaction, click, conversation, and decision creates data. The real question isn't whether data exists—it's whether you know how to read it.

So, what is Power BI?

At first, I thought it was just another version of Excel. But after only a week of learning, I've realized it's much more than that. Think of it as Excel's more powerful sibling. While Excel is great for spreadsheets and analysis, Power BI is built to handle much larger datasets, connect to multiple data sources, and turn raw information into interactive dashboards and meaningful insights.

This week we explored the fundamentals, including where Power BI can get data from—Excel files, CSV files, the web, databases, and much more. We also learned why understanding data types is important. Knowing whether a column contains numbers, text, currency, dates, or time helps Power BI interpret and analyze the data correctly.

Power Query Editor

One concept I really liked was the Power Query Editor.

When importing data, you usually have two choices: Load or Transform Data.

Here's how I think about it:

Imagine a child comes home after playing outside. If you simply let them into the house without doing anything, that's like clicking Load you bring the data in exactly as it is.

Choosing Transform Data, on the other hand, is like washing the child, cleaning off the dirt, changing their clothes, and making sure they're presentable before they come inside. In data terms, this means cleaning your dataset by fixing errors, removing duplicates, changing data types, renaming columns, and preparing everything before analysis.

DAX Basics

We also got introduced to DAX (Data Analysis Expressions), which is Power BI's formula language.

DAX allows you to create measures, calculated columns, and other calculations that help you extract more meaning from your data.

For example, if you want to calculate the total revenue, you can use the SUM() function. Simple, but powerful.

Some other common DAX functions include:
Logical:IF(), SWITCH()
Date & Time:TODAY()
Text: LEN(), RIGHT()

I'm only one week in, but it's already changing how I think about data. Before, I mostly saw rows and columns. Now I'm starting to see stories, patterns, and insights waiting to be uncovered.

Looking forward to learning more and this time, I'll try not to disappear for so long.

How Excel is Used in Real-World Data Analysis

Brian Kiprop — Sun, 07 Jun 2026 12:23:55 +0000

Before this week, I thought Excel was just a fancy calculator with boxes. But after three days of my Data Science & Analytics course, I realise I was wrong. Really wrong.

Excel is a spreadsheet tool used by millions of people from small business owners to data analysts at giant companies. And the best part? You don’t need to be a programmer to use it. You just need to know a few tricks.

Here’s how Excel helps solve real-world problems using exactly what I learned in Week 1.

3 Real-World Ways Excel Is Used

Business decisions with logic
Managers use IF() statements to answer yes/no questions. Example: =IF(Sales>1000, "Bonus", "Needs Improvement"). One cell can decide who gets paid more.
Cleaning messy data
Real data is never clean. Marketing teams use Remove Duplicates, Find & Replace, and Text to Columns to fix hundreds of messy rows in seconds. No manual typing.
Tracking deadlines and ages
HR teams use DATEDIF() to calculate employee ages or years of service. TODAY() and NOW() keep reports automatically updated. No more “oh, I forgot to update the date.”

3 Excel Features I Learned This Week
Remove Duplicates – One click, and Excel deletes repeated rows. Saved me from sending the same customer email twice.

IFERROR() – Hides ugly errors like #DIV/0! and shows something friendly instead (e.g., “Check data”). Your boss will thank you.

Sort & Filter – With AutoFilter, I can find all sales above $500 in one second. Then Custom Sort lets me sort by date and region together.

My personal reflection
Honestly? Learning Excel has changed how I see data. I used to look at a messy spreadsheet and feel lost. Now I see Remove Duplicates, Text to Columns, and TRIM() as tiny tools that bring order to chaos.

Data isn’t scary anymore. It’s just a puzzle and Excel gives me the pieces.

I’m only one week in. But I already feel like a junior data analyst in training.