Quando iniziamo un progetto di data warehousing, la prima cosa che facciamo è definire le tabelle dimensionali. Le tabelle dimensionali sono i bit interessanti, la struttura attorno alla quale costruiamo le nostre misurazioni. Sono disponibili in molte forme e dimensioni. In questo articolo, daremo un'occhiata più da vicino a ciascun tipo di tabella dimensionale.
Le tabelle dimensionali forniscono un contesto ai processi aziendali che desideriamo misurare. Ci dicono tutto quello che dobbiamo sapere su un evento. Dato che danno sostanza alle misurazioni (i.e. tabelle dei fatti) del sistema di data warehouse (DWH), dedichiamo più tempo alla loro definizione e identificazione che a qualsiasi altro aspetto del progetto. Tabelle dei fatti definire le misure; le tabelle dimensionali danno il contesto. (Per saperne di più sulle tabelle dei fatti, dai un'occhiata a questi post sul data warehousing, lo schema a stella, lo schema del fiocco di neve e i fatti sulle tabelle dei fatti).
La caratteristica principale delle tabelle dimensionali è la loro molteplicità di attributi . Gli attributi sono le colonne che riepiloghiamo, filtriamo o aggreghiamo. Hanno una cardinalità bassa e di solito sono testuali e temporali. Le tabelle dimensionali hanno una chiave primaria basata sulla chiave aziendale sottostante o una chiave surrogata . Questa chiave primaria è la base per unire la tabella delle dimensioni a una o più tabelle dei fatti.
Rispetto alle tabelle dei fatti, le tabelle dimensionali sono di piccole dimensioni, facili da memorizzare e hanno un impatto minimo sulle prestazioni.
Diamo ora un'occhiata ad alcune delle tabelle delle dimensioni che incontrerai in un ambiente di data warehouse.
Una tabella dimensionale comune:la dimensione conforme
Inizieremo con un tipo di base:la dimensione conformata. Questi contengono più attributi, che possono essere indirizzati in diverse tabelle di origine ma che fanno riferimento allo stesso dominio (cliente, contratto, affare, ecc.) Le dimensioni conformi vengono utilizzate con molti fatti e dovrebbero essere univoche per il valore del grano/dominio nel data warehouse.
Esempio:
Diamo un'occhiata a una tipica tabella dimensionale, DIM_CUSTOMER .
Definiamo:
id– La chiave primaria della tabella delle dimensioni.cust_natural_key– La chiave naturale per il cliente.first_name– Il nome del cliente.last_name– Il cognome del cliente.address_residence– L'indirizzo di residenza del cliente.date_of_birth– La data di nascita del cliente.marital_status– Il cliente è sposato? Definito come Y (sì) o N (no).gender– Il sesso del cliente, M (maschio) o F (femmina).
Gli attributi della tabella delle dimensioni dipendono dalle esigenze aziendali. Possiamo espandere questo tipo di tabella per contenere informazioni specifiche del settore (data di default, attività, ecc.)
Tabelle dimensionali che cambiano lentamente
Con il passare del tempo, le dimensioni possono cambiare i loro valori. Nei paragrafi seguenti esamineremo le dimensioni classificate in base al modo in cui archiviano (o non archiviano) i dati storici.
Diciamo che hai una dimensione cliente. È probabile che alcuni attributi cambino nel corso della vita del cliente, ad es. numero di telefono, indirizzo, stato civile, ecc. Questo tipo di tabella è ciò che Ralph Kimball chiama una dimensione che cambia lentamente, o SCD.
L'SCD è disponibile in molti tipi; otto di loro sono abbastanza comuni. Di questi, vedrai di più i tipi da 0 a 4; i tipi 5, 6 e 7 sono ibridi dei primi cinque. (Nota:lo schema di numerazione di questi SCD inizia con uno 0 invece di un 1.)
Gli SCD ibridi offrono maggiore flessibilità e prestazioni migliori, ma a scapito della semplicità. Usiamo questi tipi di tabella quando dobbiamo fare un'analisi analitica di corrente dati con alcuni storici considerazioni.
Tipo SCD 0:riempimento una volta
Questo è il tipo più elementare di tabella delle dimensioni:la riempi una volta e mai riempilo di nuovo. Considerali come dati di riferimento. Un tipico esempio di ciò è la dimensione della data. Non è necessario riempire questa dimensione con ogni carico DWH. La tavola dimensionale non cambia nel tempo. Non puoi ottenere più date o modificare le date.
La tabella dei fatti si collega agli attributi originali della dimensione.
Esempio
Diamo un'occhiata alla dimensione temporale:
La struttura è piuttosto semplice:
id– Chiave surrogatatime_date– Data effettivatime_day– Giorno del mesetime_week– Settimana dell'annotime_month– Mese in un annotime_year– Rappresentazione numerica di un anno
SCD di tipo 1:riscrittura dei dati
Come suggerisce il nome, riscriviamo questo tipo di tabella dimensionale ad ogni carico DWH. Non è necessario conservarne una cronologia, ma prevediamo che verranno apportate alcune modifiche.
La differenza tra un SCD di tipo 0 e un tipo 1 non è nella struttura della tabella. Ha a che fare con l'aggiornamento dei dati. Non aggiorni mai i dati in un Tipo 0, ma a volte lo fai in un Tipo 1.
Una tabella riscrivibile è il modo più semplice per gestire le modifiche (elimina/inserisci), ma aggiunge poco valore aziendale. Dopo aver definito una tabella delle dimensioni come questa, è difficile installare la traccia storica.
La tabella dei fatti si collega agli attributi correnti della dimensione.
Esempio
Diamo un'occhiata alla dimensione dell'account:
La sua struttura è la seguente:
id– La chiave surrogata della tabellaaccount_name– Il nome dell'accountaccount_type– La categoria dell'accountaccount_activity– Segnala diversi tipi di attività
Se esaminiamo i dati prima della modifica, vedremmo questo:
Se il tipo di account è cambiato, i dati verrebbero semplicemente sovrascritti:
SCD di tipo 2:monitoraggio degli attributi storici per riga
Questa è la forma più comune di tracciamento storico in un sistema DWH. Le tabelle SCD di tipo 2 aggiungono nuove righe per ogni modifica storica degli attributi dimensionali tra Carichi di acqua calda sanitaria . In questo tipo, definiamo la chiave primaria come chiave surrogata perché la chiave aziendale avrà più rappresentazioni nel tempo. Quando le righe che contengono la modifica dei dati si alterano, definiamo un nuovo valore per la chiave surrogata che corrisponde al valore nella tabella dei fatti. Dobbiamo aggiungere almeno due colonne, valid_from e valid_to , per memorizzare la cronologia in questo modo.
La tabella dei fatti si collega agli attributi storici della dimensione tramite la chiave surrogata. L'aggregazione avviene sulla chiave naturale .
Esempio
Diamo un'occhiata alla precedente tabella delle dimensioni del cliente, ora espansa con due colonne di data:
Diamo un'occhiata ai dati:
Punti da considerare:
- Come possiamo contrassegnare la riga corrente,
valid_to? (Di solito con 31.12.9999 o NULL .) - Come possiamo contrassegnare la prima riga,
valid_from? (Di solito con 01.01.1900, ovvero la data del primo inserimento). - Definisci una riga inclusiva o esclusiva? (In precedenza, utilizziamo un
valid_frominclusivo e un esclusivovalid_to).
SCD Tipo 3:monitoraggio degli attributi storici per colonna
Come con l'SCD di tipo 2, questo tipo aggiunge qualcosa per rappresentare i valori storici. In questo caso, però, stiamo aggiungendo nuove colonne. Questi rappresentano il valore di un attributo di riga dimensionale prima che venga modificato. Di solito, manteniamo solo la versione precedente dell'attributo.
Nota:questo SCD è usato raramente.
La tabella dei fatti si collega agli attributi attuali e precedenti della dimensione.
Esempio
Diamo un'occhiata alla dimensione del cliente, questa volta con un precedente indirizzo di residenza:
In questo esempio, abbiamo aggiunto una nuova colonna, previous_address_residence , per rappresentare il vecchio indirizzo del cliente. Se osserviamo il nostro esempio iniziale, i dati in questa tabella sarebbero simili a questo:
Tutte le informazioni storiche, ad eccezione dell'indirizzo precedente del cliente, vengono perse.
SCD tipo 4:aggiunta di una mini-dimensione
Questo tipo di quota non si basa su modifiche strutturali (Tipo 3) o di valore (Tipo 2). Piuttosto, si basa sulle modifiche di progettazione al modello. Se la nostra tabella dimensionale contiene dati altamente volatili, ovvero dati che cambiano frequentemente, la dimensione della tabella dimensionale aumenterebbe in modo significativo.
Per mitigare questo, estraiamo gli attributi volatili in una mini-dimensione . Queste mini-dimensioni potrebbero quindi essere aggregate al livello rilevante per l'attività. Tuttavia, questa aggregazione non essere confuso con l'aggregazione dei fatti . L'esempio chiarirà.
La tabella dei fatti si collega agli attributi storici della dimensione.
Esempio
Diamo un'occhiata a un esempio da un semplice data mart finanziario. Supponiamo di dover tenere traccia del ritardo di alcuni clienti con i loro pagamenti. Chiamiamo questo attributo giorni scaduti o DPD. Se dovessimo tracciare DPD ogni giorno in una dimensione di Tipo 2, la dimensione della tabella esploderebbe presto oltre i limiti gestibili. Quindi estraiamo l'attributo e troviamo i periodi di DPD rilevanti per l'azienda, ad esempio con incrementi di 30 giorni (0-30 DPD, 30-60 DPD, 60-90 DPD, ecc.)
Possiamo prendere altri attributi ad alta volatilità, come l'età, e costruire periodi rilevanti anche per loro (ad es. 20-30 anni, 30-40 anni, ecc.)
Se osserviamo i dati nella mini-dimensione del cliente, avremmo qualcosa del genere:
Gli attributi sono:
id– Chiave primaria surrogataDPD_period– Giorni scadutiDEM_period– Periodo demografico
Il semplice schema a stella sarebbe simile al seguente:
Nota che per eseguire qualsiasi analisi sugli attributi di entrambe le tabelle, dovremmo collegarli alla tabella dei fatti.
SCD tipo 5:creazione di una mini-dimensione con estensione riscrivibile
Questo è il primo dei nostri costrutti di tabelle dimensionali ibride. In un SCD di tipo 5, aggiungiamo la versione corrente dei dati mini-dimensionali alla tabella dimensionale. Dobbiamo tenere a mente che aggiungeremo solo la corrente rappresentazione della mini-dimensione alla dimensione principale.
Riforniamo questa estensione di dimensioni minime con ogni carico (l'SCD "riscrivibile" di tipo 1).
Sebbene la storicizzazione di questa estensione possa benissimo portare a problemi di dimensioni, li abbiamo già mitigati con la tabella delle mini-dimensioni.
Usiamo questa tecnica quando vogliamo fare analisi direttamente sulle tabelle dimensionali.
Esempio
Espandendo l'esempio precedente con la mini-dimensione corrente, otteniamo:
Il dim_mini_customer_current la tabella contiene i valori degli attributi più recenti che corrispondono a dim_customer tavolo. Ora possiamo eseguire analisi specifiche del cliente senza passare dalla tabella dei fatti (che è molto lenta).
La tabella dei fatti si collega agli attributi storici della dimensione.
Tipo 6:dimensione di tipo 2 (riga storica) con attributo riscrivibile
Questo è un costrutto dimensionale molto comune. Aggiungiamo un attributo che memorizza una cosa, di solito l'ultimo valore noto, che riscriviamo ad ogni caricamento. Ciò ci consente di raggruppare tutti i fatti in base al loro valore attuale, mentre l'attributo storico mostra i dati come erano quando si sono verificati gli eventi.
La tabella dei fatti si collega ai valori dimensionali nel momento dell'evento con valori dimensionali extra correnti.
Esempio
Espandi la tabella cliente precedente con un current_address_residence colonna.
Ora abbiamo un attributo che aggiorneremo al valore corrente, usando la chiave naturale (cust_natural_key ).
Tipo 7:dimensioni di tipo 2 (riga storica) con uno specchio corrente
Possiamo usare questo tipo solo se c'è una chiave naturale nella dimensione della tabella. La chiave non deve cambiare durante la vita dell'entità.
L'idea è semplice:aggiungiamo una rappresentazione corrente della tabella dimensionale allo schema del fiocco di neve. Quindi inseriamo la chiave naturale della nuova dimensione nella tabella dei fatti. (La chiave surrogata della dimensione storica è ancora presente.)
La tabella dei fatti si collega ai valori dimensionali al momento dell'evento e ai valori dimensionali correnti.
Esempio
Diamo un'occhiata al nostro schema a stella dell'account cliente. Aggiungiamo la nuova dimensione, dim_current_customer , alla tabella dei fatti. Questa tabella è collegata alla tabella dei fatti tramite una chiave naturale, cust_natural_key .
Questa costruzione ci consente di eseguire query analitiche sullo schema a stella con i valori attuali e storici degli attributi del cliente.
Dimensioni del dominio
Una dimensione di dominio è una semplice forma di tabella dimensionale. Contiene informazioni sul dominio della misurazione sottostante di un attributo dimensionale. Queste tabelle memorizzano vari codici e valori esplicativi.
Esempio
Un semplice esempio potrebbe essere una tabella delle valute.
In questa tabella, memorizziamo informazioni descrittive su varie unità monetarie.
A mio parere personale, l'uso migliore della dimensione del dominio è nella documentazione dei valori dei dati che troviamo nel sistema DWH.
Dimensioni spazzatura
I sistemi di origine transazionale generano molti indicatori e flag. Questi attributi possono essere considerati dati categoriali, ma non sono rilevanti per l'azienda o autoesplicativi. Possiamo archiviare tutti questi indicatori e flag in una tabella dimensionale chiamata dimensione spazzatura . La dimensione spazzatura è l'alternativa all'utilizzo di dimensioni degenerate. Se non vogliamo appesantire la tabella dei fatti con molte dimensioni degenerate, creiamo una dimensione spazzatura.
Dobbiamo notare che non riempiamo tutte le possibili combinazioni di indicatori e flag. Riempiamo solo quelli che esistono nel sistema di origine.
Esempio
Le tabelle dimensionali sono gli scheletri del mondo del data warehousing:tutto è costruito attorno ad esse. Non sono grandi come tabelle dei fatti, ma la loro struttura può essere più complessa.
Puoi mettere insieme molti tipi di tabelle dimensionali, anche oltre a quelle appena discusse. E la tua attività e il tuo settore? Se hai combinato i tipi di tabelle dimensionali in qualcosa di nuovo, raccontacelo!
