Power BI / Basic: analytical and modeling foundations / Lesson 1

Desktop, service and analytical contracts

Separate data preparation, semantic modeling, report interaction and service distribution before interpreting a number on a Power BI page.

About 4 min readContent reviewed 2026-10-28

On this page

Lesson goals

Distinguish Desktop authoring from service collaboration and refresh.
Define grain, metric meaning and expected results.
State licensing and execution boundaries accurately.

Separate the artifacts

Power BI Desktop is a Windows authoring application used to prepare data, build semantic models and design reports. The Power BI service adds hosted collaboration, distribution and refresh capabilities within the organization’s configuration. A semantic model defines tables, relationships and calculations; a report presents interactive pages using that model. A service dashboard has its own tile-based behavior and is not simply another name for a Desktop report page. Name the artifact under discussion before diagnosing it: a correct visual layout cannot repair an incorrect model, and a published report is not proof of refreshed data.

Define the business question

The course uses a synthetic sales-line table where each row represents one order line. A quantity and unit price belong to that line, and line revenue is their product before any hypothetical returns or tax. The question is total line revenue under a documented selection. This definition rules out accidentally adding unit prices or counting order lines as orders. The first record shows the analytical contract without connecting to a source. Keep currency, time zone, canceled transactions and historical price treatment explicit in a real metric specification; otherwise two correct formulas can answer different questions.

text A metric contract before a visual

grain: one synthetic order line
inputs: ProductKey, Quantity, UnitPrice, OrderDate
metric: sum of Quantity * UnitPrice over included lines
exclusions: tax, returns and exchange rates are outside this fixture

The record is a teaching definition, not a connected dataset or a claimed business result.

Establish a small expected-result oracle

An expected-result oracle is an independently understandable answer used to review the model. Three lines with quantities 2, 1 and 3 and unit prices 10, 20 and 10 produce revenue 70. The second example calculates that answer in Python using integers. It does not run DAX or reproduce the Power BI engine. A small oracle makes later filter and total behavior testable: product A contributes 50 and product B contributes 20 in the shared fixture. Preserve row identities so a surprising number can be traced back to included facts rather than judged by appearance.

python Synthetic revenue oracle

lines = [("A", 2, 10), ("B", 1, 20), ("A", 3, 10)]
print(sum(quantity * price for _, quantity, price in lines))
print(sum(quantity * price for product, quantity, price in lines if product == "A"))

Expected output

70
50

70 and 50 are exact results for public in-memory rows. No Power BI file, service or data source is opened.

Keep evidence proportional

All DAX, M, model diagrams and GUI procedures remain unexecuted runnable:false examples. Only self-contained standard-library Python models run locally with synthetic data. A matching Python oracle does not prove the DAX expression, relationships, refresh or RLS behave correctly in Power BI. This distinction gives learners a concrete review plan: verify source rows, preparation, model, calculations, visual context, freshness and access as separate claims. The course assumes an import-model learning context unless another mode is explicitly discussed and avoids claiming a particular Desktop build or service capacity has been tested.

Common errors and fixes

A report page is treated as the semantic model

Why it happens: Presentation and calculation responsibilities were conflated.
How to fix it: Inspect tables, relationships and measures separately from visual layout.
Prevent it next time: Name the artifact and evidence boundary in reviews.

Line counts are labeled as order counts

Why it happens: The fact-table grain was not defined.
How to fix it: Use the documented order identifier and appropriate distinct-count contract.
Prevent it next time: Write grain and exclusions before authoring measures.

Desktop access is assumed to include unrestricted service sharing

Why it happens: Licensing, workspace permissions and capacity were ignored.
How to fix it: Check official feature entitlement and access requirements for the intended scenario.
Prevent it next time: Keep pricing and entitlement claims dated and separate from offline lessons.

Check your understanding

1. Why does summing the three unit prices produce the wrong revenue?

Show worked solution

UnitPrice is a rate at line grain, while revenue requires multiplication by each line’s quantity before summing. Prices10,20,10 sum to40, but the documented line revenue is20+20+30=70. The formula must follow the metric definition; formatting the wrong40 as currency cannot repair its meaning.

2. The Python oracle returns70. What Power BI claims remain unverified?