Free 30-day beta access · no payment · progress saved
The business problem
A BI model imports duplicates, mixes grains and repeats calculations already stable in the database.
What you will be able to do
Explain grain, modelling and the roles of SQL, Power Query and DAX, then apply those principles to a SQL source query.
Define the grain
Distinguish facts and dimensions
Divide work across SQL, Power Query and DAX
Define refresh checks
Scope of this micro-course
This micro-course targets one focused skill. It does not replace a complete path or server administration training.
Prerequisites
JOIN and aggregations
No Power BI account required
Project and practice
8 verified exercises are available. A business project is included.
Guided theory · 6 micro-lessons
Understand how to prepare a source for Power BI.
This module explains concepts and architecture decisions before connecting the tool. It includes no Power BI interface or report publishing; the SQL exercises apply the theory.
01
Define the grain before the columns
Problem. An export mixes one row per order with one row per product, doubling amounts in the model.
Principle. Write one sentence that defines a row: an order, order line, customer or month. Then select only columns compatible with that grain.
Check to understand. Compare distinct identifiers with the row count.
02
Separate facts and dimensions
Problem. Customer and product attributes are repeated in every sale, making corrections and relationships fragile.
Principle. Prepare a fact table at event grain and dimensions with stable keys. Every many-to-one relationship must be explainable and testable.
Check to understand. Check dimension key uniqueness and orphan fact keys.
03
Build a stable SQL contract
Problem. A refresh breaks because a SELECT * column changes name, type or disappears.
Principle. List columns explicitly, use stable business aliases and cast ambiguous types in SQL. The result becomes a contract between the database and BI model.
Check to understand. Check names, types, useful order, NULL values and known samples.
04
Divide work across SQL, Power Query and DAX
Problem. The same business rule is calculated in three layers and returns three answers.
Principle. Keep shared source filters, joins and rules in SQL. Use Power Query for import transformations and DAX for measures that depend on report context.
Check to understand. Document the owner of each calculation and remove duplicates.
05
Prepare dates and refresh
Problem. The model reloads all history and mixes order, payment and delivery dates.
Principle. Choose the business date, expose a usable date key and make period boundaries explicit. A refresh filter should remain deterministic and indexable.
Check to understand. Test a full period with an inclusive start and exclusive end.
06
Reconcile before publishing
Problem. The dashboard looks correct, but its revenue does not match the source system.
Principle. Return volume, total, duplicate, missing-value and status checks with the source query. Compare them after import before interpreting a KPI.
Check to understand. Keep a reference total, extraction date and the query that produced it.
Focused path
Practical exercises
Content remains centralised: completing an activity here also updates the path that contains it.
01
Avoid double counting after several joins
Calculate customer revenue without multiplying lines when an order has multiple items and multiple payments.