Snowflake schema

Hi powerbiexpert22​,
Can you check below links
Understand star schema and the importance for Power BI - Power BI | Microsoft Learn
Model relationships in Power BI Desktop - Power BI | Microsoft Learn
Best Regards,
Maruthi
LinkedIn - http://www.linkedin.com/in/maruthi-siva-prasad/
X            -  Maruthi Siva Prasad - (@MaruthiSP) / X

Hi,

Denormalizing is the right approach, snowflake to star is basically collapsing sub-dimension chains into their parent table.

To pick candidates, look for dimensions that only exist to normalize another dimension, no fact table relates to them directly. Product → Category → Subcategory chains are classic examples, collapse into one Product table with those as columns.

Keep tables separate if they're genuinely reused across multiple fact tables independently.

Do the merges in Power Query, join sub-dimensions into parents, then drop the redundant tables.

If this helped, feel free to give it a kudos or mark it as solution, helps others find it too.

denormalize from the outside in (the dimension-of-a-dimension layers, not the ones touching the fact table), do it via Power Query merges, and notes VertiPaq compression makes storage bloat a non-issue — the real win is DAX simplicity.

Yes,denormalizing is one part of converting a snowflake model to a star schema, but you should not simply denormalize everything.If you are doing this in Microsoft Fabric for a Power BI semantic model, I would approach it as a dimensional-model redesign, not as a table-by-table conversion. Microsoft recommends star schema for analytical workloads: facts contain events/measures at a consistent grain, while dimensions contain the attributes used for filtering/grouping

Hi powerbiexpert22​ -One additional point I’d consider is that the Snowflake schema in the data/warehouse layer and the Star Schema in the Power BI semantic layer don't necessarily have to be identical. In a Fabric/Power BI architecture, you can keep the source/integration layer normalized and create a dimensional/serving layer specifically for analytics. This gives you the flexibility to flatten only the dimensions that benefit from denormalization while retaining bridges or entities with independent grain.                                                                                                                            validate the grain, cardinality, SCD requirements, and row-count impact before merging tables. The goal isn't simply fewer tables, it’s a predictable 1: relationship from dimensions to facts, clear filter propagation, and correct measures.

Hope this helps.

Hi powerbiexpert22​,

You don't necessarily need to denormalize everything to get a star schema.

I'd start with the fact table and define its grain first. Then look at the related tables and see which ones are mainly providing descriptive attributes.

For example:

FactSales
→ DimProduct
→ DimSubcategory
→ DimCategory

could become a single DimProduct containing Product, Subcategory, Category, Brand, etc.

The same can be done with other dimensions where it makes sense.

You also don't have to physically change the Snowflake tables. You can keep the source schema as it is and create a dimensional layer using Snowflake views or your ETL/ELT process for Power BI.

The main goal is to have simple relationships such as:

DimProduct 1 → * FactSales
DimCustomer 1 → * FactSales
DimDate 1 → * FactSales

I wouldn't flatten every table blindly, though. Tables with different grains or many-to-many relationships need to be handled separately to avoid duplicate rows and incorrect measures.

If you share the table names/relationships, it would be easier to suggest exactly which ones I'd combine.