BI Methodology

Published 22 settembre 08 11.39 | fdechirico

 

Come annunciato dallo stesso Marco Russo sul proprio blog, egli , insieme ad Alberto Ferrari, ha pubblicato il primo di una serie di "white paper" dedicati alla BI Methodology. Come dichiarato dagli stessi autori il paper rappresenta  il tentativo di definire una metodologia per la costruzione dell'intero back-end di una soluzione di BI utilizzando Microsoft SQL Server ed i servizi ad esso legati.

Per evitare fraintendimenti, Marco e Alberto, fin dall'introduzione, segnalano che il documento non vuol essere l'ennesimo capitolo della saga "Kimball vs Inmon" (che probabilmente non avrà mai fine ma che, in realtà, non avrebbe alcun motivo di esistere) ma, più concretamente, la definizione di come "dovrebbe" essere concepito un progetto di BI (fin dall'inizio!!!) per avere una struttura sufficientemente flessibile e completa in grado di supportare al meglio le inevitabili esigenze di modifica e rivisitazione che una soluzione BI richiede nel suo normale ciclo di vita.

Il documento rappresenta la sintesi delle esperienze maturate dai due autori negli anni e quindi fornisce (se seguito nelle sue preziose indicazioni) "implicitamente"  la soluzione a tanti piccoli/grandi problemi che inevitablmente (prima o poi)  si presentano, ed ai quali, se non ci si è attrezzati prima, si fatica a fornire una soluzione o per i quali (nei casi peggiori) si  è costretti a dovere rimettere in discussione l'intero progetto.

Personalmente posso solo dire che condivido e sottoscrivo interamente i concetti e le soluzioni proposte e limitarmi a lanciare 2 suggerimenti:

                1) leggetelo!!!

                2) se avete commenti, osservazioni, dubbi e quant'altro scrivete direttamente agli autori o nel forum apposito  perchè è bene che si aprano discussioni e confronti su questo come su altri temi

Così come Marco e Alberto, sono infatti convinto che solo attraverso la discussione ed il contributo di tutti ognuno di noi può  migliorare la qualità del proprio lavoro.

Ne approfitto per citare alcune "perle di saggezza" presenti nel documento e che meritano di essere citate per la loro duplice valenza di "verità" e  provocazione:

pagina 7: "If we can express a complex query only using MDX, probably we could improve the dimensional design to simplify its usage."

pagina 7: "When the users start to look at the data, they always discover something interesting to analyze that was not so clear at the beginning. This is not a failure of the analyst; it is a rule in BI solution development"

pagina 9: "Normally in the OLTP system, you will find historical data that is not correct. This is a rule, not an exception. A system that runs from years has very often data that is not correct and never will be."

pagina 27: "There are many reasons why bad data comes to the data warehouse. The sad reality is that bad data happens and we need to manage it gracefully."

 

 

Filed under:

Comments

# dmauri said on settembre 23, 2008 05.50 :

"Normally in the OLTP system, you will find historical data that is not correct. This is a rule, not an exception. A system that runs from years has very often data that is not correct and never will be."

Questo purtroppo accade perchè i DB sono fatti da persone incopententi in materia. Un DB ben modellato dovrebbe PREVENIRE proprio questa situazione.....consentendo un NOTEVOLE risparmio di soldi durante la creazione di una soluzione di BI, in cui dalla mia esperienza il lavoro legato a "bad date" è quanto meno il 50%....

# fdechirico said on settembre 23, 2008 06.13 :

Sagge parole Davide. Quella che citi è forse la causa principale (non ho elementi per valutare in maniera oggettiva ma "a naso" mi sa che è proprio così). Resta il fatto che "l'effetto" di quella "causa" è proprio ciò che Marco e Alberto scrivono (e che noi tutti constatiamo quasi quotidianamente!!!)