Hello! Welcome to the first lesson in our "Advanced SQL for Business Analytics" module. Your goal is to pivot into data analysis and business intelligence, and a deep, practical understanding of SQL is the bedrock of that ambition.
Given your background, you're already comfortable writing moderately complex SQL queries. This lesson builds on that foundation. We'll focus on mastering one of the most fundamental and powerful SQL concepts: JOIN clauses. By the end of this session, you will be able to combine multiple tables using various JOIN types to construct the kind of comprehensive business reports that analysts build every day.
In the real world, data is almost never stored in a single, massive table. For efficiency and integrity, it's split across multiple related tables. JOINs are the tool we use to piece that data back together to answer meaningful questions.
Why We Need to Join Tables
Imagine you're an analyst at an e-commerce company. You have one table with shipment data (dates, amounts, product IDs) and another table with product details (product IDs, names, categories). If your manager asks, "What were the total sales for our 'Choco Bars' category?", you can't answer that with either table alone. You need to combine them. This is the core purpose of a JOIN.
To see a practical example of this scenario, please watch the first couple of minutes of the following video.
SQL Joins - Beginner to PRO Masterclass with 10 Examples
This video from Chandoo's YouTube channel introduces the concept of JOINs using a clear, business-oriented example with a chocolate sales database.
Watch the segment from the beginning until 02:19. Pay attention to how the speaker explains the need to combine the shipments and products tables to answer a simple business question.
The Foundation of Joins: Primary and Foreign Keys
As you'll know from your computer science background, relational databases are built on relationships. These relationships are formally defined using primary keys and foreign keys.
- A primary key is a column (or set of columns) that uniquely identifies each row in a table. For example,
product_idin aproductstable. - A foreign key is a column in one table that refers to the primary key in another table. For example, the
product_idin ashipmentstable is a foreign key that links to theproductstable.
These keys are the "bridges" that allow us to JOIN tables together accurately. To quickly refresh these concepts, please read the first part of the following article.
This article from CelerData provides a concise explanation of primary and foreign keys and why JOINs are necessary.
Read the sections titled 'What Are Primary and Foreign Keys?' and 'Why Are Joins Necessary in SQL?'. This should take about 5 minutes.
An Entity-Relationship Diagram (ERD) is a visual map of a database's tables and their relationships. As an analyst, reading an ERD is a crucial skill for understanding how to get the data you need.

Look at the ERD above. If you wanted to find the salary for each employee in the "Marketing" department, you can see you'd need to link employees -> dept_emp -> departments, and also employees -> salaries. The common columns like emp_no and dept_no are what you would use in your JOIN conditions.
The Different Types of SQL Joins
There isn't just one type of JOIN. Depending on the question you're asking, you'll need to choose the right one. The main types are INNER JOIN, LEFT JOIN, RIGHT JOIN, and FULL OUTER JOIN.
The following visual "cheat sheet" is an excellent reference for understanding how these JOINs work. The Venn diagrams are particularly intuitive.
Now, let's dive into the specifics of each type.
SQL JOINS Tutorial With Practice Exercises
This tutorial from DataLemur provides clear definitions and examples for the four main JOIN types.
Read the section titled '4 Types of SQL Joins', which covers INNER, LEFT, RIGHT, and FULL OUTER JOINs. Focus on understanding the description and the logic for each type. This should take about 10 minutes.
Let's summarize the key distinctions:
-
INNER JOIN(or justJOIN): This is the most common type. It returns only the rows where the key exists in both tables. Think of it as the intersection of two sets.- Business Question: "Show me all shipments that have a matching product in our product catalog."
-
LEFT JOIN(orLEFT OUTER JOIN): This returns all rows from the left-hand table and the matched rows from the right-hand table. If there's no match, the columns from the right-hand table will beNULL.- Business Question: "Show me all our products, and for those that have been shipped, show the shipment details."
-
RIGHT JOIN(orRIGHT OUTER JOIN): This is the mirror image of aLEFT JOIN. It returns all rows from the right-hand table. As the article mentions, this is less common because you can almost always rewrite it as aLEFT JOINby swapping the table order, which is often more intuitive. -
FULL OUTER JOIN: This returns all rows when there is a match in either the left or the right table. It's essentially a combination of aLEFTandRIGHT JOIN. If there's no match, the missing side's columns will beNULL.- Business Question: "Show me a complete list of all employees and all company-owned devices, matching them up where possible, but also showing employees with no device and devices with no assigned employee."
A Powerful Pattern: The Anti-Join
A very common and useful analytical task is to find things that didn't happen. For example, which customers haven't made a purchase? Which products have never sold? You can answer this using a LEFT JOIN combined with a WHERE ... IS NULL clause. This is often called an "anti-join."
Watch this segment to see exactly how it's done.
SQL Joins - Beginner to PRO Masterclass with 10 Examples
The 'SQL Joins' video by Chandoo also demonstrates the powerful 'anti-join' pattern.
Watch the segment from 16:48 to 19:23. The speaker explains how to find products that have never been sold using a LEFT JOIN and a WHERE IS NULL condition.
Test your understanding!
You are an analyst for a subscription service. You have two tables: customers (with customer_id, name) and subscriptions (with subscription_id, customer_id, plan_type).
Which JOIN type would you use for each of the following business questions?
- Generate a list of all customers who have an active subscription.
- Create a report showing every single customer in your database, along with their subscription plan if they have one.
- Identify all customers who have never subscribed to a plan.
Show answer
INNER JOIN: You only want customers who appear in both thecustomersandsubscriptionstables.SELECT c.name, s.plan_type FROM customers c INNER JOIN subscriptions s ON c.customer_id = s.customer_id;LEFT JOIN: You want every customer (from thecustomerstable), regardless of whether they have a subscription.SELECT c.name, s.plan_type FROM customers c LEFT JOIN subscriptions s ON c.customer_id = s.customer_id;LEFT JOINwithWHERE ... IS NULL(Anti-Join): You start by getting all customers and their potential subscriptions, then filter for the ones where the subscription information isNULL.SELECT c.name FROM customers c LEFT JOIN subscriptions s ON c.customer_id = s.customer_id WHERE s.subscription_id IS NULL;
Constructing Reports by Joining Multiple Tables
Business questions are rarely answered by joining just two tables. To build a comprehensive report, you'll often need to chain several JOINs together. The syntax is straightforward: you just add another JOIN clause after the previous one.
The key is to use table aliases (like s for shipments and p for products) to keep your query readable.
Watch this short clip to see how to join three tables to answer a more complex question.
SQL Joins - Beginner to PRO Masterclass with 10 Examples
Let's return to the 'awesome chocolates' database to see how to combine three tables in a single query.
Watch the segment from 07:35 to 09:22. Notice how the query joins shipments to people and then also to products to filter on criteria from all three tables.
This ability to link multiple data sources is what allows you to build powerful reports. In a real-world project, you would take this a step further, often using the joined data as a base for aggregations and further calculations.
The following video shows a real data analyst portfolio project. While it uses some techniques we'll cover in the next lesson (like CTEs), focus on how the analyst first creates a "base query" by joining multiple tables (fact_sales, dim_customer) to gather all the necessary raw data before performing any analysis.
SQL Data Analyst Portfolio Project | Like I Do in My Real Projects
In this video from 'Data with Baraa', you'll see how multiple JOINs form the foundation of a complex customer report.
Watch the segment from 58:13 to 1:04:15. Pay close attention to the first step, called 'retrieving the core columns' or 'base data'. See how LEFT JOIN is used to combine fact and dimension tables, and how columns from both tables are selected to create a unified dataset ready for analysis. Don't worry about the CTE syntax for now; just focus on the JOIN logic.
This is exactly how professional data analysts work: they identify the business question, map out the required tables (often using an ERD), and then write JOINs to create a single, logical dataset that they can then analyze.
Conclusion
In this lesson, we solidified your understanding of SQL JOINs, a critical skill for any data analyst.
Key Takeaways:
- Purpose:
JOINs are used to combine rows from two or more tables based on a related column, typically a primary/foreign key relationship. - Types: The four main types (
INNER,LEFT,RIGHT,FULL OUTER) serve different analytical needs, from finding exact matches to including all data from one or both tables. - Anti-Join Pattern: Using a
LEFT JOINwith aWHERE ... IS NULLcondition is a powerful way to find records that do not have a match in another table. - Reporting: Chaining multiple
JOINs together is the standard method for building comprehensive datasets that form the basis of business reports and analyses.
In the final video, you saw the analyst organizing their query with a WITH clause, creating something called a Common Table Expression (CTE). This is a technique for making long, complex queries (like those with multiple joins and aggregations) much more readable and manageable.
Next Lesson Preview:
In our next lesson, we will dive deep into Common Table Expressions (CTEs) and CASE statements. You'll learn how to use these tools to implement complex business logic and bring structure and clarity to your analytical queries, building directly on the multi-table JOINs you practiced today.