1. What is a star schema, and why use it?
A star schema separates business events in fact tables from descriptive dimensions used to filter and group them. Microsoft's Power BI guidance emphasizes consistent fact grain and clear relationships. The goal is a model whose calculations and filtering are understandable, not simply a diagram that resembles a star.
For our example, Sales contains one row per order line, while Product, Customer, and Date describe those events. Say the grain aloud: one order line, not one order and not one customer. That distinction determines whether summing a field is meaningful and whether a join can accidentally multiply values.
2. How can mixing grains produce the wrong total?
Suppose an order has two lines worth 60 and 40, and its order-level delivery fee is 10. If you repeat the fee on both lines and sum it, the report shows 20 instead of 10. The problem is the data model or aggregation contract, not the font or formatting of the card that displays it.
Choose a deliberate solution: model order-level facts separately, allocate the fee under a documented rule, or use a calculation that respects the order identity. Explain the tradeoff and test an order with one line, two lines, and a returned line. Do not hide the error with a blanket divide-by-two adjustment that happens to fit one sample.
3. When would you use a measure?
A DAX measure is evaluated in the query's context, making it useful for a value that must respond to a report's filters. A stored row-level calculation serves a different purpose. Before choosing, ask whether the desired result is a property of each row or an aggregation that should change when a user selects a period or product.
For this practice model, Sales[NetAmount] is a numeric amount already defined at order-line grain. The measure below adds it in the current context. Test the grand total, a single product, and a selected month. This example does not resolve currency conversion or returns automatically; those must be part of the business definition.
Net Sales = SUM(Sales[NetAmount])4. Why is an average of percentages often misleading?
Imagine one product generates revenue of 100 with profit of 20, while another generates revenue of 900 with profit of 90. Their margins are 20% and 10%, but the combined margin is 110 divided by 1,000, or 11%, not the unweighted average of 15%. State the intended denominator before choosing an aggregation.
Use a measure that divides aggregate profit by aggregate revenue under the intended filter context, and decide how a zero denominator should appear. Then test totals and subtotals using a tiny hand-calculated dataset. A total that differs from the average of displayed rows can be correct; explain the business meaning rather than forcing visual arithmetic.
5. How would you investigate a slow or incorrect report?
Separate incorrect source data, a problematic model relationship, a wrong calculation, and a slow query. Reduce the issue to one visual and one filter selection. Compare the expected rows and numbers against a small trusted extract. Record the freshness of that extract so a refresh delay is not misdiagnosed as a DAX defect.
For performance, measure where time is spent before rewriting everything. A report may be slow because it asks for too much detail, performs expensive calculations, or depends on a slow source. Explain the smallest experiment that distinguishes these cases. Removing business-critical logic just to make a visual faster is not an acceptable optimization.
A fifteen-minute dashboard validation exercise
Build a tiny sample with two orders, three lines, one return, and two dates. Write expected sales and margin results before opening the visual. Check no filter, one date, one product, and an empty selection. Add a deliberately duplicated dimension key and explain why the relationship or result becomes suspicious.
Practise describing the model to someone who does not know Power BI. A strong answer identifies grain, relationships, filter behavior, and reconciliation evidence. Use Cluegent during preparation to generate follow-up questions, but verify every numeric answer yourself. The linked SQL joins guide is a useful next step when duplicated rows are the source of incorrect totals.
Sources checked
These official references support the guide. Product details and technical documentation can change; check the linked source for current information.
Where Cluegent helps
Cluegent supports permitted live workflows with transcript context, typed prompts, screenshot-aware answers, resume context, custom response behavior, quick action buttons, and a private desktop overlay. It is most useful when you already understand the subject and need help staying structured under pressure.
Frequently asked questions
What should I explain before writing DAX?
Explain the business definition, fact-table grain, relevant relationships, and expected behavior under filters. Those determine whether the calculation is meaningful.
Should a total margin equal the average of row margins?
Not necessarily. A combined margin generally uses total profit divided by total revenue, which weights rows by revenue rather than averaging percentages equally.