Microsoft Fabric: Use Copilot to Generate Data Model Synonyms

Microsoft Fabric: Use Copilot to Generate Data Model Synonyms

One of my older posts explains how to enable Copilot on Fabric and how to use Copilot to generate Power BI reports. In this post, I aim to explain yet another use case for Copilot that can help us to make a better and more useful semantic model in Power BI using synonyms. In an old post published in May 2016, I explained how to use Power BI synonyms to take our Power BI Q&A experience to another level. In that post, I explained how we could use synonyms to translate data model objects in different languages so the end-user could ask questions in their native language and get the results in Power BI. That was such a cool use case for synonyms, I suppose, wasn’t it? Fast track to December 2023, I believe the Q&A is still one of the coolest Power BI features that stands out when demoing the solutions to the customers; therefore, it makes absolute sense to use synonyms to improve the Q&A‘s efficiency and accuracy. This blog post explores the possibility of using Copilot to define synonyms in Power BI Desktop.

Prerequisites

As explained here, we first need to enable Copilot on Fabric Service. Please note that the technique explained in this post requires either Power BI Premium Capacity or at least F64 Fabric capacity and won’t work on PPU, Embedded capacities, Fabric capacities smaller than F64 or Fabric Trial (FT) capacities.

We also need to have the latest version of Power BI Desktop installed on our machine. With that, let’s begin.

Using Power BI Copilot to generate synonyms

While defining synonyms for the semantic model objects significantly helps with the Q&A experience, it is still a cumbersome process if done manually. So, if we meet the prerequisites, we can summon Copilot to the rescue. Follow these steps after opening a Power BI file in Power BI Desktop:

  1. Ensure you’re signed into Fabric service with your account
  2. Click the Insert tab
  3. Select the Q&A visual
  4. On the Q&A visual, click the Q&A Setup button shown with a gear icon
  5. On the Q&A Setup window, you must see a message offering to “Improve Q&A with synonyms from Copilot” on top of the window; click the Add synonyms button

The following image shows the preceding steps:

Improve Q&A with synonyms from Power BI Copilot in Microsoft Fabric
Improve Q&A with synonyms from Copilot
Continue reading “Microsoft Fabric: Use Copilot to Generate Data Model Synonyms”

Quick Tips: Find Power BI Desktop Local Port Number with Model Explorer

Quick Tips: Find Power BI Desktop Local Port Number with Model Explorer

In March 2018, I wrote a blogpost called Four Different Ways to Find Your Power BI Desktop Local Port Number. Last week, Zoe Doughlas from Microsoft left a comment reminding me of a fifth method to get the port which encouraged me to write this quick tip. Thanks to Zoe!

As the name suggests, the blog was about finding Power BI Desktop’s local port number. If you do not have any clue what I mean by local port number, I strongly suggest reading that blog.

This blog focuses on yet another method that wasn’t available back then. Indeed, it is a new feature added to the October 2023 release of Power BI Desktop. This is a Quick Tip so let’s jump straight to the topic and learn how we find the port number (and more) in Power BI Desktop (Oct 2023 and later releases).

Prerequisites

As mentioned, this new feature was added to Power BI Desktop’s October 2023; therefore, we must install that release on our local machine. Indeed, the October 2023 release was packed with many other features, including the Model Explorer (the topic of this blog) and the ability to define calculation groups directly in Power BI Desktop. Many of these features are still in preview; hence, they require enabling.

The following few steps explain how to enable Preview Features in Power BI Desktop:

  1. Open Power BI Desktop and click Settings (the gear icon) from the right pane
  2. On the Options page, from the GLOBAL section, click the Preview features tab
  3. Enable the desired features; for this blog, we need the Model explorer and Calculation group authoring
  4. Click OK

The following image shows the above steps:

Enabling Preview Features in Power BI Desktop
Enabling Preview Features in Power BI Desktop

Depending on the selected features, you may need to restart your Power BI Desktop to allow them to enable.

Looking at the above image, some of you may ask “Soheil, are you using an older version of Power BI Desktop?” and I am glad you asked. The answer as always is “It depends”. And, this time it depends on the timing of writing this blog which is early December 2023, and the fact that Power BI Desktop November 2023 was released a couple of weeks ago, therefore, Power BI Desktop October 2023 is kind of OLD! And, YES! I installed Power BI Desktop Nov 2023 for the sake of writing this blogpost.

Continue reading “Quick Tips: Find Power BI Desktop Local Port Number with Model Explorer”

Thin Reports, What Are They, Why Should I Care and How Can I Create Them?

Thin Reports in Power BI

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.

Continue reading “Thin Reports, What Are They, Why Should I Care and How Can I Create Them?”

Demystifying “DirectQuery” and “Connect Live”

The terms “DirectQuery” and “Connect Live” are somehow confusing. I saw lots of people are using both terminologies as alternatives. But, the context of “DirectQuery” and “Connect Live” are very different indeed. Therefore, if use a a terminology when we’re talking about a different context then the whole situation might get quite confusing. in this post I try to explain the differences and make it more clear to prevent using a wrong terminology and make sure everyone is on the same page when we’re referring to “DirectQuery” or “Connect Live”.

When we use the “DirectQuery” terminology we are actually talking about connecting from Power BI Desktop instance to an RDBMS type of data source like SQL Server DB or Oracle DB.

There are two types of data connections when we’re connecting to RDBMS like SQL Server or Oracle DB from Power BI Desktop:

  • Import Data: which literally loads data into the underlying model to make it available in memory
  • DirectQuery: which doesn’t load data into model. Instead, it runs multiple concurrent queries on the RDBMS side (data source side) and gets the results. This is good to support real-time data processing.

Note: The same principal applies to SSAS Tabular.

DirectQuery/Data Import Mode in Power BI Desktop

On the other hand, when talk about “Connect Live”, we are referring to the data connection type from a reporting tool like Power BI Desktop OR Excel to an instance of SSAS, either SSAS Multidimensional or SSAS Tabular.

Continue reading “Demystifying “DirectQuery” and “Connect Live””