Una volta terminate le modifiche da apportare sul modello in fase di ETL, è possibile procedere allo step conclusivo del progetto ovvero la realizzazione ed elaborazione dei cubi (Process) sia per la modellazione tabulare che per quella multidimensionale di origine. Il Process del modello, è utilizzato anche dagli amministratori dell’istanza, per mantenere periodicamente aggiornati gli oggetti SSAS presenti nel cubo, come mostrato in Figura 8.3.
Figura 8.3 Elaborazione di cubo in SSAS
L'elaborazione consiste in una serie di passaggi che consentono di popolare gli oggetti di Analysis Services mediante l’accesso e il recupero dei dati dalle fonti originali. La procedura di elaborazione varia a seconda del tipo di oggetto e delle opzioni di elaborazione selezionate.
Nel nostro caso, poiché stiamo effettuando per la prima volta l’elaborazione del cubo tabulare, eseguiremo il comando di elaborazione completa (Full Process) che inizializza e rielabora (qualora esistesse) un cubo in Analysis Service, perdendo tutti i dati all’interno del cubo sottostante delle precedenti elaborazioni per la completa rielaborazione e successivamente, è possibile accedere agli oggetti di Analysis Services per l'esecuzione di query. Il processo di elaborazione funziona all'interno di una transazione, della quale è possibile eseguire il commit o il rollback. Se i processi di elaborazione hanno esito
negativo, viene eseguito il rollback della transazione. In caso di esito positivo, verrà applicato un blocco esclusivo all'oggetto durante il commit delle
modifiche, a indicare che l'oggetto è temporaneamente non disponibile per le query o l'elaborazione. Durante la fase di commit della transazione è ancora possibile inviare query all'oggetto, ma tali query verranno accodate fino al termine del commit.
Il “Process” viene applicatata per entrambe le modellazioni
(Multidimensionale e Tabulare) determinano due cubi distinti, utili per effettuare i vari confronti prestazionali in fase di utilizzo ed esecuzione.
Come già detto precedentemente nella definizione del "Multidimensional Data Model", l’azienda ha pensato di suddividere la memorizzazione delle tabelle dati degli importi in due aree distinte (Offline ed Online).
La sorgente dati con tabelle offline contiene dati storici relativi a scenari e periodi passati, mentre quella con tabelle online contiene dati relativi a scenari e periodi correnti, entrambe identiche dal punto di vista strutturale ma con capacità differenti (la capacità della sorgente dati offline è di gran lunga maggiore rispetto a quella online).
Grazie a tale suddivisione, è stato possibile processare il modello tabulare con tabelle degli importi differenti ottenendo due cubi con dati e capacità
differenti:
• “Tgk_Full”: Cubo processato ed ottenuto a partire dalla sorgente dati con dati storici e correnti del modello (Online e Offline) con la presenza di 139.418.866 di righe nella tabella dei fatti con una capienza pari a 1313,58 MB.
• “Tgk_Light”: Cubo processato ed ottenuto a partire dalla sorgente dati contenente i soli dati correnti (Online) con la presenza di 15.585.575 di righe nella tabella dei fatti con una capienza pari a 233,02 MB.
La realizzazione di cubi in SSAS Tabulare con capacità differenti ci permette di analizzare la “scalabilità del modello”, come la modellazione tabulare si
comporta all’aumentare progressivo dei dati al variare del tempo rispetto alle caratteristiche di scalabilità teoriche del modello multidimensionale.
Mentre per il modello multidimensionale è stato processato il modello originario ottenendo un solo cubo completo a partire dalla sorgente dati con dati storici e correnti del modello (Online e Offline) con una capienza del cubo pari a 1352,90 MB definito “Tgk_M” (leggermente più capiente rispetto al medesimo cubo processato in versione tabulare “Tgk_Full”).
Per poter effettuare analisi sulle prestazioni tra le due modellazioni, è
necessario eseguire un set di query sui diversi cubi precedentemente realizzati, così da analizzare il comportamento e i tempi di esecuzione query a confronto. Per la fase di definizione e generazione query è stato utilizzato il tool
Microsoft Excel con l’utilizzo delle Pivot Table, mentre per la fase di analisi e monitoraggio delle performance è stato adottato il tool Microsoft SQL Server Profiler utilizzato appositamente per identificare e misurare le prestazioni delle query nel tempo eseguite in una istanza di DB Sql Sever o Analysis Service (compatibile sia per cubi realizzati per modellazioni tabulari che per cubi multidimensionali).
Il supporto di SQL Profiler per query MDX nel contesto e supporto di Analysis Service viene introdotto a partire dalla versione di SQL Server 2005 ma attualmente risulta essere ancora un tool prettamente focalizzato per analisi query su Database.
Per i nostri scopi di analisi, il tool sarà utilizzato essenzialmente per recuperare i tempi di esecuzione per specifiche query complesse che causano un
rallentamento durante l’esecuzione di report da parte del cliente.
È possibile seguire l’attività SSAS catturando e analizzando gli eventi delle tracce query generati dall'istanza. Ogni evento di una traccia contiene una serie di dati rilevanti.
La seguente Figura descrive un esempio di monitoraggio, in SQL Server Profiler, di una query eseguita in una istanza SSAS.
Figura 8.4: Esempio di monitoraggio con SQL Server profiler
Come detto precedentemente, le query MDX sono state sviluppate
prettamente per modelli multidimensionali e successivamente query DAX per modelli tabulari ma in una istanza tabulare è possibile eseguire sia query di tipo DAX che query MDX.
Microsoft Excel presenta il vantaggio di impostare una connessione dati su un server Analysis Services indifferentemente dalla tipologia dell’istanza
(Multidimensionale o/e Tabulare) per mezzo di una semplice tabella pivot e lo svantaggio di non essere ancora attualmente supportato alla generazione di query in linguaggio DAX per i seguenti motivi:
• Il modello tabulare è un nuovo approccio di modellazione in SSAS proposto da Microsoft e attualmente non esiste ancora un motore di traduzione query ma MDX a DAX in fase di reporting con Microsoft Excel
• Il linguaggio DAX non è un vero e proprio linguaggio query e presenta caratteristiche di formulazione totalmente differenti.
In futuro, per ottenere un confronto completo utilizzando le piene capacità e funzionalità interne dei due modelli e la potenza dei due linguaggi, è possibile determinare query per entrambe le modellazioni con linguaggi differenti (DAX per modellazioni tabulari e MDX per modellazioni multidimensionali).
Attualmente le formule DAX possono essere utilizzate solo in cartelle di lavoro di Excel che contengono dati PowerPivot.
È possibile visualizzare le espressioni DAX inviate al motore di archiviazione in memoria se si esegue il monitoraggio delle interazioni tra il client
Non è stato possibile effettuare analisi con il client PowerPivot a causa di mancanza di privilegi di utilizzo aziendali e di compatibilità con il modello corrente.
Un altro utile tool per la generazione di report e di esecuzione query su modellazioni SSAS è PowerBI, software di proprietà Microsoft che mostra però lo stesso svantaggio di non essere ancora pienamente supportato durante il filtraggio delle dimensioni in modellazione tabulare in presenza di attributi chiave composti. Una soluzione possibile per superare tale incompatibilità è l’aggiunta di un attributo chiave per ogni tabella, combinando le varie Primary Key composte ottenendo una singola Primary Key per ogni tabella. A causa del gran numero di tabelle dati non si è scelto di attuare tale implementazione. Per questi motivi, nel nostro caso, ci limiteremo ad effettuare ed a confrontare i tempi prestazioni per query di tipo MDX per entrambe le modellazioni mediante l’utilizzo delle tabelle Pivot con Microsoft Excel, tralasciando le possibili e ulteriori ottimizzazioni disponibili che presenta il modello tabulare con l’utilizzo di query DAX.