Skipp Merchant
770-967-3815
Planning and developing a Power BI dataset (semantic model) or MS Access split database application is like planning a vacation. You plan where you want to go then map out how to get there.
When planning a vacation, a person doesn’t take all their clothes, just what they need, and planning Power BI datasets is the same, but with data instead of clothes. Some things taken on vacations like airline tickets and reservations are more important than other things. Dataset plans have important items as well, especially when the plans involve creating the modular parts (views) of the data in an external to Power BI environment like SQL Server or Amazon Redshift. During this phase, extra care needs to be taken to make sure that the modular parts can be related later when building the Power BI data model. This includes being sure that relatable data is contained in special columns called primary keys and that the data in those columns abides by certain referential integrity rules.
Imagine that your are traveling by car and know that a bridge is out. You’d plan another route. Splitting a Microsoft Access database application by separating the user (front-end) interface from the most of the data, data tables, and programming (the to-be back-end) can have bridge outages too. When an Access back-end is migrated to Sequel Server the bridge will be out and certain data types, values, and programming that will not migrate over and will require reworking. Reworking is a process waste, so I recommend avoiding building the types of structures that will require rework.
Some projects that I work on are pre-existing Power BI reports or entire Power BI web services that need to be fixed, modernized, and upgraded. This can be like an explorer who stumbles upon the ruins of an ancient temple in a jungle. There is a definite structure in front of you, but the archetect is long gone and nowhere to be found. Inside of the structure, there may be a lot of meaningless clutter, some things that belong there, some that don’t, duplicates of things, and no documentation to explain what-is-what. In these no-doc, no-developer scenarios, I start at the end of the data story, at the end in Power BI desktop, then I go backward into Power Query where I identify the external data sources, then go back to the external data sources.
After the data sources are fixed, fixing the Power BI reports, dashboards, DAX measures, or semantic data models requires a certain amount of experience and skill. This is even more so when I work in a no-doc, no-developer scenario where the missing developer was sloppy and undisciplined but had a substantial amount of technical ability. The challenge in these cases is knowing when that developer’s work was good and when that developer just thought it was.
So, you get the picture… Sometimes looking at another developer’s work is like an explorer in a jungle looking at ruins. You ask yourself “Were these people advanced and using irrigation to water their crops, or where they are sacrificing something to try to make it rain?”
A good Power BI developer plans and documents their work so that it is easy for others to understand. They will add comments to their DAX code and utilize indention and naming conventions to make their code easy to read.
© Leansoftlytics 2024 All rights reserved