I segreti della modellazione di un datawarehouse : 3a parte

Eccoci ad un altra puntata dei miei segreti su come modellare un datawarehouse … e questa volta parlerò di 2 pattern di modellazione a me “cari” , 1 per le dimensioni e 1 per i fatti, più che disegno del datawarehouse parliamo di modellazione dell’ETL ma poco cambia … tendenzialmente queste decisioni le prende il DWH Architect quindi possiamo parlare sempre di modellazione del dwh

Fatti a scacchiera

devo essere sincero la cosa più divertente di un pattern di questo tipo è trovargli un nome e poi usarlo per dare un certo valore alla tua soluzione, come se fosse un qualcosa imparato ad Harvard🙂

vediamo la soluzione detta “fatto a scacchiera” , spesso quando abbiamo fatti con 2 misure alimentate da 2 flussi differenti (per semplicità nell’esempio parleremo di un confronto venduto vs budget ) ho visto procedure che fanno la full outer join (e quando non è presente giri strani per simularla ) . Supponiamo di avere un flusso di venduto e un flusso di budget che ci diano queste informazioni

Venduto : Pippo = 100, pluto = 50, paperino = 25

Budget = pippo = 75, pluto = 70, topolino = 100

come denotate pippo e pluto sono presenti in entrambi i flussi , paperino solo nel venduto ( magari è un cliente nuovo ) , topolino solo nel budget

per poter fare un confronto venduto vs budget non ci sono molti dubbi nel dire che il ns fatto avrà come campi il cliente, la misura venduto e la misura budget ma abbiamo diverse opzioni nel disegno dell’ETL tipicamente chi ha una testa da sviluppatore di procedure tipiche del mondo transazionale andrà a mettere in join i 2 datasource, poi inizierà a lavorare di outer finchè riuscirà ad arrivare ad una soluzione che permettà di ottenere questo tipo di dati nel fatto

ora … ottimo soluzione con dati che quadrano con le fonti iniziali, vengono occupate solo i record che servono etc etc ma quanti possibili errori potremmo commettere in fase di ETL ? questo è un esempio banale ma  il db potrebbe non supportare la full outer join piuttosto che la clausola di join stessa potrebbe non essere accettata dall’outer join etc etc

Io preferisco lavorare con un fatto a scacchiera. Cosa è un fatto a scacchiera ? Semplice : è un fatto dove un flusso popola una misura e lascia l’altra a zero, e l’altro flusso lascia a 0 la prima misura e popola la seconda … se la misura piena la coloriamo di nero e quella a 0 di bianco ottieniamo una scacchiera. Il ns strumento di reporting tanto poi lavorerà con delle aggregazioni sulle misure quindi il fatto che vada a sommare degli 0 non cambia nulla

E il bello è che per fare tutto questo ci basta lavorare con delle UNION ALL che rende il tutto più semplice (nessuna join ) più sicuro ( nessun errore nella join ) e veloce ( mancano le join )

ecco il risultato :

Attenzione ! In questa versione semplificata ovviamente non si possono fare le medie

Questo è un esempio della filosofia KISS ( Keep It Simple Stupid ! )

Dimensioni Matrioska

Abbiamo appena parlato di budget … spesso il budget ci viene fornito su dei livelli di aggregazione differenti rispetto a quello delle ns dimensioni cliente e/o prodotto, tipicamente perchè non può essere stilato un budget per ogni singolo cliente o prodotto e anche perchè se voglio fare un budget per i nuovi clienti che troverò nel corso dell’anno non posso certo preallocare dei codici …

Qui la gente inizia a sbizzarrirsi con soluzioni differenti come una seconda dimensione dedicata al budget , un fatto dove confluiscono budget e venduto aggregati ad un livello omogeneo (e creata una nuova dimensione ) etc etc

Io preferisco creare quella che chiamo una dimensione matrioska ad esempio nella dimensione prodotto non saranno presenti solo i record dei prodotti passati dall’anagrafica ma anche dei record con altri livelli di aggregazione del prodotto (ovviamente non tutti i campi saranno compilati)  in modo tale che si possa collegare la dimensione anche ai record del budget ,  ovviamente la chiave primaria verrà composta da un codice più il tipo di livello di aggregazione.

Ovviamente si chiama matrioska perchè all’interno della dimensione si sono N livelli un po’ come una bambola matrioska.

In generale penso che spesso e volentieri se si dedicasse più tempo al trovare soluzioni nella modellazione si riuscirebbe ad avere :

  • un datawarehouse con un disegno più semplice
  • semplicità nella gestione dell’ETL ( soprattutto nella manutenzione )
  • semplicità nell’utilizzo da parte dell’utente ( sempre meglio avere 1 sola dimensione per ogni oggetto di business )

Again : KISS ( Keep It Simple Stupid ! )

Lascia un commento

2 commenti

  1. Jean

     /  1 luglio 2012

    e se nei fatti a scacchiera costruisci la tua UNION in memoria e poi la fai seguire da una GROUP BY per aggregare le righe a 0 prima del caricamento definitivo in fact table? (ovviamente se il disegno dati e le risorse te lo permettono)

    Rispondi
  2. ciao Jean, direi che la domanda/proposta ci sta a volte è applicabile ( come nel caso semplice presentato ) ma appena i 2 datasource hanno granularità differente ( e nel caso sopra basterebbe inserire il prodotto sulle vendite ) già il gioco non funziona più … comunque il messaggio dell’articolo è appunto il favorire la union all al posto di una full outer join pura o costruita. grazie del commento

    Rispondi

Lascia un commento

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...

%d blogger cliccano Mi Piace per questo: