Modellare i dati in un data warehouse

Senza la modellazione dei dati, ogni consumer deve determinare quali tabelle si riferiscono tra loro, scrivere la propria logica di aggregazione e indovinare i significati delle colonne. La modellazione dei dati risolve questo problema incorporando la struttura, la logica di business e la documentazione direttamente nel warehouse. In un data warehouse di Microsoft Fabric, preparare i dati per chiarezza, definire le relazioni tra tabelle, standardizzare l'accesso tramite viste e misure e pubblicare modelli semantici per la creazione di report. Queste scelte di modellazione influiscono su ogni esperienza downstream, incluse le query T-SQL, i report di Power BI e l'analisi del linguaggio naturale basata sull'intelligenza artificiale.

Preparare i dati per il consumo

Prima di definire relazioni o aggiungere calcoli, è necessario pulire gli elementi visualizzati dai consumer. Le tabelle di warehouse non elaborate contengono spesso tabelle di staging, colonne chiave sostitutive e flag interni destinati all'elaborazione ETL, non all'analisi. Questi oggetti creano rumore quando i consumer esplorano i dati. Preparare il magazzino per l'uso significa mettere in evidenza solo ciò che è rilevante e renderlo comprensibile.

Nella visualizzazione modello è possibile eseguire diversi passaggi per migliorare l'esperienza di consumer:

• Nascondi oggetti interni come tabelle di staging, colonne chiave surrogata e artefatti ETL che ingombrano l'elenco dei campi.
• Rinominare le colonne in modo da usare nomi intuitivi per gli utenti, nelle quali i nomi delle colonne del magazzino sono tecnici o abbreviati. Ad esempio, rinominare CustRgnCustomer Regionin .
• Aggiungere descrizioni a tabelle e colonne in modo che gli utenti comprendano cosa rappresentano i dati senza fare riferimento alla documentazione esterna.

Questi passaggi sono importanti oltre la semplicità. Copilot in Power BI e gli agenti dati di Fabric IQ si basano su nomi di tabella, nomi di colonna e descrizioni per interpretare le domande in linguaggio naturale e generare SQL o DAX. Una colonna denominata Customer Region con una descrizione come "Area geografica dell'indirizzo primario del cliente" produce risultati in linguaggio naturale migliori rispetto CustRgn a quelli senza descrizione.

Con tabelle pulite e ben denominate, è possibile definire il modo in cui tali tabelle si connettono tra loro.

Informazioni sulle relazioni tra tabelle

Una relazione è una connessione logica tra due tabelle che consente il filtro, il raggruppamento e l'aggregazione tra tali tabelle. In uno schema star le relazioni connettono le tabelle dei fatti alle tabelle delle dimensioni tramite colonne chiave condivise.

Ad esempio, una CustomerKey colonna presente sia in FactSales e DimCustomer stabilisce il collegamento che consente l'analisi delle vendite in base agli attributi dei clienti, ad esempio area, segmento o tipo di account.

Ogni relazione ha due proprietà importanti.

• La cardinalità descrive il modo in cui corrispondono le righe nelle due tabelle. In uno schema a stella, le relazioni fatto-dimensione sono in genere relazioni di tipo molti-a-uno, in che significa che molte righe fatto vengono mappate a una singola riga dimensione.
• La direzione del filtro incrociato determina il modo in cui i filtri vengono propagati tra le tabelle. La singola direzione, in cui la dimensione filtra la tabella dei fatti, è l'impostazione standard per la maggior parte delle progettazioni dello schema star perché mantiene il comportamento del filtro prevedibile ed efficiente.

Senza relazioni definite, ogni consumer che vuole combinare i dati tra le tabelle deve scrivere logica JOIN esplicita. Le relazioni eliminano tale ripetizione codificando la connessione una sola volta. Quando si crea un modello semantico dal warehouse, queste relazioni comunicano in che modo gli agenti dati di Power BI, Copilot e Infrastruttura IQ interpretano i dati. Gli agenti dati, ad esempio, usano relazioni per generare join accurati durante la conversione di domande in linguaggio naturale in SQL.

Standardizzare gli accessi ai dati con viste e misure

Ora che le tabelle sono pulite e connesse, il passaggio successivo consiste nell'offrire ai consumer modi affidabili e coerenti per eseguire query e calcolare i dati. Senza standardizzazione, ogni team scrive la propria logica di join, applica i propri filtri e definisce le proprie formule, che causano risultati in conflitto.

Le viste offrono questa coerenza per gli utenti T-SQL. Una vista incapsula la logica di join, i filtri e le selezioni di colonne in una query riutilizzabile a cui gli utenti fanno riferimento come a una tabella. Ad esempio, una vista che unisce le tabelle dei fatti e delle dimensioni, filtra per mostrare solo gli ordini completati e visualizza solo le colonne necessarie fornisce a ogni consumatore di T-SQL un punto di partenza affidabile. Le viste fungono anche da origini dati stabili per i report. Anziché creare report direttamente rispetto alle tabelle di base che potrebbero cambiare, è possibile puntare i report alle visualizzazioni che presentano una forma coerente.

Le misure forniscono la stessa coerenza per i calcoli DAX. Una misura è un'espressione DAX riutilizzabile che definisce un calcolo come un totale, una media, un rapporto o un conteggio. Le misure vengono create direttamente nella vista modello warehouse selezionando una tabella e aggiungendo una nuova misura. Ad esempio, una Total Sales misura che somma la colonna SalesAmount garantisce che ogni consumatore usi lo stesso calcolo.

Poiché la definizione della misura si trova con i dati, diventa l'unica fonte di verità per tale metrica. Quando l'azienda cambia il modo in cui calcola i ricavi, si aggiorna la misura in un'unica posizione anziché tenere traccia di ogni report contenente la propria formula.

Insieme, visualizzazioni e misure riguardano entrambi i lati del consumo: le visualizzazioni standardizzano il modo in cui i consumatori T-SQL accedono ed eseguono query sui dati, mentre le misure standardizzano il modo in cui i calcoli aziendali appaiono nei rapporti e nelle dashboard.

Creare un modello semantico per la creazione di report di Power BI

Con tabelle preparate, relazioni definite e misure e viste standardizzate in essere, il warehouse è pronto per il reporting downstream. I team che eseguono query direttamente sul warehouse usando T-SQL o si connettono tramite strumenti di terze parti possono usare il modello di warehouse as-is. Tuttavia, quando si vogliono creare report e dashboard interattivi di Power BI, la creazione di un modello semantico è il passaggio successivo.

I modelli semantici creati da un warehouse Fabric usano la modalità Direct Lake. A differenza della modalità di importazione tradizionale, che copia i dati nella memoria di Power BI, Direct Lake legge i dati direttamente dai file Parquet di OneLake. Ciò significa che i report riflettono i dati del warehouse più recenti senza richiedere aggiornamenti pianificati. Ciò significa anche evitare il sovraccarico di storage ed elaborazione della gestione di una copia separata dei dati.