Practical technology learning
Power BI Relationships: Check Row Meaning and Key Uniqueness First
Build confidence in a small model before decorating its charts. This exercise uses invented product IDs and sale-line quantities to check a simple one-to-many design. Its purpose is to connect table structure to an independently calculated result, rather than treating an automatically detected relationship as proof of correctness.
Describe the grain of both tables
Create a Products table with two rows: P101 and P102, each with a different display label. Create Sales with three separate sale lines: P101 quantity 2, P101 quantity 3 and P102 quantity 4. State that each Sales row represents one line, not one product.
Calculate the expected quantities independently: P101 has 5, P102 has 4 and the overall total is 9. These are synthetic teaching values. Keep the source rows and those expected results in a short review sheet.
Inspect the keys before creating the relationship
Check that Products contains one row per product ID and that the linked columns have compatible data types. Compare the Sales product IDs with the product list and identify any unmatched value before deciding how the report should present it.
In this intended design Products supplies the unique one-side key and Sales supplies the repeating many-side key. A repeated product ID in Sales is expected; a duplicate ID in Products is a different issue that needs investigation.
Review cardinality and the filtering path
Create or inspect the relationship deliberately. For this simple model, verify that filtering the product table can reach the relevant sale lines. Explain the chosen direction rather than switching settings until a chart changes.
Microsoft’s relationship guidance defines cardinality through the linked column values, including uniqueness on the one side. A different real-world business structure may require a different model. Do not select many-to-many solely to silence a duplicate-key problem in this fixture.
Check one product and then the whole result
Use a simple table visual or another transparent result view before complex formatting. Select P101 and compare the reported quantity with 5. Repeat for P102 and compare with 4. Clear the selection and compare the overall quantity with 9.
If a result differs, inspect the source rows, key values, relationship and active filters in that order. Do not change the expected answer to match the visual. Keep the initial fixture intact while trying one diagnostic change at a time.
Introduce controlled modelling problems
- Add a duplicate product key and explain why the intended unique-key contract fails.
- Add a sale line with an unmatched ID and decide how that case should be investigated.
- Change one linked column’s type in a disposable copy and review the mismatch.
- Restore the clean fixture and repeat the three expected totals.
- Document the model change separately from visual styling.
Keep the model explanation with the report
Record each table’s row meaning and the reason for its relationship. That note helps another learner review a later change without guessing from the diagram alone. Mango Engineers’ Power BI course includes modelling foundations; discuss the current learning sequence and entry requirements with the team.