Home / Topics

SQL for Business Analysts

SQL lets a business analyst answer questions about data without waiting for someone else to run a report. You don't need to become a developer. A few query patterns cover most BA work: pulling a list, filtering it, joining two tables, counting and totalling, and checking the data for gaps and duplicates. These tutorials teach those patterns on the same small shop database, one idea at a time.

Why a BA needs SQL

Requirements are only as good as the data behind them. Before you write "customers can see their last 10 orders", it helps to check how many orders a customer really has. Before sign-off, you can check that a new report's totals match the source. SQL is how you do that yourself, in minutes. It also makes conversations with developers easier, because you can talk about tables, keys and joins in their terms.

A suggested order

Start with SELECT and WHERE: choosing columns and filtering rows. Then joins, which most people find hardest: INNER JOIN first, then LEFT JOIN, then the lesson comparing all join types, and the one on why joins sometimes create duplicate rows. Next come GROUP BY, HAVING and COUNT DISTINCT for summaries. After that, pick what your work needs: CASE WHEN for labels, NULL handling, date filters, subqueries and CTEs, and window functions like ROW_NUMBER, RANK and running totals.

The last group of lessons is the most BA-specific: finding duplicates, finding missing records, profiling a table, data quality checks, validating requirements against data and reconciling totals. These are the queries you will reuse on real projects.

Good habits

Run a COUNT(*) before and after a join; if the number jumps, the join is creating duplicates. Remember that NULL is not equal to anything, not even NULL, so use IS NULL to find it. And SQL dialects differ in small ways (for example LIMIT vs TOP, and date functions), so check which database your company uses before copying a query into it.