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

Business Intelligence : Progetti Vincenti … come continuarli ?

Nel precedente articolo “Progetti di BI vincenti come iniziare” avevamo visto 11 step per iniziare bene un progetto di Business Intelligence, è però importante condividere il fatto che un progetto di BI vincente lo si riconosce dal fatto che la fine di uno step è l’inizio di una nuova fase, infatti tipicamente quando gli utenti sono contenti e apprezzano le potenzialità di quanto fatto è l’inizio di una serie di richieste per andare oltre , non possiamo però dormire sugli allori pensando che abbiamo lavorato bene e quindi tanto prima o poi i clienti chiederanno qualcosa di nuovo e soprattutto dobbiamo pensare che utenti che non chiedono e si adeguano a quanto hanno determinano la “morte” del progetto, il famoso mito che “tanto quando il cliente cambia ERP etc bisognerà rifare l’ETL e ci sarà da lavorare” sta crollando anche perchè ormai gli ERP si portano dietro la loro parte di BI.

Quindi cosa fare per dare longevità al progetto di BI e renderlo uno dei punti forti dei sistemi informativi del cliente ?

Automatizzare il reporting

Tipicamente i clienti hanno sempre dei report che vogliono aggiornare ogni giorno, ogni mese etc, magari report che devono essere inviati a N persone con dati differenti ( pensiamo ad una forza vendita ) , quindi possiamo far vedere all’utente quanto tempo potrebbe risparmiare schedulando il reporting e facendo in modo che sia automatizzato ( in modo da non avere prompt nel reporting schedulato )

Budget/Target

Diffidate da datamart dove non viene richiesto di inserire un budget/target o quanto meno la possibilità di calcolare dei KPI, se l’utente vuole monitorare le performance confrontandole con un obbiettivo allora avrà una urgenza da soddisfare, bisogna poi far capire che con un DWH ben modellato possiamo inserire e controllare budget a granularità anche fine ( tipo per ogni cliente o famiglia prodotti ) oltre che a diverse versioni o focus ( es: revisioni di estimate, target su prodotti focus ) in pratica far capire all’utente che non sempre avere un target vuol dire doverlo calcolare/caricare per ogni singola referenza possiamo lavorare al livello che meglio si associa alle possibilità dell’utente

Integrare dati dell’utente

Quei dannati file excel che hanno sempre qualche informazione che sui sistemi non esiste devono per forza essere caricati nel DWH, bisogna saper illustrare quali vantaggi potremmo creare se si potesse fare delle analis anche con quei dati

Mash-up dei datamart

Avere N datamart chiusi nei loro mondi può essere un primo passo, ma dobbiamo liberare la potenza generata dall’incrocio di tali dati, incrociare i dati dell’ordinato con i dati dei crediti potrebbe veramente dare dei quadri di lettura differenti, infatti sapere che il cliente X ha raddoppiato l’ordinato rispetto all’anno precedente ed è ora nella top 10 dei ns clienti più grandi ci può rendere felice, ma se potessimo aggiungere anche il fatto che in realtà non sti sta pagando da 6 mesi allora il quadro cambia totalmente … possiamo essere contenti che un cliente che non ci sta pagando stia ordinando molto ? quale esposizione ci genera ? e via dicendo gli esempi possono essere infiniti il limite potrebbe essere solo la ns fantasia , sicuramente potremmo trovare tantissimi indicatori importanti che nascono dall’unione dei dati di differenti datamart e la cui lettura di insieme può stravolgere quanto avevamo appreso leggendo i dati dei singoli datamart

Arricchimenti derivati

I dati che si possono integrare nel ns DWH per arricchire quanto già presente non vengono solo da “mondi esterni” ( file excel, altri datamart etc ) ma assumono grande importanza anche quelli derivati dai dati del datamart stesso, ad esempio in un classico datamart delle vendite potremmo “arricchire” la dimensione dei clienti o dei prodotti con dati tipo la classe di strategicità del cliente ( analisi ABC, grafico di Pareto, regola dell’80-20 etc ) , con il suo trend ( nuovo cliente,  cliente stabile, cliente con ordinato in crescita )  etc, già semplicemente questi attributi potrebbero regalare nuovi tipi di analisi o semplificare di molto quelle richieste dagli utenti ( es: qual’e’ il fatturato dei nuovi clienti vs quello fatto l’anno scorso da clienti persi ? quanti clienti sono in crescita e come si suddivido come classe di importanza ? qual’e’ la percentuale di fatturato data dai nuovi prodotti, dai prodotti in forte crescita etc etc ) …

Riassunto

In generale le parole chiavi per rendere un progetto vincente nel tempo, e proteggersi da cambi di idea del cliente che potrebbe “buttare” il ns progetto per adottare quello integrato nel nuovo ERP, potrebbero essere

Integrare : inserire sempre nuovi dati da ogni fonte (anche gli open data potrebbero tornare utili )

Incrociare : analisi incrociate tra diversi datamart

Customizzare: è il cliente che necessita delle analisi e di quelle che servono a lui, più sono tagliate su misura e più apprezzerà

Fate in modo che quanto fatto non sia replicabile da una sw house per quanto grande con le loro soluzioni generiche

 

 

 

 

 

 

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: