DEV Community: Cynthia Teigut

“How Analysts Translate Messy Data, DAX, and Dashboards into Action Using Power BI”

Cynthia Teigut — Sun, 08 Feb 2026 13:55:31 +0000

I have recently noticed that it is very easy to carried away by the data I am analysing which makes me sometimes want to add more on the dashboard which causes overcrowded and unneccersaary information which becomes hard for people hence realised that:
Analysts can clean a messy data,DAX and dashboards using power bi best practises rto ensure the report is not over crowded and easy to be understood.The following are ways inwhch one can minimize Messiness:

Limit the number of visuals in dashboards and reports
Using too many visuals in a single report slows report performance as each visual requires data processing and rendering. Limit widget visuals to eight per report page and grids to one per page. Limit tiles to 10 per dashboard.

Limiting the number of visuals reduces the amount of data that needs to be fetched and displayed at once.

Also consider using Power BI’s new card visual, capable of displaying multiple cards within a single container. This improves report performance and minimizes the number of queries fired by consolidating information into a single query.

Use on-premises data gateway standard mode instead of personal mode
The personal mode imports data into Power BI, which can cause resource limitations and performance issues (particularly with large databases). On the other hand, the standard mode retains data in its original location.

As the standard mode doesn't import any data into Power BI, it is more efficient. Using this gateway minimizes data duplication, reduces memory usage, and avoids potential performance bottlenecks.

Use separate gateways for Power BI service live connection and scheduled data refresh
A Power BI service live connection (DirectQuery) maintains a real-time connection with data sources. Scheduled data refresh updates imported data at set times. Using the same gateway for both live connections and scheduled data refresh can overload it during refreshes, slowing live connections.

Separating the gateways ensures that both functions can work efficiently without affecting each other.

Use calculated measures and filters to limit complex measures and aggregations in data models
Complex measures and aggregations in data models can slow down query performance. Using calculated measures, which is computed during query execution, are more efficient than calculated columns. Applying filters can also aid in this process.

Push calculations to the source
Pushing calculations to the source is recommended as it offloads the processing to the data source, optimizing query processing. Being closer to the source can increase performance speed.

Use Star schema instead of the snowflake schema when possible
The star schema is a simpler and more denormalized data model compared to the snowflake schema. The snowflake schema involves more complex queries due to multiple related tables.

The star schema accelerates query execution and eases maintenance by reducing required joins. It improves query efficiency, reduces data redundancy, and simplifies report development.

Use slicers sparingly
Slicers are a great way of allowing users to navigate data, but they come at a performance cost. Each slicer generates two queries: one fetches the data and the other fetches selection details. Adding too many slicers drastically slows performance. Use the Filter pane to evaluate and remove unnecessary slicers.

Host reports and data sources in the same region
A Power BI tenant is the dedicated environment that houses an organization's data, reports, and dashboards. Microsoft operates data centers worldwide to provide and hosts its services. Each data center is in a specific region.

Hosting both tenant and data source in the same region minimizes network latency. This enables quicker data transfer, query execution, and thus faster data retrieval and report rendering.

Partition data and process multiple partitions in parallel for large semantic models
Partitioning is a technique that divides large tables into smaller subsets called partitions based on specific criteria. A columnar index is a type of database index that stores and organizes data by columns rather than rows.

Power BI uses columnar indexes, so longer, leaner tables perform better. The partitioning approach, where only necessary fields and tables are imported, improves data loading efficiency, and reduces resource consumption. This leads to faster report performance.

Use calculation groups to reduce redundant measures
Calculation groups allow you to define calculations (like time intelligence) once and apply them to multiple measures. This reduces the number of measures in your model and simplifies maintenance.

Schemas and Data Modelling in Power BI

Cynthia Teigut — Sun, 08 Feb 2026 13:04:24 +0000

What Is a Star Schema?
A star schema is the structure Power BI is designed to work with. Imagine one central table – the fact table, with several dimension tables radiating out from it like the points

Each dimension connects directly to the fact table using a simple one-to-many relationship.

Each dimension connects directly to FactSales. Customer details, product categories, store information, and date table each sit in their own denormalised table, making the model fast, tidy, and easy to understand.

Your fact table contains measurable events such as SalesAmount, Quantity, and foreign keys to each dimension.

The dimension tables hold descriptive details such as CustomerName, City, ProductCategory, StoreRegion, or anything you want to filter and slice by.

Why Power BI loves star schemas
Fast queries – Fewer joins mean VertiPaq can scan data efficiently.
Better compression – Dimension tables contain repeated values, which compress extremely well.
Predictable DAX – Filter propagation and functions like CALCULATE or time intelligence work cleanly.
Easy for users – Even non-technical users can understand the layout in Model view.
A well-built star schema is as close as you get to “plug and play” modelling in Power BI.

Before moving on, here are two quick definitions:

Normalised data: information split into multiple related tables to remove duplication.
Denormalised data: related attributes stored together in one table to make querying faster.
This distinction becomes important when looking at schemas.

What Is a Snowflake Schema?
A snowflake schema appears when your dimension tables are normalised where tables are broken up into several smaller tables connected across multiple levels.

Dimensions branch into extra layers. Customers link to cities, cities to countries, products to categories, and so on; creating longer chains of joins for Power BI to navigate.

Instead of having all product attributes in one table, details like store, product, and customer are split out into different lookup tables.

This design is common in large data warehouses, where storage savings and strict data governance are priorities.

Where snowflakes cause problems in Power BI
Slower performance – VertiPaq must hop through several tables to apply a single filter.
Harder to understand – Users often struggle to follow multi-level lookups.
More fragile – Changes in one table require updates across several others.
Trickier DAX – Multi-hop relationships make filter behaviour less predictable.
Snowflakes aren’t wrong. They’re just not what Power BI performs best with.

Why Star Schemas Outperform Snowflakes (VertiPaq Basics)
VertiPaq is how Power BI stores it’s data, and controls how you access it!

It stores data in compressed columns and only loads the columns needed for a query. Star schemas line up perfectly with how VertiPaq is designed:

Dimension tables compress better because repeated values (e.g., ProductCategory) shrink well.
Fact tables remain dense and efficient when dimensions are flattened.
Fewer relationships reduce the work required for filter propagation.
Lower cardinality improves indexing and speeds up grouping and filtering.
Snowflake schemas do the opposite: they increase cardinality, add extra joins, and create more relationships for VertiPaq to manage.

Git BEGINNER’S MANUAL

Cynthia Teigut — Sun, 18 Jan 2026 06:55:30 +0000

If you’re just starting out with coding or working on projects with others, you’ve probably heard about Git.

Git is a tool that helps you keep track of your code, see what changes were made, and work with others without accidentally messing things up. Think of it like a magical notebook that remembers every change you make and lets you go back in time whenever you need.

This guide will walk you through the basics: tracking changes, pushing and pulling code, and understanding version control—all in plain English.

What is Version Control, Anyway?

Before Git, managing code changes was messy. If two people edited the same file, it could be a nightmare to combine their work. That’s where version control comes in.

Version control systems (like Git) keep a history of your project. You can:

See exactly what changed and when.
Revert back if something breaks.
Collaborate with others safely.

Basically, Git keeps your code organized and your sanity intact.

Git Basics: Key Terms You Should Know

Here are a few words you’ll see all the time in Git:

Repository (repo) – Your project folder tracked by Git. You can have one on your computer (local) or on GitHub (remote).
Commit – A snapshot of your code at a particular moment. Think of it like saving your game progress.
Branch – A parallel version of your project. You can experiment on a branch without affecting the main project.
Push – Send your local changes to the online repository.
Pull – Grab the latest changes from the online repository to your computer.

Step 1: Setting Up Git

Before you start using Git, you need to install it and tell it who you are:

Install Git
Download it from git-scm.com and follow the instructions for your computer.
Set your name and email

   git config --global user.name "Your Name"
   git config --global user.email "you@example.com"

This tells Git who made which changes.

Step 2: Starting a Git Repository

To start tracking your project:

cd path/to/your/project
git init

This creates a hidden folder where Git keeps track of everything you do.

Step 3: Tracking Your Changes

Git keeps an eye on your files, but you have to tell it when you want to save a snapshot:

Check what’s changed

   git status

Stage files – Choose which files you want to save:

   git add filename

Or all files at once:

   git add .

Commit changes – Save a snapshot:

   git commit -m "A short description of what you changed"

Think of staging as packing your bag and commit as taking a photo before sending it off.

Step 4: Working With a Remote Repository

If you’re collaborating, you’ll probably use a platform like GitHub. Here’s how:

Connect your local repo to GitHub

   git remote add origin https://github.com/username/repo.git

Push your changes – Send your local commits to GitHub:

   git push origin main

Pull changes – Get the latest updates from GitHub:

   git pull origin main

Always pull before pushing so you don’t overwrite someone else’s work.

Step 5: Viewing History and Differences

See all commits:

  git log

See what changed in a file:

  git diff filename

This is like checking your project’s “time machine” to see what was done and when.

Step 6: Branching (Optional, But Handy)

Branches let you try new ideas without messing up the main project:

Create a branch

  git branch new-feature

Switch to that branch

  git checkout new-feature

Merge back to main when ready

  git checkout main
  git merge new-feature

Branches are like experimenting in a sandbox—you can play around safely!

Tips for Beginners

Commit often. Small changes are easier to manage.
Write meaningful commit messages. It helps you (and your teammates) understand your changes.
Pull before pushing. Avoid conflicts!
Use branches to try new things without breaking the main project.

Conclusion

Git might seem intimidating at first, but once you get the hang of it, it’s a lifesaver for developers. It helps you track your code, collaborate safely, and fix mistakes without panic.

Start small: make commits, push and pull, and explore branches. Soon, using Git will feel like second nature.