Lesson 10 of 11 · 26 min

Building BI-ready datasets

By the end of this lesson you can design a dataset for a BI tool (grain, keys, attributes, additive measures, flags), build it with pre-aggregated CTEs that cannot fan out, and publish it as a clearly named view.

A BI-ready dataset is a table or view that a dashboard tool (Power BI, Tableau, Looker Studio, Metabase …) reads directly. The person using it will filter, group and sum its columns with clicks, not SQL, so the dataset has to make the right answer the easy one. A checklist:

  • One declared grain, unique: one row per day × channel, one row per customer. Put it in the name or the description, and test it.
  • Keys and readable attributes: the date as a real date, names rather than codes (channel_name, not channel_key), and the attributes users will filter by.
  • Additive measures (orders, units, net_sales, returned_net_sales) rather than ratios. The tool can compute net_sales / orders at any level; a stored average order value would be summed or averaged incorrectly.
  • Special cases resolved explicitly: guest checkouts labelled ('Guest checkout' instead of a NULL region), test accounts excluded, missing values as 0 where 0 is the truth.
  • Clear, stable names: lower_snake_case, units in the name when ambiguous (_sar, _pct), a prefix that marks the object as published for reporting (rpt_).
Included with a Formula Quest membership

This lesson, its 4 graded exercises and every other Members lesson in SQL Quest come with a Formula Quest membership that includes SQL (Single Quest with SQL selected, Quest Trio including SQL, or Quest Unlimited), or with SQL access from your organization.

Free to everyone: all of SQL Foundations and Retrieving and Filtering Data, the first lesson of every track, the playground, the dataset library and the SQL reference. See free lessons