Amith D

Yeah. Hi. Myself is Amit. So I have around 8 years of experience in the IT industry. So 6 years into Power BI and data modeling, data analysis, and data warehousing. So I have started my career with report creations using SQL Server. So I worked on stored procedures, functions, views, and I used T-SQL to create reports like sales reports, etcetera reports using SQL Server, and I used SQL scripts over there. Later, I got interested in Power BI, then I moved creating reports and dashboards into Power BI and also like working back-end data for data warehousing. I particularly worked on projects in the finance and HR domains. We usually collect data from multiple data sources, which the company uses. And from there, we will use that data and load it to the landing page, then we will transform, clean the data, and improve the quality, remove nulls, and index the data. Everything we do is configuration, and we will move to the staging space. There, we create facts and dimensions and build the model and then move it to the curated space. From the curated space, we use the data to create reports on dashboards. In this process, I use especially ADF for orchestrating the data, and I used a skill server for creating incremental load processes and full load processes and manipulating the data, transforming the data. And we used Databricks for transforming the data and ADF stuff. I also used T-SQL queries and M query for the ETL processes. I used Power BI in this. Other than that, I worked on Databricks as well. For storage, we used Azure SQL DB and Azure Synapse. Now, I have certified for Microsoft also. We use some Microsoft Fabric for a few things. Okay. This is all about my experience. And we also use agile methodology. We follow every 2-week sprint, and there will be a planning retrospective on the demonstrations every 2 weeks. Based on the input from the demo, we will improve our changes in the next sprint. This is how we follow the project. Thank you.

Balance. Okay. So we will first check the volume of the data, what this data is related to, and how quickly we can connect it to Power BI. We will check that first. So, and then we'll see what type of data it is. So, it's a streaming data or it's a day-to-day update data, like that. So then, we will decide. The main thing is that if only one thing is affected, it's the data model. Other than that, I think we can easily copy data to the database, and we can create the report.

To so probably a different that won't load in the intended application, we could use techniques such as checking the XML endpoint, which is the main thing to check for the data. We will check the XML endpoint, see whether the XML endpoint is correct in the external application. It's not loading to the external application.

Okay, so we take the dashboards into its applications using, for the IMEI analytics. We use the XML endpoint. That endpoint, we use it in the external application so that users can see the Power BI reports in the Power BI embedded space.

And would you choose to build a new table or view in the database for a report? Okay. So if we are, like, if we are having the data from the different tables and then we can create a query so that to join between the tables, and we can create it as a view, and it will be a virtual table. So that will do the processing in the data source itself, not in the Power BI engine. That's when we use the views. And if we have that data entries happening in a particular table, that's a physical space, physical storage, then we use a table. If there is a usage of the particular users doing entry in the table, then we create it as a table; else we create it as a view.

So for a virtual person control, for Power BI, we can integrate that with the Git, and we can give the Azure DevOps organization, create an organization, and create a project, and we can link that to the Power BI, that one. And, so we can create it as a 3 or 4 stages, like a dev test, UAT and prod, or dev test and UAT and prod, depending on the company hierarchy and the requirement. So, we can create a deployment pipeline over there, and in that, we can create 3 workspaces. 1 is dev, test, and prod. We can assign that 3 workspaces to the 3 pipelines in the deployment pipelines. Then we can integrate that with the Git with the project. Every time you upload it to the Power BI service, it will ask you if you map with the commit it with the branch, then it will be like, a version will be managed, and you can see the history. So, previous changes, whatever you do, you can see the version history. This is one type, and another type is you can integrate with the Azure DevOps. You can create a clone that Azure repos into your local system. From there, you can whenever you do the changes in, that create a service principle using Power BI, and whenever you do the changes in the local system, in your branch, so automatically. And if you once you commit and push it to the main branch, in GitHub, then you can see the changes in the Power BI. So, once you do all the changes and they move to the development test, once the user approves the changes, then you can get the merge it with the master branch. So, you can use Azure DevOps, and you can use the Azure Git integration inside the Power BI service. So there are 2 options to do it. Thank you.

It's a number of filters on sales here in 2022. So here in this formula, you have the filter, which particularly does it to the table. So now you see sales are selected as all sales. So however, you are doing the sales for the year 2022. So we don't need to use a filter function here, just filter. So directly, we can use all sales and the sales year 2022 because filter will only concentrate on a particular table, not on all the tables existing in that particular visual. So you can use some sales amount, and all sales for 2022.

So let's start from orders in our join customer. Okay, customer dot country is equal to Germany. So here, yeah. So you can. Okay, so the star is only the star. Instead of taking the star, we can take only the select required columns inside the query, then I think like the performance will improve because if you take the star, then it will fetch all the records from the orders and columns from the customer. So instead, we can take only the required columns in the select statement. Yeah. Thank you.

To implement a forward way reporting solution for complex business logic and accent, we can use the following options: For complex business logic, especially in DAX, we can use variables. Variables play an important role in DAX, allowing us to use them in formulas, which can improve performance. We can also use the tabular editor, which is a good option for checking query performance and improving it through trial and error. Another option is the data model, which should have properly assigned relationships between tables, designed to provide integral security and avoid affecting report performance. On the visual level, we can use the performance analyzer in the Power BI desktop. This allows us to improve performance by checking how much time visuals are taking to refresh and also improve DAX formulas based on visual performance. The three stages for improving Power BI performance are: 1. Data model stage: Properly assigning relationships between tables and designing the data model for integral security. 2. Using variables in DAX formulas to improve performance. 3. Visual performance: Using the performance analyzer to check and improve DAX formulas. Additionally, we can use DAX Studio to check the schema and required columns, allowing us to improve Power BI performance by using the standard format from DAX Studio.

What strategies would you apply to ensure Power BI reports remain accessible during database maintenance activities. Activities. So, like, if you see, if you're doing maintenance, then improving import mode is the best way to have it when you're doing database maintenance activities. But it's only workable for small data. It doesn't work for big data. For the latter, if you have a data warehouse, you can create some replicated data and you can do the connection to that or using a branch. So you're having a data test and production environment. So there, you can use a branch and you keep that data in one branch and then you can do the database maintenance activities. I think so. Yeah. So we use a separate database for the reporting. So, whenever there is a maintenance issue in the operational data, then I don't think it will affect the analytical data. In case if you're doing the maintenance activities for the analytical data, then, yeah, using the import mode is one of the options so that the reports will be continuously running because it will store it in the cache memory in Power BI itself or using a different environment, like creating some different environment and with the same name and connecting to that data source until the maintenance activities.

How do you incentivize your team to maintain good quality in the development of DAS expressions? Underscale queries. Yes. So, like, the scale queries and the tags expressions are a different type of report but using a different syntax. So, we use a tabular editor, similar to SSMS for SQL Server. For the decks, we use a tabulator. And, of course, in the new version of Power BI, we can do it in Power BI itself. However, maintaining and managing the DAX expressions in tabulator is much better than in BI. So, we check the DAX expressions to ensure that the logic is the same, and we apply the aggregate functions on the filtered data for reporting. Similarly, for tax, we check the particular requirement, filter it out, capture the filter into a variable, and then use the variable in the creating function.