Modellazione dimensionale in Microsoft Fabric Warehouse: tabelle dei fatti

Si applica a:✅ endpoint di Analisi SQL e Warehouse in Microsoft Fabric

Nota

Questo articolo fa parte della serie di articoli sulla modellazione dimensionale. Questa serie si basa su materiale sussidiario e procedure consigliate per la progettazione relativa alla modellazione dimensionale in Microsoft Fabric Warehouse.

Questo articolo fornisce indicazioni e procedure consigliate per la progettazione di tabelle dei fatti in un modello dimensionale. Fornisce una guida pratica per Warehouse in Microsoft Fabric, un'esperienza che supporta molte funzionalità T-SQL, come la creazione di tabelle e la gestione dei dati nelle tabelle. Si ha, quindi, il pieno controllo sulla creazione delle tabelle del modello dimensionale e sul caricamento dei dati.

Nota

In questo articolo il termine data warehouse si riferisce a un data warehouse aziendale, che fornisce un'integrazione completa dei dati critici nell'organizzazione. Al contrario, il termine warehouse da solo si riferisce a un Fabric Warehouse, ovvero un database relazionale SaaS (Software as a Service) che è possibile usare per implementare un data warehouse. Per maggiore chiarezza, in questo articolo verrà usato il termine Fabric Warehouse.

Suggerimento

Se si è inesperti con la modellazione dimensionale, prendere in considerazione questa serie di articoli come primo passo. Non è pensato per fornire una discussione completa sulla progettazione di modellazione dimensionale. Per altre informazioni, vedere direttamente il contenuto pubblicato ampiamente adottato, ad esempio The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling (terza edizione, 2013) di Ralph Kimball e altri.

In un modello dimensionale una tabella dei fatti archivia le misurazioni associate a osservazioni o eventi. Potrebbe archiviare ordini di vendita, saldi azionari, tassi di cambio, letture della temperatura e altro ancora.

Le tabelle dei fatti includono misure, che sono in genere colonne numeriche, ad esempio la quantità degli ordini di vendita. Le query analitiche riepilogano le misure (usando sum, count, average e altre funzioni) all'interno del contesto dei filtri e dei raggruppamenti delle dimensioni.

Le tabelle dei fatti includono anche chiavi di dimensione, che determinano la dimensionalità dei fatti. I valori chiave della dimensione determinano la granularità dei fatti, ovvero il livello atomico in base al quale vengono definiti i fatti. Ad esempio, una chiave della dimensione della data dell'ordine in una tabella dei fatti di vendita imposta la granularità dei fatti a livello di data, mentre una chiave della dimensione data di destinazione in una tabella dei fatti di destinazione delle vendite potrebbe impostare la granularità a livello di trimestre.

Nota

Sebbene sia possibile archiviare i fatti a una granularità più elevata, non è facile suddividere i valori delle misure in livelli inferiori di granularità (se necessario). I volumi di dati più grandi, insieme ai requisiti analitici, possono fornire un motivo valido per archiviare fatti di granularità più elevati, ma a scapito dell'analisi dettagliata.

Per identificare facilmente le tabelle dei fatti, in genere si assegnano prefissi con f_ o Fact_ ai nomi.

Estrarre la struttura della tabella

Per descrivere la struttura di una tabella dei fatti, considerare l'esempio seguente di una tabella dei fatti di vendita denominata f_Sales. Questo esempio applica procedure di progettazione consigliate. Ogni gruppo di colonne viene descritto nelle sezioni seguenti.

CREATE TABLE f_Sales
(
    --Dimension keys
    OrderDate_Date_FK INT NOT NULL,
    ShipDate_Date_FK INT NOT NULL,
    Product_FK INT NOT NULL,
    Salesperson_FK INT NOT NULL,
    <…>
    
    --Attributes
    SalesOrderNo INT NOT NULL,
    SalesOrderLineNo SMALLINT NOT NULL,
    
    --Measures
    Quantity INT NOT NULL,
    <…>
    
    --Audit attributes
    AuditMissing BIT NOT NULL,
    AuditCreatedDate DATE NOT NULL,
    AuditCreatedBy VARCHAR(15) NOT NULL,
    AuditLastModifiedDate DATE NOT NULL,
    AuditLastModifiedBy VARCHAR(15) NOT NULL
);

Chiave primaria

Come nel caso dell'esempio, la tabella dei fatti di esempio non ha una chiave priomario. Ciò è dovuto al fatto che in genere non serve uno scopo utile e aumenterebbe inutilmente le dimensioni di archiviazione delle tabelle. Una chiave primaria è spesso implicita nel set di chiavi e attributi delle dimensioni.

Chiavi di dimensione

La tabella dei fatti di esempio include diverse chiavi di dimensione, che determinano la dimensionalità della tabella dei fatti. Le chiavi delle dimensioni sono riferimenti alle chiavi surrogate (o attributi di livello superiore) nelle dimensioni correlate.

Nota

Si tratta di una tabella dei fatti insolita che non include almeno una chiave della dimensione data.

Una tabella dei fatti può fare riferimento a una dimensione più volte. In questo caso, è nota come dimensione di ruolo. In questo esempio la tabella dei fatti contiene le chiavi della dimensione OrderDate_Date_FK e ShipDate_Date_FK. Ogni chiave della dimensione rappresenta un ruolo distinto, ma esiste una sola dimensione data effettiva.

È consigliabile impostare ogni chiave di dimensione come NOT NULL. Durante il caricamento della tabella dei fatti, è possibile utilizzare membri di dimensioni speciali per rappresentare stati di errore mancanti, sconosciuti, N/D o errori, se necessario.

Attributi

La tabella dei fatti di esempio ha due attributi. Gli attributi forniscono informazioni aggiuntive e impostano la granularità dei dati della tabella dei fatti, ma non sono chiavi di dimensione né attributi di dimensione, né misure. In questo esempio le colonne dell'attributo archiviano le informazioni sugli ordini di vendita. Altri esempi possono includere numeri di monitoraggio o numeri di ticket. Ai fini dell'analisi, un attributo potrebbe formare una dimensione degenere.

Misure

La tabella dei fatti di esempio include anche misure, ad esempio la colonna Quantity. Le colonne di misura sono in genere numeriche e comunemente aggregabili (ovvero possono essere sommate e riepilogate usando altre aggregazioni). Per altre informazioni, vedere la sezione Tipi di misura di seguito in questo articolo.

Attributi di controllo

La tabella dei fatti di esempio include anche vari attributi di controllo. Gli attributi di controllo sono facoltativi. Consentono di tenere traccia di quando e come i record dei fatti sono stati creati o modificati e possono includere informazioni di diagnostica o risoluzione dei problemi generate durante i processi ETL (Extract, Transform e Load - estrai, trasforma, carica). Ad esempio, è necessario tenere traccia di chi (o quale processo) ha aggiornato una riga e quando. Gli attributi di controllo permettono anche di diagnosticare un problema complesso, ad esempio l'arresto imprevisto di un processo ETL.

Dimensione tabella dei fatti

Le tabelle dei fatti variano in dimensioni. La loro dimensione corrisponde alla dimensionalità, alla granularità, al numero di misure e alla quantità di cronologia. Rispetto alle tabelle delle dimensioni, le tabelle dei fatti sono più strette (meno colonne), ma grandi o persino immense in termini di righe (in eccesso di miliardi).

Concetti relativi alla progettazione dei fatti

In questa sezione vengono descritti vari concetti di progettazione dei fatti.

Tipi di tabella dei fatti

Esistono tre tipi di tabella dei fatti:

• Tabelle dei fatti delle transazioni
• Tabelle dei fatti di snapshot periodici
• Tabelle dei fatti di accumulazione di snapshot

Tabelle dei fatti delle transazioni

Una tabella dei fatti delle transazioni archivia gli eventi o le transazioni aziendali. Ogni riga archivia i fatti in termini di chiavi di dimensione e misure e, facoltativamente, altri attributi. Tutti i dati sono completamente noti quando vengono inseriti e non cambiano mai (tranne per correggere gli errori).

In genere, le tabelle dei fatti delle transazioni archiviano i fatti al livello più basso possibile di granularità e contengono misure che sono aggregabili in tutte le dimensioni. Una tabella dei fatti di vendita che archivia ogni riga dell'ordine di vendita è un ottimo esempio di una tabella dei fatti delle transazioni.

Tabelle dei fatti di snapshot periodici

Una tabella dei fatti di snapshot periodici archivia le misurazioni in base a un intervallo predefinito o a intervalli specifici. Fornisce un riepilogo delle metriche chiave o degli indicatori di prestazioni nel tempo, quindi è utile per l'analisi delle tendenze e il monitoraggio delle modifiche nel tempo. Le misure sono sempre semi-aggregabili (descritte più avanti).

Una tabella dei fatti di inventario è un ottimo esempio di una tabella snapshot periodica. Viene caricato ogni giorno con il saldo azionario di fine giornata di ogni prodotto.

Le tabelle snapshot periodiche possono essere usate invece di una tabella dei fatti delle transazioni quando si registrano volumi elevati di transazioni è costosa e non supporta alcun requisito analitico utile. Ad esempio, potrebbero esserci milioni di movimenti azionari in un giorno (che potrebbero essere archiviati in una tabella dei fatti delle transazioni), ma l'analisi riguarda solo le tendenze dei livelli azionari di fine giornata.

Tabelle dei fatti di accumulazione di snapshot

Una tabella dei fatti di accumulazione di snapshot archivia le misurazioni che si accumulano in un periodo o un flusso di lavoro ben definito. Spesso registra lo stato di un processo aziendale in fasi o attività cardine distinte, che possono richiedere giorni, settimane o persino mesi per il completamento.

Una riga dei fatti viene caricata subito dopo il primo evento in un processo e quindi la riga viene aggiornata in una sequenza stimabile ogni volta che si verifica un evento cardine. Gli aggiornamenti continuano fino al completamento del processo.

La tabella dei fatti di accumulazione di snapshot ha più chiavi della dimensione dei dati, ognuna che rappresenta un evento cardine. Alcune chiavi della dimensione potrebbero registrare uno stato N/D fino a quando il processo non arriva a una determinata attività cardine. Misura in genere la durata dei record. La durata tra le attività cardine può fornire informazioni utili su un flusso di lavoro aziendale o un processo di assembly.

Tipi di misura

Le misure sono in genere numeriche e comunemente aggregabili. Tuttavia, per alcune misure non è possibile effettuare una somma. Queste misure sono classificate come semi-aggregabili o non aggregabili.

Misure aggregabili

Una misura aggregabile può essere sommata in qualsiasi dimensione. Ad esempio, la quantità di ordini e i ricavi delle vendite sono misure aggiuntive (la fornitura di ricavi viene registrata per una singola valuta).

Misure semiadditive

Una misura semi-aggregabile può essere sommata solo in determinate dimensioni.

Ecco alcuni esempi di metriche semi-aggregabili.

• Qualsiasi misura in una tabella dei fatti snapshot periodica non può essere sommata in altri periodi di tempo. Ad esempio, non è consigliabile sommare l'età di un articolo di magazzino campionato ogni notte, ma è possibile sommare l'età di tutti gli articoli di magazzino su uno scaffale, ogni notte.
• Una misura di saldo azionario in una tabella dei fatti dell'inventario non può essere sommata con altri prodotti.
• I ricavi delle vendite in una tabella dei fatti di vendita con una chiave della dimensione valuta non possono essere sommati tra valute diverse.

Misure non aggregabili

Una misura non aggregabile non può essere sommata in nessuna dimensione. Un esempio è una lettura della temperatura, che per sua natura non ha senso aggiungere ad altre letture.

Altri esempi includono tassi, ad esempio i prezzi unitari e i rapporti. Tuttavia, è considerata una procedura migliore archiviare i valori usati per calcolare il rapporto, consentendo di calcolare il rapporto, se necessario. Ad esempio, una percentuale di sconto di un fatto di vendita può essere archiviata come misura di importo dello sconto (da dividere per la misura dei ricavi di vendita). Oppure, l'età di un articolo di magazzino sullo scaffale non deve essere sommata nel tempo, ma si potrebbe osservare una tendenza nell'età media degli articoli di magazzino.

Anche se alcune misure non possono essere sommate, sono comunque misure valide. Possono essere aggregate usando count, distinct count, minimum, maximum, average e altre. Inoltre, le misure non aggregabili possono diventare aggregabili quando vengono usate nei calcoli. Ad esempio, il prezzo unitario moltiplicato per la quantità di ordini produce ricavi di vendita, che è aggregabile.

Tabelle dei fatti senza fatti

Quando una tabella dei fatti non contiene colonne di misura, viene chiamata tabella dei fatti senza fatti. Una tabella dei fatti senza fatti registra in genere eventi o occorrenze, ad esempio la presenza degli studenti alle lezioni. Dal punto di vista dell'analisi, è possibile ottenere una misurazione conteggiando le righe dei fatti.

Tabelle dei fatti di aggregazione

Una tabella dei fatti di aggregazione rappresenta un rollup di una tabella dei fatti di base a una granularità inferiore e/o superiore. Lo scopo è accelerare le prestazioni delle query per le dimensioni comunemente sottoposte a query.

Nota

Un modello semantico di Power BI può generare aggregazioni definite dall'utente per ottenere lo stesso risultato o usare la tabella dei fatti di aggregazione del data warehouse usando la modalità di archiviazione DirectQuery.

Contenuto correlato

Nel prossimo articolo di questa serie vengono fornite informazioni sulle linee guida e sulle procedure consigliate per la progettazione per il caricamento di tabelle dei modelli dimensionali.