Modellazione dimensionale in Microsoft Fabric Warehouse: tabelle delle dimensioni

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 materiale sussidiario e procedure consigliate per la progettazione di tabelle delle dimensioni 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 delle dimensioni descrive un'entità rilevante per i requisiti aziendali e di analisi. In generale, le tabelle delle dimensioni rappresentano gli elementi modellati. Gli elementi possono essere prodotti, persone, luoghi o qualsiasi altro concetto, tra cui data e ora. Per identificare facilmente le tabelle delle dimensioni, in genere si assegnano prefissi con d_ o Dim_ ai nomi.

Struttura tabella delle dimensioni

Per descrivere la struttura di una tabella delle dimensioni, considerare l'esempio seguente di una tabella delle dimensioni di venditori denominata d_Salesperson. Questo esempio applica procedure di progettazione consigliate. Ogni gruppo di colonne viene descritto nelle sezioni seguenti.

CREATE TABLE d_Salesperson
(
    --Surrogate key
    Salesperson_SK INT NOT NULL,
    
    --Natural key(s)
    EmployeeID VARCHAR(20) NOT NULL,
    
    --Dimension attributes
    FirstName VARCHAR(20) NOT NULL,
    <…>
    
    --Foreign key(s) to other dimensions
    SalesRegion_FK INT NOT NULL,
    <…>
    
    --Historical tracking attributes (SCD type 2)
    RecChangeDate_FK INT NOT NULL,
    RecValidFromKey INT NOT NULL,
    RecValidToKey INT NOT NULL,
    RecReason VARCHAR(15) NOT NULL,
    RecIsCurrent BIT NOT NULL,
    
    --Audit attributes
    AuditMissing BIT NOT NULL,
    AuditIsInferred BIT NOT NULL,
    AuditCreatedDate DATE NOT NULL,
    AuditCreatedBy VARCHAR(15) NOT NULL,
    AuditLastModifiedDate DATE NOT NULL,
    AuditLastModifiedBy VARCHAR(15) NOT NULL
);

Chiave sostitutiva

La tabella delle dimensioni di esempio ha una chiave sostitutiva denominata Salesperson_SK. Una chiave sostitutiva è un identificatore univoco a colonna singola generato e archiviato nella tabella delle dimensioni. Si tratta di una colonna chiave primaria usata per correlare ad altre tabelle nel modello dimensionale.

Le chiavi sostitutive cercano di isolare il data warehouse dalle modifiche apportate ai dati di origine. Forniscono anche molti altri vantaggi, in quanto consentono di:

• Consolidare più origini dati (evitando conflitti di identificatori duplicati).
• Consolidare le chiavi naturali multicolonna in una chiave a colonna singola più efficiente.
• Tenere traccia della cronologia delle dimensioni con una dimensione modificabile lentamente (SCD) di tipo 2.
• Limitare la larghezza della tabella dei fatti per l'ottimizzazione dell'archiviazione (selezionando il tipo di dati Integer più piccolo possibile).

Una colonna chiave sostitutiva è una procedura consigliata, anche quando una chiave naturale (descritta di seguito) sembra un candidato accettabile. È consigliabile, inoltre, evitare di dare significato ai valori chiave (ad eccezione delle chiavi delle dimensioni data e delle dimensioni temporali, come illustrato più avanti).

Chiavi naturali

La tabella delle dimensioni di esempio ha anche una chiave naturale, denominata EmployeeID. Una chiave naturale è la chiave archiviata nel sistema di origine. Consente di correlare i dati delle dimensioni al sistema di origine, il che avviene in genere tramite un processo ETL (Extract, Load and Transform) per caricare la tabella delle dimensioni. A volte una chiave naturale è detta chiave aziendale. In questo caso, i relativi valori possono essere significativi per gli utenti aziendali.

Altre volte le dimensioni non hanno una chiave naturale. Questo può essere il caso della dimensione data o delle dimensioni di ricerca, oppure quando si generano dati delle dimensioni normalizzando un file flat.

Attributi dimensione

Una tabella delle dimensioni di esempio include anche attributi delle dimensioni, ad esempio la colonna FirstName. Gli attributi delle dimensioni forniscono contesto ai dati numerici archiviati nelle tabelle dei fatti correlate. In genere, si tratta di colonne di testo usate nelle query analitiche per filtrare e raggruppare (suddividere in parti più piccole), ma non per essere aggregate. Alcune tabelle delle dimensioni contengono pochi attributi, mentre altre ne contengono molti (quanti ne servono per supportare i requisiti di query del modello dimensionale).

Suggerimento

Un buon modo per determinare le dimensioni e gli attributi necessari è trovare le persone giuste e porre le domande giuste. In particolare, mantenere l'avviso per la menzione della parola per. Ad esempio, quando un utente dice di dover analizzare le vendite per venditore, per mese e per categoria di prodotto, intende dire che ha bisogno di dimensioni con tali attributi.

Se si prevede di creare un modello semantico Direct Lake, è necessario includere tutte le colonne possibili necessarie per filtrare e raggruppare come attributi della dimensione. Questo accade perché i modelli semantici Direct Lake non supportano le colonne calcolate.

Chiavi esterne

La tabella delle dimensioni di esempio ha anche una chiave esterna, denominata SalesRegion_FK. Altre tabelle delle dimensioni possono fare riferimento a una chiave esterna, la cui presenza in una tabella delle dimensioni rappresenta un caso speciale. Indica che la tabella è correlata a un'altra tabella delle dimensioni, vale a dire che potrebbe far parte di una dimensione snowflake o è correlata a una dimensione outrigger.

Fabric Warehouse supporta vincoli di chiave esterna, che tuttavia non possono essere applicati. Pertanto, è importante che il processo ETL verifichi l'integrità tra le tabelle correlate durante il caricamento dei dati.

È comunque consigliabile creare chiavi esterne. Un buon motivo per creare chiavi esterne non attuabili è consentire agli strumenti di modellazione, come Power BI Desktop, di rilevare e creare automaticamente relazioni tra tabelle nel modello semantico.

Attributi di rilevamento cronologico

La tabella delle dimensioni di esempio include anche vari attributi di rilevamento cronologico. Gli attributi di rilevamento cronologico sono facoltativi e dipendono dalla necessità di tenere traccia di modifiche specifiche che si verificano nel sistema di origine. Consentono di archiviare i valori per supportare il ruolo primario di un data warehouse, che consiste nel descrivere accuratamente il passato. In particolare, questi attributi archiviano il contesto cronologico quando il processo ETL carica dati nuovi o modificati nella dimensione.

Per altre informazioni, vedere Gestire le modifiche cronologiche di seguito in questo articolo.

Attributi di controllo

La tabella delle dimensioni di esempio include anche vari attributi di controllo. Gli attributi di controllo sono facoltativi ma consigliati. Consentono di tenere traccia di quando e come i record delle dimensioni sono stati creati o modificati e possono includere informazioni di diagnostica o risoluzione dei problemi generate durante i processi ETL. 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. Possono anche contrassegnare i membri di dimensione come errori o membri dedotti.

Dimensione tabella delle dimensioni

Spesso, le dimensioni più utili e versatili in un modello dimensionale sono quelle grandi e ampie. Sono grandi in termini di righe (milioni e milioni) e ampie in termini di numero di attributi della dimensione (potenzialmente centinaia). Le dimensioni non sono così importanti (anche se bisognerebbe progettare e ottimizzare per le dimensioni più piccole possibili). Ciò che conta è che la dimensione supporti il filtro, il raggruppamento e l'analisi cronologica accurata dei dati dei fatti necessari.

Più sistemi di origine potrebbero originare grandi dimensioni. In questo caso, l'elaborazione delle dimensioni deve combinare, unire, deduplicare e normalizzare i dati; nonché assegnare chiavi sostitutive.

In confronto, alcune dimensioni sono minuscole. Possono rappresentare tabelle di ricerca che contengono solo vari record e attributi. Spesso queste dimensioni piccole archiviano i valori di categoria correlati alle transazioni nelle tabelle dei fatti e vengono implementate come dimensioni con chiavi sostitutive per correlare ai record dei fatti.

Suggerimento

Se si hanno molte dimensioni piccole, è consigliabile consolidarle in una dimensione indesiderata.

Concetti relativi alla progettazione delle dimensioni

In questa sezione vengono illustrati vari concetti relativi alla progettazione delle dimensioni.

Denormalizzazione e normalizzazione a confronto

È quasi sempre il caso in cui le tabelle delle dimensioni debbano essere denormalizzate. Mentre la normalizzazione è il termine usato per descrivere i dati archiviati in modo da ridurre i dati ripetitivi, la denormalizzazione è il termine usato per definire i casi in cui esistono dati ridondanti pre-calcolati. I dati ridondanti sono in genere dovuti all'archiviazione delle gerarchie (di cui si parlerà in seguito), ovvero all'appiattimento delle gerarchie. Ad esempio, una dimensione prodotto può archiviare sottocategorie (e gli attributi correlati) e categorie (e gli attributi correlati).

Poiché le dimensioni sono in genere piccole (rispetto alle tabelle dei fatti), il costo dell'archiviazione dei dati ridondanti è quasi sempre compensato dal miglioramento delle prestazioni e dell'utilizzabilità delle query.

Dimensioni a fiocco di neve

Un'eccezione alla denormalizzazione consiste nella progettazione di una dimensione snowflake. Una dimensione snowflake viene normalizzata e archivia i dati della dimensione in diverse tabelle correlate.

Il diagramma seguente illustra una dimensione snowflake che comprende tre tabelle delle dimensioni correlate: Product, Subcategory e Category.

È consigliabile implementare una dimensione snowflake quando:

• La dimensione è estremamente grande e i costi di archiviazione superano la necessità di prestazioni elevate delle query. (Tuttavia, si consiglia di valutare periodicamente che sia ancora questo il caso.)
• Sono necessarie chiavi per correlare la dimensione a fatti più granulari. Ad esempio, la tabella dei fatti sulle vendite archivia le righe a livello di prodotto, ma la tabella dei fatti sugli obiettivi di vendita archivia le righe a livello di sottocategoria.
• È necessario tenere traccia delle modifiche cronologiche a livelli più elevati di granularità.

Nota

Tenere presente che una gerarchia in un modello semantico di Power BI può basarsi solo sulle colonne di una singola tabella del modello semantico. Pertanto, una dimensione snowflake deve fornire un risultato denormalizzato usando una visualizzazione che unisce le tabelle snowflake.

Gerarchie

In genere, le colonne delle dimensioni producono gerarchie. Le gerarchie consentono di esplorare i dati a livelli distinti di riepilogo. Ad esempio, la visualizzazione iniziale di un oggetto visivo matrice può mostrare le vendite annuali e l'utente del report può scegliere di eseguire il drill-down per visualizzare le vendite trimestrali e mensili.

Esistono tre modi per archiviare una gerarchia in una dimensione. Puoi usare:

• Colonne di una singola dimensione denormalizzata.
• Una dimensione snowflake che comprende più tabelle correlate.
• Una relazione padre-figlio (autoreferenziazione) in una dimensione.

Le gerarchie possono essere bilanciate o sbilanciate. Inoltre, è importante capire che alcune gerarchie sono incomplete.

Gerarchie bilanciate

Le gerarchie bilanciate sono il tipo di gerarchia più comune. Una gerarchia bilanciata ha lo stesso numero di livelli. Un esempio comune di gerarchia bilanciata è una gerarchia di calendario in una dimensione data che comprende i livelli per anno, trimestre, mese e giorno.

Il diagramma seguente illustra una gerarchia bilanciata delle aree di vendita. Comprende due livelli, ovvero il gruppo di aree di vendita e l'area di vendita.

I livelli di una gerarchia bilanciata si basano su colonne di una singola dimensione denormalizzata o di tabelle che formano una dimensione snowflake. Quando si basano su una singola dimensione denormalizzata, le colonne che rappresentano i livelli più elevati contengono dati ridondanti.

Per le gerarchie bilanciate, i fatti si correlano sempre a un singolo livello della gerarchia, che in genere è il livello più basso. In questo modo, i fatti possono essere aggregati al livello più alto della gerarchia (viene eseguito il rollup). I fatti possono essere correlati a qualsiasi livello, in base all'intervallo della tabella dei fatti. Ad esempio, la tabella dei fatti sulle vendita può essere archiviata a livello di data, mentre la tabella dei fatti sugli obiettivi di vendita può essere archiviata a livello di trimestre.

Gerarchie sbilanciate

Le gerarchie sbilanciate sono un tipo meno comune di gerarchia. Una gerarchia sbilanciata presenta livelli basati su una relazione padre-figlio. Per questo motivo, il numero di livelli in una gerarchia sbilanciata è determinato dalle righe della dimensione e non dalle colonne specifiche della tabella delle dimensioni.

Un esempio comune di una gerarchia sbilanciata è una gerarchia di dipendenti in cui ogni riga di una dimensione di dipendenti è correlata a una riga di un reporting manager nella stessa tabella. In questo caso, qualsiasi dipendente può essere un manager con dipendenti incaricati del reporting. Naturalmente, alcuni rami della gerarchia avranno più livelli di altri.

Il diagramma seguente illustra una gerarchia sbilanciata. Comprende quattro livelli, in cui ogni membro nella gerarchia è un venditore. Bisogna sottolineare che i venditori hanno un numero diverso di predecessori nella gerarchia a seconda del loro referente.

Altri esempi comuni di gerarchie sbilanciate includono la fatturazione dei materiali, modelli di titolarità aziendale e la contabilità generale.

Per le gerarchie sbilanciate, i fatti sono sempre correlati all'intervallo della dimensione. Ad esempio, i fatti sulle vendite sono correlati a venditori diversi, che presentano strutture di reporting diverse. La tabella delle dimensioni avrà una chiave sostitutiva (denominata Salesperson_SK) e una colonna chiave esterna ReportsTo_Salesperson_FK che fa riferimento alla colonna chiave primaria. I venditori senza nessuno da gestire non sono necessariamente al livello più basso dei rami della gerarchia. Quando non è al livello più basso, un venditore può vendere prodotti e avere venditori incaricati del reporting che vendono anch'essi prodotti. Pertanto, il rollup dei dati dei fatti deve considerare il singolo venditore e tutti i relativi discendenti.

L'esecuzione di query sulle gerarchie padre-figlio può essere lenta e complessa, soprattutto per grandi dimensioni. Sebbene il sistema di origine possa archiviare le relazioni come padre-figlio, è consigliabile naturalizzare la gerarchia. In questo caso, naturalizzare significa trasformare e archiviare i livelli della gerarchia nella dimensione sotto forma di colonne.

Suggerimento

Se si sceglie di non naturalizzare la gerarchia, è comunque possibile creare una gerarchia basata su una relazione padre-figlio in un modello semantico di Power BI. Tuttavia, questo approccio non è consigliato per grandi dimensioni. Per altre informazioni, vedere Informazioni sulle funzioni per le gerarchie padre-figlio in DAX.

Gerarchie incomplete

A volte una gerarchia è incompleta perché l'elemento padre di un membro della gerarchia si trova a un livello che non è immediatamente superiore. In questi casi, i valori mancanti del livello ripetono il valore dell'elemento padre.

Si consideri un esempio di gerarchia geografica bilanciata. Una gerarchia incompleta esiste quando un paese/area geografica non ha province. Ad esempio, la Nuova Zelanda non ha province. Quindi, quando si inserisce la riga Nuova Zelanda, è necessario archiviare anche il valore paese/area geografica nella colonna StateProvince.

Il diagramma seguente rappresenta una gerarchia incompleta di aree geografiche.

Gestire le modifiche cronologiche

Quando necessario, è possibile gestire le modifiche cronologiche implementando una dimensione modificabile lentamente (SCD). Una SCD mantiene il contesto cronologico quando vi vengono caricati dati nuovi o modificati.

Di seguito sono riportati i tipi di SCD più comuni.

• Tipo 1: sovrascrivere il membro della dimensione esistente.
• Tipo 2: inserire un nuovo membro di dimensione con controllo delle versioni basato sul tempo.
• Tipo 3: tenere traccia della cronologia limitata con gli attributi.

È possibile che una dimensione supporti sia le modifiche SCD di tipo 1 che le modifiche SCD di tipo 2.

La SCD di tipo 3 non è comunemente usata, in parte perché è difficile da usare in un modello semantico. È opportuno valutare attentamente se un approccio di SCD di tipo 2 sia più adatto.

Suggerimento

Se ci si aspetta una dimensione modificabile rapidamente, ovvero una dimensione con un attributo che cambia frequentemente, è consigliabile aggiungere tale attributo alla tabella dei fatti. Se l'attributo è numerico, come il prezzo del prodotto, è possibile aggiungerlo come misura nella tabella dei fatti. Se l'attributo è un valore di testo, è possibile creare una dimensione basata su tutti i valori di testo e aggiungerne la chiave di dimensione alla tabella dei fatti.

SCD di tipo 1

Le modifiche apportate alla SCD di tipo 1 sovrascrivono la riga della dimensione esistente perché non è necessario tenere traccia delle modifiche. Questo tipo di SCD può essere usato anche per correggere gli errori. Si tratta di un tipo comune di SCD da usare per la maggior parte degli attributi modificabili, ad esempio il nome del cliente, l'indirizzo email e altri.

Il diagramma seguente illustra lo stato precedente e successivo di un membro di dimensione venditore in cui è stato modificato il numero di telefono.

Questo tipo di SCD non mantiene la prospettiva cronologica perché la riga esistente viene aggiornata. Ciò significa che le modifiche della SCD di tipo 1 possono comportare diverse aggregazioni di livello superiore. Ad esempio, se un venditore viene assegnato a un'altra area di vendita, la modifica alla SCD di tipo 1 sovrascriverà la riga della dimensione. Il rollup dei risultati cronologici di vendita dei venditori per area genererebbe quindi un risultato diverso perché usa la nuova area di vendita corrente. È come se quel venditore fosse sempre assegnato alla nuova area di vendita.

SCD di tipo 2

Le modifiche alla SCD di tipo 2 comportano nuove righe che rappresentano una versione basata sul tempo di un membro di dimensione. Esiste sempre una riga di versione corrente che riflette lo stato del membro di dimensione nel sistema di origine. Gli attributi di rilevamento cronologico nella tabella delle dimensioni archiviano valori che consentono di identificare la versione corrente (il flag corrente è TRUE) e il relativo periodo di validità. È necessaria una chiave sostitutiva in quanto saranno presenti chiavi naturali duplicate quando si archiviano più versioni.

Si tratta di un tipo comune di SCD da riservare, tuttavia, agli attributi che devono mantenere la prospettiva cronologica.

Ad esempio, se un venditore viene assegnato a un'altra area di vendita, una modifica alla SCD di tipo 2 comporta un'operazione di aggiornamento e un'operazione di inserimento.

1. L'operazione di aggiornamento sovrascrive la versione corrente per impostare gli attributi di rilevamento cronologico. In particolare, la colonna di fine validità viene impostata sulla data di elaborazione ETL (o su una data e ora appropriate nel sistema di origine), mentre il flag corrente è impostato su FALSE.
2. L'operazione di inserimento aggiunge una nuova versione corrente, impostando la colonna di inizio validità sul valore della colonna di fine validità (usato per aggiornare la versione precedente) e il flag corrente su TRUE.

È importante comprendere che la granularità delle tabelle dei fatti correlate non è a livello di venditore, ma piuttosto a livello di versione del venditore. Il rollup dei risultati di vendita cronologici per area genererà risultati corretti, ma ci saranno due (o più) versioni dei membri venditore da analizzare.

Il diagramma seguente illustra lo stato precedente e successivo di un membro di dimensione venditore in cui è stata modificata l'area di vendita. Poiché l'organizzazione vuole analizzare il lavoro richiesto ai venditori in base all'area a cui sono assegnati, attiva una modifica alla SCD di tipo 2.

Suggerimento

Quando una tabella delle dimensioni supporta modifiche alla SCD di tipo 2, è necessario includere un attributo etichetta che descriva il membro e la versione. Si consideri il seguente esempio: il venditore Lynn Tsoflias di Adventure Works cambia incarico dall'area di vendita dell'Australia all'area di vendita del Regno Unito. L'attributo etichetta per la prima versione potrebbe essere "Lynn Tsoflias (Australia)", mentre l'attributo etichetta per la nuova versione corrente potrebbe essere "Lynn Tsoflias (Regno Unito)." Se utile, è possibile includere nell'etichetta anche le date di validità.

È consigliabile bilanciare la necessità di accuratezza della cronologia con l'utilizzabilità e l'efficienza. Provare a evitare di apportare troppe modifiche alla SCD di tipo 2 in una tabella delle dimensioni, in quanto può comportare un numero eccessivo di versioni che possono ostacolare la comprensione da parte degli analisti.

Inoltre, la presenza di troppe versioni potrebbe indicare una migliore archiviazione di un attributo modificabile nella tabella dei fatti. Riprendendo l'esempio precedente, se le modifiche all'area di vendita sono frequenti, l'area di vendita può essere archiviata come chiave di dimensione nella tabella dei fatti, piuttosto che implementare una SCD di tipo 2.

Si considerino i seguenti attributi di rilevamento cronologico di una SCD di tipo 2.

CREATE TABLE d_Salesperson
(
    <…>

    --Historical tracking attributes (SCD type 2)
    RecChangeDate_FK INT NOT NULL,
    RecValidFromKey INT NOT NULL,
    RecValidToKey INT NOT NULL,
    RecReason VARCHAR(15) NOT NULL,
    RecIsCurrent BIT NOT NULL,

    <…>
);

Di seguito sono riportati gli scopi degli attributi di rilevamento cronologico.

• La colonna RecChangeDate_FK archivia la data di entrata in vigore della modifica. Consente di eseguire query quando sono state apportate modifiche.
• Le colonne RecValidFromKey e RecValidToKey archiviano le date di entrata in vigore della riga. È consigliabile archiviare la data meno recente trovata nella dimensione data per RecValidFromKey allo scopo di rappresentare la versione iniziale e archiviare 01/01/9999 per il RecValidToKey delle versioni correnti.
• La colonna RecReason è facoltativa. Consente di documentare il motivo per cui è stata inserita la versione. Può codificare gli attributi modificati oppure può trattarsi di un codice del sistema di origine che indica un motivo aziendale specifico.
• La colonna RecIsCurrent consente di riprendere solo le versioni correnti. Viene usato quando il processo ETL cerca le chiavi delle dimensioni durante il caricamento delle tabelle dei fatti.

Nota

Alcuni sistemi di origine non archiviano modifiche cronologiche, quindi è importante che la dimensione venga elaborata regolarmente per rilevare le modifiche e implementare le nuove versioni. In questo modo, è possibile rilevare le modifiche poco dopo che si sono verificate e le relative date di validità saranno precise.

SCD di tipo 3

Le modifiche alla SCD di tipo 3 tengono traccia della cronologia limitata con gli attributi. Questo approccio può essere utile quando è necessario registrare l'ultima modifica o una serie di modifiche più recenti.

Questo tipo di SCD mantiene una prospettiva cronologica limitata. Può rivelarsi utile quando devono essere archiviati solo i valori iniziali e correnti. In questo caso, le modifiche provvisorie non sono necessarie.

Ad esempio, se un venditore viene assegnato a un'altra area di vendita, la modifica alla SCD di tipo 3 sovrascriverà la riga della dimensione. Una colonna che archivia specificamente l'area di vendita precedente viene impostata come area di vendita precedente e la nuova area di vendita viene impostata come area di vendita corrente.

Il diagramma seguente illustra lo stato precedente e successivo di un membro di dimensione venditore in cui è stata modificata l'area di vendita. Dal momento che l'organizzazione vuole determinare qualsiasi assegnazione precedente dell'area di vendita, attiva una modifica alla SCD di tipo 3.

Membri di dimensione speciale

È possibile inserire in una dimensione righe che rappresentano stati mancanti, sconosciuti, N/D o di errore. Ad esempio, è possibile usare i seguenti valori di chiavi sostitutive.

Valore di chiave	Scopo
0	Mancante (non disponibile nel sistema di origine)
-1	Sconosciuto (errore di ricerca durante il caricamento di una tabella dei fatti)
-2	N/D (non disponibile)
-3	Error

Calendario e orario

Quasi senza eccezioni, le tabelle dei fatti archiviano misure in momenti specifici. Per supportare l'analisi per data (ed eventualmente orario), sono necessarie dimensioni di calendario (data e ora).

È raro che un sistema di origine disponga dei dati relativi alla dimensione calendario. Devono quindi essere generati nel data warehouse. In genere, vengono generati una sola volta e, se si tratta di una dimensione calendario, vengono estesi con date future quando necessario.

Dimensione data

La dimensione data (o calendario) è la dimensione più comune usata per l'analisi. Archivia una riga per ogni data e supporta il requisito comune di filtrare o raggruppare per periodi specifici di date, come anni, trimestri o mesi.

Importante

Una dimensione data non deve includere un intervallo che si estende all'ora del giorno. Se è richiesta l'analisi dell'ora del giorno, è necessario disporre di una dimensione data e di una dimensione temporale (descritta di seguito). Le tabelle dei fatti che archiviano l'ora del giorno devono avere due chiavi esterne, una per ciascuna di queste dimensioni.

La chiave naturale della dimensione data deve usare il tipo di dati data. La chiave sostitutiva deve archiviare la data usando il formato YYYYMMDD e il tipo di dati int. Questa procedura accettata deve essere l'unica eccezione (insieme alla dimensione temporale) quando il valore della chiave sostitutiva ha significato ed è leggibile. L'archiviazione YYYYMMDD come tipo di dati int non è solo efficiente e ordinata numericamente, ma è conforme anche al formato univoco di data ISO (International Standards Organization) 8601.

Ecco alcuni attributi comuni da includere in una dimensione data.

• Year, Quarter, Month, Day
• QuarterNumberInYear, MonthNumberInYear – possono essere necessari per ordinare le etichette di testo.
• FiscalYear, FiscalQuarter – alcuni programmi di contabilità aziendale iniziano a metà anno, per cui l'inizio/fine dell'anno di calendario e l'anno fiscale sono diversi.
• FiscalQuarterNumberInYear, FiscalMonthNumberInYear – possono essere necessari per ordinare le etichette di testo.
• WeekOfYear – esistono diversi modi per etichettare la settimana dell'anno, tra cui uno standard ISO che prevede 52 o 53 settimane.
• IsHoliday, HolidayText – se l'organizzazione opera in più aree geografiche, è necessario mantenere più serie di elenchi di festività che ogni area geografica osserva come dimensione separata o naturalizzata in più attributi nella dimensione data. L'aggiunta di un attributo HolidayText contribuisce a identificare le festività per il reporting.
• IsWeekday – analogamente, in alcune aree geografiche, la settimana lavorativa standard non va dal lunedì al venerdì. Ad esempio, la settimana lavorativa va dalla domenica al giovedì in molte aree del Medio Oriente, mentre in altre aree la settimana lavorativa dura quattro o sei giorni.
• LastDayOfMonth
• RelativeYearOffset, RelativeQuarterOffset, RelativeMonthOffset, RelativeDayOffset – possono essere necessari per supportare il filtro della data relativa (ad esempio, il mese precedente). I periodi correnti usano uno scarto pari a zero (0); i periodi precedenti archiviano scarti di -1, -2, -3...; i periodi futuri archiviano scarti di 1, 2, 3....

Come per ogni dimensione, è importante che contenga attributi che supportino i requisiti noti di filtro, raggruppamento e gerarchia. Possono essere presenti anche attributi che archiviano le traduzioni delle etichette in altre lingue.

Quando la dimensione viene usata per correlare a fatti più granulari, la tabella dei fatti può usare la prima data del periodo. Ad esempio, una tabella dei fatti sugli obiettivi di vendita che archivia gli obiettivi trimestrali dei venditori archivia la prima data del trimestre nella dimensione data. Un approccio alternativo consiste nel creare colonne chiave nella tabella della data. Ad esempio, una chiave quarter può archiviare la chiave quarter usando il formato YYYYQ e il tipo di dati smallint.

La dimensione deve essere popolata con l'intervallo noto di date usate da tutte le tabelle dei fatti. Deve includere anche date future quando il data warehouse archivia fatti relativi a obiettivi, budget o previsioni. Come per altre dimensioni, si possono includere righe che rappresentano situazioni mancanti, sconosciute, N/D o di errore.

Suggerimento

Cercare "generatore di dimensioni data" su Internet per trovare script e fogli di calcolo che generano dati sulle date.

In genere, all'inizio dell'anno successivo, il processo ETL estende le righe della dimensione data a un numero specifico di anni successivi. Quando la dimensione include i relativi attributi di scarto, il processo ETL deve essere eseguito ogni giorno per aggiornare i valori degli attributi di scarto in base alla data corrente (oggi).

Dimensione temporale

In alcuni casi, i fatti devono essere archiviati in un momento specifico (come l'ora del giorno). In questo caso, creare una dimensione temporale (o orologio). Può avere un intervallo di minuti (24 x 60 = 1.440 righe) o persino secondi (24 x 60 x 60 = 86.400 righe). Altri possibili intervalli includono mezz'ora o un'ora.

La chiave naturale di una dimensione temporale deve usare il tipo di dati orario. La chiave sostitutiva può usare un formato appropriato e archiviare valori che hanno un significato e sono leggibili, ad esempio, usando il formato HHMM o HHMMSS.

Ecco alcuni attributi comuni da includere in una dimensione temporale.

• Hour, HalfHour, QuarterHour, Minute
• Etichette del periodo di tempo (mattina, pomeriggio, sera, notte)
• Nomi dei turni di lavoro
• Flag di picco o fuori picco

Dimensioni conformi

Alcune dimensioni possono essere conformi. Le dimensioni conformi sono correlate a molte tabelle dei fatti e quindi sono condivise da più stelle in un modello dimensionale. Forniscono coerenza e consentono di ridurre lo sviluppo e la manutenzione in corso.

Ad esempio, è consuetudine che le tabelle dei fatti archivino almeno una chiave della dimensione data (perché l'attività è quasi sempre registrata in base alla data e/o all'ora). Per questo motivo, una dimensione data è una dimensione conforme comune. È pertanto necessario assicurarsi che la dimensione data includa attributi rilevanti per l'analisi di tutte le tabelle dei fatti.

Il diagramma seguente mostra la tabella dei fatti Sales e la tabella dei fatti Inventory. Ogni tabella dei fatti è correlata alla dimensione Date e alla dimensione Product, che sono conformi.

Per fare un altro esempio, il dipendente e gli utenti possono essere lo stesso insieme di persone. In questo caso, può essere opportuno combinare gli attributi di ogni entità per produrre una dimensione conforme.

Dimensioni con ruoli multipli

Quando si fa più volte riferimento a una dimensione in una tabella dei fatti, diventa nota come dimensione con ruoli multipli.

Ad esempio, quando una tabella dei fatti sulle vendite ha chiavi di dimensioni data dell'ordine, data di spedizione e data di consegna, la dimensione data è correlata in tre modi. Ogni modo rappresenta un ruolo distinto, ma esiste una sola dimensione data effettiva.

Il diagramma seguente illustra una tabella dei fatti Flight. La dimensione Airport è una dimensione con ruoli multipli perché è correlata due volte alla tabella dei fatti come dimensione Departure Airport e dimensione Arrival Airport.

Dimensioni di tipo junk

Una dimensione junk è utile quando ci sono molte dimensioni indipendenti, soprattutto quando comprendono pochi attributi (talvolta anche uno solo) e quando questi attributi hanno una bassa cardinalità (pochi valori). L'obiettivo di una dimensione junk consiste nel consolidare molte piccole dimensioni in una singola dimensione. Questo approccio di progettazione può ridurre il numero di dimensioni e il numero di chiavi della tabella dei fatti, e quindi la dimensione di archiviazione delle tabelle dei fatti. Consentono anche di ridurre i messaggi secondari del riquadro Dati perché mostrano agli utenti un minor numero di tabelle.

Una tabella delle dimensioni junk è in genere il prodotto cartesiano di tutti i valori degli attributi delle dimensioni, con una colonna chiave sostitutiva.

Validi candidati includono flag e indicatori, stato dell'ordine e stati demografici dei clienti (sesso, fascia di età e altri).

Il diagramma seguente illustra una dimensione junk denominata Sales Status che combina i valori di stato dell'ordine e i valori di stato del recapito.

Dimensioni degenerate

Una dimensione degenere si presenta quando la dimensione ha lo stesso intervallo dei fatti correlati. Un esempio comune di una dimensione degenere è una dimensione del numero di ordine di vendita correlata a una tabella dei fatti sulle vendite. In genere, il numero di fattura è un singolo attributo non gerarchico nella tabella dei fatti. È quindi una procedura accettata non copiare questi dati per creare una tabella delle dimensioni separata.

Il diagramma seguente illustra una dimensione Sales Order che rappresenta una dimensione degenere basata sulla colonna SalesOrderNumber di una tabella dei fatti sulle vendite. Questa dimensione viene implementata come visualizzazione che riprende i valori distinti del numero di ordine di vendita.

Suggerimento

È possibile creare una visualizzazione in un Fabric Warehouse che presenti la dimensione degenere come dimensione a scopo di query.

Dal punto di vista della modellazione semantica di Power BI, è possibile creare una dimensione degenere come tabella separata usando Power Query. In questo modo, il modello semantico è conforme alla procedura consigliata secondo cui i campi usati per filtrare o raggruppare sono originati dalle tabelle delle dimensioni e i campi usati per riassumere i fatti sono originati dalle tabelle dei fatti.

Dimensioni outrigger

Quando una tabella delle dimensioni è correlata ad altre tabelle delle dimensioni, è nota come dimensione outrigger. Una dimensione outrigger consente di conformarsi e riusare le definizioni nel modello dimensionale.

Ad esempio, è possibile creare una dimensione dati geografici che archivia le posizioni geografiche per ogni codice postale. È quindi possibile fare riferimento a tale dimensione dalla dimensione cliente e dalla dimensione venditore, che archivierebbe la chiave sostitutiva della dimensione dati geografici. In questo modo, i clienti e i venditori possono quindi essere analizzati usando posizioni geografiche coerenti.

Il diagramma seguente illustra una dimensione Geography che rappresenta una dimensione outrigger. Non è correlato direttamente alla tabella dei fatti Sales. Al contrario, è correlato indirettamente tramite la dimensione Customer e la dimensione Salesperson.

Si consideri che la dimensione data può essere usata come dimensione outrigger quando altri attributi della tabella delle dimensioni archiviano delle date. Ad esempio, la data di nascita in una dimensione cliente può essere archiviata usando la chiave sostitutiva della tabella delle dimensioni data.

Dimensioni multivalore

Quando un attributo della dimensione deve archiviare più valori, è necessario progettare una dimensione multivalore. È possibile implementare una dimensione multivalore creando una tabella bridge (talvolta denominata tabella join). Una tabella bridge archivia una relazione molti-a-molti tra entità.

Si consideri, ad esempio, una dimensione venditore e che ogni venditore sia assegnato a una o più aree di vendita. In questo caso, è opportuno creare una dimensione dell'area di vendita. Questa dimensione archivia ogni area di vendita una sola volta. Una tabella separata, nota come tabella bridge, archivia una riga per ogni relazione tra venditore e area di vendita. Fisicamente, esiste una relazione uno-a-molti dalla dimensione venditore alla tabella bridge e un'altra relazione uno-a-molti dalla dimensione dell'area di vendita alla tabella bridge. Logicamente, esiste una relazione molti-a-molti tra venditori e area di vendita.

Nel diagramma seguente la tabella delle dimensioni Account è correlata alla tabella dei fatti Transaction. Poiché i clienti possono avere più account e gli account possono avere più clienti, la tabella delle dimensioni Customer è correlata tramite la tabella bridge Customer Account.

Contenuto correlato

Nell'articolo successivo di questa serie vengono fornite informazioni sul materiale sussidiario e sulle procedure consigliate per la progettazione delle tabelle dei fatti.