Progettare uno schema star per i modelli semantici

Si è scelto il modo in cui i dati passano al modello semantico. Ora progettare lo schema a stella che lo organizza per query chiare ed efficienti. Uno schema a stella connette le tabelle dei fatti alle tabelle delle dimensioni tramite relazioni, creando i percorsi di filtro su cui si basano i report e l'uso dell'intelligenza artificiale. Se si ha familiarità con la creazione di uno schema star in Power BI Desktop, questa unità è incentrata sulle decisioni di progettazione delle relazioni importanti man mano che i modelli aumentano di complessità e scalabilità.

Schema stellare in un modello semantico

In uno schema star le tabelle dei fatti archiviano eventi aziendali misurabili (ad esempio transazioni di vendita, righe ordine e visite Web) e le tabelle delle dimensioni forniscono il contesto descrittivo (ad esempio i dettagli del prodotto, le informazioni sui clienti e gli attributi di data). Le tabelle delle dimensioni filtrano le tabelle dei fatti tramite relazioni, che consente agli utenti di filtrare le metriche in base a qualsiasi attributo descrittivo.

In un modello semantico di Fabric questo modello fornisce una propagazione pulita dei filtri per i report e l'utilizzo di intelligenza artificiale. Quando Copilot o un agente dati genera una query in linguaggio naturale, uno schema a stella ben organizzato offre all'A percorsi chiari per accedere ai dati corretti. Relazioni ambigue o circolari confondono sia gli utenti dei report che gli strumenti di intelligenza artificiale.

Impatto della modalità di archiviazione sulle relazioni

Le relazioni in un modello semantico si comportano in modo diverso a seconda della modalità di archiviazione. La comprensione di queste differenze è essenziale per la progettazione di uno schema star che offre prestazioni elevate in diversi scenari.

Relazioni Direct Lake

In modalità Direct Lake il motore legge le relazioni direttamente dai metadati della tabella Delta. Le relazioni sono ottimali quando:

• Le colonne chiave della dimensione presentano una cardinalità bassa rispetto alle righe della tabella dei dati.
• L'integrità referenziale viene mantenuta nei dati di origine. Quando si mantiene l'integrità referenziale, il motore usa INNER join invece di LEFT OUTER join, migliorando così le prestazioni delle query.
• Le colonne utilizzate nelle relazioni vengono indicizzate nelle tabelle Delta sottostanti.

Relazioni tra fonti incrociate

Fabric modelli semantici possono connettere tabelle da archivi dati diversi. Una tabella dei fatti di una lakehouse può avere una relazione con una tabella delle dimensioni di un warehouse o con una tabella a cui si accede tramite un endpoint di analisi SQL. Queste connessioni tra origini usano funzionalità del modello composito.

Quando le tabelle provengono da origini diverse, la modalità di archiviazione per ogni tabella determina il funzionamento della relazione in fase di query. Il motore risolve ogni lato in modo indipendente e unisce i risultati.

Tipi di relazione

Relazioni uno-a-molti

Uno-a-molti è il tipo di relazione più comune in uno schema a stella. Un valore univoco in una tabella delle dimensioni è correlato a molte righe in una tabella dei fatti. Ad esempio, una riga di prodotto nella dimensione Prodotto corrisponde a migliaia di righe di ordine nella tabella dei fatti di Vendite.

Configurare relazioni uno-a-molti con la direzione del filtro dalla dimensione (il lato "uno") alla tabella dei fatti (il lato "molti"). Questo è il modello di filtro dello schema a stella standard.

Relazioni molti-a-molti

Le relazioni many-to-many sono necessarie quando nessuna delle due tabelle presenta valori univoci per la colonna della relazione. Usare una tabella bridge per risolvere queste relazioni. Una tabella bridge si trova tra due tabelle e contiene combinazioni univoche delle chiavi da ogni lato.

Ad esempio, se un cliente può avere più account e un account può appartenere a più clienti, una tabella bridge Customer-Account risolve la relazione. La tabella bridge ha relazioni uno-a-molti con le tabelle Customer e Account.

Direzione di filtraggio

Nella maggior parte delle implementazioni dello schema a stella, usare un filtro unidirezionale dalla dimensione al fatto. Ciò garantisce una propagazione prevedibile dei filtri ed evita ambiguità nei risultati della query.

Il filtro bidirezionale è talvolta necessario per le relazioni molti-a-molti o quando le tabelle delle dimensioni devono essere filtrate in base ai valori nella tabella dei fatti. Usare i filtri bidirezionali con moderazione perché possono ridurre le prestazioni delle query e creare comportamenti di filtro imprevisti nei report.

Integrità referenziale

L'impostazione Considera integrità referenziale indica al motore di usare INNER join anziché LEFT OUTER join durante l'esecuzione di query su una relazione. Nelle modalità Direct Lake e DirectQuery questa impostazione può migliorare significativamente le prestazioni perché riduce il numero di righe dei processi del motore.

Abilitare questa impostazione quando si è certi che ogni valore di chiave esterna nella tabella dei fatti abbia un valore corrispondente nella tabella delle dimensioni. Se l'integrità referenziale viene violata, le righe con chiavi non corrispondenti scompaiono automaticamente dai risultati della query.

Relazioni inattive e USERELATIONSHIP

Esiste una sola relazione attiva tra due tabelle alla volta. Quando sono necessari più percorsi di relazione, ad esempio una data di ordine e una data di spedizione correlate alla stessa dimensione Date, rendere attiva una relazione e le altre inattive.

Usare la USERELATIONSHIP funzione in DAX per attivare una relazione inattiva all'interno di un calcolo:

Shipped Amount =
CALCULATE(
    SUM(Sales[Amount]),
    USERELATIONSHIP(Sales[ShipDate], 'Date'[Date])
)

Questo modello mantiene il modello pulito e supporta più prospettive analitiche sugli stessi dati.

Gestire lo schema snowflake dei modelli semantici

I dati di origine arrivano spesso in uno schema snowflake normalizzato, in cui le tabelle delle dimensioni vengono suddivise in più tabelle correlate. Ad esempio, una dimensione Product può essere separata in tabelle Product, Subcategory e Category, ognuna collegata tramite chiavi esterne.

In un modello semantico sono disponibili due opzioni: appiattire il fiocco di neve in uno schema star o mantenere la struttura normalizzata.

Appiattire lo schema a stella

L'appiattimento significa combinare le tabelle delle dimensioni normalizzate in una singola tabella delle dimensioni denormalizzata. La tabella Product includerà direttamente le colonne Subcategory e Category, eliminando le tabelle e le relazioni aggiuntive.

Appiattire quando:

• La tabella delle dimensioni combinata è ancora piccola rispetto alla tabella dei fatti (come è quasi sempre il caso per le dimensioni).
• Si vogliono percorsi di filtro più semplici dalla dimensione al fatto. Ogni filtro passa attraverso una relazione anziché una catena.
• Il consumo di intelligenza artificiale è una priorità. Meno tabelle e relazioni più semplici offrono percorsi più chiari per Copilot e per gli agenti di dati verso i dati corretti.

Appiattire le tabelle delle dimensioni durante la preparazione dei dati in lakehouse o flussi di dati, prima che i dati raggiungano il modello semantico. Usare unioni di Power Query, join SQL o trasformazioni notebook per combinare le tabelle normalizzate in una singola dimensione.

Mantenere la struttura snowflake

In alcuni casi, mantenere la struttura normalizzata ha senso:

• La gerarchia delle dimensioni ha più livelli e l'appiattimento creerebbe decine di colonne ridondanti.
• Più tabelle di fatti condividono tabelle di sottodimensione, come ad esempio una tabella "Category" condivisa utilizzata dai fatti "Sales" e "Inventory", e la denormalizzazione creerebbe copie incoerenti.
• La sicurezza a livello di riga deve essere applicata a un livello specifico nella gerarchia.

Quando si conserva una struttura a fiocco di neve, è importante configurare attentamente le relazioni. Ogni relazione nella catena deve usare il filtro a direzione singola dalla tabella più esterna verso la tabella dei fatti in modo che i filtri vengano propagati correttamente. Un filtro per categoria deve attraversare la sottocategoria, quindi il prodotto e infine entrare nella tabella dei fatti aziendali.

Quando usare modelli compositi per scenari tra origini

Usare modelli compositi quando lo schema star si estende su più archivi di dati Fabric o include origini esterne. Gli scenari comuni includono:

• Tabelle dei fatti in un lakehouse con tabelle delle dimensioni gestite in un warehouse.
• Streaming in tempo reale dei dati da un eventhouse combinato con dati storici in un lakehouse.
• Dati di riferimento da un'origine esterna (importazione) combinati con tabelle dei fatti native di Fabric (Direct Lake).

In questi scenari, configurare la modalità di archiviazione per ogni tabella in modo indipendente e verificare che le relazioni tra origini funzionino in modo accettabile entro i volumi di dati previsti.