Tutorials › Power BI › Star Schema Design

The star schema is not a Power BI concept. It predates Power BI by thirty years — it comes from Ralph Kimball's data warehousing methodology from the 1990s, and it has outlasted every BI tool trend since then. That longevity is not an accident. It works. I have modelled data in nearly every architecture imaginable over my career — normalised relational databases, denormalised flat files, ODS layers, data vaults, graph databases. For interactive business reporting, nothing performs better or maintains cleaner than a well-designed star schema. The reasons are not arbitrary. A star schema aligns with how BI engines — including Power BI's VertiPaq — are built to work. It separates facts (what happened: transactions, events, measurements) from dimensions (who, what, where, when: customers, products, regions, dates). This separation is what makes cross-dimensional filtering fast and DAX formulas readable. The practical test I use to check if a model is star schema ready: can you answer every business question with a measure on the fact table, filtered by one or more dimension tables? If yes, you have a star schema. If your answer requires joining two fact tables, or filtering a dimension by another dimension, you have a design problem — and it will show up as slow reports and confusing DAX. Learn this design pattern completely. It is the one modelling concept that transfers directly from Power BI to Tableau, SQL Server Analysis Services, Databricks, and any serious BI platform you will ever work with.

          ┌─────────────┐
          │  DIM_Date   │
          │  DateKey    │
          │  Date       │
          │  Month      │
          │  Quarter    │
          │  Year       │
          └──────┬──────┘
                 │
┌──────────┐    │    ┌──────────────┐
│DIM_Cust  │    │    │ DIM_Product  │
│CustID    │    │    │ ProductID    │
│Name      │    │    │ ProductName  │
│Region    ├────┤    │ Category     │
│Segment   │    │    │ Price        │
└──────────┘    │    └──────────────┘
                │
         ┌──────┴───────┐
         │  FACT_Sales  │  ← CENTRE (fact table)
         │  OrderID     │
         │  DateKey     │
         │  CustID      │
         │  ProductID   │
         │  Quantity    │
         │  Amount      │
         └──────────────┘

Rules:
• Fact table has FK columns + numeric measures only
• Dimension tables have descriptive attributes
• All relationships flow FROM dimensions TO fact