Modellazione datawarehouse : soluzione al tuo problema

e adesso cosa scrivo ? fa caldo non ho molte idee … aspetto settembre ? … NO !!

Voglio provare a costruire parte del blog risolvendo i vs problemi di modellazione.Se avete qualche problema di modellazione del datawarehouse o in generale di modellazione per l’analisi dei dati lasciatemi un commento con una breve descrizione o il vs contatto e provoerò, dove possibile, a darvi una soluzione con una risposta breve o un articolo dedicato.

Cosa ne dite ?

Chi sarà il primo a proporre un problema ? e chi proporrà il più curioso o difficile ?

vediamo cosa ne salta fuori

 

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 ! )

DWH : I segreti della modellazione dati svelati ( parte 1a )

Visto che negli articoli precedenti ho sempre parlato della modellazione dei dati come della regola base per poter ottenere un Datawarehouse ben fatto e quindi un progetto di Business Intelligence vincente, è doveroso iniziare a svelare questi fantomatici segreti

Segreto N.1:

Come prima cosa il guru della modellazione di un dwh : Ralph Kimball è sicuramente il punto di riferimento storico per quanto riguarda la modellazione , lo star-schema etc etc.

Si lo so quasi tutti coloro che fanno BI lo conoscono ( lui si che può essere detto uno dei massimi esperti di BI ) quindi è il segreto di Pulcinella ma penso che ogni tanto bisognerebbe rispolverare i suoi libri e articoli per rinfrescare i concetti.

Segreto N.2:

Ascoltare l’utente … si lo avevo già detto negli altri articoli quanto questo sia importante, ma ora aggiungo che non solo è importante ascoltare per capire cosa l’utente vuole o necessita ma che ascoltandolo con la giusta attenzione spesso capita che la modellazione se la fa quasi da solo … sceglie lui qual’è la soluzione migliore per le sue analisi ( es: se servono N misure e o se serve 1 misura con  un attributo che la “categorizza” )

Ascoltare è alla base della conversazione, parlare viene dopo …

Segreto N.3:

La semplicità : provate a pensare che l’utente debba usare le Pivot di Excel al posto di uno strumento di query & reporting … il dwh è ancora così semplice da usare ? fate sempre conto che l’utente finale per quanto smanettone non sarà mai in grado di poter costruire una query troppo complessa per tirarsi fuori i suoi dati quindi … Semplicità !

Mi piace usare un concetto per esprimere questa semplicità o quella che deve esistere nell’ETL ( ma questo è un altro capitolo )

“Tutto deve essere come acqua che scorre “

Avete mai visto (in Natura ) l’acqua fare dei percorsi strani ? Stessa cosa nella modellazione

Segreto N.4:

Sulla tabella del fatto è sempre meglio abbondare con colonne flag, contatori e colonne d’aiuto per la costruzione dei metadati … lasciate perdere il discorso che meno colonne esistono nella tabella e più veloce sarà il db a leggerla, perchè tanto poi rischiate di dover fare query più complesse per calcolare le misure derivate … guadagnereste 10 e perdereste 100 … pensate alle analisi che vorranno i clienti quelle dovranno essere veloci non solo la lettura del fatto … ottimizzare il tutto focalizzandosi su alcuni tecnicismi sarebbe come avere una macchina velocissima sul dritto ma che non tiene la strada in curva …

Segreto N.5:

“The middle way is the right way”: in caso di dubbi non scegliete soluzioni estreme

Segreto N.6:

“Il mattino ha l’oro in bocca”,”La notte porta consiglio” : Come ? sono solo detti popolari ? … No! Questa è saggezza popolare … io modello di prima mattina perchè spesso mi sveglio e la soluzione si presenta da sola …

Segreto N.7:

“In caso di dubbi chiedete all’utente” : si ricollega al saper ascoltare il cliente, ma io spesso e volentieri propongo all’utente le varie soluzioni di modellazione e lascio che sia lui a scegliere quella che fa per lui

Beh direi che per oggi basta, questa è solo la 1a parte e più che segreti sono dei consigli (altrimenti che segreti sarebbero ?) … i segreti veri sono altri 🙂 … e non ho ancora parlato di esempi di modellazione e tecniche da applicare … calma per il momento.

Come ? No … tutti questi consigli , segreti etc non sono raccolti in nessun libro purtroppo .. al massimo esistono dei corsi che raccontano il tutto con esempi  reali . Questo è il link Corsi di modellazione DWH

Alla prossima …

%d blogger hanno fatto clic su Mi Piace per questo: