Power BI and Microsoft Fabric for Beginners: Semantic Models, Lakehouses and Reports

Start with the reporting problem

A beginner can create several Fabric items successfully and still be unsure which one supplies a report. Understanding the responsibilities of storage, preparation, semantic modelling and presentation makes that system easier to debug. Start with three fictional registrations and follow them through the complete reporting path before introducing a larger dataset.

Core concepts to learn

Build a practice scenario

1. Create the three-row fictional registrations source and separate course and date tables.
2. Prepare the data, record its grain and validate course-key uniqueness before creating relationships.
3. Create the semantic model explicitly, select its tables and define the two reporting measures.
4. Build a summary and course breakdown, then add the fourth registration to test the source-to-report update path.

Use sample, authorised or fictional data. Do not publish credentials, business data, account numbers or customer information in a portfolio. If a task has financial, security or production impact, include a review or approval step before any change.

What good work looks like

Understand the three objects before building a report

A lakehouse is a place to organize data for analytical work, including files and tables. A semantic model adds the reporting meaning: relationships, measures, formats and the fields people use for analysis. A report is the set of pages and visuals through which readers explore that model. Giving all three objects the same display name does not make them the same component.

For a beginner, follow one record through the chain. A fictional course registration may first arrive in a source file, become a cleaned table row, contribute to an enrolment measure and appear in a monthly chart. When the chart is wrong, this chain provides a way to locate the issue instead of repeatedly changing colours or refreshing the browser.

Microsoft’s lakehouse documentation describes an automatically created SQL analytics endpoint for querying lakehouse tables. That does not imply an automatically created reporting model. Since September 2025, new lakehouses, warehouses and mirrored items no longer receive default semantic models automatically. Create the required semantic model explicitly and select the appropriate tables.

Build a small enrolment model with a clear grain

Use fictional tables for registrations, courses and dates. State that one registration row represents one student’s enrolment in one course on a particular registration date. Assign a RegistrationID and CourseID, and store the relevant amount as a numeric field. Avoid placing repeated course descriptions and several unrelated dates into a structure without first deciding what each row means.

For a control example, create three registrations: two for a Python course at 4,000 each, and one for an Excel course at 3,000. The expected registration count is three and the total is 11,000. The Python filter should show two registrations and 8,000. These deliberately small numbers let you verify the model without trusting a complex source extract.

Keep one row per course in the course dimension and relate it to the registrations through CourseID. A date dimension gives report authors a consistent calendar. Microsoft’s star-schema guidance explains the different roles of dimension and fact tables. In this exercise, use the dimension for course labels and the registration fact for counting and summing.

Add a duplicate course key intentionally in a separate practice copy. Observe how the model or relationship validation reacts, then repair the dimension. Do not solve a duplicate-key problem by adding more visual filters. Record the expected uniqueness rule so the next data load can be checked before the report is shared.

Make the transformation and semantic responsibilities visible

During data preparation, standardize date types, normalize course identifiers and decide how invalid records are handled. Keep rejected rows in a reviewable practice output with a reason, such as missing course key or invalid registration date. Silently dropping every problematic row may make a chart appear tidy while hiding a material completeness issue.

In the semantic model, define measures such as Registration Count and Registration Amount, with descriptions that identify the included records. If cancelled registrations are excluded, say so explicitly. Do not allow one page to sum gross registrations while another shows net registrations under the identical label Total Enrolments.

When adding a new source table, verify its inclusion in the semantic model. Microsoft’s current management guidance says there is no automatic table-and-view synchronization from the warehouse or SQL analytics endpoint source. A successful ingestion therefore does not guarantee that a new table is available to a report author.

A practical refresh and reconciliation sequence

1. Record the source extract date and the number of registration rows received.
2. Apply preparation rules and reconcile accepted rows, rejected rows and duplicates against the input.
3. Confirm that the reporting table contains the intended period and expected control totals.
4. Check the semantic model’s table selection, relationships and storage-mode-specific refresh behaviour.
5. Open the report with cleared filters, compare the overall totals, then repeat the course-level checks.

Now add a fourth registration worth 2,000 to the fictional source. The expected total becomes 13,000 and the expected count becomes four after the entire reporting path is current. If the lakehouse shows four rows but the report shows three, investigate the model and report stages. If the lakehouse itself still has three, the issue is earlier.

Keep the reporting cutoff visible in project notes. A daily management report does not need to pretend that every visual represents the present second. What matters is whether its agreed data window is complete, consistent and understandable.

Plan access and licensing separately from model design

Fabric capacity and per-user Power BI licensing serve different purposes. The ability to create a lakehouse does not automatically mean every colleague can view every report without the required license or permission. Consult the current Fabric licensing guidance for the intended author and reader scenario before sharing the exercise outside your own workspace.

Test with a representative reader account as well as the author account. Check access to the report and underlying semantic model, and validate any intended data restrictions. Keep sensitive source access separate from a beginner’s need to read a curated report. Do not use broad administrator permissions as evidence that ordinary viewers have the intended experience.

Beginner questions that prevent rework

Do I need a lakehouse for every Power BI report? No. Begin with the data and collaboration requirement. A small report may have a simpler suitable source path. Learning Fabric is valuable when you can explain which preparation, storage or collaboration need it addresses.

Why does a new table not appear in my report? Check the selected semantic model and whether that table was added to it. Also confirm permissions, supported storage mode and the relevant processing state. Recreating the whole report is rarely a useful first diagnostic step.

What should my portfolio demonstrate? Show the source-to-report path, data grain, three control totals, one deliberately introduced defect and its diagnosis. Include limitations and the person or process responsible for keeping the data current.

Official references

• Microsoft Fabric lakehouse overview
• Create and manage Power BI semantic models
• Star-schema guidance for Power BI
• Fabric licensing and capacity

Frequently asked question

What should a beginner practise after learning Power BI and Microsoft Fabric?

Build one small, documented exercise that uses the concepts safely, validate the result, and explain the decisions and limitations. Repeating this cycle makes learning more reliable than collecting disconnected tutorials.