One of the best ways I've found to learn a technology is to build something with it.
Recently, I decided to spend some time in Power BI using Microsoft's AdventureWorks sample database. Rather
than focusing on advanced analytics or complex visualizations, I wanted to create a simple sales dashboard
that answered a few basic business questions.
How much revenue have we generated?
How many orders contributed to that revenue?
Which product categories generate the most sales?
Those questions became the foundation of the dashboard.
The first step was connecting Power BI Desktop to a local SQL Server instance hosting the AdventureWorks
database. Rather than importing every table available, I selected a small group of sales and product tables
that would support the reporting requirements.
The data model included sales orders, sales order details, customers, territories, products, product
subcategories, and product categories.
Before building a single visual, I spent time validating relationships within the model. One of the most
important relationships connected product information to sales order details. Without that connection,
product category reporting would not have produced accurate results.
Once the model was in place, I created my first measure.
Total Revenue simply summed the LineTotal values from the sales order detail table.
That measure became the first KPI displayed on the dashboard and answered a simple but important question:
How much revenue exists within the dataset?
From there, additional measures were added to support reporting and analysis.
The next visual focused on revenue by product category.
As soon as the chart was connected to the revenue measure, the dashboard began revealing insights. Bikes
represented the largest share of revenue by a considerable margin, while categories such as accessories and
clothing contributed significantly less.
One of the most valuable lessons came from dashboard interaction.
Selecting Bikes immediately changed the revenue card and exposed how Power BI filter context works. The same
measure that originally answered "How much revenue do we have?" was now answering "How much revenue came
from Bikes?"
That distinction helped reinforce one of Power BI's most important concepts. Measures are not simply
calculations. They are calculations evaluated within a specific context.
Another lesson came while building an order-related metric.
Initially, I expected an order measure to behave the same way as the revenue measure. When it didn't, I was
forced to take a closer look at where the data was coming from and how filter context was flowing through
the model. That small troubleshooting exercise ended up being more educational than creating the chart
itself.
Once the dashboard was functioning as expected, it was published to the Power BI Service and embedded within
a dedicated Power BI Lab Team site in SharePoint.
The dashboard itself remains relatively simple, but that was intentional. The goal was not to build a
production-ready analytics platform. The goal was to better understand data modeling, relationships,
measures, filter context, and report interactivity.
Sometimes the most valuable lessons come from small projects.
A revenue card, a product category chart, and a few measures were enough to provide a useful reminder of how
much happens behind the scenes before a dashboard can answer even the simplest business questions. 🐦🐦