From the “Data but Make it Personal” series – Part 6
Why good design makes great dashboards possible
I love a beautiful dashboard.
A clean layout, the right colors, interactive filters, the magic of seeing a story unfold visually — it’s one of the things that got me into data in the first place.
But now that I’ve spent some serious time building dashboards (and fixing plenty of broken ones), I know something I didn’t fully appreciate before, the most beautiful dashboard in the world won’t work if the data model behind it is a mess.
Great dashboards aren’t just built, they’re architected. And the architecture lives in the model.
So, this blog is about the unsung hero of data analytics: the data model.
The relationships, the structure, the foundational logic that makes everything else possible.
What Is a Data Model, Anyway?
A data model is like the floor plan for your entire data project.
It defines:
- What tables you have.
- What kind of data each one holds.
- How they connect to each other.
- And what kind of logic those connections enable.
Without this blueprint, you’re basically throwing bricks together and hoping a house appears.
In Power BI, Tableau, or probably any other BI tool, this usually means defining relationships between tables — setting primary and foreign keys, deciding which fields to join on, and configuring the direction of filtering between tables (this in Power BI).
The goal? To let your measures and visuals function without confusion, duplications, or chaos. To let you actually tell the story your data holds.
Flat Tables (my first instinct and biggest mistake)
When I first started working with data, I fell into the trap most beginners do, bringing everything into one big, flat table.
One row per transaction, with all the customer info, product names, regional codes, and whatever else fit.
It worked — until it didn’t. Until I was working with a large enough dataset to crash my computer every time I wanted to render the visualizations.
The files got slow. The calculations repeated unnecessarily. Even simple filtering by region or customer segment suddenly took a huge toll on performance, and I couldn’t figure out why.
Thankfully, in training I learned the golden rule:
A good data model doesn’t repeat — it connects.
Star Schema: Your New Best Friend
For most analytical dashboards, the ideal structure is the star schema.
Picture it like this:
- In the center, you have your fact table — where all your numeric data lives: sales, visits, hours worked.
- Surrounding it are your dimension tables— your categories: products, dates, stores, customers.
This model lets you:
- Create clean, one-to-many relationships
- Simplify your filtering logic
- Speed up calculations
- Scale up easily when new data comes in
Think of it like a well-organized closet. Everything has its place, and finding what you need is easy — because the structure makes sense.
Relationship Design: A Technical Mini-Guide
Here’s a little cheat sheet of lessons I learned (sometimes the hard way):
- Use Surrogate Keys (Not Just Names). Names change, but IDs don’t. Always create relationships using primary keys like Customer ID instead of Customer Name.
- Be Clear on Filter Direction (only need to be aware of this in Power BI, thank god!). Do you want Date to filter Sales? Or the other way around? Set the cross-filter direction accordingly.
- Avoid Bi-Directional Relationships When Possible. They seem convenient but can create ambiguous filter paths and unexpected results. Use them sparingly, and only when you’re sure about the logic.
These little technical decisions can make or break your entire dashboard.
So, What Makes a Good Model?
In short (and hey, just my humble, hard-earned, data-analyst-in-the-making opinion):
- Simple where possible
- Scalable when needed
- Easy for others to understand
- Structured in a way that matches how users actually explore the data
A good model lets your dashboard shine, without you having to wrestle with filter conflicts, duplicated rows, or measure spaghetti.
And it earns you something even better: peace of mind.
Conclusions
I used to think the “fun part” of a data project was the visual layer — the charts, the interactivity, the colors.
And yes, that part is still exciting.
But now I know there’s also fun in getting the dashboard to just work and that starts way earlier, in the model.
So next time you start a project, before diving into DAX or formatting tooltips, pause for a second and ask yourself:
What’s the structure here?
Are my tables talking to each other the right way?
Because when your model is strong, everything else becomes easier.
And beautiful dashboards?
They’re built on invisible architecture.
