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 di modellazione dimensionale . Questa serie è incentrata sulle linee guida e sulle procedure consigliate di progettazione correlate alla modellazione dimensionale in Microsoft Fabric Warehouse.

Questo articolo fornisce indicazioni e procedure consigliate per la progettazione di tabelle delle dimensioni in un modello dimensionale. Fornisce indicazioni pratiche per Warehouse in Microsoft Fabric, un'esperienza che supporta molte funzionalità T-SQL, ad esempio la creazione di tabelle e la gestione dei dati nelle tabelle. È quindi possibile controllare completamente la creazione delle tabelle del modello dimensionale e il caricamento con i dati.

Nota

In questo articolo il termine data warehouse si riferisce a un data warehouse aziendale, che offre un'integrazione completa dei dati critici nell'organizzazione. Al contrario, il data warehouse autonomo si riferisce a un warehouse di infrastruttura, ovvero un database relazionale SaaS (Software as a Service) che è possibile usare per implementare un data warehouse. Per maggiore chiarezza, in questo articolo quest'ultimo è menzionato come Fabric Warehouse.

Suggerimento

Se si è inesperti con la modellazione dimensionale, prendere in considerazione questa serie di articoli il primo passaggio. Non è progettato per fornire una discussione completa sulla progettazione di modellazione dimensionale. Per altre informazioni, fare riferimento direttamente a contenuti pubblicati ampiamente adottati, ad esempio The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling (3rd edition, 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. Le cose possono essere prodotti, persone, luoghi o qualsiasi altro concetto, tra cui data e ora. Per identificare facilmente le tabelle delle dimensioni, in genere si antepongono i nomi con d_ o Dim_.

Struttura della tabella delle dimensioni

Per descrivere la struttura di una tabella delle dimensioni, considerare l'esempio seguente di una tabella delle dimensioni salesperson denominata d_Salesperson. Questo esempio applica procedure di progettazione consigliate. Ognuno dei gruppi di colonne è 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 surrogata

La tabella delle dimensioni di esempio ha una chiave surrogata denominata Salesperson_SK. Una chiave surrogata è 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 surrogate cercano di isolare il data warehouse dalle modifiche apportate ai dati di origine. Offrono anche molti altri vantaggi, consentendo di:

• Consolidare più origini dati (evitando conflitti di identificatori duplicati).
• Consolidare le chiavi naturali a più colonne in una chiave a colonna singola più efficiente.
• Tenere traccia della cronologia delle dimensioni con una dimensione a modifica lenta (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 surrogata è una procedura consigliata, anche quando una chiave naturale (descritta di seguito) sembra un candidato accettabile. È anche consigliabile evitare di dare significato ai valori chiave (ad eccezione delle chiavi delle dimensioni di data e ora, come descritto 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 della dimensione al sistema di origine, in genere eseguito da un processo ETL (Extract, Load e Transform) per caricare la tabella delle dimensioni. A volte una chiave naturale è detta chiave aziendale e i relativi valori possono essere significativi per gli utenti aziendali.

A volte le dimensioni non hanno una chiave naturale. Questo può essere il caso per la dimensione data o le dimensioni di ricerca o quando si generano dati di dimensione normalizzando un file flat.

Attributi dimensione

Una tabella delle dimensioni di esempio include anche attributi di dimensione, ad esempio la FirstName colonna. 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 (sezione e dadi), ma non per essere aggregate. Alcune tabelle delle dimensioni contengono alcuni attributi, mentre altri contengono molti attributi (il numero necessario per supportare i requisiti di query del modello dimensionale).

Suggerimento

Un buon modo per determinare quali dimensioni e attributi è necessario trovare le persone giuste e porre le domande giuste. In particolare, mantenere l'avviso per la menzione della parola by. Ad esempio, quando un utente dice di dover analizzare le vendite per venditore, per mese e per categoria di prodotti, indica che hanno 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 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 e la loro presenza in una tabella delle dimensioni è 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, ma non possono essere applicati. Pertanto, è importante che il processo ETL test per l'integrità tra le tabelle correlate quando vengono caricati i dati.

È comunque consigliabile creare chiavi esterne. Un buon motivo per creare chiavi esterne non valide è 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 cronologici. Gli attributi di rilevamento cronologico sono facoltativi in base alla necessità di tenere traccia di modifiche specifiche man mano 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 la modifica cronologica più avanti 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 possono anche aiutare a diagnosticare un problema complesso, ad esempio quando un processo ETL si arresta in modo imprevisto. Possono anche contrassegnarli come errori o membri dedotti.

Dimensioni tabella dimensione

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

Le dimensioni grandi potrebbero essere generate da più sistemi di origine. In questo caso, l'elaborazione delle dimensioni deve combinare, unire, deduplicare e standardizzare i dati; e assegnare chiavi surrogate.

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

Suggerimento

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

Concetti relativi alla progettazione delle dimensioni

In questa sezione vengono descritti vari concetti di progettazione delle dimensioni.

Denormalizzazione e normalizzazione

È 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 dove esistono dati ridondanti pre-calcolati. I dati ridondanti sono in genere dovuti all'archiviazione delle gerarchie (descritte più avanti), ovvero le gerarchie vengono appiattite. Ad esempio, una dimensione product potrebbe archiviare sottocategorie (e i relativi attributi) e categoria (e i relativi attributi correlati).

Poiché le dimensioni sono in genere ridotte (rispetto alle tabelle dei fatti), il costo dell'archiviazione dei dati ridondanti è quasi sempre superiore alle prestazioni e all'usabilità delle query migliorate.

Dimensioni snowflake

Un'eccezione alla denormalizzazione consiste nel progettare 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, Subcategorye Category.

È consigliabile implementare una dimensione snowflake quando:

• La dimensione è estremamente elevata e i costi di archiviazione superano la necessità di prestazioni elevate delle query. (Tuttavia, periodicamente rivaluta che questo rimane ancora il caso.
• Sono necessarie chiavi per correlare la dimensione a fatti più granulari. Ad esempio, la tabella dei fatti di vendita archivia le righe a livello di prodotto, ma la tabella dei fatti di destinazione vendite 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ò essere basata solo su colonne di una singola tabella di modelli semantici. Pertanto, una dimensione snowflake deve restituire un risultato denormalizzato usando una vista 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 potrebbe mostrare 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.
• Dimensione snowflake, che comprende più tabelle correlate.
• Relazione padre-figlio (autoferenziazione) in una dimensione.

Le gerarchie possono essere bilanciate o sbilanciate. È anche importante comprendere che alcune gerarchie sono incomplete.

Gerarchie bilanciate

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

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 sono basati su colonne di una singola dimensione denormalizzata o da tabelle che formano una dimensione snowflake. Quando si basa su una singola dimensione denormalizzata, le colonne che rappresentano i livelli più elevati contengono dati ridondanti.

Per le gerarchie bilanciate, i fatti riguardano sempre un singolo livello della gerarchia, che in genere è il livello più basso. In questo modo, i fatti possono essere aggregati (arrotolati) al livello più alto della gerarchia. I fatti possono essere correlati a qualsiasi livello, determinato dalla granularità della tabella dei fatti. Ad esempio, la tabella dei fatti di vendita potrebbe essere archiviata a livello di data, mentre la tabella dei fatti di destinazione delle vendite potrebbe essere archiviata a livello di trimestre.

Gerarchie sbilanciate

Le gerarchie non bilanciate sono un tipo meno comune di gerarchia. Una gerarchia sbilanciata ha 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 della tabella delle dimensioni specifiche.

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

Il diagramma seguente illustra una gerarchia sbilanciata. Comprende quattro livelli e ogni membro nella gerarchia è un venditore. Si noti che i venditori hanno un numero diverso di predecessori nella gerarchia in base a chi segnalano.

Altri esempi comuni di gerarchie sbilanciate includono la fattura dei materiali, i modelli di proprietà dell'azienda e il libro mastro generale.

Per le gerarchie sbilanciate, i fatti sono sempre correlati alla granularità della dimensione. Ad esempio, i fatti di vendita si riferiscono a venditori diversi, che hanno strutture di report diverse. La tabella delle dimensioni avrà una chiave surrogata (denominata Salesperson_SK) e una ReportsTo_Salesperson_FK colonna chiave esterna che fa riferimento alla colonna chiave primaria. Ogni venditore senza nessuno da gestire non è necessariamente al livello più basso di qualsiasi ramo della gerarchia. Quando non sono al livello più basso, un venditore potrebbe vendere prodotti e fare riferimento a venditori che vendono anche 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 complessa e lenta, soprattutto per dimensioni di grandi dimensioni. Anche se il sistema di origine potrebbe archiviare le relazioni come padre-figlio, è consigliabile naturalizzare la gerarchia. In questa istanza, naturalizzare significa trasformare e archiviare i livelli della gerarchia nella dimensione come 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 dimensioni di 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 nella gerarchia esiste a un livello che non è immediatamente sopra di esso. In questi casi, i valori di livello mancanti ripetono il valore dell'elemento padre.

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

Il diagramma seguente illustra una gerarchia incompleta di aree geografiche.

Gestire la modifica cronologica

Quando necessario, la modifica cronologica può essere gestita implementando una dimensione a modifica lenta (SCD). Un scD mantiene il contesto cronologico come dati nuovi o modificati, viene caricato in esso.

Ecco i tipi di scD più comuni.

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

È possibile che una dimensione possa supportare le modifiche di tipo 1 e SCD di tipo 2.

Il tipo SCD 3 non viene comunemente usato, in parte a causa del fatto che è difficile usare in un modello semantico. Valutare attentamente se un approccio di tipo SCD 2 sarebbe più adatto.

Suggerimento

Se si prevede una dimensione a modifica rapida, 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 tipo 1

Le modifiche apportate al 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 e deve essere usato per la maggior parte degli attributi modificati, ad esempio il nome del cliente, l'indirizzo di posta elettronica e altri.

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

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

ScD tipo 2

Le modifiche al tipo 2 di scD comportano nuove righe che rappresentano una versione basata sul tempo di un membro della dimensione. Esiste sempre una riga di versione corrente e riflette lo stato del membro della dimensione nel sistema di origine. Gli attributi di rilevamento cronologico nell'archivio tabelle delle dimensioni consentono di identificare la versione corrente (il flag corrente è TRUE) e il relativo periodo di validità. È necessaria una chiave surrogata perché saranno presenti chiavi naturali duplicate quando vengono archiviate più versioni.

Si tratta di un tipo comune di scD, ma deve essere riservato per gli attributi che devono mantenere la prospettiva cronologica.

Ad esempio, se un venditore viene assegnato a un'area di vendita diversa, una modifica di tipo 2 di modifica 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 cronologici. In particolare, la colonna di validità finale viene impostata sulla data di elaborazione ETL (o un timestamp appropriato nel sistema di origine) e il flag corrente è impostato su FALSE.
2. L'operazione di inserimento aggiunge una nuova versione corrente, impostando la colonna di validità iniziale sul valore della colonna di validità finale (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 del livello di versione del venditore. Il rollup dei risultati delle vendite storiche nell'area produrrà risultati corretti, ma saranno disponibili due o più versioni dei membri del venditore da analizzare.

Il diagramma seguente illustra lo stato precedente e successivo di un membro della dimensione del venditore in cui è stata modificata l'area di vendita. Poiché l'organizzazione vuole analizzare le attività dei venditori in base all'area a cui sono assegnati, attiva una modifica di tipo SCD di tipo 2.

Suggerimento

Quando una tabella delle dimensioni supporta le modifiche al tipo 2 della dimensione, è necessario includere un attributo label che descrive il membro e la versione. Si consideri un esempio quando il venditore Lynn Tsoflias di Adventure Works cambia l'assegnazione dall'area di vendita australiana all'area di vendita del Regno Unito. L'attributo label per la prima versione potrebbe leggere "Lynn Tsoflias (Australia)" e l'attributo label per la nuova versione corrente potrebbe leggere "Lynn Tsoflias (Regno Unito)." Se utile, è possibile includere anche le date di validità nell'etichetta.

È consigliabile bilanciare la necessità di accuratezza storica rispetto all'usabilità e all'efficienza. Provare a evitare di dover modificare troppe modifiche al tipo 2 in una tabella delle dimensioni perché può comportare un numero eccessivo di versioni che potrebbero rendere difficile per gli analisti comprendere.

Inoltre, troppe versioni potrebbero indicare che un attributo che cambia potrebbe essere archiviato meglio nella tabella dei fatti. L'estensione dell'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 anziché implementare un scD di tipo 2.

Si considerino gli attributi di rilevamento cronologici di tipo 2 seguenti.

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 cronologici.

• La RecChangeDate_FK colonna archivia la data di entrata in vigore della modifica. Consente di eseguire query quando sono state apportate modifiche.
• Le RecValidFromKey colonne e RecValidToKey archiviano le date di validità valide per la riga. È consigliabile archiviare la data meno recente trovata nella dimensione data per RecValidFromKey per rappresentare la versione iniziale e archiviare 01/01/9999 per le RecValidToKey versioni correnti.
• La RecReason colonna è facoltativa. Consente di documentare il motivo per cui è stata inserita la versione. Può codificare gli attributi modificati o potrebbe trattarsi di un codice del sistema di origine che indica un motivo aziendale specifico.
• La RecIsCurrent colonna consente di recuperare 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 nuove versioni. In questo modo, è possibile rilevare le modifiche poco dopo che si verificano e le relative date di validità saranno accurate.

ScD tipo 3

Le modifiche di tipo 3 di scD tengono traccia della cronologia limitata con 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ò essere utile quando devono essere archiviati solo i valori iniziali e correnti. In questo caso, le modifiche provvisorie non sarebbero necessarie.

Ad esempio, se un venditore viene assegnato a un'area di vendita diversa, una modifica di tipo SCD 3 sovrascrive la riga della dimensione. Una colonna che archivia in modo specifico 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 della dimensione del venditore in cui è stata modificata l'area di vendita. Poiché l'organizzazione vuole determinare qualsiasi assegnazione precedente dell'area di vendita, attiva una modifica di tipo 3 di scD.

Membri della dimensione speciale

È possibile inserire righe in una dimensione che rappresenta stati mancanti, sconosciuti, N/A o di errore. Ad esempio, è possibile usare i valori di chiave surrogati seguenti.

Valore 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 applicabile)
-3	Error

Calendario e ora

Quasi senza eccezioni, le tabelle dei fatti archiviano le misure in punti specifici nel tempo. Per supportare l'analisi per data (ed eventualmente ora), è necessario che siano presenti dimensioni del calendario (data e ora).

Non è raro che un sistema di origine disponga di dati della dimensione del calendario, quindi deve essere generato nel data warehouse. In genere, viene generato una sola volta e, se si tratta di una dimensione del calendario, viene estesa con date future quando necessario.

Dimensione data

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

Importante

Una dimensione di data non deve includere un granularità che si estende all'ora del giorno. Se è necessaria l'analisi dell'ora del giorno, è necessario disporre sia di una dimensione di data che di una dimensione temporale (descritta di seguito). Le tabelle dei fatti che archiviano l'ora del giorno devono avere due chiavi esterne, una a ognuna di queste dimensioni.

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

Ecco alcuni attributi comuni da includere in una dimensione data.

• Year, Quarter, MonthDay
• QuarterNumberInYear, MonthNumberInYear , che potrebbe essere necessario per ordinare le etichette di testo.
• FiscalYear, FiscalQuarter – alcune pianificazioni contabili aziendali iniziano a metà anno, in modo che l'inizio/fine dell'anno di calendario e l'anno fiscale siano diversi.
• FiscalQuarterNumberInYear, FiscalMonthNumberInYear , che potrebbe essere necessario per ordinare le etichette di testo.
• WeekOfYear – esistono diversi modi per etichettare la settimana dell'anno, tra cui uno standard ISO con 52 o 53 settimane.
• IsHoliday, HolidayText : se l'organizzazione opera in più aree geografiche, è necessario mantenere più set di elenchi di festività che ogni area geografica osserva come dimensione separata o naturalizzata in più attributi nella dimensione data. L'aggiunta di un HolidayText attributo può aiutare a identificare le festività per la creazione di report.
• IsWeekday – analogamente, in alcune aree geografiche, la settimana lavorativa standard non è da lunedì a venerdì. Ad esempio, la settimana lavorativa è da domenica a giovedì in molte aree del Medio Oriente, mentre altre aree impiegano una settimana lavorativa di quattro o sei giorni.
• LastDayOfMonth
• RelativeYearOffset, RelativeQuarterOffset, RelativeMonthOffset, RelativeDayOffset che potrebbe essere necessario per supportare il filtro delle date relative (ad esempio, il mese precedente). I periodi correnti usano un offset pari a zero (0); i periodi precedenti archivia gli offset di -1, -2, -3...; periodi futuri archivia offset di 1, 2, 3....

Come per qualsiasi dimensione, ciò che è importante è che contiene attributi che supportano i requisiti noti di filtro, raggruppamento e gerarchia. Potrebbero essere presenti anche attributi che archiviano le traduzioni delle etichette in altre lingue.

Quando la dimensione viene utilizzata per correlare a fatti più elevati, la tabella dei fatti può utilizzare la prima data del periodo di data. Ad esempio, una tabella dei fatti di destinazione delle vendite 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 date. Ad esempio, una chiave quarter potrebbe archiviare la chiave quarter usando YYYYQ il formato e il tipo di dati smallint .

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

Suggerimento

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

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

Dimensione temporale

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

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

Ecco alcuni attributi comuni da includere in una dimensione temporale.

• Hour, HalfHour, QuarterHourMinute
• Etichette del periodo di tempo (mattina, pomeriggio, sera, notte)
• Nomi dei turni di lavoro
• Flag peak o off-peak

Dimensioni conformi

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

Ad esempio, è tipico che le tabelle dei fatti archivino almeno una chiave della dimensione data (perché l'attività è quasi sempre registrata per data e/o 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 Sales fatti e la tabella dei Inventory fatti. Ogni tabella dei fatti è correlata alla dimensione e Product alla Date dimensione, che sono dimensioni conformi.

Come un altro esempio, i dipendenti e gli utenti potrebbero essere lo stesso set di persone. In questo caso, potrebbe essere opportuno combinare gli attributi di ogni entità per produrre una dimensione conforme.

Dimensioni con ruoli multipli

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

Ad esempio, quando una tabella dei fatti di vendita ha chiavi relative alla data di ordine, alla data di spedizione e alla data di consegna, la dimensione data è correlata in tre modi. Ogni modo rappresenta un ruolo distinto, ma esiste una sola dimensione data fisica.

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

Dimensioni indesiderate

Una dimensione indesiderata è utile quando sono presenti molte dimensioni indipendenti, soprattutto quando comprendono alcuni attributi (ad esempio uno) e quando questi attributi hanno una cardinalità bassa (pochi valori). L'obiettivo di una dimensione indesiderata consiste nel consolidare molte dimensioni di piccole dimensioni in una singola dimensione. Questo approccio progettuale può ridurre il numero di dimensioni e ridurre il numero di chiavi della tabella dei fatti e quindi le dimensioni di archiviazione delle tabelle dei fatti. Consentono anche di ridurre il disordine del riquadro dati perché presentano meno tabelle agli utenti.

Una tabella delle dimensioni indesiderate archivia in genere il prodotto cartesiano di tutti i valori di attributo della dimensione, con un attributo chiave surrogata.

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

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

Dimensioni degenerate

Una dimensione degenerata può verificarsi quando la dimensione è allo stesso livello dei fatti correlati. Un esempio comune di una dimensione degenerata è una dimensione numero ordine di vendita correlata a una tabella dei fatti di vendita. In genere, il numero di fattura è un singolo attributo non gerarchico nella tabella dei fatti. È quindi consigliabile non copiare questi dati per creare una tabella delle dimensioni separata.

Il diagramma seguente illustra una dimensione che rappresenta una Sales Order dimensione degenerata in base alla SalesOrderNumber colonna in una tabella dei fatti di vendita. Questa dimensione viene implementata come visualizzazione che recupera i valori distinti del numero di ordine di vendita.

Suggerimento

È possibile creare una vista in un'istanza di Fabric Warehouse che presenta la dimensione degenerata come dimensione a scopo di query.

Dal punto di vista della modellazione semantica di Power BI, è possibile creare una dimensione degenerata come tabella separata usando Power Query. In questo modo, il modello semantico è conforme alla procedura consigliata utilizzata per filtrare o raggruppare i campi provenienti dalle tabelle delle dimensioni e i campi usati per riepilogare i fatti vengono 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 riutilizzare le definizioni nel modello dimensionale.

Ad esempio, è possibile creare una dimensione geography che archivia le posizioni geografiche per ogni codice postale. È quindi possibile fare riferimento a tale dimensione dalla dimensione customer e dalla dimensione salesperson, che archivierebbe la chiave surrogata della dimensione geography. In questo modo, i clienti e i venditori possono quindi essere analizzati usando località geografiche coerenti.

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

Si consideri che la dimensione data può essere utilizzata come dimensione outrigger quando altri attributi della tabella delle dimensioni archiviano date. Ad esempio, la data di nascita in una dimensione customer può essere archiviata usando la chiave surrogata della tabella della dimensione 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 salesperson e che ogni venditore sia assegnato a una o più aree di vendita. In questo caso, è opportuno creare una dimensione dell'area di vendita. Tale 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 salesperson 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 aree di vendita.

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

Contenuto correlato

Nell'articolo successivo di questa serie vengono fornite informazioni sulle linee guida e sulle procedure consigliate per la progettazione per le tabelle dei fatti.