Model Planning: Model Planning: 5

5

Model Planning:

Model Planning:

La fase di modellizzazione del Power Cube

La fase di modellizzazione del Power Cube

Nella fase di analisi dei requisiti aziendali, sono stati identificati e descritti i principali indicatori di performance richiesti dalla Direzione e le possibili prospettive di indagine degli eventi di interesse aziendale più significativi, vale a dire le vendite e gli acquisti dei prodotti. Abbiamo trattato inoltre l'importanza delle collaborazioni avutesi con gli utenti, con la Direzione e con i responsabili del CED per una comprensione soddisfacente degli aspetti del contesto aziendale più importanti per questo progetto. Dopo aver analizzando il sistema informativo aziendale, è stato implementato il Catalogo “Statistiche Magazzino” che rappresenta il primo obbiettivo raggiunto nell'iter di progettazione del Power Cube. La fase di lavoro che verrà trattata in questo capitolo rappresenta un passo fondamentale per il ciclo di vita del cubo multidimensionale: verrà infatti descritto il processo di modellizzazione del cubo, ovvero la costruzione dell'infrastruttura multidimensionale attraverso lo strumento di sviluppo COGNOS Power Play Transformer. Nel Capitolo I, era stata fornita una breve descrizione di questo tool mettendone in evidenza la duplice modalità di utilizzo: quella automatica e quella manuale. Senza ritornare sul primo metodo ritenuto inadeguato ai nostri scopi, è opportuno sottolineare che l'utilizzo manuale di COGNOS Power Play Transformer ha permesso soprattutto di coniugare le conoscenze di dominio fino ad ora raccolte con gli aspetti prettamente ingegneristici che sono stati affrontati nel proseguo di questo lavoro.

5.1 Il modello Transformer “CAPPISA_Power_Cube”

5.1 Il modello Transformer “CAPPISA_Power_Cube”

Un modello Trasformer è una particolare struttura multidimensionale che contiene la definizione di 3 componenti principali:

➢ Mappa delle Dimensioni; ➢ Lista delle Misure;

➢ Sorgenti Dati.

La Mappa delle Dimensioni (Dimension Map) è costituita dall'insieme delle dimensioni di analisi e dei rispettivi livelli gerarchici che rispecchiano determinati segmenti aziendali e che sono state oggetto di indagine nelle fasi iniziali del lavoro; la Lista delle Misure (Measures List) contiene l'insieme degli indicatori aziendali (anche questi raccolti inizialmente in collaborazione con la Direzione) attraverso cui quantificare gli aspetti di business di nostro interesse, vale a dire le vendite e gli acquisti dei prodotti. Le Sorgenti Dati (Data Sources) infine, costituiscono le fonti necessarie per alimentare, durante il processo di costruzione del cubo, ogni livello gerarchico e ciascuna misura del modello con i valori opportuni. La tipologia e la struttura dei dati sorgenti sono due aspetti che incidono profondamente sulle prestazioni di questo processo, e possono avere ripercussioni anche sulla performance delle applicazioni Power Play per l'analisi OLAP del cubo multidimensionale; in maniera simile alla progettazione di un Catalogo Impromptu, dove avevamo discusso l'importanza di una buona strategia di join, la fase di preparazione e progettazione dei dati sorgenti è stata studiata con attenzione per una buona riuscita del modello e verrà trattata approfonditamente in seguito. Le componenti strutturali del modello Transformer costituiscono quindi una collezione di “oggetti” con particolari proprietà, che possono essere controllati e gestiti

facilmente grazie all'ambiente grafico windows-based offerto da COGNOS Trasformer. Oltre le tre componenti del modello sopra descritte, Transformer permette di visualizzare altre aree di lavoro importanti dal punto di vista amministrativo, attraverso le quali si può disporre contestualmente di un controllo continuo dei dati che stiamo trattando; ad esempio, è possibile visualizzare il contenuto delle sorgenti dati (Data Source Viewer) che alimenteranno le categorie di ogni livello dimensionale, oppure la struttura gerarchica della mappa delle dimensioni (Dimension Viewer). Infine, per il Power Cube associato al modello multidimensionale, è riservata una finestra specifica (Power Cube List) attraverso la quale poter gestire e configurare opportuni parametri per il processo di creazione del Power Cube, e studiare le proprietà del cubo generato. Queste ultime aree di lavoro sono state impiegate nelle fasi di preparazione e ottimizzazione del processo di creazione del cubo, quindi in fasi successive a quelle che saranno discusse a breve.

5.1.1 La Mappa delle Dimensioni

5.1.1 La Mappa delle Dimensioni

Il primo passo verso la costruzione del modello per l'azienda (che è stato denominato, con ovvio riferimento, “CAPPISA_Power_Cube”) è stato quello di disegnare la mappa delle dimensioni partendo dalla specifiche raccolte nella Tabella 3.3 del Capitolo III. Il risultato di questo procedimento manuale è riportato in Figura 5.1. La mappa si articola in 6 dimensioni ognuna delle quali è composta da una gerarchia di categorie organizzate per livelli. Il percorso che unisce le categorie del livello gerarchico più alto a quello più basso (Drill Down Path) è univoco per tutte le dimensioni definite fatta eccezione per la dimensione Agenzia: il livello “Magazzino” infatti è raggiungibile scendendo in profondità partendo

alternativamente da uno dei due livelli superiori “Area” o “Comune”. Questa scelta implementativa riflette, come già discusso nelle specifiche delle dimensioni in esame, l'effettiva disposizione geografica delle agenzie e fornisce una prospettiva di analisi alternativa. In generale, in un modello Transformer le dimensioni si dividono in due grandi gruppi: le dimensioni cosi dette regolari e quelle temporali. Le prime (regular dimension) contengono livelli e categorie che si riferiscono tipicamente alla struttura aziendale, mentre le altre (time dimension) contengono livelli e categorie basati su valori temporali. Nel nostro modello, con riferimento intuitivo ai nomi scelti per le dimensioni, Periodo è la dimensione temporale, mentre le altre 5 sono dimensioni regolari. Si è ritenuto opportuno sottolineare questa diversificazione perché Transformer permette di gestire in modo automatico la generazione dei livelli per la dimensione temporale. In particolare, dopo aver definito il nome della dimensione, il programma attende, con un prompt di richiesta, l'opzione di input del progettista che può scegliere se generare le categorie di default oppure di tralasciare questo processo in favore di quello manuale; nel primo caso, Transformer genera automaticamente 3 livelli temporali gerarchici, Year/Quarter/Month, di cui è possibile modificare il nome o altresì eliminare il livello che non si ritiene adatto alle proprie analisi riducendo cosi la

profondità della gerarchia generata. Nel modello “CAPPISA_Power_cube” è stata impiegata questa tecnica, ridefinendo opportunamente i nomi dei livelli come mostrato in Figura 5.1, ed eliminando manualmente il livello intermedio relativo al quadrimestre; quest'ultima scelta è stata presa in collaborazione con la Direzione la quale, pur valutando questo livello di aggregazione temporale una prospettiva interessante, non la ha ritenuta necessaria per le analisi dei trend delle vendite e degli acquisti. Viceversa, la dimensione temporale modellata da Transformer in modo automatico è stata impiegata integralmente nel modello di Power Cube secondario (“CAPPISA_Classi_fatturato”), sviluppato su proposta personale per integrare il contenuto informativo del cubo originario con le informazioni relative alle performance di vendita dei clienti del Consorzio Agrario; attraverso questo modello alternativo (che tratteremo più avanti) si possono analizzare, ad esempio, le tipologie degli acquisti dei clienti suddivisi in classi di fatturato, oppure vedere come si sia evoluto nel tempo il loro “rapporto” nei confronti di certe linee di prodotti; chiaramente, queste sono analisi qualitative che non hanno nulla a che che vedere con quelle più complesse che si possono ottenere con applicazioni specifiche di data-mining, che esulano dal presente lavoro di tesi; il nostro scopo è quello di fare in modo che l'utente possa costruire la propria analisi OLAP navigando attraverso i dati del Power cube e contestualmente attraverso quelli di un altro cubo (Drill Through) generando così report dinamici e dal contenuto informativo maggiormente dettagliato.

5.1.2 La lista delle Misure

5.1.2 La lista delle Misure

La definizione dell'insieme delle misure è stata condotta anch'essa con un procedimento manuale e si compone di 6 misure ordinarie e di 2 misure derivate: le prime verranno generate direttamente con i valori numerici di opportuni dati sorgenti, le altre due sono invece il risultato di una formula matematica avente per argomenti alcune delle misure precedenti. In Figura 5.2 è riportato l'elenco delle misure definite nella sua versione definitiva; infatti il completamento delle proprietà delle stesse è avvenuto solo successivamente, e cioè dopo la definizione dei dati sorgenti e pertanto tralasciamo questa discussione per riprenderla in seconda sede disponendo di in un quadro più completo. Fino a questo punto infatti, la definizione manuale del nostro modello è stata ottenuta attraverso un mapping relativamente semplice delle specifiche descritte nei capitoli precedenti; la progettazione dei dati sorgenti ed la loro associazione alle componenti del modello fino ad ora trattate coinvolge aspetti di carattere maggiormente ingegneristico che inizieremo a descrivere a partire dal prossimo paragrafo.

Figura 5.2 Lista delle Misure

Misure ordinarie

Misure derivate

5.2 Preparazione alla progettazione dei Dati Sorgenti

5.2 Preparazione alla progettazione dei Dati Sorgenti

Come anticipato all'inizio di questo capitolo, una corretta modellizzazione delle sorgenti dati ha un impatto decisamente positivo sulla performance del cubo sia per quanto riguarda la tempistica del processo di creazione che per quanto concerne le prestazioni delle applicazioni Power Play a run tme per le analisi OLAP. Questo tipo di considerazioni sono state raggiunte prendendo in esame le fasi in cui si articola il processo di generazione del Power Cube, e sono state un punto di riferimento importante al fine di intraprendere le decisioni implementative migliori. Transformer infatti genera la struttura del cubo eseguendo un algoritmo interno costituito da una serie di operazioni di lettura e scrittura dei dati la cui complessità dipende anche dalla struttura delle fonti sorgenti, oltre che ovviamente da altri fattori che considereremo. In Figura 5.3 è rappresento il diagramma delle attività relativo al processo, la cui dinamica si svolge principalmente attraverso 3 fasi distinte:

● Generazione delle categorie e del work file: è la fase di lettura dei records

dei dati sorgenti per la creazione delle categorie; i records di input elaborati sono memorizzati successivamente in forma compressa in file temporanei (work files) sulla base del modello Transformer.

● Update dei metadati: è la fase nella quale viene definita la struttura del

Power Cube: al termine della lettura dei dati di input, il file work temporaneo viene elaborato per definire l'insieme delle categorie che verranno inserite all'interno del cubo; in particolare, Transformer genera una copia del file work, ed una volta completata la sua elaborazione, elimina il file work originale e la lista delle categorie candidate vengono memorizzate

all'interno della struttura del cubo. Sono inclusi inoltre i metadati relativi alle dimensioni, livelli e alle misure per l'inizializzazione del Power cube.

● Update dei dati: rappresenta (normalmente) lo step dominante dell'intero

processo in termini di tempo; una volta aggiunte le categorie, i valori attuali

Figura 5.3 Il processo di generazione del Power Cube

Inizializzazione e generazione del

Power Cube

Inizializzazione del Power Cube ed update dei metadati Generazione delle

categorie e del work file

Update dei dati per il Power Cube Work File Dati sorgenti Modello Modello Modello Records di input Works records Dati Works records Metadati Power Cube (mdc)

dei file works temporanei vengono inseriti nel cubo; è previsto un processo di consolidamento dei records e aggiornamento dello “stato” delle categorie (aggregazione delle categorie e definizione del link tra le misure e le dimensioni).

Esistono una serie di problematiche comuni tra le fasi descritte che possono inficiare il processo di generazione del cubo, come ad esempio quelle legate alla presenza di memoria o di spazio su disco insufficienti (risorse hardware), oppure quelle legate alla natura della connessione al Database. Si tratta quindi di problematiche circoscritte alle risorse di sistema disponibili che possono essere affrontate ricorrendo ad un potenziamento delle risorse stesse, sia in termini di memoria che di capacità elaborative. L'utilizzo delle risorse da parte di Power Play Transformer è indubbiamente un aspetto importante da tenere in considerazione perché legato alla struttura del modello multidimensionale, in particolare a quella delle sorgenti di dati che stiamo trattando. Infatti, l'overhead introdotto dalla fase di lettura dei records di input può ricoprire una peso significativo rispetto a quello introdotto dalle ultime due fasi del processo. Tuttavia, l'abbattimento di questi ritardi non è sempre perseguibile aumentando esclusivamente le risorse di sistema, bensì dedicando del tempo nella progettazione iniziale delle fonti di dati partendo prima di tutto da una considerazione semplice ma di fondamentale importanza: il tempo necessario per la creazione del Power Cube è direttamente proporzionale al numero di records di input elaborati da Transformer. Sulla base di questo principio, l'obbiettivo che ha caratterizzato questa fase di progettazione è stato quello di strutturare i dati sorgenti in modo tale da premettere a Transformer il recupero dal Database aziendale dei dati strettamente necessari per le misure e per le categorie dei livelli gerarchici, mantenendo, come vedremo, un livello di ridondanza minimo

per il corretto collegamento tra i diversi livelli. Il primo passo verso la fase operativa della progettazione, è stato quello di stabilire la tipologia si dati sorgenti più consona ai nostri scopi, che verrà discussa nel prossimo paragrafo.

5.2.1 L'utilizzo di COGNOS Impromptu per

5.2.1 L'utilizzo di COGNOS Impromptu per

la generazione dei file sorgenti

la generazione dei file sorgenti

In generale, Transformer supporta un'ampia gamma di formati di dati sorgenti, dai semplici file di testo (nelle estensioni più comuni come .txt, .asc, .csv,...) a file nativi per alcuni tipi di database (dBase, Microsoft Access, Paradox,..); facendo riferimento all'architettura client/server rappresentata in Figura 2.1 del Capitolo II, i dati sorgenti del nostro modello sono stati generati attraverso la creazione di opportuni reports in ambiente Impromptu, che per default risulta direttamente accessibile dalla barra del menu di Transformer, e provvedendo al salvataggio degli stessi come Impromptu Query Definition file (estensione .iqd). Un file IQD (Figura 5.4) si articola in una serie di sezioni contenenti le informazioni necessarie (metadati) utilizzate da Tranformer per l'accesso al Database; in particolare, al suo interno è contenuta la definizione della query SQL (compresa tra le clausole BEGIN SQL ed END SQL) generata da Impromptu, e quella relativa alle diverse colonne nello stesso ordine di presenza all'interno del report. In questo senso, la definizione di un file IQD nel modello Transformer è costituita da un insieme di colonne sorgenti che verranno opportunamente associate ai livelli che compongono le dimensioni ed alle misure. In particolare, le colonne che saranno utilizzate da Tranformer per il popolamento delle categorie delle dimensioni conterranno dati strutturali, caratterizzati cioè da un contenuto pressoché statico come ad esempio

espressioni di testo (descrizioni, etichette, ecc..), mentre le colonne che alimenteranno l'insieme delle misure conteranno dati transazionali, tipicamente valori numerici che si diversificano dai precedenti per il loro carattere dinamico.

L'utilizzo di un ambiente di sviluppo integrato come quello offerto da COGNOS Tranformer ed Impromptu ha portato vantaggi indiscutibili per il controllo mantenimento dei file generati; l'area di preview dei dati sorgenti (Data Source Viewer) consente un refresh continuo del contenuto delle colonne con i dati operazionali residenti nel Database aziendale. Inoltre, lo spazio su disco occupato da questa tipologia di file è piuttosto ridotto e ciò ha contribuito positivamente al mantenimento delle dimensioni del nostro modello entro certi limiti.

Figura 5.4 Struttura di un Impromptu Query Definition file

COGNOS QUERY STRUCTURE,1,1

DATABASE, ...// Nome del Database Aziendale (“CAPPISA_su_aix”). DATASOURCENAME,...// Percorso del report Impromptu ( file .imr). TITLE, ...// Nome del report.

BEGIN SQL select ... ... ... from ... where ... END SQL

COLUMN,1,...// Nomi identificativi delle colonne che costituiscono COLUMN,2,...// il report, contenenti dati transazionali o strutturali. COLUMN,3,...//

...

Query nel linguaggio Impromptu SQL

5.2.2 Multiple Data Sources

5.2.2 Multiple Data Sources

Fino a questo punto della trattazione, si è fatto implicito riferimento alla presenza di molteplici sorgenti dati; la nostra attenzione iniziale si era in realtà focalizzata sulla possibilità di poter generare un report Impromptu globale, facendo confluire in una singola sorgente l'intero corredo di dati strutturali e transazionali per l'alimentazione del nostro modello. La generazione di un report simile si è rivelata da subito problematica: il grande volume di dati da estrarre ha richiesto la definizione di un numero di colonne elevato, tale da rendere difficoltosa la loro gestione, e che ha comportato inevitabilmente una perdita significativa della visibilità dei dati del report ed il rischio di ottenere records duplicati al suo interno e quindi informazioni ridondanti. In alcuni dei tentativi intrapresi, la consistenza dei dati ottenuti è stata compromessa poiché il livello elevato di complessità della query SQL ha portato ad un incremento dei tempi di risposta non tollerabili.

In sostanza, l'impiego di una sorgente di dati singola si è rivelata interessante solamente da un punto di vista teorico; dalla stima del numero di bytes complessivi che devono essere elaborati da Transformer per popolare il nostro modello con una singola fonte dati, è emerso un valore decisamente superiore rispetto a quello stimato per più sorgenti distinte; riporteremo in forma schematica il risultato di questo calcolo evidenziando come la notevole differenza riscontrata tra i due approcci discussi, abbia confermato positivamente la scelta implementativa intrapresa. In precedenza, si è messo in evidenza come esista una differenza fondamentale tra dati strutturali e dati transazionali; sulla base di questa diversificazione, ci è sembrato opportuno classificare i dati sorgenti che dovranno essere creati in due gruppi: i files IQD strutturali ed i files IQD transazionali. Dal prossimo paragrafo verrà descritta la procedura operativa per la creazione del primo gruppo di files.

5.2.1.1 Il set di files IQD strutturali 5.2.1.1 Il set di files IQD strutturali

Le dimensioni strutturali che compongono la mappa delle dimensioni del nostro modello 5: Gruppi Merceologici, Agenzia, Causale Vendita/Acquisto, Clienti e Fornitori. Per ognuna di queste dimensioni, è stato creato report ad hoc in ambiente Impromptu e successivamente il file iqd generato dal salvataggio del report è stato aggiunto all'insieme (inizialmente vuoto) dei dati sorgenti; infine sono state definite manualmente le relazioni opportune tra le colonne sorgenti ed i livelli della dimensione in esame. Il primo report generato è quello relativo alla dimensione Clienti; in Figura 5.5 è riportata la finestra Impromptu per la definizione della query, cioè per la selezione manuale delle colonne che formeranno il report.

Le colonne raffigurate nell'area Query data sono state selezionate dalle tabelle del Catalogo “Statistiche Magazzino” riportate nell'area adiacente alla precedente. Successivamente, è stato impostato un filtro (Figura 5.6) opportuno dal comando Filter per selezionare le informazioni strettamente relative ai soci clienti, che sono memorizzate nella medesima tabella dove risiedono quelle relative ai fornitori.

La finestra in primo piano permette di visualizzare il contenuto completo del Catalogo nella stessa modalità della finestra precedente; la definizione del filtro coinvolge la colonna “codtcf” che non è stata selezionata in precedenza tra gli argomenti della query, ma che appartiene alla tabella “mitico_clfagg”. Dalla barra

del menù del finestra Query che stiamo descrivendo, non sono state utilizzate le funzionalità di raggruppamento ed ordinamento (Group e Sort) poiché non necessarie alla luce della finalità per cui è stato creato il report. In Figura 5.7, riportiamo comunque il report nella sua forma base ottenuto dall'esecuzione della query.

A questo punto, è stato effettuato il salvataggio del report “Clienti.imr” in formato .iqd, mantenendo immutato il nome del file che corrisponde alla dimensione che stiamo trattando. Riportiamo il contenuto del file “Clienti.iqd” visualizzabile attraverso un semplice file di testo, con lo scopo di evidenziare la corrispondenza tra la definizione della query SQL nel linguaggio nativo di Impromptu e le operazioni manuali descritte in precedenza. Nel seguito della trattazione, l'output

relativo agli altri report non verrà raffigurato (come vedremo è il medesimo ottenuto nel preview Data Sources Viewer di Transformer) ma ci è sembrato opportuno ed interessante mantenere il contenuto dei files iqd, evidenziando le corrispondenze di cui si è parlato in precedenza.

// File Clienti.iqd // File Clienti.iqd COGNOS QUERY COGNOS QUERY STRUCTURE,1,1 STRUCTURE,1,1 DATABASE,CAPPI_su_aix DATABASE,CAPPI_su_aix DATASOURCENAME,C:\Cubi\Report_Cubi\Clienti.imr DATASOURCENAME,C:\Cubi\Report_Cubi\Clienti.imr TITLE,Clienti TITLE,Clienti BEGIN SQL BEGIN SQL select T1."codclf" as c1, select T1."codclf" as c1, T1."ragsoc" as c2, T1."ragsoc" as c2, T1."codpro" as c3, T1."codpro" as c3, T2."descri" as c4, T2."descri" as c4, T2."codreg" as c5 T2."codreg" as c5 from "mitico_clifor" T1, from "mitico_clifor" T1, "mitico_tbprov" T2, "mitico_tbprov" T2, "mitico_clfagg" T3 "mitico_clfagg" T3

where (T1."codpro" = T2."codpro")

where (T1."codpro" = T2."codpro")

and (T1."codclf" = T3."codclf")

and (T1."codclf" = T3."codclf")

and ((T3."codtcf" = 'C') and ((T3."codtcf" = 'C') END SQL END SQL COLUMN,0,CodiceCliente COLUMN,0,CodiceCliente COLUMN,1,Ragsoc COLUMN,1,Ragsoc COLUMN,2,Codpro COLUMN,2,Codpro COLUMN,3,Descri COLUMN,3,Descri COLUMN,4,Codreg COLUMN,4,Codreg

Il procedimento impiegato per la creazione del file “Fornitori.iqd” è stato svolto in maniera analoga a quello precedente. La dimensione Fornitori si compone di un solo livello, per cui i dati estratti dalle colonne delle tabelle del Catalogo sono

quelli relativi unicamente al codice identificativo del socio fornitore, nome anagrafico, ed indirizzo. Quest'ultimo è stato ottenuto dai valori di altre colonne mediante l'utilizzo di una particolare funzione che opera su stringhe di caratteri (funzione pack), che ha restituito la descrizione testuale dell'indirizzo nel formato desiderato. Il contenuto del file riportato di seguito evidenzia le corrispondenze tra le nostre operazioni manuali e l'SQL generato da Impromptu; l'unica nota aggiuntiva è la presenza tra gli argomenti della clausola SELECT della funzione pack. // File Fornitori.iqd // File Fornitori.iqd COGNOS QUERY COGNOS QUERY STRUCTURE,1,1 STRUCTURE,1,1 DATABASE,CAPPISA_su_aix DATABASE,CAPPISA_su_aix DATASOURCENAME,C:\Cubi\Report_Cubi\Fornitori.imr DATASOURCENAME,C:\Cubi\Report_Cubi\Fornitori.imr TITLE,Fornitori TITLE,Fornitori BEGIN SQL BEGIN SQL select T1."codclf" as c1, select T1."codclf" as c1, T1."ragsoc" as c2, T1."ragsoc" as c2,

(pack(T1."indiri" || T1."indir2" || T1."codcap" || ',' || T1."comune" || '(' || T1."codpro" || ')')) as c3

(pack(T1."indiri" || T1."indir2" || T1."codcap" || ',' || T1."comune" || '(' || T1."codpro" || ')')) as c3

from "mitico_clifor" T1,

from "mitico_clifor" T1,

"mitico_clfagg" T2

"mitico_clfagg" T2

where (T1."codclf" = T2."codclf")

where (T1."codclf" = T2."codclf")

and (T2."codtcf" = 'F') and (T2."codtcf" = 'F') END SQL END SQL COLUMN,0,CodiceFornitore COLUMN,0,CodiceFornitore COLUMN,1,RagSociale COLUMN,1,RagSociale COLUMN,2,Indiri COLUMN,2,Indiri

La funzione pack effettua un concatenamento dei caratteri e delle stringhe passate per argomento restituendo, mediante un'operazione di padding, una stringa nella quale sono stati eliminati gli spazi in eccesso e mantenendo intatta la dimensione delle stringhe originarie. E' interessante sottolineare la traduzione a livello di

sintassi del linguaggio SQL: l'operatore aritmetico '+' è tradotto da Impromptu nell'operatore '||'. Si tratta di una tipica conversione adottata dal programma, che è stata riscontrata anche nei file successivi che andiamo a descrivere. Per la dimensione Agenzia, il contenuto del file “Magazzino.iqd” è riportato di seguito.

// File Magazzino.iqd // File Magazzino.iqd COGNOS QUERY COGNOS QUERY STRUCTURE,1,1 STRUCTURE,1,1 DATABASE,CAPPISA_su_aix DATABASE,CAPPISA_su_aix DATASOURCENAME,C:\

DATASOURCENAME,C:\Cubi\Report_Cubi\Magazzini.imrCubi\Report_Cubi\Magazzini.imr TITLE,Magazzini1 TITLE,Magazzini1 BEGIN SQL BEGIN SQL select T1."codmag" as c1, select T1."codmag" as c1, T1."indiri" as c2, T1."indiri" as c2, T1."descri" as c3, T1."descri" as c3, T2."codpro" as c4, T2."codpro" as c4, T2."descri" as c5, T2."descri" as c5, T1."comune" as c6 T1."comune" as c6 from "mitico_tbprov" T2, from "mitico_tbprov" T2, "mitico_tbmaga" T1 "mitico_tbmaga" T1

where (T2."codpro" = T1."codpro")

where (T2."codpro" = T1."codpro")

and (T1."tipmag" = '1') and (T1."tipmag" = '1') END SQL END SQL COLUMN,0,CodiceMagazzino COLUMN,0,CodiceMagazzino COLUMN,1,IndirizzoMaga COLUMN,1,IndirizzoMaga COLUMN,2,Descrizione COLUMN,2,Descrizione COLUMN,3,Codpromag COLUMN,3,Codpromag COLUMN,4,Descrimag COLUMN,4,Descrimag COLUMN,5,Comune COLUMN,5,Comune

Le colonne relative alla provincia ed al comune dell'agenzia verranno utilizzate da Transformer per alimentare il primo livello della dimensione Agenzia, costituito da due sottolivelli distinti che confluiscono nel livello sottostante; vedremo in seguito, come queste colonne dovranno essere associate in modo opportuno ai suddetti

livelli per assicurare la corretta generazione delle categorie per il Drill Down Path alternativo. L'ultima dimensione che ci resta da esaminare è la dimensione Gruppi Merceologici. Nella discussione relativa alla progettazione del nostro Catalogo, avevamo visto come le tabelle contenenti le informazioni dei diversi gruppi di prodotti fossero in realtà una copia (alias) di una tabella del Database aziendale; avevamo inoltre discusso la scelta di includere le tabelle “Famiglia”, “Gruppo” e “Sottogruppo” nel Catalogo e la relativa strategia di join implementata per un corretto recupero delle descrizioni di ogni singolo gruppo e per garantire la consistenza dei dati nei report creati dall'utente. Tali descrizioni sono le stesse che devono essere estrapolate in questa fase, ma il loro recupero è stato ideato diversamente da quanto effettuato fino a questo momento, Infatti, la creazione di un unico report contenente le informazioni dell'intera gerarchia di gruppi merceologici avrebbe comportato la definizione di opportune espressioni condizionali tra le colonne selezionate (Query data) e di un filtro piuttosto complesso con il rischio di degradare eccessivamente le prestazioni nell'estrazione dei dati da parte di Transformer. Poiché, come avevamo detto nel corso del paragrafo, Transformer interpreta una query come un set distinto di colonne, la nostra idea è stata quella di creare 3 semplici reports distinti, uno per ogni singolo livello gerarchico della dimensione. Come vedremo, il ricorso a questa ulteriore “segmentazione” dei dati ha contribuito positivamente sulla durata del processo di creazione del cubo, obbiettivo principe di tutta la nostra discussione. Inoltre le espressioni impostate per i filtri riflettono specularmente la codifica dei codici dei tre livelli presente nelle 3 tabelle. Per completezza, riportiamo di seguito i 3 files iqd generati (GM_Famiglia.iqd, GM_Gruppo.iqd, GM_Sottogruppo.iqd) per poi proseguire con il paragrafo successivo, dove verrà presentato il file iqd transazionale del quale discuteremo l'impostazione complessiva della query entrando dovutamente nella semantica dei dati aziendali per la comprensione delle scelte intraprese.

// File GM_Famiglie.iqd // File GM_Famiglie.iqd COGNOS QUERY COGNOS QUERY STRUCTURE,1,1 STRUCTURE,1,1 DATABASE,CAPPISA_su_aix DATABASE,CAPPISA_su_aix DATASOURCENAME,C:\Cubi\Report_cubi\

DATASOURCENAME,C:\Cubi\Report_cubi\GM_Famiglie.imrGM_Famiglie.imr TITLE,GM_Famiglie TITLE,GM_Famiglie BEGIN SQL BEGIN SQL select T1."codgr1" as c1, select T1."codgr1" as c1, T1."descri" as c2 T1."descri" as c2 from "Famiglia" T1 from "Famiglia" T1

where ((T1."codgr2" = ' ') and (T1."codgr3" = ' '))

where ((T1."codgr2" = ' ') and (T1."codgr3" = ' '))

END SQL END SQL COLUMN,0,Codgr1 COLUMN,0,Codgr1 COLUMN,1,DescrFamiglia COLUMN,1,DescrFamiglia // File GM_Gruppi.iqd // File GM_Gruppi.iqd COGNOS QUERY COGNOS QUERY STRUCTURE,1,1 STRUCTURE,1,1 DATABASE,CAPPISA_su_aix DATABASE,CAPPISA_su_aix DATASOURCENAME,C:\Cubi\Report_cubi\

DATASOURCENAME,C:\Cubi\Report_cubi\GM_Gruppi.imrGM_Gruppi.imr TITLE,GM_Gruppi TITLE,GM_Gruppi BEGIN SQL BEGIN SQL select T1."codgr1" as c1, select T1."codgr1" as c1, T1."codgr2" as c2, T1."codgr2" as c2, T1."descri" as c3 T1."descri" as c3 from "Gruppo" T1 from "Gruppo" T1

where ((T1."codgr2" <> ' ') and (T1."codgr3" = ' '))

where ((T1."codgr2" <> ' ') and (T1."codgr3" = ' '))

END SQL END SQL COLUMN,0,Codgr1 COLUMN,0,Codgr1 COLUMN,1,Codgr2 COLUMN,1,Codgr2 COLUMN,2,DescrGruppo COLUMN,2,DescrGruppo

// File GM_Sottogruppi.iqd // File GM_Sottogruppi.iqd COGNOS QUERY COGNOS QUERY STRUCTURE,1,1 STRUCTURE,1,1 DATABASE,CAPPISA_su_aix DATABASE,CAPPISA_su_aix DATASOURCENAME,C:\Cubi\Report_cubi\

DATASOURCENAME,C:\Cubi\Report_cubi\GM_Sottogruppi.imrGM_Sottogruppi.imr TITLE,GM_Sottogruppi TITLE,GM_Sottogruppi BEGIN SQL BEGIN SQL select T1."codgr1" as c1, select T1."codgr1" as c1, T1."codgr2" as c2, T1."codgr2" as c2, T1."codgr3" as c3, T1."codgr3" as c3, T1."descri" as c4 T1."descri" as c4 from "Sottogruppo" T1 from "Sottogruppo" T1

where (((T1."codgr1" <> ' ') and (T1."codgr2" <> ' ')) and (T1."codgr3" <> ' '))

where (((T1."codgr1" <> ' ') and (T1."codgr2" <> ' ')) and (T1."codgr3" <> ' '))

END SQL END SQL COLUMN,0,Codgr1 COLUMN,0,Codgr1 COLUMN,1,Codgr2 COLUMN,1,Codgr2 COLUMN,2,Codgr3 COLUMN,2,Codgr3 COLUMN,3,DescrSottogruppo COLUMN,3,DescrSottogruppo

In ultima analisi, ci sembra opportuno osservare gli ultimi due files contengono la definizione delle colonne relative ai codici identificativi dei livelli parentali; questa scelta è stata necessaria per mantenere una corretta visibilità (scope) dei diversi files sorgenti relativamente ai livelli gerarchici. Questo aspetto, collegato al problema dell'unicità delle categorie, verrà ripreso opportunamente in seguito quando verranno descritte le relazioni associative tra le colonne dei file sorgenti ed i diversi livelli delle dimensioni.

5.2.2.2 Il file IQD transazionale 5.2.2.2 Il file IQD transazionale

L'ultimo ma non meno importante file iqd che stiamo per trattare contiene la definizione delle colonne sorgenti per le misure del nostro modello Transformer “CAPPISA_Power_Cube”. Contrariamente da quanto annunciato all'inizio, il set di file transazionali è in realtà costituito da un unico file; la scelta di mantenere l'insieme delle colonne relative agli indicatori delle vendite e degli acquisti all'interno di un'unica sorgente è legata ancora una volta alla durata temporale della fase di lettura dei dati durante il processo di creazione del cubo. Il file transazionale in esame, “Vendite_Acquisti.iqd”, è stato ottenuto dal report Impromptu omonimo, frutto della fusione di due reports distinti che originariamente avevamo implementato per recuperare i dati relativi alle vendite dei prodotti (“Vendite.imr”) e degli acquisti dai fornitori (“Acquisti.imr”). Inizialmente, l'aver generato due file transazionali distinti è risultato apparentemente in linea con il principio di segmentazione dei dati per una riduzione significativa del volume dei dati da elaborare. Nel nostro caso invece, si è dovuto ricorrere ad una “inversione di tendenza” per l'ottenimento di tempi di elaborazione migliori; prima di affrontare questo aspetto, è opportuno descrivere operativamente come siano state individuate le tabelle del Catalogo e le relative colonne dalle quali poter estrarre gli indicatori aziendali discussi nei capitoli precedenti. In Figura 5.7, riportiamo la finestra Impromptu per la selezione delle colonne per il report “Vendite_Acquisti.imr”. Le aree racchiuse nelle forme circolari contengono le colonne sorgenti relative alle misure del modello (area Query data) e le tabelle dalle quali sono state selezionate (area Catalog). Ciascuna misura è stata definita in modo opportuno per permetterne una corretta allocazione con i livelli delle dimensioni: le misure Quantità venduta, Importo vendite, Importo provvigioni e Valore di costo non devono essere allocate per la dimensione Fornitori; viceversa, l'allocazione delle misure rimanenti non

coinvolgere la dimensione Clienti.Prima di esaminare la definizione di ciascuna misura, riportiamo in Figura 5.8, il filtro creato per questo report. L'espressione logica del filtro definito è composta da 4 filtri principali che agiscono rispettivamente (partendo da sinistra e procedendo verso destra nella lettura del filtro) sulle tabelle “Mitico_Tbcama”, “Mitico_magmov” e “Mitico_tbmaga”.In particolare, dalla prima tabella che contiene la specifica delle diverse causali, sono stati selezionati i records relativi alle sole operazioni di vendita e di acquisto definendo l'espressione riportata per la colonna “caurag” ed escludendo eventuali omaggi (corrispondenti a movimenti di magazzino a cui non è imputabile alcun

ricavo) agendo sulla colonna “caumov”.Con lo stesso approccio, agendo sulla colonna “codctf” della tabella “Mitico_magmov” sono state recuperati i records

relativi alle operazioni di vendita e di acquisto dei soci clienti e fornitori (escludendo i soci fornitori conferenti o gli agenti rappresentanti,...) e della tabella “Mitico_tbmaga” sono stati selezionati i records relativi alle agenzie del Consorzio escludendo magazzini di deposito. La semplificazione dell'espressione del filtro, nel caso avessimo trattato le misure aziendali delle vendite separatamente da quelle degli acquisti, avrebbe coinvolto solamente la prima colonna: infatti, per il report “Vendite.imr” avremmo dovuto imporre una semplice relazione di uguaglianza (caurag = 'V'), così come per il report “Acquisti.imr” (caurag = 'A'). In questo

ultimo caso, è opportuno evidenziare che, a fronte di questa parziale semplificazione del filtro, l'elaborazione complessiva dei due files iqd ha richiesto un tempo maggiore rispetto a quello richiesto per l'elaborazione di un unico file; il motivo di un tale incremento di tempo risiede nel fatto che Transformer deve necessariamente effettuare un accesso ulteriore alle tabelle definite nei due filtri e ciò può degradare eccessivamente le prestazioni; infine, la definizione del filtro aumenta la complessità delle relazioni di join tra le tabelle dalle quali sono state selezionate le colonne sorgenti.

Dopo queste considerazioni, riprendiamo con la definizione delle colonne del nostro report relative alle misure, in particolare partendo da quelle associate alle vendite dei prodotti.

● Quantità venduta: in Figura 5.7, si è riportata la porzione della finestra

Impromptu relativa alla definizione dell'espressione impostata per questa misura. La colonna della tabella “Mitico_magmov” che contiene il valore numerico dell'ammontare della quantità venduta di un determinato prodotto è “Qtamov”; di tale valore ne abbiamo estratto il valore assoluto poiché presente nella tabella con segno negativo per indicare una diminuzione delle giacenze di magazzino a seguito di una operazione di vendita. L'espressione condizionale è stata introdotta per allocare la nostra misura esclusivamente in relazioni alle operazioni di vendita; la colonna Quantità venduta del nostro report conterrà quindi valori nulli solo in corrispondenza dei records che si riferiscono alle operazioni di acquisto.

● Importo delle vendite: l'espressione relativa al calcolo dell'importo delle

singole operazioni di vendita è riportata in Figura 5.9: “Valnet” è la colonna della tabella “Mitico_magmov” contenente il valore numerico dell'importo

venduto; questo valore deve essere estratto in maniera coerente alla tipologia di vendita effettuata: nel caso ad esempio vengano generati documenti come note di credito o resi da clienti, è necessario invertire il segno dell'importo relativo (poiché non corrisponde ad un guadagno) mentre in tutti gli altri casi l'importo coincide con il valore positivo “Valnet”. L'elenco delle causali di magazzino (colonna “codcma” della tabella Mitico_magmov”) in corrispondenza delle quali viene effettuata questa inversione è specificato nello statement IF più interno. Anche in questo caso, come nel precedente, l'importo delle vendite deve essere allocato esclusivamente all'operazione di vendita (clausola IF esterna).

Figura 5.9 Espressione di calcolo per la misura Importo delle Vendite

● Valore di costo del venduto: in Figura 5.10 è riportata l'espressione per il

calcolo di questa misura; essa è ottenuta dal prodotto della quantità di prodotto venduto per il costo di riferimento unitario, valore dinamico presente nella colonna “cosrif” della tabella “Mitico_magmov” che fornisce il costo della merce al momento della vendita.

● Importo provvigioni: sempre relativamente alle operazioni di vendita, la

misura in esame è stata ottenuta impostando l'espressione raffigurata in Figura 5.11; la colonna “prvage” contiene le aliquote percentuali provvigionali relative ai singoli prodotti riportati in un documento di vendita

Figura 5.11 Espressione di calcolo per la misura Importo provvigioni

Le considerazioni fatte per il calcolo di questi indici valgono anche per le misure relative agli acquisti. Le uniche differenze riguardano i codici delle causali magazzino in corrispondenza dei quali invertire il segno del valore numerico “Valnet”, e l'assenza di una misura analoga a quella relativa all'importo delle provvigioni (che di fatto hanno senso solo per operazioni di vendita). Tralasciamo quindi questa descrizione per analizzare invece l'insieme delle colonne che precedono quelle relative alle misure. Il contenuto di queste colonne non è propriamente transazionale: la colonna “Annomese” ad esempio contiene un valore numerico ottenuto dalla colonna “datare” della tabella “Mitico_magmov” per la dimensione Periodo, mentre le altre contengono i codici identificativi dei livelli delle dimensioni restanti. In definitiva, si tratta di valori numerici dal carattere strutturale ben diverso dal carattere fortemente dinamico che contraddistingue l'insieme delle misure; nonostante questo, la loro definizione è stata necessaria per fare in modo che Transformer possa allocare correttamente le misure alle categorie dei diversi livelli gerarchici; vedremo tra breve come la presenza di queste colonne,

minimamente ridondante rispetto al contenuto delle colonne strutturali, abbia fornito un contesto completo per una corretta relazione tra i dati sorgenti e la mappa delle dimensioni. Prima di passare alla definizione delle suddette relazioni, riportiamo per completezza, il contenuto del file iqd generato dal report appena esaminato, evidenziando con colori diversi le linee di codice SQL relative alla definizione delle colonne sorgenti (colore blu) e quelle relative al filtro della query (colore rosso). // File Vendite_Acquisti.iqd COGNOS QUERY STRUCTURE,1,1 DATABASE,CAPPISA_su_aix DATASOURCENAME,C:\Cubi\Report_cubi\Vendite_Acquisti.imr TITLE,Vendite_Acquisti BEGIN SQL

select ((od_year(T1."datare"))) * 100 + ((od_month(T1."datare"))) as c1,

T2."codgr1" as c2, T3."codgr2" as c3, T4."codgr3" as c4, T1."codart" as c5, (pack(T5."desc11" || T5."desc12")) as c6, T1."codmag" as c7,

CASE WHEN (T6."caurag" = 'V') THEN ('VENDITA') ELSE ('ACQUISTO') END as c8,

T6."descri" as c9,

CASE WHEN (T1."codtcf" = 'C') THEN (T1."codclf") ELSE null END as c10, CASE WHEN (T1."codtcf" = 'F') THEN (T1."codclf") ELSE null END as c11,

CASE WHEN (T6."caurag" = 'V') THEN ((absolute(T1."qtamov"))) ELSE null END as c12, 'Unità di misura: ' || T1."codums" as c13,

CASE WHEN (T6."caurag" = 'A') THEN ((absolute(T1."qtamov"))) ELSE null END as c14,

CASE WHEN (T6."caurag" = 'V') THEN ((absolute(T1."qtamov")) * T1."cosrif") ELSE null END as c15, CASE WHEN (T6."caurag" = 'V') THEN ((absolute(T1."qtamov")) * T1."prvage" / 100) ELSE null END as c16, CASE WHEN (T6."caurag" = 'V') THEN (CASE WHEN (T1."codcma" IN ('03','04','49','CG','CZ'))

THEN (- T1."valnet") ELSE (T1."valnet") END) ELSE null END as c17, CASE WHEN (T6."caurag" = 'A') THEN (CASE WHEN (T1."codcma" IN ('09','FP','CL','FI'))

from "mitico_magana" T5, "mitico_magmov" T1, "Famiglia" T2, "Gruppo" T3, "Sottogruppo" T4, "mitico_tbcama" T6, "mitico_tbmaga" T7, "mitico_clifor" T8

where (T5."codart" = T1."codart") and (((T2."codgr1" = T5."codgr1") and (T2."codgr2" = ' ')) and (T2."codgr3" = ' ')) and (((T3."codgr1" = T5."codgr1") and (T3."codgr2" = T5."codgr2")) and (T3."codgr3" = ' ')) and (((T4."codgr1" = T5."codgr1") and (T4."codgr2" = T5."codgr2"))

and (T4."codgr3" = T5."codgr3")) and (T6."codcma" = T1."codcma") and (T7."codmag" = T1."codmag") and (T8."codclf" = T1."codclf")

and ((((T6."caurag" IN ('V','A')) and (T1."caumov" <> '1')) and (T1."codtcf" IN ('C','F'))) and (T7."tipmag" = '1'))

END SQL COLUMN,0,Annomese COLUMN,1,Codgr1 COLUMN,2,Codgr2 COLUMN,3,Codgr3 COLUMN,4,Codart COLUMN,5,DescrArticolo COLUMN,6,CodiceMagazzino COLUMN,7,Evento COLUMN,8,DescrCausale COLUMN,9,CodiceCliente COLUMN,10,CodiceFornitore COLUMN,11,Quantita' venduta COLUMN,12,Codums COLUMN,13,Quantità acquistata COLUMN,14,Valore di costo COLUMN,15,Importo provvigioni COLUMN,16,Importo vendite COLUMN,17,Importo acquisti

Anche in questo caso, è interessante notare la conversione di linguaggio dove costrutto IF è stato tradotto in CASE WHEN; infine, è opportuno sottolineare che l'espressione del filtro che compare immediatamente dopo le relazioni di join tra le tabelle del Catalogo (nella clausola WHERE), non aumenta in modo significativo la complessità globale delle relazioni stesse.

5.3 Le associazioni dei Dati Sorgenti con

5.3 Le associazioni dei Dati Sorgenti con

la Mappa delle Dimensioni

la Mappa delle Dimensioni

Per definire correttamente le relazioni tra i nostri dati sorgenti ed i livelli gerarchici delle dimensioni è stato necessario, come abbiamo trattato in precedenza, definire un numero di colonne sufficienti per ognuno dei file IQD generati, evitando allo stesso tempo la definizione di colonne in eccesso il cui contenuto informativo verrebbe ugualmente elaborato da Transformer con inutile perdita di tempo. Vediamo a questo punto, come sono state impostate manualmente le associazioni tra le colonne sorgenti e i diversi livelli gerarchici, partendo dai files IQD strutturali (Figura 5.12).

Figura 5.12 Il set di file IQD strutturali

Clienti.iqd Magazzini.iqd Fornitori.iqd GM_Famiglie.iqd GM_Gruppi.iqd GM_Sottogruppi.iqd

●

● Dimensione Clienti: la Figura 5.13 mostra la finestra delle proprietà del

livello Regione e Provincia le associazioni con le impostate manualmente.

In Figura 5.14, sono raffigurate le finestre analoghe alle precedenti per la selezione delle colonne sorgenti per il livello Nome cliente.

Figura 5.14 Associazione delle colonne sorgenti con il livello Nome cliente

Le categorie dei livelli della dimensione Clienti verranno popolate direttamente dai dati estratti da Transformer durante l'elaborazione della query SQL relativa al file sorgente Clienti.iqd; la visibilità della dimensione (detta scope) è un aspetto importante che può essere monitorato per controllare se nel nostro modello esistono conflitti, cioè scorrette relazioni tra le colonne dei file IQD sorgenti ed i livelli delle dimensioni. In questo caso, la corretta associazione colonne-livelli è segnalata Transformer evidenziando con colore giallo l'intera dimensione in esame.

● Dimensione Fornitori ed Agenzia: in maniera del tutto analoga, sono state

ripetute le stesse associazioni manuali (Figura 5.15 e 5.16).

Figura 5.15 Associazione delle colonne sorgenti con il livello Fornitore

In Figura 5.17, sono riportate le relazioni imposte per il livello Comune e

per il livello Magazzino, livello gerarchico più basso dove confluiscono i 2

livelli superiori, Area e Comune.

In generale, ogni volta che viene definito un Alternate Drill Down Path Transformer richiede necessariamente che le categorie del livello a cui convergono i livelli sovrastanti siano dichiarate uniche. In Figura 5.17 e 5.18, sono raffigurate le dimensioni con Drill Down alternativo per il modello in esame e per il modello “CAPPISA_Classi_fatturato” e le loro corrispondenti visualizzazioni in ambiente Power Play per Windows.

Figura 5.17 Alternate Drill Down Path nel modello “CAPPISA_Power_Cube”

1.

Figura 5.18 Alternate Drill Down Path nel modello “CAPPISA_Classi_fatturato”

Primary Drill Down Path Alternate Drill Down Path Primary Drill Down Path Alternate Drill Down Path

Per il livello Magazzino abbiamo provveduto al settaggio del check box relativo a questa proprietà. All'interno di un modello Transforemer, l'unicità di un livello significa che tale livello contiene solo una istanza per ciascuna categoria sorgente; in altri termini, non possono esistere due categorie con lo stesso nome che rappresentano due entità distinte nell'abito di uno stesso livello.

La caratteristica dell'unicità è quindi legata alla natura dei dati sorgenti ed è opportuno “comunicarla” al programma, anche se il progettista potrebbe tralasciare questo aspetto rischiando che un errore simile venga rilevato da Transformer compromettendo la qualità dei dati all'interno del cubo. In generale infatti, affinché Transformer possa generare accuratamente le categorie che verrano visualizzate da Power Play, deve essere in grado di identificare ciascuna categoria di un livello unicamente attraverso il suo valore nella colonna sorgente, senza riferimento alle categorie dei livelli parentali.

Se un livello convergente contiene occorrenze multiple di una stessa categoria, Transformer non può determinare univocamente quale percorso intraprendere (Drill Down Path) nel processo di generazione delle categorie. Inoltre, se tutte le le categorie di un livello vengono dichiarate uniche quando in realtà non lo sono, possono insorgere risultati non validi quando Transformer tenta di associare valori ambigui alle categorie in un livello convergente; Transformer infatti associa il valore alla prima delle categorie a cui è associato nel livello.

●

● Dimensione Gruppi Merceologici: in Figura 5.19 e 5.20 sono riportate le

relazioni stabilite tra i livelli della dimensione Gruppi Merceologici e le colonne sorgenti del file iqd relativo evidenziandone lo scope .

Figura 5.20 Associazione delle colonne sorgenti con il livello Sottogruppo

Le categorie dell'ultimo livello Articolo (che è stato definito unico per quanto discusso in precedenza) verranno alimentate con le colonne sorgenti definite nel file IQD transazionale “Vendite_Acquisti.iqd”. In Figura 5.21, è raffigurato lo scope ricoperto dal nostro file transazionale sull'intera mappa delle dimensioni e le relazioni tra i livelli e le colonne sorgenti.

Figura 5.21 Relazione tra colonne sorgenti del file Vendite_Acquisti.iqd e la Mappa

delle Dimensioni Colonne

sorgenti per le Misure

La mappa colorata evidenzia in toni di giallo più leggeri la presenza di livelli non direttamente raggiungibili dalla sorgente “Vendite_Acauisti.iqd”: per i livelli Area e Comune della dimensione Agenzia così come per i livelli Regione e Provincia della dimensione Clienti, non sono state definite ulteriori colonne sorgenti poiché già presenti nelle rispettive fonti dati analizzate in precedenza (la loro presenza sarebbe risultata ridondante), ma unicamente le colonne relative ai livelli infimi della gerarchia che sono stati dichiarati opportunamente unici.

5.4 L'allocazione delle Misure

5.4 L'allocazione delle Misure

In questo paragrafo, prendiamo in esame la definizione delle relazioni tra le colonne sorgenti del file transazionale e le misure definite manualmente (Figura 5.2) partendo da quelle regolari, per poi procedere con le misure calcolate.

In Figura 5.22, è riportata la finestra delle proprietà generali della misura Importo netto vendite; è stato definito il nome della misura che Power Play visualizzerà (Measure label) , un nome alternativo che abbiamo scelto coincidente con quello della misura stessa ma per il quale in realtà avremmo potuto utilizzare un'abbreviazione o qualunque altro codice alfanumerico (Short name), e due proprietà relative al valore numerico trattato. In particolare, il range di rappresentazione del valore numerico (Storage type), che verrà utilizzato da Transformer per memorizzare il valore all'interno del work file ma che non ha alcun effetto sul tipo di compressione del valore della misura all'interno del cubo, e l'Output scale, nella pratica un valore numerico intero che rappresenta una particolare potenza di 10 per esprimere la misura con un numero di cifre decimali o significative che meglio rappresentano l'indicatore aziendale visualizzato a run time da Power Play. La Figura 5.23 mostra la colonna sorgente da cui saranno estratti i valori per la nostra misura.

L'ultima proprietà che ci sembra degna di nota è quella relativa al tipo di funzione di Rollup che può essere specificata per una determinata misura. Questa particolare funzione specifica la modalità attraverso la quale Transformer e Power Play gestiscono i valori numerici delle misure nel passaggio dalle categorie dei livelli più bassi a quelli superiori. Il comportamento di default di Transformer è quello di sommare i valori numerici delle misure di tutte le categorie discendenti della categoria corrente; Tranformer applica tale funzione nel processo di creazione del Power Cube, mentre Power Play la esegue a run time. Nel nostro lavoro, si è scelto di mantenere il comportamento di default (Regular Rollup Sum) come mostrato in Figura 5.24; le altre tipologie di rollup non sono state approfondite in quanto non sono state impiegate per i nostri scopi di analisi OLAP.

Per le misure regolari rimanenti sono state impiegate le medesime scelte e quindi non ci dilungheremo su queste ulteriormente; prendiamo in esame invece, il calcolo delle misure derivate Utile (Figura 5.25) e Marginalità percentuale (Figura 5.26). L'utile è stato calcolato come differenza tra l'importo delle vendite ed il valore d'acquisto della merce venduta; l'operazione aritmetica di sottrazione coinvolge 2 misure regolari.

La misura Marginalità percentuale è stata definita come il rapporto tra l'utile e l'importo delle vendite; si tratta di una misura espressa da un valore percentuale, quindi è stato definito opportunamente il suo formato e ne è stata data una succinta descrizione nel box Description. Tale descrizione potrà essere sempre visualizzata in Power Play e fornisce all'utente informazioni aggiuntive sempre utili.

Figura 5.26 Definizione dell'espressione di calcolo per la misura Marginalità percentuale

5.5 Considerazioni finali sul

5.5 Considerazioni finali sul

Modello Transformer “CAPPISA_Power_Cube”

Modello Transformer “CAPPISA_Power_Cube”

In questo paragrafo riportiamo alcune considerazioni sul modello Transformer che abbiamo descritto. Per quanto riguarda la scelta di implementare sorgenti dati distinte per il nostro modello, avevamo discusso le difficoltà riscontrate nella creazione di una sorgente singola, descrivendo qualitativamente la natura del report Impromptu globale (Totale_Vendite_Acquisti.imr). Il calcolo del numero di bytes complessivo che avevamo lasciato in sospeso è riportato in Tabella 5.1.

Tabella 5.1 Calcolo del numero di bytes complessivo nei due casi esaminati Multiple

Data Source e Single Data Source

Data Souces- IQD files Bytes/records Numero recors

Totale Bytes per IQD file Clienti.iqd 104 21346 2219984 Fornitori.iqd 302 10460 3158920 Magazzini.iqd 138 40 5520 GM_Famiglie.iqd 37 16 592 GM_Gruppi.iqd 47 192 9024 GM_Sottogruppi.iqd 52 239 12428 Vendite_Acquisti.iqd 662 218113 144390806

Totale bytes Multiple Data Sources 149797274

Totale_Vendite_Acquisti.iqd 1175 218113 256282775

Numero di bytes salvati nell'elaborazione Transformer _{106485501~ 104MB}

I dati sono stati estratti dalle proprietà delle singole colonne che costituiscono i rispettivi report prima del salvataggio degli stessi nel formato .IQD. La differenza significativa tra le due soluzioni ci ha fatto proseguire, come avevamo preannunciato, nella nostra progettazione di molteplici fonti dati nella metodologia

che abbiamo discusso, nella quale si è cercato di mantenere costantemente vivo l'obbiettivo di migliorare la performance del processo di creazione del cubo che riesamineremo, insieme ad altri aspetti, a partire dal prossimo capitolo.

In ultima analisi, essendo giunti al termine della modellizzazione OLAP del nostro Power Cube, discutere delle tipologie di formato nelle quali può essere salvato ed esportato il modello Transformer. Esistono essenzialmente due tipi di formato:

➢ Formato .MDL: si tratta di un formato ASCII che consente di visualizzare il

contenuto del modello multidimensionale in formato testo, quindi dalle dimensioni contenute (Figura 5.27).

Figura 5.27 File ASCII CAPPISA_Power_Cube.mdl

Compatibile tra le diverse versioni di Transformer, è utilizzato anche per importare od esportare un modello (backup) poiché caratterizzato da un elevato grado di tolleranza alle modiche apportate al modello che lo rendono

raramente corrompibile. A differenza dell'altro tipo di formato che discuteremo, il tempo impiegato per l'apertura del file è dell'ordine di alcuni secondi (in base alla dimensione del modello) ma in generale meno rapido dell'altro formato a causa del processo di compilazione attuato da Tranformer. Infine, è possibile modificare direttamente il contenuto del file di testo per particolari scopi come ad esempio automatizzare il processo di creazione del cubo, o apportare cambiamenti strutturali al modello senza ricorrere all'interfaccia dell'ambiente Transformer. Queste operazioni richiedono la conoscenza dei costrutti del linguaggio MDL che non sono stati affrontati in questo lavoro di tesi.

➢ Formato .PY?: si tratta di un formato binario, nativo nella release 7.0 di

Transformer. Non risulta compatibile tra le versioni del programma ma, trattandosi di un formato già compilato, i tempi di caricamento dello stesso sono molto rapidi. L'ultimo carattere ('?') relativo all'estensione del può cambiare in base alla versione di Transformer. A differenza del precedente formato, le dimensioni di questo file possono raggiungere dimensioni significative in seguito a ripetute modifiche apportate al modello, che possono causare un elevato livello di frammentazione del file con conseguente facilità di corruzione. Per questo motivo, chiaramente legato alla natura binaria del file, ai fini del nostro lavoro, tale formato non è stato utilizzato, se non per lo studio delle funzionalità di Transformer. Per completezza infine, ci sembra opportuno sottolineare che i file work che genera Transformer nel processo di creazione del cubo sono anch'essi in formato binario; sono file temporanei che contengono checkpoint entries, cioè indirizzi che referenziano i principali step dell'algoritmo di creazione. Pochè, come avevamo detto parlando delle fasi principali del processo,

Transformer elimina questi file al termine della successione di passi, l'esistenza di uno di questi checkpoint file nel sistema (ad esempio nella directory adibita al salvataggio di file temporanei) dimostra al progettista la terminazione anomala del programma in sessioni precedenti. Tranformer permette di recuperare un modello di una delle sessioni non correttamente terminate (recovering model) all'atto della creazione di nuovo modello, mostrando l'elenco dei file temporanei suddetti (estenzione.QY?).

Il modello Transformer “CAPPISA_Power_Cube” che abbiamo trattato è riportato in Figura 5.28 nella sua versione completa; a partire dal prossimo capitolo, prenderemo in esame i principali aspetti del processo di creazione del cubo.

Figura 5.28 Il Modello Tranformer “CAPPISA_Power_Cube”

Data source Viewer