SQL for Analytics
For analysts writing SQL, build reliable SELECT queries by controlling clause logic, NULL handling, explicit columns, dates, and deterministic ordering.
Free module
Complete module 1 without creating an account
The complete content is available on this page.
Start module 1 freeComplete and no account required · SQL for Analytics
Module 1 · complete and free
SQL for Analytics
It opens here, with no account or page change.
About this course
This course suits analysts who need query results that remain understandable as data changes. You will reason about SQL’s logical order, handle missing values deliberately, select named columns, and add a stable tie-breaker for ordering. At work, filters and time windows are easier to audit. SQL clauses must be written in the fixed order SELECT–FROM–WHERE–GROUP BY–HAVING–ORDER BY–LIMIT, yet the database executes them in a different logical sequence, which explains why a column alias defined in SELECT cannot be referenced inside WHERE. Replacing SELECT * with an explicit column list protects downstream pipelines from silent breakage when upstream schemas change, and using IS NULL, IS NOT NULL, and COALESCE makes NULL handling deliberate rather than accidental. Deterministic results also require an ORDER BY with a tiebreaker column, and half-open date ranges such as >= start AND < next_start prevent subtle timestamp bugs that BETWEEN can introduce. INNER JOIN returns only rows matched on both sides, LEFT JOIN preserves every row from the left table and fills unmatched right-side columns with NULL, and an anti-join—a LEFT JOIN filtered with WHERE right_table.id IS NULL—surfaces rows that have no counterpart in the second table. Before writing any join, identifying the cardinality (1:1, 1:N, or N:M) is essential because the result inherits the cardinality of the right-hand side, meaning a customer with five orders will appear five times after an INNER JOIN to an orders table. This module teaches you how to summarize raw event and transaction data into meaningful business metrics using SQL. You will practice GROUP BY, HAVING and conditional aggregation to build cohort tables and multi-step funnels. By the end, you will be able to answer questions like "how many users signed up last month and came back?" and "where do users drop off in our checkout flow?". Window functions such as ROW_NUMBER(), RANK(), SUM() OVER(), LAG(), and LEAD() compute rankings, running totals, and period-over-period comparisons across related rows without collapsing the result set the way GROUP BY does; PARTITION BY defines independent groups, ORDER BY inside OVER() controls row order within each partition, and the ROWS BETWEEN frame clause narrows which rows contribute to each calculation. Because window functions are evaluated after WHERE, any filter on their output must be placed in an outer query wrapped around a CTE. Slow queries typically stem from full table scans, insufficiently filtered joins, or repeated computation, and running EXPLAIN ANALYZE reveals which of these is occurring by exposing sequential scans, join strategies, and gaps between estimated and actual row counts. Indexes accelerate filtering and joining on large, high-selectivity columns but add overhead to write-heavy tables and offer little benefit on low-cardinality columns; plain views provide reusable abstraction without any speed gain, while materialized views and pre-aggregated tables trade acceptable staleness for fast reads.
What you'll learn
- By the end of this module, you'll be able to predict which clause aliases are invisible to `WHERE` by applying the logical execution order SELECT–FROM–WHERE–GROUP BY–HAVING–ORDER BY–LIMIT to a given query.
- By the end of this module, you'll be able to write `WHERE` filters that correctly handle `NULL` values using `IS NULL`, `IS NOT NULL`, and `COALESCE`, so that rows with missing data are included or excluded intentionally.
- By the end of this module, you'll be able to construct a deterministic `ORDER BY` clause by appending a unique tiebreaker column to any sort key that does not guarantee a single row order.
- By the end of this module, you'll be able to select between `INNER JOIN`, `LEFT JOIN`, and anti-join patterns by stating the cardinality relationship between two tables before writing the query.
- By the end of this module, you'll be able to detect row duplication in a joined result set by comparing pre- and post-join row counts and verifying join-key uniqueness on the right-hand table.
- By the end of this module, you'll be able to prevent fan-out inflation in aggregated metrics by pre-aggregating a many-side table in a subquery before joining it to the anchor table.
- Write GROUP BY queries with multiple grouping keys and aggregate functions
Roles this course opens up
Typical job titles that ask for this skill.
See live job listings (129,985)How access works
Start 1 course for free. Upgrade when you're ready to unlock the rest.
1 course free
Start one Academy course immediately. No credit card required. Test Academy before committing.
Start freeFull course + every Academy tool
All modules, certificate on completion, career coach, interview prep and unlimited course generation — across every course.
See Premium+ plansOther courses you might like
Account Management Fundamentals
For account managers taking over a client relationship: turn handover notes into a clear account brief, credible next steps and a communication rhythm.
Accounting Fundamentals
Build a sound accounting habit from the start: learn how transactions change assets, liabilities and equity, then record them with clear double-entry logic.
Administrative Management
For administrators and team coordinators: build a filing system people can follow, with clear folders, consistent names and one reliable version of every document.