Perché lo star schema è il modello “nativo” di Power BI

Il motore analitico di Power BI (VertiPaq, columnar e in-memory) è ottimizzato per un preciso pattern di modellazione: lo star schema. Non è una preferenza stilistica, è il modo in cui il motore raggiunge le performance migliori e in cui il DAX produce misure prevedibili. Progettare un buon modello semantico significa quindi tradurre i dati in due categorie di tabelle: fact e dimension.

Fact table: gli eventi misurabili

Una fact table registra gli eventi di business — una vendita, un ordine, una transazione, una telefonata. Ha tipicamente molte righe (milioni), poche colonne, ed è composta da:

  • misure (measures) numeriche additive: Quantity, SalesAmount, Cost;
  • chiavi esterne verso le dimensioni: ProductKey, CustomerKey, DateKey.

Su questa tabella scriverai le aggregazioni DAX (SUM, SUMX, …). Regola pratica: se una colonna la sommi o la conti, appartiene alla fact; se invece ci filtri o raggruppi, appartiene a una dimensione.

Dimension table: gli attributi descrittivi

Una dimension table contiene gli attributi descrittivi con cui si affetta l’analisi: la tabella Product con categoria e colore, Customer con città e segmento, Date con anno, mese e trimestre. Ha poche righe e molte colonne testuali. Le dimensioni forniscono le etichette di righe, colonne, slicer e assi dei visual. Le relazioni fact→dimension sono uno-a-molti, con direzione di filtro singola dalla dimensione verso la fact (il pattern raccomandato per evitare ambiguità).

Star schema vs snowflake vs tabella flat

  • Tabella flat (tutto denormalizzato in un’unica tabella): sembra semplice, ma esplode la cardinalità delle colonne, gonfia il modello in memoria, duplica i valori descrittivi e rende i calcoli distinti (es. “numero di prodotti unici”) più fragili. VertiPaq comprime peggio colonne ad alta cardinalità.
  • Snowflake (dimensioni normalizzate su più tabelle collegate, es. Product → Subcategory → Category): fedele al database sorgente, ma introduce relazioni a catena che allungano i percorsi di filtro, peggiorano le performance e complicano il DAX.
  • Star schema: una fact centrale circondata da dimensioni denormalizzate a un solo livello. Offre il miglior compromesso: compressione efficiente, percorsi di filtro corti, misure leggibili.

Quando collassare uno snowflake

Nella maggior parte dei casi conviene collassare lo snowflake in un’unica dimensione: porta Category e Subcategory dentro la tabella Product con una merge in Power Query, ottenendo una singola dimensione denormalizzata. Mantieni lo snowflake solo in casi limitati: dimensione condivisa tra più fact a granularità diversa, o tabella intermedia enorme che diventerebbe ridondante se duplicata. In dubbio, per l’esame: collassa.

Role-playing dimensions

Una role-playing dimension è un’unica dimensione usata in più ruoli dalla stessa fact. Il caso classico è Date, richiamata da OrderDateKey e ShipDateKey. In un modello tabellare puoi avere una sola relazione attiva per coppia di tabelle: la seconda diventa inattiva (linea tratteggiata).

Due strategie:

  • Relazione inattiva + USERELATIONSHIP: mantieni una sola tabella Date e attivi l’altra relazione dentro la misura:

    Sales by Ship Date =
CALCULATE ( [Total Sales], USERELATIONSHIP ( Sales[ShipDateKey], 'Date'[DateKey] ) )

  • Dimensione duplicata (Order Date e Ship Date come tabelle separate): utile quando vuoi usare entrambe le date contemporaneamente negli stessi visual, senza scrivere una misura per ogni caso.

Scelta d’esame: se serve confrontare le due date nello stesso visual/filtro, duplica la dimensione; se basta cambiare prospettiva a livello di misura, usa USERELATIONSHIP.

Trappole tipiche d’esame

  • Importi il modello relazionale OLTP as-is (tabelle normalizzate, snowflake profondi) → sbagliato: rimodella a stella in Power Query, collassando le dimensioni e separando fatti da attributi. È l’errore più penalizzato.
  • Scenario: Product, Subcategory, Category in tre tabelle collegate e performance lente → risposta: denormalizza in un’unica dimensione Product (collapse snowflake).
  • Scenario: la fact ha OrderDate e ShipDate verso la stessa Date → una relazione è inattiva; per misurare sulla data di spedizione usa USERELATIONSHIP, oppure duplica la dimensione se servono entrambe nel visual.
  • Scenario: colonna che devi sommare finita in una dimensione (o attributo testuale nella fact) → riallocala: misure nella fact, attributi descrittivi nelle dimensioni.
  • Scenario: qualcuno propone una singola tabella flat “per semplicità” → segnala l’impatto negativo su compressione, dimensione del modello e cardinalità; preferisci lo star schema.