Forum Discussion

powerbiexpert22's avatar
powerbiexpert22
Icon for Impactful Individual rankImpactful Individual
29 days ago
Solved

Snowflake schema

i need to convert snowlfake schema into star schema, the only way i can think is by denormalizing tables however i am not sure which tables i should consider for denormalization, also is there any ot...
Need Help
power bi
  • ShahRukhSameer's avatar
    ShahRukhSameer
    29 days ago

    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.

rajendraongole1's avatar
rajendraongole1
Icon for Super User rankSuper User
29 days ago

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.