From data sources, to ETL and your semantic layer - learn how key BI components come together in Power BI.
Thin reports: What are they and why should you care?
Find out why using a shared dataset allows organisations to have a single source of truth with the help of thin reports.
Shared Datasets have been around for quite a while now. In June 2019, Microsoft announced a new feature called Shared and Certified Datasets with the mindset of supporting enterprise-grade BI within the Power BI ecosystem. In essence, the shared dataset feature allows organisations to have a single source of truth across the organisation serving many reports.
A Thin Report is a report that connects to an existing dataset on Power BI Service using the Connect Live connectivity mode. So, we basically have multiple reports connected to a single dataset. Now that we know what a thin report is, let’s see why it is best practice to follow this approach.
Prior to the Shared and Certified Datasets announcement, we used to create separate reports in Power BI Desktop and publish those reports into Power BI Service. This approach had many disadvantages, such as:
- Having many disparate islands of data instead of a single source of truth.
- Consuming more storage on Power BI Service by having repetitive table across many datasets
- Reducing collaboration between data modellers and report creators (contributors) as Power BI Desktop is not a multi-user application.
- The reports were strictly connected to the underlying dataset so it is so hard, if not totally impossible, to decouple a report from a dataset and connect it to a different dataset. This was pretty restrictive for the developers to follow the Dev/Test/Prod approach.
- If we had a fairly large report with many pages, say more than 20 pages, then again, it was almost impossible to break the report down into some smaller and more business-centric reports.
- Putting too much load on the data sources connected to many disparate datasets. The situation gets even worst when we schedule multiple refreshes a day. In some cases the data refresh process put exclusive locks on the the source system that can potentially cause many issues down the road.
- Having many datasets and reports made it harder and more expensive to maintain the solution.
In my previous blog, I explained the different components of a Business Intelligence solution and how they map to the Power BI ecosystem. In that post, I mentioned that the Power BI Service Datasets map to a Semantic Layer in a Business Intelligence solution. So, when we create a Power BI report with Power BI Desktop and publish the report to the Power BI Service, we create a semantic layer with a report connected to it altogether. By creating many disparate reports in Power BI Desktop and publishing them to the Power BI Service, we are indeed creating many semantic layers with many repeated tables on top of our data which does not make much sense.
On the other hand, having some shared datasets with many connected thin reports makes a lot of sense. This approach covers all the disadvantages of the previous development method; in addition, it decreases the confusion for report writers around the datasets they are connecting to, it helps with storage management in Power BI Service, and it is easier to comply with security and privacy concerns.
At this point, you may think why I say having some shared datasets instead of having a single dataset covering all aspects of the business. This is actually a very interesting point. Our aim is to have a single source of truth available to everyone across the organisation, which translates to a single dataset. But there are some scenarios in which having a single dataset does not fulfil all business requirements. A common example is when the business has strict security requirements that a specific group of users and the report writers cannot access or see some sensitive data. In that scenario, it is best to create a completely separate dataset and host it on a separate Workspace in Power BI Service.
Options for creating thin reports
We currently have two options to implement thin reports:
- Using Power BI Desktop
- Using Power BI Service
As always, the first option is the preferred method as Power BI Desktop is currently the predominant development tool available with many capabilities that are not available in Power BI Service such as the ability to see the underlying data model, create report level measures and create composite models, just to name some. With that, let’s quickly see how we can create a thin report on top of an existing dataset in both options.
Creating Thin Reports with Power BI Desktop
Creating a thin report in the Power BI Desktop is very easy. Follow the steps below to build one:
- On the Power BI Desktop, click the Power BI Dataset from the Data section on the Home ribbon
- Select any desired shared dataset to connect to
- Click the Create button
- Create the report as usual
- Last but not least, we Publish the report to the Power BI Service
As you may have noticed, we are connected live from the Power BI Desktop to an existing dataset on the Power BI Service. As you can see the Data view tab disappeared, but we can see the underlying data model by clicking the Model view as shown on the following screenshot:
Now, let us have a look at the other option for creating thin reports.
Creating Thin Reports on Power BI Service
Creating thin reports on the Power BI Service is also easy, but it is not as flexible as Power BI Desktop is. For instance, we currently cannot see the underlying data model on the service. The following steps explain how to build a new thin report directly from the Power BI Service:
- On the Power BI Service, navigate to any desired Workspace where you would like to create your report and click the New button
- Click Report
- Click Pick a published dataset
- Select the desired dataset
- Click the Create button
- Create the report as usual
- Click the File menu
- Click Save to save the report
This is it. You have it.