Forem: Ephantus Macharia

Subqueries vs CTEs in SQL: Master Nested Queries and Write Cleaner, Smarter Code

Ephantus Macharia — Thu, 30 Apr 2026 13:41:06 +0000

If you've been writing SQL for a while, you've hit this wall your query works, but it's a mess of nested parentheses and you can barely read it yourself. That's the moment subqueries and CTEs become your best friends.

Both tools let you break complex logic into manageable steps.

Subqueries

A subquery is a query inside another query. The inner query runs first, and its result is used by the outer query.

The Classic Use Case

Say you want to find all employees earning above the company average:

SELECT name, salary
FROM employees
WHERE salary > (
    SELECT AVG(salary)
    FROM employees
);

The inner query calculates the average first let's say 58,000 then the outer query filters for everyone above that. Simple and effective.

Subquery in the FROM Clause

You can also use a subquery as a temporary table by placing it in the FROM clause:

SELECT dept_name, avg_salary
FROM (
    SELECT department AS dept_name,
           ROUND(AVG(salary), 2) AS avg_salary
    FROM employees
    GROUP BY department
) AS dept_summary
WHERE avg_salary > 60000;

The inner query builds a summary table per department. The outer query then filters it. You can't filter on an aggregate alias directly in WHERE, so this pattern is really handy.

Correlated Subquery

A correlated subquery references the outer query it runs once for every row:

SELECT name, salary, department
FROM employees e
WHERE salary = (
    SELECT MAX(salary)
    FROM employees
    WHERE department = e.department
);

For each employee, the inner query finds the highest salary in their department. This gives you the top earner from every department in one query.

Using IN with a Subquery

-- Employees who have made at least one sale
SELECT name
FROM employees
WHERE id IN (
    SELECT DISTINCT employee_id
    FROM sales
);

And the opposite employees who have never made a sale:

SELECT name
FROM employees
WHERE id NOT IN (
    SELECT employee_id
    FROM sales
    WHERE employee_id IS NOT NULL
);

Always filter out NULLs when using NOT IN. If the subquery returns even one NULL, you'll get zero results a silent bug that's easy to miss.

CTEs (Common Table Expressions)

A CTE lets you name a subquery and place it at the top of your statement using WITH. Same result, but much easier to read and maintain.

Basic Syntax

WITH cte_name AS (
    SELECT ...
    FROM ...
)
SELECT *
FROM cte_name;

Rewriting Our First Example as a CTE

WITH company_avg AS (
    SELECT AVG(salary) AS avg_salary
    FROM employees
)
SELECT e.name, e.salary
FROM employees e, company_avg
WHERE e.salary > company_avg.avg_salary;

Same logic, but now the average calculation has a name. Anyone reading this query immediately knows what company_avg means.

Chaining Multiple CTEs

This is where CTEs really shine you can stack them, each building on the previous:

WITH 
dept_totals AS (
    SELECT department,
           SUM(salary)  AS total_salary,
           COUNT(*)     AS headcount
    FROM employees
    GROUP BY department
),
dept_averages AS (
    SELECT department,
           ROUND(total_salary / headcount, 2) AS avg_salary
    FROM dept_totals
),
top_departments AS (
    SELECT department, avg_salary
    FROM dept_averages
    WHERE avg_salary > 65000
)
SELECT *
FROM top_departments
ORDER BY avg_salary DESC;

Read it top to bottom calculate totals, derive averages, filter the top ones.

Reusing a CTE

One thing subqueries can't do cleanly a CTE can be referenced multiple times in the same query:

WITH high_earners AS (
    SELECT * FROM employees
    WHERE salary > 70000
)
SELECT 'Count'         AS metric, COUNT(*)        AS value FROM high_earners
UNION ALL
SELECT 'Total Payroll',           SUM(salary)              FROM high_earners
UNION ALL
SELECT 'Average Salary',          ROUND(AVG(salary), 2)    FROM high_earners;

One definition, three uses. With a subquery you'd repeat the same block three times.

Recursive CTE For Hierarchical Data

CTEs have one trick subqueries simply cannot do recursion. Perfect for org charts, category trees, or any parent-child relationship:

WITH RECURSIVE org_chart AS (
    -- Start: the CEO (no manager above them)
    SELECT id, name, manager_id, 1 AS level
    FROM employees
    WHERE manager_id IS NULL

    UNION ALL

    -- Recurse: find everyone who reports to someone already in the CTE
    SELECT e.id, e.name, e.manager_id, oc.level + 1
    FROM employees e
    JOIN org_chart oc ON e.manager_id = oc.id
)
SELECT name, level
FROM org_chart
ORDER BY level, name;

Output:

name	level
Sarah (CEO)	1
Alice	2
Bob	2
Charlie	3
Diana	3

The query keeps joining until no more reports are found. No loops, no procedural code just SQL.

Takeaways

Subqueries are great for quick, inline logic filtering with IN, comparing against an aggregate, or building a derived table
CTEs shine when your logic is multi-step, needs to be reused, or involves recursion
Both are tools for breaking complex problems into steps picking one is about readability and context, not right vs wrong

How to Publish a Power BI Report and Embed It on a Website

Ephantus Macharia — Wed, 29 Apr 2026 10:46:52 +0000

A Step-by-Step Guide Using the Electronic Sales Data Dashboard

Introduction

Microsoft Power BI is a leading business intelligence platform that transforms raw data into rich, interactive dashboards. Once you've built a report like the Electronic Sales Data Dashboard used in this guide the next step is sharing it with stakeholders by publishing it to Power BI Service and embedding it on a website for broader access.

This guide walks through every stage of that process, with steps tailored directly to the Electronic Sales Data Dashboard (.pbix), which contains three report pages:

Page	Description
Dashboard	KPI cards, bar charts, line chart, pie chart, slicers, and a product table
Profit Margin (City, Product)	Column and bar charts breaking down profit margin by city and product
Geographical Sales Analysis	Interactive maps showing sales by city and country

Step 1 Create a Workspace in Power BI Service

Before publishing, you need a workspace a collaborative container in the cloud where your reports and datasets live.

How to do it:

Open your browser and go to https://app.powerbi.com.
Sign in with your Microsoft 365 or Power BI account.
In the left navigation panel, click Workspaces.
Click + New workspace at the top right.
In the panel that slides open:
- Enter a Name (e.g., Electronics Sales Analytics)
- Optionally add a Description (e.g., Sales performance reports for electronic products)
- Select a License mode — choose Pro or Premium per user if you need to share with others outside your organisation
Click Save.

Step 2

Upload and Publish the Report from Power BI Desktop

With the workspace ready, publish the .pbix file from Power BI Desktop.

How to do it:

Open the file Electronic_Salesdata_Dashboard.pbix in Power BI Desktop.
In the Home ribbon, click the Publish button (cloud icon).
A dialog box will appear — Select a destination:
- Choose the workspace you just created (e.g., Electronics Sales Analytics)
Click Select.
Power BI Desktop will upload the report and data model to the cloud.
Once complete, a success message appears with a link: Open 'Electronic_Salesdata_Dashboard' in Power BI.
Click the link to verify all three pages — Dashboard, Profit Margin (City, Product), and Geographical Sales Analysis — are rendering correctly in the browser.

Step 3

Generate the Embed Code

Once the report is live in Power BI Service, you can generate an iframe embed code.

How to do it:

Open the report in Power BI Service at app.powerbi.com.
Click File in the top menu bar.
Select Embed report → Publish to web (public).
A warning dialog will appear confirming the report will be publicly accessible — click Create embed code to proceed.
The next dialog presents two things:
- A shareable link (for direct URL sharing)
- An HTML iframe snippet ready to paste into any webpage

Example embed snippet generated:

<iframe
  title="Electronic Sales Data Dashboard"
  width="1140"
  height="541.25"
  src="https://app.powerbi.com/reportEmbed?reportId=YOUR_REPORT_ID&autoAuth=true&ctid=YOUR_TENANT_ID"
  frameborder="0"
  allowFullScreen="true">
</iframe>

Step 4

Embed the Report on Your Website

Paste the iframe into your HTML. Below are two approaches — a fixed-size embed and a fully responsive one.

Option A — Fixed-size embed (simplest)

<iframe
  title="Electronic Sales Data Dashboard"
  width="1140"
  height="541"
  src="https://app.powerbi.com/reportEmbed?reportId=YOUR_REPORT_ID&autoAuth=true&ctid=YOUR_TENANT_ID"
  frameborder="0"
  allowFullScreen="true">
</iframe>

Option B — Responsive embed (recommended)

<!-- Responsive Power BI embed wrapper -->
<div style="position: relative; padding-top: 56.25%; overflow: hidden;">
  <iframe
    title="Electronic Sales Data Dashboard"
    src="https://app.powerbi.com/reportEmbed?reportId=YOUR_REPORT_ID&autoAuth=true&ctid=YOUR_TENANT_ID"
    style="position: absolute; top: 0; left: 0; width: 100%; height: 100%;"
    frameborder="0"
    allowFullScreen="true">
  </iframe>
</div>

Embedding a Specific Page

To load a specific report page on page load, append the pageName parameter to the src URL:

Report Page	URL Parameter to Append
Dashboard	`&pageName=ReportSection`
Profit Margin (City, Product)	`&pageName=ReportSection1`
Geographical Sales Analysis	`&pageName=ReportSection2`

Example:

src="https://app.powerbi.com/reportEmbed?reportId=YOUR_REPORT_ID&pageName=ReportSection2"

Report Pages Overview

Page 1 _ Dashboard

The main dashboard contains the following visuals:

3 KPI Cards — Total Sales, Total Profit, Profit Margin
Bar chart — Sales by Product Name
Bar chart — Sales by Region
Bar chart — Sales by Product Category
Line chart — Sales over time (by Quarter and Month)
Pie chart — Sales by Region and Country
2 Slicers — Filter by Region and by Customer Name
Table — Product Name list

Page 2_ Profit Margin (City, Product)

Column chart — Total Sales by Country
Clustered column chart — Profit Margin by City
Bar chart — Profit Margin by Product Name
2 Slicers — Filter by Product Name and by City

Page 3 _ Geographical Sales Analysis

Bubble map — Sales Amount sized by city
Bubble map — Sales Amount sized by country

Key Insights & Best Practices

1. Use Premium Capacity for Scale

Power BI Premium capacity lets you embed reports without requiring every viewer to have a Pro licence. This is essential for public-facing websites where visitor volumes are unknown.

2. Apply Row-Level Security (RLS)

Before publishing this dashboard to a public or semi-public audience, define RLS roles in Power BI Desktop (Modelling → Manage roles) to restrict which rows of the fact, Customer, or Location tables individual users can see.

3. Schedule Data Refresh

The sales data in this dashboard is static until refreshed. Set up a data gateway and configure a scheduled refresh (daily or weekly) in the workspace settings so the embedded report always reflects current figures.

4. Make the Embed Responsive

Always use the padding-top wrapper approach (Option B above) so the dashboard scales cleanly on mobile, tablet, and desktop screens without horizontal scrollbars.

5. Control Which Page Loads First

Use the pageName URL parameter to decide whether visitors land on the summary Dashboard, the Profit Margin drill-down, or the Geographical map view depending on your audience.

6. Monitor Usage

Use the Usage Metrics report in the workspace to track how many users view the embedded report, which pages they visit most, and peak viewing times.

7. Secure Sensitive Sales Data

For any scenario involving authenticated users or confidential sales figures, replace "Publish to web (public)" with the Power BI Embedded (Azure) approach. This uses a service principal and generates tokens server-side, keeping data protected behind authentication.

Summary

Step	Action
1	Create a workspace in Power BI Service
2	Publish `Electronic_Salesdata_Dashboard.pbix` from Power BI Desktop
3	Generate an iframe embed code via File → Embed report → Publish to web
4	Paste the responsive frame snippet into your website HTML

With these four steps, your Electronic Sales Data Dashboard complete with KPI cards, regional sales charts, profit margin analysis, and geographic maps is live and fully interactive on your website.

Understanding Data Modelling in Power BI: Joins, Relationships, and Schemas.

Ephantus Macharia — Mon, 30 Mar 2026 18:39:36 +0000

Data modelling is the process of defining how your tables are structured and how they relate to one another. Instead of dumping everything into one giant flat table, you organise your data into multiple purpose-built tables and link them together. Power BI then uses those links to filter, aggregate, and display data correctly across your entire report.

Joins

How Tables Connect at the Query Level
A join is how you combine rows from two tables based on a shared column. In Power BI, joins happen inside Power Query before the data even hits your model.

There are four main join types:

Inner Join

Returns only rows that have a match in both tables. If a farmer exists in your Sales table but not in your Customers table, that row is dropped.

You only use when you want complete, matched records.

Left Outer Join

Returns all rows from the left table, plus any matches from the right. Unmatched rows from the right come back as nulls.

you use it when you want to keep all records from your primary table regardless of whether a match exists.

Right Outer Join

The mirror of a left join keeps all rows from the right table and fills nulls where the left has no match.

Full Outer Join

Returns all rows from both tables. Nulls appear wherever there's no match on either side.

Use when you want a complete picture and you are willing to handle the nulls.

In Power Query, you access these through Home → Merge Queries, then pick your join type from the dropdown.

Relationships

How Tables Connect in the Model
Once your tables are loaded, relationships are how Power BI understands the links between them inside the data model. Unlike joins (which physically merge rows), relationships are virtual they let Power BI filter one table through another without duplicating data.

You define relationships in the Model view, and they work automatically whenever you use fields from multiple tables in a visual.

The Three Relationship Types

One-to-Many (1:*) —The most common type. One row in Table A matches multiple rows in Table B. Example: one County matches many farmers. One Product matches many sales transactions.

One-to-One (1:1) Each row in Table A matches exactly one row in Table B. Example: one Employee record maps to one HR Profile. Rare in practice, often a sign you could just merge the tables.

Many-to-Many (:) Multiple rows in Table A match multiple rows in Table B. Example: one Order can contain many Products, and one Product can appear in many Orders. Power BI supports this natively, but it can create ambiguous filter paths best handled with a bridge table in between.

Filter Direction

Every relationship has a filter direction it controls which way filters flow between tables.

Single direction

filters flow one way only (from the "one" side to the "many" side). This is the safe default.
Both directioners flow both ways, Powerful, but can cause unexpected results in complex models. Use sparingly.
How Joins and Relationships Are Connected
This is where it clicks: joins and relationships solve the same problem at different stages of your pipeline.

A join in Power Query physically combines two tables into one before loading. A relationship in the model keeps tables separate but links them logically. The choice between them comes down to this:

Join (Power Query) Relationship (Model)
When it runs At data refresh / load time At query / visual render time
Result One merged table Two separate linked tables
Best for Lookup columns you need in the fact table Filtering and aggregating across tables
Performance Can increase table size Keeps model lean
A common pattern: use a join to bring a single lookup column (like County Region) into your fact table, while using relationships to connect your full dimension tables (Date, Product, Customer) for filtering.

Schemas

How You Arrange Your Tables
A schema is the overall blueprint of your model how many tables you have and how they're arranged. There are two schemas you'll encounter most in Power BI.

Star Schema

The star schema has one central fact table surrounded by several dimension tables. The fact table holds your numbers (revenue, yield, quantity). The dimension tables hold your descriptive context (who, what, when, where).

dim_Date ─┐
dim_County ─┤
dim_CropType ─┼──── fact_FarmerProduction
dim_Season ─┤
dim_SoilType ─┘

Every dimension connects directly to the fact table in a one-to-many relationship. This is the recommended structure for Power BI it's simple, fast, and the DAX engine is optimised for it.

Snowflake Schema

The snowflake schema normalises the star further by splitting dimension tables into sub-tables. Instead of one flat dim_Product table, you might have dim_Product → dim_Category → dim_SubCategory.

It reduces data duplication but adds complexity. In Power BI, the extra join hops can slow down queries and make DAX harder to write. Unless you have a strong reason (very large dimension tables with many repeated values), stick with the star schema.

Flat Table

A single flat table with no relationships is fine for small, simple datasets. If you're working with under 10,000 rows and don't need to join to anything else, a flat table keeps things uncomplicated. The moment you need to combine data sources, or your dimension data is repeated hundreds of times, move to a star schema.

Putting It All Together

Load your raw tables into Power Query
Use joins to pull in any lookup values you need directly in the fact table (e.g., a region name from a county lookup)
Load separate dimension tables  Date, County, Crop Type, Season — without merging them

Define relationships in Model view between your fact table and each dimension (one-to-many, single-direction filter)
Arrange your model as a star schema — fact table in the centre, dimensions around it

Concept : What it does, Where in Power BI

Inner join: Keep only matched rows  Power Query → Merge
Left join:  Keep all left rows + matches    Power Query → Merge
One-to-many relationship: Link dimension to fact table  Model view
Many-to-many relationship:Complex links, use bridge table   Model view
Star schema:    Fact + flat dimensions  Model view layout
Snowflake schema:Fact + normalised sub-dimensions   Model view layout

Conclusion

Data modelling in Power BI isn't about complexity, it's about clarity. A well-structured star schema with clean one-to-many relationships will outperform a messy flat table every time, both in query speed and in how easy your DAX becomes to write and maintain.

Start with your fact table, build your dimensions, connect them with single-direction relationships, and keep it flat.

From confusion to clarity;How Excel-Data analysis has Transformed my skills

Ephantus Macharia — Fri, 27 Mar 2026 09:54:01 +0000

Introduction

The Dataset That Changed Everything
I will be honest. When I first opened the Jumia Kenya product dataset, I had no idea where to begin. There were 115 rows of product data, but the prices were buried inside text strings like "KSh 1,525", the ratings were written as "4.5 out of 5", the review counts were all negative numbers, and a full 50 per cent of the rows had no rating information at all. It looked less like a dataset and more like a problem waiting to punish me.
That experience, the confusion, the slow process of fixing each issue one by one, and the moment when the data finally came alive is exactly what this article is about. Learning Excel data analysis did not just teach me a set of formulas. It changed the way I think, the way I approach problems, and the way I trust my own conclusions. This is my story of how that happened, told through the real data I cleaned, interpreted, and turned into a working dashboard.

Step One:

Working on Messy Data

What Real-World Data Taught Me First

Real-world data is rarely clean I learned that the hard way!
Data analysis means looking at clean and beautiful tables and extracting insights or so I thought!
Well, I was wrong most of the work happens before even a single chart is drawn!

The 6 Problems I Found in the Jumia Dataset
Prices were stored as text every price had a "KSh" prefix attached to it.
Ratings were written as sentences "4.5 out of 5" instead of just "4.5".
Review counts were negative every review count was entered as a minus value.
One product had a price range "KSh 1,620 – KSh 1,980" instead of a single value.
Percentage Discounts were stored as text "38%" instead of a real number.
58 products had no rating at all half of the products were blank for ratings!

What This Taught Me

Every single problem needed a deliberate solution in Excel.
Not only did I learn how to solve these problems, but I also learned how to solve them permanently!
The order in which I solved these problems also taught me how to diagnose the problem before even touching the data!.

=VALUE(SUBSTITUTE(SUBSTITUTE(A2,"KSh",""),",",""))   // Strip KSh and commas from price text, then convert to a true number
=VALUE(LEFT(A2,3))   // Extract just the numeric rating from "4.5 out of 5."

=ABS(A2)   // Convert negative review counts to positive values
=IF(ISBLANK(A2),"No Rating",IF(A2<3,"Poor",IF(A2<4.5,"Average","Excellent")))   //

What Actually Surprised Me About Data Cleaning

The difficulty was not the surprising part. Each fix is straightforward once you know the function
What surprised me is the amount of change the data underwent after the fixes The column of seemingly random characters, the wall of meaningless text, suddenly looked like: ✅ Sortable ✅ Calculable ✅ Chart-ready

The Real Meaning of Data Cleaning

Data cleaning is not about correcting errors. It is about transforming noise into a signal
The moment the data underwent its transformation is the moment I understood the true meaning of cleaning
No explanation or book can do justice to the experience of going through the transformation yourself

Skill Gained: What I Do Differently Now

I instinctively inspect every new dataset for the following six things before I do anything else
It takes five minutes to inspect
It saves hours of confusion
This is not something I learned by reading about it. This is something I learned by going through the experience once.

Step Two:

Creating Meaning with Formulas Data Enrichment

Clean data tells you what exists. Enriched data tells you what it means
This is where Excel formulas started feeling genuinely powerful
I was no longer just correcting errors; I was creating knowledge

New Columns I Added to the Dataset
Discount Amount (KES)

Formula: Current Price subtracted from Old Price
Reveals the real savings in shillings, not just a percentage
Why it matters:

64% off a KES 199 item = only KES 354 saved
39% off a KES 3,750 drill = KES 2,393 saved
Percentage figures alone were hiding this distinction entirely

Rating Category

Used an IFS formula to classify every product into a clear tier:

Poor — rating below 3
Average — rating between 3 and 4.4
Excellent — rating of 4.5 and above

Turns a raw number into a label anyone can read instantly

Discount Category

Grouped every product into one of three discount tiers:

Low Discount — below 20%
Medium Discount — between 20% and 40%
High Discount — above 40%

Why These Columns Mattered

Rating Category and Discount Category became the foundation of almost every comparison in the final analysis
Without them, grouping and comparing products would have required manual sorting every single time
With them, a single AVERAGEIF or COUNTIF formula answers any group-level question instantly

=IFS(D2<3,"Poor",D2<4.5,"Average",D2>=4.5,"Excellent
=IFS(C2<20,"Low Discount",C2<=40,"Medium Discount",C2>40,"High Discount")

This step taught me something important about data analysis: the raw data rarely tells the whole story. The enriched data does. A number like 3.7 says very little on its own. The label "Average" is placed alongside it, in context with 114 other products.

Step Three:

Charts

After cleaning and enriching the data, I ran a full descriptive analysis using AVERAGE, COUNTIF, AVERAGEIF, and CORREL functions. But the moment the analysis truly came alive was when I built the visualizations. The charts below were produced directly from the cleaned Jumia dataset, and each one taught me something that the tables had kept hidden.

This chart showed me immediately that 65 out of 115 products more than half carry a discount above 40%. At first, I assumed this meant they were the best-performing products.

The rating category chart was the most visually striking finding of the entire analysis. The grey "No Rating" segment representing 50% of all products dominates the chart. This is not just a design choice; it is a data quality alarm. Half the products in this dataset have never been reviewed. Any conclusion I draw about ratings applies only to the other half, and I must clearly state this every time I present findings. Learning to read that caveat into a chart and to communicate it honestly felt like a genuine step forward as an analyst.

The top 10 discount chart delivered a surprise. The highest-discounted products are not expensive electronics or premium appliances. They are small everyday items: a bottle opener, a keychain, crochet needles, and a pillowcase. The product with the single highest discount in the entire dataset (64% off) costs just KES 199. That is a powerful reminder that percentage discounts and absolute value are entirely different things, a lesson I learned from the data, not from a textbook

Average rating and average reviews by discount category

Finding that medium-discount products outperform high-discount ones on both measures
This final chart is the one I am most proud of, because it contradicts the most natural assumption in the entire dataset. I expected high-discount products to have the most reviews and the highest ratings. More discounts should mean more buyers, and more buyers should mean more reviews. The data said the opposite. Medium-discount products (20–40% off) had an average rating of 4.28 and 15.3 reviews. High-discount products rated only 3.61 and averaged 11.1 reviews. The correlation between discount percentage and reviews was just −0.14, essentially zero. Higher discounts do not drive customer engagement. Product quality does.

Products Analysed-115
Avg Current Price-1174
Avg Discount-36.96%
Avg Rating-3.89/5

How This Has Made Me a Better Analyst and a Better Thinker
Working through this project from raw CSV to finished dashboard gave me five concrete skills that I did not have before, and that I now use every time I open a spreadsheet.
1) Skills This Project Built

Diagnose the first scan for broken data before touching anything
Write self-explanatory formulas SUBSTITUTE, VALUE, ABS, IFS, AVERAGEIF
Trust the data, not your expectations correlation was −0.14, not what I hoped
Charts are not decoration every chart reveals what the table could not
Declare data gaps honestly 50% missing ratings must be stated. not hidden

The Spreadsheet That Taught Me to Think

Here I Started vs Where I finished
Started, finished 115 rows of messy data. A fully formatted Excel dashboard. Did not know VLOOKUP. Can clean, enrich, analyse, and visualise. Assumed data was neat. Know how to diagnose and fix real problems. Trusted percentages. Know how to check the numbers behind them

What This Project Actually Taught Me

Not just which function to use, but when and why
Not just how to build charts, but how to read and explain them
Not just Excel skills, but thinking skills

Things That Made It Real

Excel gave me the tools
The Jumia dataset gave me the practice
This course gave me the framework

I will carry these skills into every dataset, every report, and every decision I face from here on.

Data Analysis Setup: Tools, Installation, and Best Practices

Ephantus Macharia — Mon, 23 Mar 2026 06:38:00 +0000

In previous centuries, we used to decide as we always used to: based on a gut feeling, a coin toss or a prayer. However, we can not afford to guess in a world that is changing this rapidly. However, it is feared that the analysis of data removes humanity in the decision-making process- that it reduces individuals to statistics. I want to argue the opposite. Proper data analysis is the most understanding thing that you can do. It prevents the projection of personal prejudices on the world and makes one see people as they are, not as you think they are. It is not a de-humanizing of the process, it is simply a human element that has gotten right at last.

Below are various tools that will help you kickstart your journey of Data Analysis:

EXCEL INSTALLATION GUIDE

Step 1

Steps into Installaling Excel on windows

1.Go to the official page of MICROSOFT OFFICE Website:https://www.office.com/

2 . Sign in with your Microsoft Account.

Click install Office

4 Open the downloaded OfficeSetup.exe file.

5 Wait for the installation to complete.

6.After installation:

7 Open Microsoft Excel from the Start Menu.

8 Sign in to activate the software.

ANACONDA INSTALLATION GUIDE.

Steps into Installing Anaconda On windows

Anaconda-platforms is a tool developed to design to securely build, and deploy artificial intelligence and machine learning models, primarily using Python and open-source software.

Step 2

1 .Go to the official Anaconda website: https://www.anaconda.com

2 .Download the Anaconda Distribution for Windows.

3 .Open the downloaded .exe installer.

4 .Click Next → Agree to License.

5 .Choose Just Me installation.

6 .Select the installation location (default recommended).

7 .Click Install.

8 .After installation, click Finish.

9 .To verify installation:

10 .Open Anaconda Navigator from the Start Menu

Forem: Ephantus Macharia

Subqueries vs CTEs in SQL: Master Nested Queries and Write Cleaner, Smarter Code

Subqueries

The Classic Use Case

Subquery in the FROM Clause

Correlated Subquery

Using IN with a Subquery

CTEs (Common Table Expressions)

Basic Syntax

Rewriting Our First Example as a CTE

Chaining Multiple CTEs

Reusing a CTE

Recursive CTE For Hierarchical Data

Takeaways

How to Publish a Power BI Report and Embed It on a Website

A Step-by-Step Guide Using the Electronic Sales Data Dashboard

Introduction

Step 1 Create a Workspace in Power BI Service

How to do it:

Step 2

Upload and Publish the Report from Power BI Desktop

How to do it:

Step 3

How to do it:

Example embed snippet generated:

Step 4

Option A — Fixed-size embed (simplest)

Option B — Responsive embed (recommended)

Embedding a Specific Page

Report Pages Overview

Page 1 _ Dashboard

Page 2_ Profit Margin (City, Product)

Page 3 _ Geographical Sales Analysis

Key Insights & Best Practices

1. Use Premium Capacity for Scale

2. Apply Row-Level Security (RLS)

3. Schedule Data Refresh

4. Make the Embed Responsive

5. Control Which Page Loads First

6. Monitor Usage

7. Secure Sensitive Sales Data

Summary

Understanding Data Modelling in Power BI: Joins, Relationships, and Schemas.

Joins

Inner Join

Left Outer Join

Right Outer Join

Full Outer Join

Relationships

Filter Direction

Single direction

Schemas

Star Schema

Snowflake Schema

Flat Table

Concept : What it does, Where in Power BI

Conclusion

From confusion to clarity;How Excel-Data analysis has Transformed my skills

Introduction

The 6 Problems I Found in the Jumia Dataset

What This Taught Me

What Actually Surprised Me About Data Cleaning

The Real Meaning of Data Cleaning

Creating Meaning with Formulas Data Enrichment

What This Project Actually Taught Me

Things That Made It Real

Data Analysis Setup: Tools, Installation, and Best Practices