Alla BI Conference è arrivata l'ora del grande annuncio.

Da qualche tempo si vociferava sulla grande novità che sarebbe stata annunciata ed ora cominciamo a scoprire di cosa si tratta:

Project Madison (scale-out version of SQL Server, powered by DATAllegro technology)

SQL Server "Kilimanjaro" (next release of SQL Server)

Gemini (Analysis Services 2010 - Analysis Services using column-oriented and in-memory technologies)

Maggiori dettagli nei blog di Marco e Mosha e per chi volesse guardarsi la registrazione della keynote, qui Mosha ha postato i link.

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."

Per chi avesse partecipato all'evento di ieri (di cui qui Luca fa un breve resoconto) e avesse assistito all'ultima sessione sulla BI, devo correggere una mia errata affermazione in risposta ad una domanda di un partecipante relativa alla presenza o meno delle novità di Analysis Services nell'edizione Express.

Evidentemente la risposta è NO in quanto non è presente Analysis Services in tale edizione.

A "parziale" discolpa posso solo dire che per noi "cubisti" l'edizione Express (e Compact) viene sempre un po' snobbata in quanto, appunto, non contenente la parte BI e quindi mi riferivo alle differenze tra Enterprise e Standard Edition.

In ogni caso, per sgombrare ogni dubbio, il riferimento è ovviamente il sito ufficiale:

http://www.microsoft.com/sqlserver/2008/en/us/editions.aspx

Ogni tanto è utile fermarsi a riflettere ed a guardare le cose da una diversa angolazione.

Siamo tutti presi dalla quotidianità e dai nostri piccoli/grandi problemi.

E questo è il punto...  quanto grandi? o quanto piccoli?

Penso che questo valga più di mille parole.

Stimolato dal post di Andrea, vi propongo la mia personale classifica relativamente alle novità introdotte in Analysis Services 2008:

1) Aggregation Designer Improvement
2) SSAS database attach/detach
3) Attribute relationship tab 
4) Data Management Views
5) Writeback to MOLAP
6) Block computation

Qual'è la vostra?

 (Ah, sì, sono 6 ... ma proprio non saprei quale eliminare!!!)

Su richiesta è disponibile qui 

Se qualcuno poi fosse un po' stufo di questi cumulative update package, può unirsi a coloro che hanno richiesto a gran voce la SP3 qui.

Considerato che ad oggi esistono solo 3 libri su MDX (se qualcuno ne conosce altri si faccia avanti!!!)

MDX Solutions: With Microsoft SQL Server Analysis Services by George Spofford  (ante SSAS 2005)

MDX Solutions: With Microsoft SQL Server Analysis Services 2005 and Hyperion Essbase by George Spofford, Sivakumar Harinath, Christopher Webb, and Dylan Hai Huang (post SSAS 2005, in pratica l'evoluzione del precedente)

Fast Track to MDX by Mark Whitehorn, Robert Zare, and Mosha Pasumansky (orientato maggiormente agli script MDX e comunque ante SSAS 2005)

l'annuncio di un nuovo libro su questo argomento non può che fare piacere:

Fiendish MDX (Ensuring no-one but you understands the business logic on your cube)

Se poi a dare l'annuncio (come autore del libro) è un collega di Solid Quality Mentors, non si può che esserne felici.

Il titolo (molto intrigante) lascia intendere che il libro avrà un taglio molto particolare dedicato a chi "sta sul pezzo" tutti i giorni. Considerata la competenza e la professionalità di Chris sarà sicuramente un ottimo libro e spero di averne una copia al più presto.

 P.S. per chi non conoscesse Chris Webb.

UPDATE: visto che Chris lo ha reso noto... si tratta di uno scherzo!!!

... e se volete a vostra volta pubblicare un libro andate qui.

Per coloro che fossero interessati a certificarsi, è disponibile da pochi giorni in Prometric l'esame

70-556 TS: Microsoft Office PerformancePoint Server 2007, Applications

Se siete interessati qui trovate la Preparation Guide di Microsoft, mentre qui trovate una lista degli argomenti coperti dall'esame. La lista è relativa all'esame in versione beta ma pare che sia ancora valida.

 Fonti Adrian Downes e Nick Barclay (autori delle Rational Guide per PerformancePoint Server 2007: Monitoring e Planning)

Dopo il 70-431 (all'epoca era obbligatorio per la certificazione BI, ora non più!), ed il 70-445 (in versione BETA), finalmente ieri ho trovato il tempo (e la voglia ) di sostenere l'esame 70-446 (che non avevo superato in versione BETA).

Esame superato e finalmente terminato il percorso di certificazione sulla BI.

E adesso sotto con Performance Point in attesa di AS2008!!!

Io l'ho scoperta oggi, e visto che è in beta suppongo sia nuova:

http://www.sqlcommunity.com/

 "La stessa query MDX eseguita in momenti diversi fornisce risultati diversi"

Se fosse uno strumento diffuso come Excel, probabilmente il titolo di questo post sarebbe stato anche il titolo di molti giornali (vedi il post di Luca)

In realtà, come segnalato in questo documento la spiegazione è sempre legata alle conversioni fra tipi di dati.

Ma come fa notare Chris Webb nel suo post (fonte di questa notizia) è meglio saperlo prima di scoprirlo su segnalazione di un nostro cliente.

La CTP di giugno contiene molte novità riguardo MDX.

Per sapere quali basta rivolgersi a Mosha!

Non ho ben capito se l'ordine è esattamente quello con cui Mosha elenca i vincitori, comunque sia, male che vada è un terzo posto!

 A parte gli scherzi, mi è spiaciuto non incontrare Mosha e scambiare due chiacchiere con lui visto che è passato dall'Italia.

Per quanto riguarda il quiz due considerazioni:

1) Mosha è diabolico!

2) Questi "giochini" sono veramente utili per approfondire certi argomenti e per scoprire aspetti poco noti del linguaggio MDX e del motore di AS.

Ieri sera ho visto, per caso, una puntata di Numb3rs. Premetto che non sono un grande appassionato di questo telefilm (anche se talvolta mi capita di vederlo) ma la puntata di ieri sera ha attirato la mia attenzione per "deformazione professionale".

La solita indagine alla ricerca di una banda di criminali si è conclusa (ovviamente!) con la loro cattura dopo una indagine condotta utilizzando svariate tecnologie di ultimissima generazione, tra cui, in primis (udite, udite): "data mining".

Devo dire che aspettavo al varco di udire qualche castronata ma, aldilà della solita (e comprensibile, trattandosi di un telefilm) esagerazione cinematografica, i principi che sono stati brevemente (molto!) spiegati nel corso della puntata erano corretti e molto probabilmente sono riusciti a chiarire al vasto pubblico di cosa si tratta.

La cosa che mi è piaciuta è che questa tecnologia (come invece spesso accade) non sia stata spacciata come la ricetta magica per l'analisi dei dati ma, anzi, ne siano stati evidenziati anche i limiti o comunque la necessità (fondamentale!) della corretta interpretazione umana dei risultati ottenuti.

Nella puntata si fa infatti riferimento ad un progetto dell'FBI mirato ad individuare potenziali terroristi tra la popolazione statunitense (incrociando i dati su di essi disponibili alla amministrazione USA tramite appunto il data mining) e nell'elenco prodotto figurava anche Condoleezza Rice!

Ora, non so quanto ci sia di vero (e non voglio certo avventurarmi in considerazioni socio-politiche sul tema!), ma è certo che il messaggio (che condivido pienamente!) che il data mining sia una (delle tante) tecnologie utili all'analisi dei dati ma che senza il contributo umano di analisti che sappiano correttamente applicarla ed interpretarne i risultati, rischia di non centrare gli obiettivi che si pone (o peggio!!), credo sia la nota positiva da portare a casa. 

La considerazione finale che posso fare è che in genere quando una tecnologia, per quanto di nicchia ed innovativa, arriva ad essere oggetto di una puntata di una serie di così grande successo, significa che la sua diffusione (per lo meno negli States) sta cominciando a diventare un fenomeno "visibile". E questo è decisamente un bene.

Complimenti agli autori e produttori tra cui figura un certo Ridley Scott!!!

In questi ultimi giorni ho affrontato un problema di performance di un mio vecchio progetto abbastanza complesso. Interamente basato su Analysis Services 2000 e SQL Servrer 2000, è costituito da 34 cubi, 19 cubi virtuali e 212 (decentododici!!!) dimensioni condivise.

Tralasciando i dettagli tecnici che hanno di fatto imposto scelte architetturali che hanno prodotto questi numeri decisamente importanti, il problema che si è presentato è quello di performance totalmente insoddisfacenti nell'esecuzione di alcune query MDX.

Per inquadrare meglio il problema, va detto che i 34 cubi fisici sono in realtà 17 "coppie" di cubi identici dal punto di vista delle dimensioni (un cubo contiene una sola misura in "DistinctCount" e l'altro contiene tutte misure additive). Su ogni coppia di cubi è costruito un cubo virtuale che è poi il cubo al quale accedono gli utenti.

Ognuno dei 34 cubi fisici è partizionato per data e contiene dati a "stock" che si aggiornano mensilmente. La fase ETL è demandata all'esecuzione schedulata di VB script che, attraverso l'uso di Stored Procedure, si preoccupano del caricamento dei dati e del partizionamento del data mart di SQL Server (creando nuove tabelle fatti ad ogni nuovo caricamento ed eventualmente cancellando quelle "out of range"), della verifica della qualità dei dati (provenienti da estrazioni lato mainframe) e della registrazione in apposite tabelle di SQL Server (e su file) di tutti i log e le statistiche relativi alle azioni intraprese. Gli stessi script istanziano anche una ".dll" (scritta appositamente) che, utilizzando DSO, si fa carico del partizionamento dei cubi (creando una partizione per ogni tabella fisica) e dell'elaborazione di dimensioni e cubi (fisici e virtuali).

Tra i 19 cubi virtuali, ve ne sono due particolari che sono costruiti su più cubi fisici (una dozzina)! Le query in questione insistono proprio su questi ultimi ed i loro tempi di esecuzione spaziano da alcuni minuti a ... infinito (nel senso che nessuno ha mai avuto la pazienza di vedere se venivano effettivamente risolte). Va anche detto che queste query sono particolarmente complesse (molte decine di righe di codice) e contengono parecchio membri e set calcolati. Inoltre, per la tipologia dei dati in gioco, non possono sfruttare le aggregazioni dei cubi ma devono necessariamente fare una scansione dei dati contenuti nelle partizioni.

Dopo avere analizzato il codice ed eliminato diversi potenziali "colli di bottiglia", le prestazioni non sono migliorate in maniera significativa e comunque non per tutte le query.

Ci si è concentrati quindi su altri aspetti "esterni" e, dopo avere scartato diverse ipotesi, si è cominciato a sospettare che il partizionamento dei cubi non fosse corretto. O meglio, ci si è chiesti se effettivamente venissero utilizzate solo le partizioni utili alla risoluzione delle query.

Se il progetto fosse stato realizzato con SQL 2005 ed Analysis Services 2005 ci sarebbe venuto in soccorso il Profiler, ma con AS 2000 come si poteva fare?

Quello che noi sapevamo era dove (fisicamente) risiedono i file relativi alle partizioni dei cubi: nelle relative sottocartelle all'interno della cartella "Data" di Analysis Services.

Quello che (di fatto) volevamo sapere era "quali" di questi file venivano usati da Analysis Services per risolvere le query.

Quale strumento ci poteva aiutare a scoprirlo???   Il mitico FileMon di Mark Russinovich!!! (od eventualmente il suo successore Process Monitor).

Quindi, lanciato il programma, impostato come filtro il solo "msmdsrv.exe", avviata la registrazione degli eventi, lanciata la prima query e .... haha!!! venivano usate TUTTE le partizioni di TUTTI i cubi!!!!

Ci si è quindi accorti di un errore strutturale per cui lo slicer impostato nelle partizioni era incompleto e quindi insufficiente (ma solo per alcune situazioni particolari, guarda caso quelle delle query utilizzate!!!) a risolvere efficientemente le query MDX.

A questo punto è stato semplice (beh, insomma, quasi!!!) modificare la dll per correggere il problema e partizionare correttamente i cubi.

Morale... mi ero dimenticato quanto fosse "dura" la vita da "cubista" solo 5 anni fa (o se preferite solo una release fa)!!!