Piccin Elisa

UNIVERSITÀ DEGLI STUDI DI TRIESTE

Facoltà di IngegneriaCorso di laurea in Ingegneria Elettronica curriculum Gestionale

PROVA FINALE IN

BASI DI DATI

SVILUPPO DI UN’APPLICAZIONE OLAPPER L’ANALISI DI GUASTI DI ELETTRODOMESTICI

Relatore: Laureanda:Chiar.mo Prof. Fermeglia Maurizio Piccin Elisa

Anno Accademico 2007-2008

Alla mia famiglia

INDICE

Introduzione...........................................................................................1

1. Il processo aziendale di analisi dei rientri dall’utenza: raccolta dei

dati..........................................................................................................3

1.1 Il contesto operativo..............................................................................3

1.1.1 L’azienda.............................................................................................3

1.1.2 Il processo di analisi tecnica in laboratorio dei rientri dall’utenza....4

1.2 Elaborazione di un modello relazionale per la raccolta dei dati............6

1.2.1 Scopo dell’analisi................................................................................6

1.2.2 Requisiti espressi in linguaggio naturale............................................6

1.2.3 Esame delle entità...............................................................................8

1.2.4 Relazioni............................................................................................10

1.2.5 Schema concettuale..........................................................................10

1.2.6 Motivazione dell’utilizzo di livelli gerarchici....................................11

1.2.7 Business rules...................................................................................11

1.2.8 Ristrutturazione dello schema concettuale......................................12

1.2.9 Schema fisico....................................................................................13

1.3 Interfaccia per l’inserimento dei dati..................................................14

1.3.1 Manuale dell’applicazione................................................................16

1.4 Necessità di uno strumento per l’analisi dei dati................................17

2. Architetture per l’analisi dei dati...................................................18

2.1 Dai dati alla conoscenza: Business Intelligence..................................18

2.1.1 Struttura di un sistema di BI............................................................19

2.1.2 Strumenti di Business Intelligence...................................................22

2.2 OLTP e OLAP........................................................................................23

2.3 Data Warehouse...................................................................................25

2.3.1 Definizione di Data Warehouse.........................................................25

2.3.2 Architettura di un Data Warehouse..................................................26

2.4 Rappresentazione multidimensionale dei dati.....................................29

2.4.1 Il modello multidimensionale............................................................29

2.4.2 Operazioni nel modello multidimensionale.......................................31

2.5 Realizzazione di un data warehouse....................................................33

2.5.1 Rappresentazione relazionale di un Data Warehouse......................35

2.6 Passaggio da un DB relazionale ad uno dimensionale (Data

Warehouse)....................................................................................................38

3. Data Warehouse per l’analisi dei guasti.........................................41

3.1 Scopo del progetto...............................................................................41

3.2 Microsoft SQL Server 2005..................................................................41

3.3 Importazione della base di dati............................................................44

3.4 SQL Server Analysis Services 2005.....................................................49

3.4.1 Architettura di Analysis Services......................................................49

3.4.2 Modello UDM (Unified Dimensional Model).....................................50

3.5 Progettazione del modello multidimensionale per il Data Warehouse 51

3.5.1 Fatti nel modello multidimensionale.................................................51

3.5.2 Misure nel modello multidimensionale.............................................52

3.5.3 Dimensioni nel modello multidimensionale......................................52

3.6 Ristrutturazione dello schema relazionale...........................................54

3.6.1 Dimensioni temporali........................................................................54

3.6.2 Ristrutturazione della dimensione Localizzazione Difetto................56

3.6.3 Ristrutturazione della dimensione Tipo Difetto................................58

3.6.4 Rappresentazione relazionale del Data Warehouse.........................60

3.7 Sviluppo del progetto con SSAS 2005.................................................62

3.7.1 Creazione del progetto......................................................................62

3.7.2 Origine dei dati.................................................................................63

3.7.3 Vista origine dati...............................................................................64

3.7.4 Creazione del cubo............................................................................66

3.7.5 Design del cubo.................................................................................68

3.7.6 Impostazioni per il processamento del cubo.....................................71

3.7.7 Processamento del cubo...................................................................72

3.7.8 Raffinamento della struttura multidimensionale..............................74

3.7.9 Browsing...........................................................................................80

4. Elaborazione e rappresentazione dei dati relativi alla difettosità

analizzata..............................................................................................83

4.1 Microsoft Excel 2003 come client OLAP..............................................83

4.1.1 Componenti necessari per accedere alle origini dati OLAP.............84

4.1.2 Microsoft Office Excel Add-in for SQL Server Analysis Services.....85

4.1.3 Accesso al database..........................................................................86

4.2 Elaborazione dei dati...........................................................................88

4.2.1 Diagrammi di Pareto.........................................................................88

4.2.2 Analisi di una serie temporale..........................................................90

4.2.3 Altri tipi di grafico.............................................................................94

4.3 Utilizzo delle connessioni per la creazione di report...........................99

4.4 Aggiornamento dei report..................................................................102

4.4.1 Cubi off-line.....................................................................................103

Conclusioni.........................................................................................105

Bibliografia.........................................................................................107

Siti web e documentazione on-line.....................................................108

NOTA BENE: tutti i dati riportati relativamente alla difettosità del prodotto

hanno fini puramente esemplificativi.

Introduzione

Introduzione

In questo lavoro di tesi si tratterà della struttura Data Warehouse e della modellazione concettuale multidimensionale alla base della realizzazione di un’applicazione di tipo OLAP, orientata all’analisi di dati riguardanti la difettosità riscontrata su sottoassiemi di prodotti elettrodomestici.

Il progetto nasce dalla constatazione dell’esigenza di un supporto informativo al processo aziendale di analisi tecnica dei componenti difettosi rientrati dall’utenza; tale processo viene effettuato da Electrolux Home Products S.p.A. presso il proprio stabilimento produttivo a Porcia-PN (e, in generale, presso altri stabilimenti produttivi europei) e consente una percezione della qualità del prodotto che non sarebbe possibile ottenere solo attraverso l’utilizzo di dati interni. Una gestione efficace dei dati originati da tale processo si tramuta per l’organizzazione, e in particolare per la funzione Qualità, nella capacità di individuare criticità e direzioni oggettive di miglioramento.

L’obiettivo della tesi è quello di approfondire l’approccio metodologico per la realizzazione di un Data Warehouse e, in particolare, di applicare le tecniche della modellazione multidimensionale all’insieme dei dati di interesse per l’applicazione; i risultati ottenuti saranno proposti, infine, attraverso alcune elaborazioni e rappresentazioni dei dati tipicamente richieste, allo scopo di valutare le potenzialità dello strumento realizzato.

Per poter realizzare il Data Warehouse sono stati affrontati diversi punti nel corso dello svolgimento del lavoro; essi si possono ritrovare nella struttura della tesi e possono essere così sintetizzati:

analisi della realtà di riferimento e raccolta dei requisiti; studio delle architetture per l’analisi dei dati; analisi della tecnologia utilizzata per il progetto (in base ai vincoli

di progetto); progettazione e successiva implementazione del Data Warehouse; test del Data Warehouse; utilizzo di un’applicazione client per l’interrogazione dei dati.

Il progetto svolto in questa tesi si inquadra nell’ambito di un insieme di tecnologie e metodologie sempre più accurate, indicate con il termine Business Intelligence, aventi l’obiettivo di supportare un’organizzazione nel trarre vantaggio competitivo dallo sfruttamento del proprio patrimonio informativo. Attualmente la Business Intelligence è diventata una priorità strategica per molte organizzazioni, in quanto un ritmo di produzione delle informazioni di fatto costantemente in crescita richiede metodi per una loro gestione efficiente ed efficace, oltre a strumenti per il miglioramento delle performance e per il supporto alle decisioni.Nella realtà un sistema di Business Intelligence si configura come una soluzione integrata composta da più moduli (si parla infatti di “piattaforma Business Intelligence”) e diversi tool si trovano integrati e differentemente combinati nei pacchetti Business Intelligence disponibili sul mercato. Per la realizzazione del progetto trattato in questa tesi la scelta dei tool e degli applicativi è stata determinata dai vincoli di progetto.

1

Introduzione

Vincoli del progetto sono stati la sorgente dei dati disponibile, i sistemi operativi lato server e lato client, la scelta dei tools e degli applicativi della piattaforma Microsoft. Come soluzione Business Intelligence, in particolare, è stata utilizzata la piattaforma Microsoft SQL Server 2005 (Standard Edition), che dispone di uno strumento di sviluppo, quale Business Intelligence Development Studio, per progetti Analysis Services.

La tesi è organizzata secondo quattro capitoli, che ripercorrono l’iter di svolgimento del lavoro. Segue una sintesi dei contenuti di ogni capitolo.

Capitolo 1: Il processo aziendale di analisi dei rientri dall’utenzaLa tesi si apre con una contestualizzazione della realtà di riferimento e una schematizzazione del processo aziendale che origina i dati oggetto dell’analisi. Questi passaggi sono infatti preliminari alla comprensione del modello relazionale utilizzato per la raccolta dei dati; quest’ultimo modello non è oggetto di questa tesi (è infatti un input del progetto), tuttavia da esso non si può prescindere, in quanto costituisce la base a partire dalla quale realizzare, attraverso opportune ristrutturazioni, il modello dei dati per il Data Warehouse.

Capitolo 2: Architetture per l’analisi dei datiIl capitolo presenta i concetti alla base delle moderne architetture per l’analisi dei dati. Vengono trattate inizialmente la definizione e la struttura di un sistema di Business Intelligence con riferimento allo sviluppo attuale; si procede poi differenziando le applicazioni OLAP da quelle OLTP sulla base delle loro caratteristiche principali. La parte centrale del capitolo sviluppa due aspetti: a) la definizione e l’architettura di un Data Warehouse; b) la rappresentazione multidimensionale dei dati e la sua implementazione relazionale.

Capitolo 3: Data Warehouse per l’analisi dei guastiVengono trattate le varie fasi di realizzazione del Data Warehouse, descrivendo le caratteristiche degli strumenti utilizzati e indicando come i concetti teorici esposti trovino applicazione nel software di sviluppo. Vengono quindi trattate la progettazione e l’implementazione del modello multidimensionale rispetto alla sorgente dei dati considerata, le impostazioni utilizzate per il processamento del Data Cube e le operazioni di raffinamento che hanno condotto ad una struttura dei dati orientata all’analisi.

Capitolo 4: Elaborazione e rappresentazione dei dati relativi alla difettosità analizzata

L’ultimo capitolo è dedicato alla presentazione di alcune analisi e risultati ottenuti dalla struttura dati progettata nel capitolo precedente. Viene posto in evidenza l’utilizzo concreto del sistema da parte

2

Introduzione

dell’utenza, con particolare attenzione alle diverse possibilità di collegamento ai dati presenti nel Data Warehouse.

3

Il processo aziendale di analisi dei rientri dall’utenza

1. Il processo aziendale di analisi dei rientri dall’utenza: raccolta dei dati

1.1 Il contesto operativo

1.1.1 L’aziendaLe origini dell’attuale stabilimento Electrolux di Porcia (Pordenone) risalgono al 1954 e sono legate all’imprenditore pordenonese Antonio Zanussi, che vi avviò la produzione di cucine a gas, elettriche e miste, seguendo negli anni una strategia di progressiva diversificazione del portafoglio prodotti.Nel 1984 la società Zanussi è stata acquisita dal gruppo multinazionale svedese Electrolux AB e, a seguito di modifiche strategico - organizzative, oggi lo stabilimento di Porcia fa parte dell’unità Electrolux Major Appliances Europe di Electrolux AB ed è inserito all’interno della divisione Industrial Operation Laundry. Attualmente esso copre un’area di circa 673.000 m2, di cui 138.000 appartenenti all’area di produzione, con un organico complessivo costituito da circa 2.200 persone.La gamma di produzione dello stabilimento attualmente consiste in:

lavabiancheria a carica frontale (Front Loader WM) lavasciuga biancheria a carica frontale (Front Loader WD)

Il volume produttivo stimabile è di oltre 2.000.000 di apparecchi/anno, di cui oltre l’80% destinato all’esportazione. I principali mercati (che nel totale compongono oltre il 75% delle apparecchiature prodotte) sono: Germania, Gran Bretagna, Russia, Italia, Francia, Paesi Scandinavi, Olanda e Spagna.

4

Figura 1.1 Organigramma

Capitolo 1

1.1.2 Il processo di analisi tecnica in laboratorio dei rientri dall’utenzaL’attività di analisi tecnica di componenti difettosi rientrati dall’utenza viene effettuata dall’unità Quality/Supplier Quality Assurance in collaborazione con la progettazione centrale (Fabric Care Product Development) per le linee di prodotto lavabiancheria a carica frontale e lavasciuga biancheria a carica frontale.

A partire dal 2008 è stato deciso di estendere il processo a tutti i plants afferenti all’Industrial Operation Laundry, con la necessità quindi di standardizzarne i metodi di test in laboratorio e di raccolta dei dati per permettere un’analisi efficace e coerente sia a livello centrale che a livelli più disaggregati.

Secondo un approccio per macro-aree, si può pervenire allo schema seguente. L’attività di immissione dei prodotti sul mercato non è cioè un flusso “a senso unico”, ma esiste una retroazione il cui valore aggiunto è essenziale nell’ottica del miglioramento continuo della qualità.

L’analisi dei rientri è focalizzata su componenti o assiemi rientrati dall’utenza a seguito di una sostituzione, effettuata dall’assistenza tecnica sul prodotto finito di uno specifico stabilimento (e.g. Porcia).

Da un punto di vista tecnico, scopo di questo processo è l’analisi approfondita del componente o dell’assieme , per identificare la/e causa/e del guasto e definire azioni correttive adeguate. Poiché non sarebbe pensabile analizzare al 100% l’attività di ricambio effettuata dall’assistenza tecnica presso il cliente, viene fatta rientrare solo una percentuale di tali volumi, prelevandola da vari centri di raccolta situati nei principali mercati secondo criteri opportunamente stabiliti dalla funzione Qualità.

L’attività di analisi dei componenti difettosi rientrati dal mercato permette di verificare, insieme alle informazioni rilevate dai laboratori interni, l’affidabilità dei componenti elettrici, elettronici, elettro-meccanici ed estetici e l’efficacia delle azioni correttive intraprese dai fornitori e/o delle modifiche introdotte a livello progettuale o di processo produttivo. Ciò consente una percezione della qualità che non sarebbe possibile avere utilizzando solo dati interni e, inoltre,

Figura 1.1 Flusso di analisi

5


ha contenuti tecnici molto importanti per i processi sia del fornitore che dell’azienda stessa coinvolti nella produzione e nella progettazione.

A supporto dei contenuti tecnico-operativi del processo di analisi tecnica dei componenti rientrati dall’utenza (procedure di test e di ricerca del guasto specifiche per componente), risultano fondamentali le fasi di raccolta e analisi dei dati. Quest’ultima in particolare deve consentire di realizzare il vero valore aggiunto insito nel processo, cioè ricavare informazione dai dati. Ciò si tramuta per l’azienda, e in particolare per la Qualità, nella capacità di individuare situazioni critiche e direzioni oggettive di miglioramento attraverso una gestione efficace dei dati. E’ in questo contesto che si inquadra il lavoro svolto.

Si riporta di seguito un diagramma di flusso sintetico del processo.

6

Capitolo 1

Figura 1.2 Diagramma di flusso del processo di analisi dei rientri utenza

7


1.2 Elaborazione di un modello relazionale per la raccolta dei dati

1.2.1 Scopo dell’analisiLa fase precedente alla realizzazione di uno strumento per l’analisi dei dati si è concentrata prevalentemente nel fornire agli utenti uno strumento di input adatto a registrare i risultati dell’analisi di laboratorio dei componenti rientrati dall’utenza. Per fare ciò, in questa fase preliminare si è proceduto a:

individuare i dati raccolti dal laboratorio e da inserire nel database

individuare le relazioni esistenti tra tali dati

individuare una codifica opportuna per i dati da inserire nel database

determinare le operazioni sui dati da eseguire nel database (es. aggiornamento dizionari, spedizioni)

elaborare un manuale di utilizzo del database rivolto agli utenti

In questo elaborato tuttavia non si discuteranno formalmente tutti i passaggi relativi all’analisi e all’implementazione del sistema di raccolta dei dati, poiché ciò esime dagli scopi proposti (in sintesi realizzare uno strumento per l’analisi dei dati) e costituisce una fase già stata in parte avviata all’inizio del progetto.

1.2.2 Requisiti espressi in linguaggio naturale I requisiti per quanto riguarda il sistema di input dei dati sono stati raccolti attraverso interviste, osservazione del processo di analisi tecnica in laboratorio e consultazione dei dati già esistenti sotto varie forme (cartaceo, moduli di laboratorio, documenti Excel, altri database).

E’ quindi emersa la volontà di realizzare un database in MS Access per la catalogazione dei risultati dell’analisi di laboratorio dei componenti rientrati dall’utenza; esso deve risultare strutturato in modo da standardizzare i criteri di raccolta delle informazioni nei vari stabilimenti europei afferenti a Industrial Operation Laundry e da permettere successive analisi flessibili sui dati raccolti.

Tutti i dati relativi ad un componente analizzato dal laboratorio devono essere inseriti in una scheda, che riporti il tipo di componente analizzato e il tipo di difetto riscontrato dal laboratorio. Ad ogni scheda devono essere associati la data di inserimento, lo stabilimento dove è stata effettuata l’analisi e il nome dell’utente che ha inserito i dati. Deve essere possibile consultare o aggiornare schede precedentemente create (anche da altri utenti) e ricercare agevolmente le schede presenti che soddisfino determinati criteri di selezione.

Ogni componente analizzato deve essere univocamente determinato e devono essere rintracciabili eventuali altri componenti ad esso allegati (sostituzioni multiple). Bisogna inoltre riconoscere se il componente apparteneva originariamente al prodotto finito uscito dalla fabbrica o se si tratta di un ricambio.

Per ogni componente inserito deve essere indicato il mercato di provenienza, la data di acquisto, la data di chiamata dell’assistenza tecnica, il Product Number Code, il modello e il numero seriale del prodotto finito corrispondente. Questi dati sono riportati in un modulo, detto “claim”,

8

Capitolo 1

associato al componente dall’assistenza tecnica, in cui sono riportati anche la descrizione del difetto lamentato dall’utente e la codifica del difetto riscontrato dal tecnico al momento della sostituzione: anche queste informazioni, qualora disponibili, devono essere registrate nel database. Bisogna tenere presente che la claim potrebbe essere stata completata parzialmente o non correttamente.

Poiché i componenti analizzati in laboratorio sono sottoassiemi di fornitura esterna, è importante mantenere per ognuno di essi il riferimento al fornitore corrispondente attraverso nome del fornitore, stabilimento e data di fabbricazione del componente e codice del componente nella distinta base Electrolux (questi dati sono riportati in un’etichetta stampata apposta dal fornitore al sottoassieme).

Il risultato dell’analisi di laboratorio relativamente ad un componente rientrato dall’utenza può ricadere in due distinte situazioni, entrambe di interesse per il database:

a) determinazioni di un difetto (es. saldatura difettosa) o di un guasto (es. pista esplosa per corto circuito interno)

b) “ no fault found ” (non riscontrato difetto), ovvero il componente, sottoposto ai test diagnostici previsti e al collaudo in macchina, non si discosta dal funzionamento a specifica e non compromette la funzionalità della macchina

Poiché l’analisi di laboratorio di un componente può richiedere l’intervento di più unità interne allo stabilimento, può essere utile (ad es. per motivi di tracciabilità interna) registrare nel database un componente che non ricade in nessuna delle due situazioni precedenti, ma che è ancora in fase di analisi/collaudo.

Il difetto riscontrato per ogni componente analizzato va inoltre di volta in volta classificato secondo le seguenti 4 macro-aree: Application, Components, Design, Process. Il caso di difetto non riscontrato va invece classificato in un’area a sé stante.

La scheda relativa ad ogni componente deve contenere informazioni sulla localizzazione del difetto sia a livello generale che a livello più dettagliato. Ad es. nel caso di una resistenza interrotta nella scheda elettronica, il problema riguarda a un livello più alto la basetta elettronica principale e ad un livello più basso la particolare resistenza, identificata univocamente nello schema elettrico del circuito con una sigla (es. R96).

Devono inoltre essere predisposti in ogni scheda appositi campi per la registrazione dell’ultimo codice di errore memorizzato e del numero di cicli e di ore di lavoro effettuati al momento della sostituzione, la cui rilevazione verrà effettuata con un tool di lettura automatica della memoria della scheda elettronica.

In vista di una futura integrazione con il sistema informatizzato di gestione delle azioni correttive, è necessario considerare la possibilità di poter collegare un difetto riscontrato su un componente a una specifica azione correttiva. E’ stata infine manifestata l’esigenza di poter tracciare direttamente tramite il database quantità, data, tipo e codice identificativo dei pezzi difettosi che vengono spediti al fornitore e ricezione del feedback da parte dello stesso.

9


1.2.3 Esame delle entitàLe entità rappresentano classi di oggetti che hanno proprietà comuni ed esistenza autonoma ai fini dell’applicazione di interesse. Attraverso l’analisi dei requisiti sono state individuate le seguenti entità, con particolare attenzione ai processi che generano i dati.

Di seguito viene descritta più approfonditamente, anche se sempre a livello concettuale, l’entità che modellizza l’output del processo di analisi in laboratorio dei sottoassiemi rientrati, in quanto è di interesse centrale per gli scopi proposti e su di essa si concentreranno principalmente le elaborazioni successive.

Nell’esame delle entità e dello schema concettuale sono state incluse anche entità trattate solo marginalmente dall’applicazione in analisi (come Fornitori, Azioni Correttive e Dati Assistenza Tecnica) al fine di chiarirne il legame con i dati trattati e di fornire una documentazione di supporto per future integrazioni di basi di dati (e sorgenti di dati in generale).

SOTTOASSIEME RIENTRATO

Coincide fisicamente con il sottoassieme rientrato dall’utenza per essere analizzato in laboratorio; riporta informazioni quali fornitore, stabilimento di produzione, matricola e codice nella distinta base Electrolux. Si può inoltre distinguere se si tratta di un pezzo originale (cioè originariamente appartenente al prodotto finito) o di un ricambio.

RISULTATO ANALISI DI LABORATORIO

Rappresenta l’output del processo di analisi tecnica in laboratorio dei sottoassiemi rientrati dall’utenza. Le informazioni ottenute tramite tale processo vengono sintetizzate nel database attraverso due coordinate fondamentali: il tipo di problema riscontrato e la localizzazione di tale problema nel sottoassieme. Bisognerebbe più propriamente parlare di difetto o di guasto o di errore, tuttavia in questo contesto non è necessario distinguerli: si userà perciò genericamente il termine “difetto”.

LOCALIZZAZIONE DEL DIFETTO: attraverso questo attributo si vuole rappresentare l’origine del problema riscontrato nel sottoassieme analizzato, localizzandolo attraverso una gerarchia di livelli consona alla metodologia di analisi tecnica seguita e rivolta all’attuazione di azioni correttive. Si tratta quindi di un attributo composto, le cui voci sono di seguito riportate.

FAMIGLIA

E’ il livello più alto (meno dettagliato) con cui è possibile identificare l’oggetto dell’analisi di laboratorio e deve essere sempre specificato, a prescindere dalla determinazione della causa del problema di funzionamento.

COMPONENTE E’ il livello gerarchico successivo alla Famiglia in ordine di dettaglio crescente. La determinazione del componente difettoso, guasto oppure funzionante diversamente da quanto previsto a specifica è il

10

Capitolo 1

risultato dei test diagnostici eseguiti in laboratorio. E’ possibile che non venga riscontrato alcun problema di funzionamento (situazione di “ no fault found ”).

DETTAGLIO COMPONENTE

E’ il livello gerarchico successivo al Componente in ordine di dettaglio crescente. Non è detto che sia sempre significativo o definibile un tale livello di dettaglio; viene specificato quando il livello superiore non è sufficiente a localizzare in modo adeguato la causa del problema: può essere utile, ad esempio, riportare la denominazione a disegno di un determinato componente (soprattutto per schemi elettronici).

TIPO DI DIFETTO: anche in questo caso si tratta di un attributo composto, essendo possibili due livelli di dettaglio

DIFETTOIndica il problema di funzionamento riscontrato. E’ possibile che non venga riscontrato alcun problema di funzionamento (situazione di “ no fault found ”).

CAUSA DEL DIFETTO

Questo ulteriore livello del problema riscontrato va specificato qualora sia stato possibile e necessario risalire alla particolare causa che ha portato al malfunzionamento (ad esempio un corto circuito esterno può compromette componenti della scheda elettronica principale).

FORNITORE

Azienda i cui prodotti finali fungono da input del processo di fabbricazione Electrolux. In questo contesto non sono rilevanti i dettagli del rapporto di fornitura o altri elementi utili alla valutazione del fornitore, gestita attraverso altri sistemi. Il riferimento al fornitore deve essere mantenuto attraverso nome del fornitore, stabilimento e data di fabbricazione del sottoassieme fornito e codice del sottoassieme nella distinta base Electrolux.

MERCATO

Mercato di vendita del prodotto finito a cui apparteneva il sottoassieme analizzato. Ai fini dell’applicazione i mercati sono aggregati a livello nazionale.

DATI ASSISTENZA TECNICA

Al sottoassieme da analizzare è allegato un modulo cartaceo contenente alcune informazioni rilevate dall’Assistenza Tecnica al momento della sostituzione, per quanto riguarda il prodotto finito, il problema manifestatosi e la diagnosi effettuata (con relativa/e sostituzione/i). In particolare quest’ultima viene espressa attraverso una combinazione di codici convenzionali validi a livello internazionale per il Service; tale aspetto non viene in questa sede approfondito, in quanto trattato in maniera esaustiva

11


attraverso altri sistemi informativi aziendali. Bisogna comunque tenere presente che il modulo allegato, detto “claim”, potrebbe riportare dati errati (ad es. data intervento < data acquisto) oppure essere incompleto o mancante.

AZIONE CORRETTIVA

Azione volta a garantire che il fornitore sia in grado di individuare ed eliminare la causa del difetto nel proprio processo produttivo.

12

Capitolo 1

1.2.4 Relazioni

Entità 1 Entità 2 RelazioneCard.

Sottoassieme rientrato

FornitoreFornitura del sottoassieme rientrato

1-N


FornitoreSpedizione al fornitore di un insieme di sottoassiemi già analizzati in laboratorio.

0-N


MercatoMercato di provenienza del prodotto finito di appartenenza del sottoassieme.

1-N


Risultato analisi laboratorio

Esito dei test diagnostici e dei collaudi.

1-N

Azione correttiva

Risultato analisi laboratorio

Azione correttiva intrapresa per risolvere un problema manifestatosi.

N-N

Azione correttiva

FornitoreResponsabilità dell’attuazione dell’azione correttiva.

1-N


Dati assistenza tecnica

Causa del rientro è la sostituzione effettuata dall’Assistenza Tecnica su un prodotto finito in seguito al manifestarsi di un problema di funzionamento.

0-1

1.2.5 Schema concettualeLo schema concettuale è il risultato dell’analisi delle entità e delle relazioni effettuata. Esso costituisce un modello della realtà di riferimento relativamente agli aspetti trattati in questa sede.

Figura 1.3 Schema concettuale per l’applicazione di inserimento dati

13


1.2.6 Motivazione dell’utilizzo di livelli gerarchiciDall’analisi delle entità è emerso come la localizzazione del problema riscontrato si esplicita attraverso l’asse gerarchico Famiglia – Componente – Dettaglio Componente. Ogni livello può generare informazioni utili a diversi attori nel sistema produttivo, in particolare:

la funzione Qualità, che deve avere in ogni momento la percezione della qualità del prodotto immesso nel mercato per poter intraprendere azioni preventive e correttive adeguate; a questo stadio può quindi essere utile considerare i livelli gerarchici più alti (Famiglia, Componente), demandando a competenze specifiche la soluzione dei problemi tecnici

la funzione Progettazione, qualora nel prodotto finito si manifestino errori/guasti sistematici nel funzionamento dovuti a errori o debolezze del progetto; la localizzazione del problema riscontrato dovrà essere allora dettagliata per permettere l’elaborazione di una soluzione tecnica efficiente ed efficace

il Fornitore, qualora il problema riscontrato sia dovuto ad un componente che non rispetti le specifiche di fornitura; anche in questo caso, come nel precedente, è necessaria una localizzazione precisa del problema (Dettaglio Componente) perché il fornitore possa analizzare la causa del difetto nel suo processo, utilizzando le sue competenze per effettuare analisi specifiche.

1.2.7 Business rulesIl termine “business rules” è utilizzato dagli analisti di sistemi informativi per indicare una qualunque informazione che definisce o vincola qualche aspetto di una applicazione.

Per quanto riguarda l’inserimento di dati, sono state definite le seguenti regole operative :

non è necessario che siano sempre specificati tutti i livelli della gerarchia Famiglia – Componente – Dettaglio Componente né della gerarchia Problema – Causa del Problema

è necessario specificare sempre almeno il livello più alto di entrambe le gerarchie (Famiglia, Problema)

un livello gerarchico può essere specificato solo se sono stati specificati anche tutti i ad esso livelli superiori

lo stesso problema può essere riscontrato su componenti diversi appartenenti a famiglie diverse

è necessario controllare le associazioni gerarchiche create nell’inserimento per evitare il proliferare di combinazioni errate (perché insensate) e di sinonimi: la qualità dei dati è infatti un elemento essenziale per l’efficacia di successive analisi. Il problema della qualità di una data source va affrontato proprio a partire dal processo di produzione dei dati.

14

Capitolo 1

15


1.2.8 Ristrutturazione dello schema concettualeAlla luce di quanto sopra esposto, è stata effettuata una ristrutturazione dello schema concettuale preliminare alla realizzazione dell’applicazione con un RDBMS.

L’entità “Dati assistenza tecnica” è stata accorpata all’entità “Sottoassieme rientrato”, avendo considerato che:

la relazione tra le due entità ha cardinalità 0-1 per l’opzionalità della presenza dei dati rilevati dall’Assistenza Tecnica, ma nella realtà il modulo allegato dall’Assistenza Tecnica è presente nella quasi totalità dei casi;

la cardinalità della relazione è quindi nella pratica 1-1; in questo caso mantenere separare le due entità equivarrebbe a sezionare verticalmente una tabella, e ciò non risulta conveniente dato che in fase di inserimento/lettura/modifica/cancellazione i rispettivi dati vengono acceduti contemporaneamente

L’entità “Risultato analisi laboratorio” è stata accorpata all’entità “Sottoassieme rientrato”, in vista delle seguenti considerazioni:

il risultato dell’analisi di laboratorio è rappresentato attraverso la combinazione dei due assi gerarchici Famiglia-Componente-Dettaglio Componente e Difetto-Causa difetto, in le cui associazioni create devono essere il più possibile monitorate, secondo quanto espresso nelle business rules

per evitare l’inconsistenza e cercare di ridurre la ridondanza e gli errori di inserimento, è quindi opportuno che tali livelli siano codificati separatamente, attraverso tabelle di lookup

inoltre i dati relativi al risultato dell’analisi in laboratorio sono acceduti unitamente a quelli relativi al sottoassieme rientrato nelle operazioni di inserimento/lettura/modifica dei dati (le più frequenti); saranno accedute separatamente in modifica/cancellazione le tabelle di lookup (operazioni meno frequenti)

I due assi gerarchici relativi a “Localizzazione del difetto” e “Tipo di difetto” sono stati codificati in tabelle di lookup distinte per ogni livello della gerarchia;

il livello più alto della gerarchia va obbligatoriamente specificato

un livello può essere specificato solo se solo se sono stati specificati anche tutti i livelli ad esso superiori

un livello assume significato solo in quanto correlato ai livelli ad esso superiori.

16

Capitolo 1

Si osserva che la ristrutturazione introdotta dall’ultimo punto aumenta il numero di accessi necessari a decodificare il risultato dell’analisi di laboratorio, ma è stata tuttavia ritenuta necessaria alla luce delle business rules.

17


1.2.9 Schema fisicoAttraverso la ristrutturazione dello schema concettuale si è pervenuti allo schema fisico riportato.

18

Figura 1.4 Schema fisico sottostante l’applicazione di inserimento dati

Capitolo 1

1.3 Interfaccia per l’inserimento dei datiIl software, sviluppato, in MS Access 2000, è diviso in 2 parti:

il database, contenente tutte le tabelle all’interno delle quali vengono memorizzati i dati; esso è accessibile in multiutenza

l’applicazione, presente nel computer di ogni utente, consente di svolgere da interfaccia alcune operazioni sui dati

All’avvio dell’applicazione viene presentato all’utente un menù dal quale è possibile accedere a tutte le varie maschere per l’input e l’output dei dati.

Attraverso l’opzione “Schede Rientri” si accede all’archivio delle analisi di laboratorio effettuate e alle maschere di inserimento e/o modifica (figura 1.6). I filtri presenti nella parte superiore consentono una selezione dei dati presentati nella vista sottostante; tale vista può essere inoltre stampata o esportata in un foglio Excel tramite gli appositi pulsanti.

Attraverso l’opzione “New Datasheet” l’utente può inserire una nuova scheda nel database (figura 1.7). Il campo ID viene assegnato automaticamente dal sistema non appena viene selezionato il fornitore: una scheda infatti non può essere salvata senza specificare il fornitore (sarebbe insensato!). La sezione relativa alle Azioni Correttive non sarà trattata in questo elaborato.

Figura 1.5 Maschera per l’inserimento e la modifica dei dati

19


I dati da inserire sono raggruppati in tre aree distinte della maschera:

user data: sono i dati riguardanti l’utente, la data e il plant di inserimento; sono pre-impostati automaticamente, ma è possibile modificarli

labs data: tutti i dati riguardanti l’esito dell’analisi tecnica svolta in laboratorio

technical service data: informazioni rilevate dal tecnico al momento della sostituzione (questa sezione comprende anche codice e matricola del sottoassieme analizzato)

In questa fase devono essere applicate diverse regole di inserimento, alcune relative al formato in cui deve essere espresso il dato altre conseguenti alle business rules precedentemente esposte. L’utente può trovare esplicito supporto in questo senso nel manuale dell’applicazione.

Per tutti quei campi il cui contenuto è vincolato attraverso la scelta in una lista di opzioni, può rendersi necessario aggiungere una voce non ancora presente o modificarne una esistente. Questo tipo di operazioni devono essere eseguite tramite la voce “Gestione Dizionari” presente nel menù iniziale. In questo modo l’utente può accedere in lettura e in modifica a tutti i Dizionari impostati.

Sono presenti diverse schede, una per ogni Dizionario (figura 1.8): Famiglie, Componenti, Dettagli Componente, Difetti, Cause del difetto, Fornitori e Mercati. Ogni Dizionario elenca in ordine alfabetico tutte le voci relative riconosciute dal sistema al momento della consultazione; sono possibili

20

Figura 1.6 Inserimento di una nuova scheda

Capitolo 1

operazioni di inserimento, aggiornamento e cancellazione rispetto alle voci esistenti.

Figura 1.7 Schede di gestione dei Dizionari

21

FAMILY

COMPONENTS

COMPONENT DETAILS

DEFECT

DEFECT CAUSES


Nella gestione dei Dizionari vengono implementati i livelli di dettaglio individuati tramite l’analisi; vale inoltre la regola secondo cui un livello gerarchico può essere specificato solo se sono stati specificati anche tutti i livelli ad esso superiori.

Ad esempio, per aggiungere un nuovo Componente è necessario prima selezionare la Famiglia di appartenenza.

Le operazioni di ricerca, ordinamento e cancellazione di termini nei Dizionari avvengono sfruttando alcune funzioni tipiche disponibili in Miscrosoft Office (Find, Find and Replace, Sort Ascending/Descending, Filter for, …)

E’ stata inoltre implementata la parte relativa alla gestione delle spedizioni al fornitore, che non viene approfondita in questa sede in quanto non inerente alle analisi successive.

1.3.1 Manuale dell’applicazione E’ stato elaborato un manuale di utilizzo dell’applicazione rivolto agli utenti al fine di inserirlo, una volta raggiunta la versione definitiva del software, nel database Laundry Quality System, sistema con cui vengono gestiti una serie di documenti del Sistema Qualità

22

Figura 1.9 Utilizzo del Dizionario Componenti

Figura 1.8 Gerarchie emerse dall’analisi

0

500

1000

1500

2000

2500

2001 2002 2003 2004 2005 2006 2007 2008

Anno

Nu

mer

o r

ien

tri

trimestr

Capitolo 1

1.4 Necessità di uno strumento per l’analisi dei datiIl processo di analisi dei rientri dall’utenza è destinato a crescere per volumi analizzati (tendenza evidenziata già a partire dagli ultimi due anni); emerge quindi la necessità di disporre di uno strumento di analisi dei dati allo scopo di:

ottimizzare le prestazioni nell’analisi produrre rappresentazioni grafiche dei dati consentire interrogazioni flessibili dei dati poter utilizzare criteri di analisi e livelli di dettaglio diversi in base

alle esigenze realizzare report

Figura 1.10 Numero di rientri analizzati in funzione degli anni

23

Capitolo 2

2. Architetture per l’analisi dei dati

“It’s the bane of modern business: too many data, not enough information.”(John W.Verity) – Business Week 1997

Lo sviluppo delle tecnologie informatiche ha permesso alle aziende di accumulare cospicue moli di dati a supporto dell’operatività quotidiana, così che una parte importante del patrimonio di conoscenza di un’azienda viene a trovarsi in forma strutturata nelle basi di dati gestionali o in forma semi-strutturata in altri tipi di archivi elettronici. Tuttavia, la tradizionale struttura di tali dati è ottimizzata per l’esecuzione di transazioni (cioè gestione di documenti operativi), ma non è adatta ad operazioni di analisi e interpretazione del business. Per supplire a tale carenza e consentire alle aziende di sfruttare il proprio patrimonio di informazioni in vista di decisioni tattiche e strategiche, sono stati messi a punto numerosi strumenti dalle caratteristiche sempre più articolate, che vengono globalmente indirizzati come Business Intelligence e/o Data Warehousing.

2.1 Dai dati alla conoscenza: Business IntelligenceIl termine Business Intelligence (BI) è stato coniato da Howard Dresner, analista di Gartner Group, nei primi anni ’90. Esso identifica quell’insieme continuo di processi attraverso cui un’azienda analizza i dati, le relazioni fra essi e le tendenze emergenti al fine di migliorare i propri processi decisionali. In particolare, per Business Intelligence si intende un insieme di modelli, metodi e strumenti rivolti:

a) alla raccolta sistematica del patrimonio di informazioni generate da un’azienda;

b) alla loro aggregazione e analisi;c) alla loro presentazioni in forma chiara ed efficace.

La popolarità di questo termine è esplosa negli ultimi anni, come conferma l’indice di Google relevance (ovvero il numero di risultati che si ottengono cercando un termine con il motore di ricerca Google) per “Business Intelligence”.

Business Intelligence

Anno Google relevance2004 ≈ 9.000.000maggio 2008 ≈ 36.000.000ottobre 2008 ≈ 49.500.000

Tabella 2-1: Google relevance per Business Intelligence

La BI, attraverso un insieme di tecnologie e metodologie, consente alle organizzazioni di trarre valore dall’enorme patrimonio informativo che ormai ovunque viene raccolto, ma che è utilizzato in forma ridotta.

La produzione di informazioni cresce a un ritmo tale da far stimare una quantità di informazioni memorizzate più che raddoppiata di anno in anno (CIO Insight, January 2007) e Gartner Group stima che nel 2012 le global companies dovranno gestire 30 volte più dati che nel 2004.

24

Architetture per l’analisi dei dati

La piattaforma Business Intelligence diventa quindi uno strumento essenziale per valorizzare il patrimonio informativo di un’organizzazione, ponendosi obiettivi quali:

supporto ai processi decisionali, a tutti i livelli; modifica e trasformazione di strategie e processi di business in

modo da trarne vantaggi competitivi; miglioramento di performance e profittabilità.

Il valore aggiunto di una soluzione BI è elevato in quanto, a partire da dati già presenti in azienda (grazie a investimenti precedenti nei sistemi informativi), fornisce un valido supporto ai processi decisionali e un’interfaccia chiara ed efficace alle informazioni per tutti gli utenti.

2.1.1 Struttura di un sistema di BILa realizzazione di un sistema di BI coinvolge tutti gli aspetti di una organizzazione: le persone, i processi, le informazioni, i piani, gli obiettivi e il sistema di misurazione dei risultati.

Le fondamenta di una struttura di sistema di BI consistono nella realizzazione di una interconnessione di alto livello tra i sistemi operazionali presenti nell’organizzazione (ed eventualmente fonti esterne), in modo da consentire un’analisi dei dati integrata. Spesso infatti accade che il patrimonio informativo sia sottoutilizzato in quanto il disallineamento e la specificità delle applicazioni settoriali non trovano riscontro in una visione strategica unitaria.

Schematicamente, un sistema di BI si basa su un’architettura a 3 livelli (figura 2.1). Al livello più basso vi sono i sistemi transazionali per la gestione quotidiana dei dati e delle transazioni che riguardano le attività correnti; a questo livello il dettaglio dei dati è elevato e le applicazioni sono in genere di tipo operativo, cioè utilizzano procedure standard per integrare e sostituire le attività impiegatizie e sono volte all’efficienza.

Il “cuore” della struttura è costituito dal Data Warehouse (par. 2.3), che si basa su metodi e strumenti per archiviare, gestire e consolidare i dati provenienti da diverse aree dell’organizzazione. Il Data Warehouse è quindi la componente essenziale su cui attuare la Business Intelligence.

Al livello più alto si trovano gli strumenti di analisi a supporto delle attività decisionali, che necessitano di informazioni selezionate e sintetizzate, dal valore strategico, rappresentabili in formati grafici chiari ed efficaci. A questo livello i sistemi informativi devono supportare attività direzionali non predefinite e poco strutturate, rispondendo ad interrogazioni particolarmente flessibili che coinvolgono grandi quantità di dati.

Figura 2.1 Livelli di un sistema di BI

25

Capitolo 2

La piattaforma BI si propone come strumento per valorizzare il patrimonio informativo, generando quel valore dell’informazione di sintesi già teorizzato da Anthony e Simon con la piramide delle attività aziendali. Risalendo dai sistemi di base fino ai sistemi per il supporto decisionale, il valore del singolo dato aumenta, in quanto riassume in sé un contenuto informativo maggiore.

26


In un sistema di BI interagiscono diversi componenti (fig. 2.2). I dati vengono estratti da una o più sorgenti preesistenti e, attraverso strumenti di ETL (Extract, Transform, Load), vengono organizzati e memorizzati in opportune strutture fisiche orientate all’analisi dei dati (Data Warehouse). Gli strumenti di analisi usufruiscono della struttura intermedia offerta dal Data Warehouse per eseguire analisi integrate su grandi moli di dati, secondo il livello di aggregazione richiesto. Il funzionamento di questa struttura è esposto con maggior dettaglio al par. 2.3.2.2.

Attualmente la Business Intelligence è diventata una priorità strategica per molte organizzazioni, in quanto costituisce uno strumento essenziale per la competitività (CIO Insight in “The Future of I.T.: What’s on the Tap for 2007 and Beyond” stimava un incremento annuale del 6,7% del budget riservato agli investimenti in BI).

Gartner Group, una delle più importanti società internazionali di ricerca e sviluppo in ambito tecnologico, ha pubblicato nel 2007 uno studio (“Business Intelligence Platform Capability Matrix”) allo scopo di fornire una guida alla comprensione e alla valutazione delle caratteristiche tecniche delle piattaforme BI sul mercato.

Gartner classifica 12 funzionalità delle piattaforme di BI, dividendole in tre aree distinte: gestione dell’informazione, integrazione e analisi (fig. 2.3). Solo la combinazione dei fattori presenti nelle tre aree può costituire una piattaforma di BI che supporti efficacemente il business.

Figura 2.2 Struttura di un sistema di BI

Figura 2.3 Business Intelligence Platform Capability Matrix

27

Capitolo 2

La prima area (Information Delivery) include le funzionalità che permettono agli utenti di realizzare reporting interattivo, “cruscotti” con indicatori sintetici e query ad hoc, con particolare attenzione alle performance. Considerato infine che la piattaforma BI in molte implementazioni costituisce il livello intermedio (il cosiddetto middle tier) su cui si basano gli strumenti di analisi, va valutata anche la capacità di integrazione con gli strumenti Office, in particolare Excel.

Per quanto riguarda l’integrazione, viene considerata l’infrastruttura BI in tutti i suoi componenti (sicurezza, amministrazione, query engine, ecc.) e il livello di integrazione nell’installazione. Inoltre viene valutata la capacità di offrire agli sviluppatori uno strumento per costruire applicazioni BI tramite tool grafici, senza la necessità di scrivere codice.

Per quanto riguarda l’area dell’analisi infine, la matrice di Gartner Group considera non solo le funzionalità OLAP (On Line Analytical Processing, par. 2.3), ma anche la presenza di strumenti di visualizzazione avanzati, l’utilizzo di tecniche matematiche avanzate per l’analisi dei dati e la possibilità di costruire modelli predittivi basati su diversi tipi di algoritmi.

L’obiettivo principale di una piattaforma di BI è comunque quello di supportare un’organizzazione nel trarre un vantaggio competitivo dallo sfruttamento del proprio patrimonio informativo. In questo senso, gli effetti più importanti sul business dovrebbero essere:

riduzione dei tempi necessari per la raccolta delle informazioni aziendali rilevanti;

automatizzazione del processo di trasformazione delle informazioni in conoscenze personalizzate;

impiego di strumenti di analisi per l’esecuzione di confronti e il supporto alle decisioni;

trasformazione delle decisioni in interventi.

28


2.1.2 Strumenti di Business IntelligenceUn sistema di BI si configura come una soluzione integrata costituita da moduli di ricerca, di analisi e di reportistica dei dati rivolta al supporto decisionale. Diversi tool si trovano integrati e differentemente combinati nei pacchetti BI sul mercato: nella tabella seguente sono brevemente descritti i principali.

OLAP Strumenti basati sull’analisi dimensionale e sul concetto di ipercubo; oggetto di questa tesi.

Scorecarding Strumento di supporto nella gestione strategica dell’impresa; permette di tradurre la mission e la strategia dell’impresa in un insieme coerente di misure di performance, facilitandone la misurabilità ("The Balanced Scorecard - Measures that Drive Performance", Harvard Business Review, R. Kaplan, D. Norton).

Dashboarding Presentazione dei dati attraverso indicatori sintetici che rappresentano il valore corrente di una prestazione rispetto a un obiettivo o una soglia prestabilita. Di solito vengono presentate più misure contemporaneamente (per questo si parla di “cruscotti”).

Information Visualization

Applicazioni che coinvolgono la selezione, la trasformazione e la rappresentazione di dati in una forma adatta a facilitarne l’esplorazione e la comprensione. E’ un’area di ricerca ricca e complessa, che si basa su teorie di information design, computer graphic, interazione uomo-macchina e scienze cognitive.

Data Modeling Analisi e design dell’informazione all’interno di un sistema, incentrati sulle entità logiche e le dipendenze tra di esse. Il modello dei dati non deve solo definire la struttura dei dati, ma anche la semantica degli stessi.

Business Logic Business Logic è un termine usato nella programmazione software per intendere uno strumento che effettua certi tipi di operazioni sui dati che lo attraversano. La Business Logic è solitamente associata a un’architettura software three-tier.

Data Warehouse Sistemi che si occupano dell’integrazione dei dati a partire da database distribuiti e strutturati diversamente (par. 2.4)

Data Mining Conosciuto anche come KDD (Knowledge Discovery in Databases), consiste nella ricerca automatica di campioni in grandi archivi di dati, usando tecniche computazionali derivate dalla statistica e dal pattern recognition (riconoscimento di modelli).

Text Mining Conosciuto anche come Intelligent Text Analysis

29

Capitolo 2

o come KDT (Knowledge Discovery in Text), si riferisce al processo di estrazione di informazioni e conoscenza interessanti e non banali a partire da testo non strutturato.

Decision Support System (DSS)

Classe di sistemi informativi computerizzati che supportano attività decisionali. Esistono vari tipi di DSS: model-driven, communication-driven, data-driven, document-driven, knowledge-driven.

Business Performance Management (BPM)

Insieme di processi che aiutano le organizzazioni ad ottimizzare le prestazioni del business: è visto come una Business Intelligence di nuova generazione. Si focalizza in processi quali la pianificazione e la previsione (scenari what-if).

Tabella 2-2 Principali tool di sviluppo BI

30


2.2 OLTP e OLAPTramite la tecnologia delle basi di dati, le imprese accumulano grandi moli di dati relativi alla loro gestione operativa quotidiana. Questi dati – se opportunamente accumulati e analizzati – possono essere utilizzati non solo per la gestione dell’impresa, ma anche per la pianificazione e il supporto alle decisioni. La tecnologia della basi di dati però è finalizzata prevalentemente alla gestione efficiente e affidabile dei dati “in linea” (On Line Transaction Processing, OLTP).

Per molti decenni si è pensato che i linguaggi di interrogazione e le architetture dei sistemi di gestione di basi di dati fossero adeguati sia per la gestione operativa sia per l’analisi dei dati. In effetti, SQL consente di costruire interrogazioni anche complesse in modo arbitrario e offre quindi alcune caratteristiche utili per l’analisi, ma i linguaggi per l’analisi dei dati vanno usati da utenti che non sono necessariamente esperti informatici e che quindi non possono padroneggiare il linguaggio SQL. Inoltre, è assai difficile ottimizzare un’applicazione in modo che soddisfi contemporaneamente le esigenze di analisi e di gestione in linea. Di conseguenza, le ultime hanno storicamente prevalso sulle prime.

Già a partire dagli anni Novanta, parallelamente allo sviluppo delle reti e dei prodotti per la distribuzione dei dati, si sono imposte nuove architetture, caratterizzate dalla separazione degli ambienti: a fianco dei sistemi per OLTP si sono sviluppati sistemi dedicati esclusivamente all’elaborazione e all’analisi dei dati, cioè a On Line Analytical Processing (OLAP); si tratta di strumenti interattivi in grado di fornire risposte in tempi brevi, anche a fronte di grandi moli di dati da prendere in considerazione.

E’ utile a questo punto considerare la divisione degli utenti di un database aziendale in due macro-categorie:

utenti amministrativi, che giornalmente accedono al database, interessati all’interrogazione, inserimento, aggiornamento e cancellazione di un ristretto numero di record (On Line Transaction Processing, OLTP);

management, che, su base periodica, interroga una notevole quantità di dati, generando diverse tipologie di aggregazioni, onde ottenere report su cui basare le proprie decisioni (On Line Analytical Processing, OLAP).

Le diverse esigenze delle elaborazioni transazionali e analitiche sono quindi alla base delle differenze tra sistemi OLTP e OLAP. I primi devono gestire numerose ma elementari operazioni di inserimento, modifica e cancellazione di singoli record; i secondi devono invece gestire rare ma pesanti e complesse interrogazioni su grandi quantità di dati eterogenei. Questo determina profonde differenze nelle caratteristiche che devono offrire, ma anche nei requisiti di risorse che necessitano.

Innanzitutto mentre le applicazioni OLTP sono normalmente condivise da un elevato numero di utenti finali che svolgono transazioni predefinite e relativamente semplici, le applicazioni OLAP sono caratterizzate da un più

31

Capitolo 2

ristretto numero di utenti che svolgono attività decisionali. E’ possibile che le funzioni di analisi vengano svolte da un gruppo di specialisti (gli “analisti”) che realizzano le analisi dei dati commissionate dai dirigenti, ma è sempre più diffusa l’esigenza di dotare gli strumenti OLAP di interfacce di facile uso, in modo da permettere un’attività decisionale più immediata ed efficace, senza la necessità di intermediari.

Un’altra differenza consiste nel fatto che, mentre nei processi OLTP viene descritto di solito solo lo “stato corrente” di una applicazione, per i motivi sopra citati, i dati gestiti dai processi OLAP sono tipicamente di tipo storico-temporale. Esiste inoltre il problema della qualità dei dati: spesso, infatti, la semplice raccolta dei dati esistenti non consente analisi significative, in quanto i dati presenti nei sistemi OLTP possono contenere inesattezze, errori e omissioni.

Le differenze essenziali tra sistemi OLTP e sistemi OLAP sono riportate nella tabella seguente.

OLAP OLTPProgettazione Orientata all’analisi e ai

reportOrientata alle

transazioniFunzione Supporto alle decisioni Gestione amministrativaFrequenza Periodica GiornalieraDati contenuti nel DB

Storici, riassuntivi Mutevoli, dettagliati

Sorgente dei dati Diverse basi di dati Singola base datiAccesso tipico Read, (periodicamente

append)Read / write / delete

Flessibilità accesso Linguaggio SQL / proprietario

Linguaggio SQL

Numero record acceduti

10E3 – 10E6 10

Tipo utenti Management AmministrativiNumero utenti Centinaia MigliaiaDimensione DB 100 GB – 1 TB 100 MB – 1 GB

Tabella 2-3: Principali differenze tra sistemi OLTP e OLAP

Riassumendo: gli OLTP (On Line Transaction Processing) sono processi

orientati alla gestione (transazioni) delle informazioni. Sono detti anche processi o database operazionali;

gli OLAP (On Line Analytical Processing) sono processi orientati alla sola analisi (interrogazione) delle informazioni, ed eventualmente al loro accumulo ulteriore. Essi sono basati su una base di dati detta Data Warehouse (magazzino di dati), nella quale vengono raccolte tutte le informazioni che, opportunamente analizzate, possono fornire supporto alle decisioni.

32


I requisiti sono quindi contrastanti e giustificano un’architettura basata sulla separazione degli ambienti (fig. 2.4), in cui i sistemi OLTP svolgono il ruolo di “sorgenti di dati” (data source) per l’ambiente OLAP.

Figura 2.4 Separazione fra gli ambienti OLTP e OLAP

33

Capitolo 2

2.3 Data Warehouse

2.3.1 Definizione di Data WarehouseTra le definizioni di Data Warehouse, diffusamente riconosciute, due in particolare ne identificano le caratteristiche peculiari. Gartner Group propone la seguente definizione di Data Warehouse:

“Un Data Warehouse è una piattaforma sulla quale vengono archiviati e gestiti dati provenienti dalle diverse aree dell’organizzazione; tali dati sono aggiornati, integrati e consolidati dai sistemi di tipo operativo per supportare tutte le applicazioni di supporto alle decisioni.”

Gartner Group

W.H. Immon presentò per primo il termine/concetto di Data Warehouse in “Building the Datawarehouse” (1992), dandone la seguente definizione:

“Il Data Warehouse è una raccolta di dati: orientata al soggetto, integrata, non volatile, variabile nel tempo.”

W.H. Immon

Alla luce di queste definizioni, è possibile evidenziare le principali caratteristiche di un Data Warehouse (DW), che distinguono una base di dati per il supporto alle decisioni da una base di dati operazionale.

Un DW è una base di dati integrata : i dati di interesse provengono infatti da diverse sorgenti informative persistenti e ciò richiede un’attività propedeutica di riconciliazione delle eterogeneità.

Un DW contiene tipicamente dati in forma aggregata : le principali attività di analisi dei dati per il supporto alle decisioni si basano su informazioni ottenute aggregando i dati disponibili rispetto ad opportune coordinate.

Un DW contiene dati di carattere storico-temporale : mentre infatti le basi di dati operazionali mantengono lo “stato corrente” dei dati, nel DW, per sua natura, è di interesse l’evoluzione storica dei dati.

Un DW è una collezione di dati orientata al soggetto (Subject Oriented): i dati contenuti nel DW possono essere organizzati sulla base di un particolare fatto o processo aziendale.

Un DW è una struttura dati non volatile : la struttura dati creata infatti non è temporanea ma persistente e gli accessi ai dati avvengono in sola lettura.

Un DW ha un’esistenza autonoma : il DW viene sempre mantenuto fisicamente separato dalle sorgenti informative; il processo che “riempie” la struttura del DW a partire dalle sorgenti operazionali è detto alimentazione del DW.

Un DW è una base di dati fuori linea : l’integrazione in linea risulta complicata in quanto i dati di interesse sono eterogenei e il mantenimento dei dati storici, l’aggregazione e l’analisi richiedono organizzazioni e metodi di accesso specifici. I meccanismi di importazione dei dati sono di tipo asincrono e periodico, in modo da non penalizzare le prestazioni delle sorgenti di dati. In tal caso,

34


il DW non contiene dati perfettamente aggiornati rispetto al flusso di transazioni che operano nei sistemi OLTP; un disallineamento controllato dei dati, però, è in genere ritenuto accettabile per molte applicazioni di analisi.

Il DW è diventato il mezzo di supporto per analisi dinamiche e multidimensionali dei dati che richiedono la lettura di un’enorme quantità di record.

35

Capitolo 2

Se il fattore tecnologico è un presupposto necessario per lo sviluppo di soluzioni di DW, il fattore critico di successo è il coinvolgimento dell’utente. Solo un’adeguata sponsorizzazione da parte del management può garantire il necessario contributo nel progetto di diversi settori aziendali con il relativo apporto di conoscenza dei processi e dei dati impiegati. Stabilire quindi preventivamente i requisiti è indispensabile per un il successo di un progetto Data Warehouse.

2.3.1.1 Il processo di Data WarehousingIl processo di Data Warehousing si basa su una struttura dati appropriata (Data Warehouse) ed è l’insieme delle attività che consentono di trasformare i dati operazionali in conoscenza per il supporto alle decisioni. Data Warehousing è quindi una collezione di metodi, tecnologie e strumenti volti al miglioramento del patrimonio informativo.A questo proposito, si indicano brevemente tre tipi di utilizzi del Data Warehouse orientati all’analisi dei dati:

Strumenti di reporting : sono quegli strumenti che permettono di realizzare sunti (report) contenenti le informazioni richieste.

Strumenti per analisi OLAP: sono strumenti in grado di elaborare i dati contenuti nel DW utilizzando modelli multidimensionali e fornendo risposte alle query in tempi molto ridotti; come già detto, la loro funzione è quella di fornire supporto a operazioni di analisi dei dati e ai processi decisionali, attraverso una specifica organizzazione dei dati.

Strumenti di Data Mining: consentono l’estrazione di informazione utile, con strumenti automatici o semiautomatici, da grandi quantità di dati al fine di scoprire strutture e regole significative.

2.3.2 Architettura di un Data Warehouse

2.3.2.1 Modello di riferimentoLa definizione dell’architettura per progetti di Data Warehousing comporta la condivisione preliminare di un modello di riferimento che rappresenta le componenti funzionali coinvolte. Queste ultime vengono aggregate in tre aree:

sorgenti di dati Data Warehouse (e Data Mart) strumenti di analisi

a formare un modello “a farfalla”. Si ha infatti ai due estremi numerosità ed eterogeneità rispettivamente di fonti di dati e di tipi di analisi, permesse da una strutturazione e organizzazione dei dati che avviene nel “cuore” del modello, il Data Warehouse. Solo individuando e gestendo correttamente tali componenti e le loro interazioni è possibile realizzare un flusso che da “molti dati” genera “molte informazioni”. Per comprendere meglio questo modello, se ne analizzerà l’architettura.

36

Figura 2.5 Modello di riferimento per il DW


2.3.2.2 Architettura di un Data Warehouse: componentiUn’architettura atta a soddisfare i requisiti di cui sopra comprende generalmente i seguenti componenti. Le sorgenti dei dati o data source. I dati vengono estratti da uno o più

sistemi preesistenti, nel sistema informativo aziendale oppure esterni ad esso ma accessibili con regolarità (per esempio rilevazioni ISTAT). I data source includono una vasta tipologia di sistemi, comprendenti anche raccolte di dati non gestite tramite DBMS oppure gestite tramite DBMS di vecchia generazione (i cosiddetti sistemi legacy).

Il data warehouse server. E’ il sistema dedicato alle gestione del data warehouse e può basarsi su diverse tecnologie (ROLAP o MOLAP, par. 2.6). Questa componente memorizza i dati attraverso opportune strutture fisiche e realizza in modo efficiente interrogazioni complesse, caratterizzate da join tra tabelle, ordinamenti e aggregazioni; esso consente anche speciali operazioni, quali roll-up, drill-down, slice-and-dice (par. 2.5.2). Molto spesso a partire dal Data Warehouse si costruiscono i Data Mart, ovvero dei sottoinsiemi logici del DW in grado di soddisfare specifiche esigenze di analisi (per esempio quelle relative a un particolare settore dell’azienda).

Un sistema di alimentazione. Esso consiste in una serie di strumenti detti ETL (Extract, Transform, Load) che svolgono le seguenti attività di base.

Estrazione dei dati dalle sorgenti. Dopo il popolamento iniziale, il processo di estrazione è tipicamente incrementale: lo strumento per l’esportazione dei dati colleziona le sole modifiche dei data source (secondo modalità illustrate nel seguito) e le comunica ai moduli successivi.

Pulizia dei dati (data cleaning). Lo scopo è quello di analizzare la correttezza dei dati prima dell’inserimento nel Data Warehouse; questo avviene applicando dei filtri in grado di eliminare dati palesemente scorretti sulla base di controlli che si applicano ai singoli data source, oppure rilevando e talvolta correggendo errori e inconsistenze nei dati estratti. Tale attività è essenziale per assicurare un sufficiente livello di qualità dei dati.

Trasformazione dei dati. Questo processo predispone i dati all’uso operativo, svolgendo prevalentemente un’opera di riconciliazione delle eterogeneità presenti nelle varie sorgenti informative. In questa fase vengono svolte, per esempio, conversioni, trasformazioni di formato e associazioni tra campi equivalenti di sorgenti diverse; vengono inoltre eseguite operazioni di de normalizzazione, ordinamento e aggregazione.

Caricamento dei dati nel Data Warehouse. Tipicamente le operazioni di acquisizione vengono svolte a lotti (in batch) quando il DW non è utilizzato per l’analisi (tipicamente di notte); si può procedere in due modi:

37

Capitolo 2

in alcune applicazioni, caratterizzate da un numero limitato di dati, si può acquisire periodicamente l’intero contenuto del DW;

più spesso i dati vengono allineati in modo incrementale (refresh), propagando al DW le modifiche fatte sulle sorgenti dei dati. Nel processo di refresh si possono usare due tecniche: invio dei dati (data shipping) e invio delle transazioni (transaction shipping). La prima tecnica può utilizzare dei trigger nel data source che, in modo trasparente alle applicazioni, registrano gli aggiornamenti in opportuni archivi variazionali; la seconda tecnica costruisce gli archivi variazionali utilizzando i log di transazione. In entrambi i casi, gli archivi variazionali vengono prodotti dal modulo di estrazione e utilizzati dal modulo di caricamento per aggiornare il DW.

38


Strumenti di analisi. Questi strumenti consentono di effettuare analisi dei dati usufruendo dei servizi offerti dal DW server e offrono interfacce in grado di presentare, in forma adeguata e facilmente comprensibile, i risultati delle analisi. Esempi di strumenti di analisi sono l’analisi multidimensionale (a partire da un modello multidimensionale dei dati, par. 2.5) e il data mining (par. 2.1.2).

Va detto che nelle architetture reali non tutte le componenti illustrate sono sempre presenti e sono possibili alcune varianti. In particolare, sono possibili architetture ad un livello, a due livelli o a tre livelli, in base alla presenza e al numero dei livelli intermedi tra sorgenti di dati e Data Warehouse. Inoltre la costruzione di un Data Warehouse aziendale, che descriva tutti i dati utili all’analisi presenti in una organizzazione, è un obiettivo ambizioso ma anche assai difficile da realizzare. Per questo motivo è oggi prevalente l’approccio metodologico bottom-up, che prevede di costruire il DW in maniera incrementale, concentrandosi separatamente su sottoinsiemi dei dati aziendali (dati dipartimentali o settoriali), per i quali sia ben chiaro l’obiettivo dell’analisi.. Questa soluzione richiede però uno sviluppo coordinato dei vari data mart (costituiti appunto da sottoinsiemi logici di dati da analizzare), affinché sia possibile, se necessario o utile, integrare data mart sviluppati separatamente. Il risultato del coordinamento di dimensioni omogenee appartenenti a data mart diversi viene detto data warehouse bus.

2.3.2.3 Qualità dei datiLa qualità dei dati è un elemento essenziale per il successo di un Data Warehouse. Infatti, se i dati memorizzati contengono imprecisioni o errori l’analisi risultante sarà necessariamente fuorviante, e l’uso del DW può risultare addirittura controproducente. Vari fattori pregiudicano la qualità dei dati.

Per esempio, in basi di dati prove di vincoli di integrità (magari perché gestite con tecnologie pre-relazionali) il tasso di errori (dirty data) è assai elevato; alcune stime indicano che i dati errati in applicazioni commerciali oscillano tra il 5 e il 30 per cento del totale (P. Atzeni et al., “Basi di dati”, seconda edizione).

Figura 2.6 Architettura di un Data Warehouse

39

Capitolo 2

Inoltre in DW costruiti assemblando dati estratti da fonti plurime si aggiungono problemi di disallineamento delle informazioni presenti in basi di dati diverse; questo problema è accentuato dalla eterogeneità dei sistemi utilizzati.

Per ottenere elevati livelli di qualità è necessario usare in maniera opportuna gli strumenti di data cleaning, esprimendo un certo numero di regole atte a garantire l’integrità dei dati (regole di integrità) e successivamente eliminando o correggendo i dati che non rispettano tali regole. Più in generale, il problema della qualità di una data source dovrebbe essere affrontato a monte, osservando con attenzione il processo di produzione dei dati e associando ad esso azioni di verifica e correzione di eventuali dati errati.

2.4 Rappresentazione multidimensionale dei datiI dati presenti in un Data Warehouse vengono presentati all’utente finale (generalmente un utente esperto nel dominio applicativo, ma non necessariamente con competenze tecniche) mediante una rappresentazione di alto livello, che prescinde dai criteri di memorizzazione dei dati e ne favorisce l’analisi. Le esigenze analitiche possono essere supportate da sistemi OLAP (On Line Analytical Processing) grazie a un insieme di tool che consente di operare on-line sui dati contenuti nel Data Warehouse. Per supportare operazioni di tipo OLAP i dati devono essere organizzati secondo un modello di rappresentazione noto come modello multidimensionale. Esso rappresenta una concettualizzazione dei dati più vicina al modo in cui l’utente percepisce la realtà aziendale.

2.4.1 Il modello multidimensionaleIl modello multidimensionale costituisce la rappresentazione logica dei dati adatta a supportare le richieste di analisi, in quanto i dati vengono organizzati secondo la prospettiva dell’utente e non secondo i modelli adottati nei sistemi che gestiscono le sorgenti informative.Il modello multidimensionale è fondato su tre concetti di base: il fatto, la misura e la dimensione.

Un fatto è un concetto del sistema informativo aziendale (o più precisamente della relativa realtà di interesse) sul quale ha senso svolgere un processo di analisi orientato al supporto alle decisioni.

Una misura è una proprietà atomica di un fatto che si intende analizzare (tipicamente un attributo numerico o un conteggio delle sue istanze).

Una dimensione è una particolare prospettiva secondo la quale può essere effettuata l’analisi di un fatto. I valori possibili per una dimensione vengono generalmente detti membri della dimensione.

40


Il modello multidimensionale si basa sulla constatazione che gli oggetti che influenzano il processo decisionale sono i fatti del mondo aziendale (esempi di fatti sono: vendite, spedizioni, ricoveri, interventi, ecc. ). Per ogni fatto interessano in particolare i valori di un insieme di misure,che descrivono quantitativamente gli eventi (ad esempio l’incasso, la quantità, i costi, la durata, ecc). Ogni misura infine può essere esaminata secondo diverse dimensioni di analisi (ad esempio il tipo di articolo venduto, il periodo di tempo in cui è stata effettuata la vendita o il luogo dove si è svolta). Inoltre le dimensioni vengono tipicamente organizzate in gerarchie di livelli di aggregazione, corrispondenti a diversi livelli di dettaglio (ad esempio la dimensione Luogo può essere organizzata nei livelli Città, Provincia e Regione).

Astraendosi dalle particolari applicazioni, si può dire che il modello multidimensionale considera uno spazio n-dimensionale i cui assi, detti dimensioni di analisi, permettono di collocare gli eventi aziendali. L’insieme degli eventi collocati nello spazio n-dimensionale così definito prende il nome di Data Cube.

Una volta fissate le dimensioni di un fatto e un livello di aggregazione di interesse per ogni dimensione, una istanza del fatto assegna, ad ogni combinazione valida di membri dei livelli selezionati, un valore per ciascuna misura del fatto.

Esiste una naturale rappresentazione grafica, peraltro largamente utilizzata dagli strumenti di analisi, nella quale le istanze di un fatto sono rappresentate da cubi multidimensionali costituiti da elementi atomici, detti celle.

Gli spigoli di una cella rappresentano quindi le dimensioni di analisi e ogni cella del cubo contiene un valore per ogni misura considerata nella descrizione del problema. Se non tutti gli eventi descrivibili tramite il cubo si verificano (esistono cioè delle celle per cui non è definita una misura), il cubo è detto “sparso”.

Se le dimensioni sono più di tre la struttura dati prende il nome di iper-cubo : in questo caso si tratta di un modello n-dimensionale (con n pari al numero delle dimensioni) non rappresentabile geometricamente, per il quale le forme di rappresentazione più comunemente utilizzate sono quelle tabellari.

A titolo di esempio, si riporta un cubo per l’analisi di un generico fatto Vendita . In questo caso, si è considerato uno spazio tridimensionale, costituito dalle dimensioni ARTICOLO, LUOGO e TEMPO, secondo cui si vuole analizzare la Vendita . Per semplicità, infine, si può definire una sola misura, la Quantità venduta.

In questo esempio, una cella (o “punto discreto”) del cubo indica quanti prodotti dell’articolo X sono stati venduto nel negozio Y nel periodo di tempo Z. In altre parole, una possibile istanza del fatto Vendita sulle dimensioni di

41

Capitolo 2

figura potrebbe associare il valore 2758 della misura Quantità Venduta ai membri: Televisori del livello Prodotto della dimensione ARTICOLO, Roma del livello Città della dimensione LUOGO e Maggio 2006 del livello Mese della dimensione TEMPO.

Riassumendo, un cubo multidimensionale è incentrato su un fatto di interesse decisionale. Esso rappresenta un insieme di eventi, descritti da misure numeriche; ogni asse del cubo è una dimensione, che può essere analizzata a vari livelli di dettaglio individuati tramite attributi strutturati in gerarchie.

In questo modello di rappresentazione, un data warehouse è costituito da un insieme di cubi dimensionali definiti su una collezione uniforme di dimensioni (questo garantisce la possibilità di combinare il contenuto di cubi diversi sulla base di membri di una dimensione condivisa). In una organizzazione basata su data warehouse bus si può assumere che ogni cubo corrisponda ad un data mart.

42

Figura 2.7 Un cubo multidimensionale rappresentante un fatto di analisi


2.4.2 Operazioni nel modello multidimensionalePer il modello multidimensionale vengono definite alcune operazioni di analisi che si esprimono come operazioni sui cubi. Si tratta di operazioni che si applicano a cubi multidimensionali e restituiscono nuovi cubi, non necessariamente con lo stesso numero di dimensioni. Tali operazioni vengono utilizzate per interrogare il contenuto del data warehouse e ottenere una presentazione dei dati adeguata al tipo di analisi da effettuare.

Le operazioni più comuni che possono essere svolte sui Data Cube, insieme alla relativa rappresentazione nel caso di cubo tridimensionale, sono le seguenti:

Roll-up: consiste nell’aumentare il livello di aggregazione dei dati, passando da un livello di dettaglio superiore a un livello di dettaglio inferiore. Si può ottenere sia aggregando i membri di un livello per salire nella rispettiva gerarchia sia eliminando completamente una dimensione; in entrambi i casi viene eseguita un’aggregazione dei dati di un cubo seguita da una funzione aggregativa (in genere la somma). L’aggregazione dei dati porta a delle “macro-celle”. Un concetto importante legato al roll-up è quello dell’additività.

Drill-down: è l’operazione duale al roll-up, consente cioè di aggiungere dettaglio a un cubo disaggregandolo lungo una o più dimensioni; si inseriscono così ulteriori dettagli all’interno della vista dei dati che si sta realizzando.

Slice-and-dice: letteralmente “tagliare a fette e cubetti”, consiste in operazioni di proiezione e selezione sui dati. In particolare, si utilizza il termine slicing per indicare l’operazione che fissa un valore per una determinata dimensione del cubo.

Figura 2.8 Roll-up

Figura 2.9 Drill-down

Figura 2.10 Slice-and-dice

43

Capitolo 2

Pivoting: significa “fare perno” e consiste nel cambiamento delle modalità di presentazione dei dati, per analizzare le stesse dimensioni secondo diverse prospettiva. Da un punto di vista geometrico, corrisponde ad un ri-orientamento del cubo.

Drill-across: coinvolge nell’analisi due o più Data Cube, combinando i dati associati a più fatti. Questa tecnica per la creazione di viste è particolarmente utile quando l’analisi riguarda un processo composto da più sottoparti.

Si è accennato al concetto di additività per l’operazione di roll-up: tale proprietà si riferisce alla misura di un fatto e garantisce la significatività dell’operazione di roll-up qualora (come accade tipicamente) la funzione di aggregazione utilizzata sia la somma.

Si dice che la misura di un fatto è additiva lungo una dimensione se ha senso sommarla rispetto a ogni possibile aggregazione ottenuta sui livelli della dimensione. Si dice invece che una misura è semiadditiva se è possibile sommarla rispetto ad alcune dimensioni, ma non a tutte.Ad esempio, le misure Quantità e Incasso del fatto Vendita sono entrambe additive per tutte le dimensioni considerate (Tempo, Luogo, Articolo); un ipotetica misura Quantità a scorta per un certo prodotto risulterebbe invece semiadditiva, in quanto additiva per la dimensione Articolo ma non additiva per la dimensione Tempo (non ha infatti senso effettuare un roll-up basato su somma per tale dimensione).

44

Figura 2.11 Pivoting

Figura 2.12 Drill-across


2.5 Realizzazione di un data warehousePer la realizzazione di una data warehouse si contrappongono due soluzioni alternative, significativamente diverse dal punto di vista metodologico.

La prima soluzione consiste nell’uso della tecnologia relazionale, opportunamente adattata ed estesa; i dati vengono memorizzati tramite tabelle e le operazioni di analisi vengono tradotte in opportune istruzioni SQL. I dati possono essere mantenuti nella locazione originaria. Sistemi di questo tipo si dicono ROLAP (Relational OLAP).

La seconda soluzione consiste nel memorizzare i dati direttamente in forma multidimensionale, tramite speciali strutture dati tipicamente proprietarie. Richiede una copia di tutti da inserire nel Data Warehouse. Sistemi di questo tipo si dicono MOLAP (Multidimensional OLAP).

A seguito di questa distinzione, si parla anche di RDBMS (Relational DBMS) e MDBMS (Multidimensional DBMS). Nelle tabelle che seguono vengono presentati i principali vantaggi e svantaggi di entrambe le soluzioni.

VANTAGGI ROLAP SVANTAGGI ROLAP è una soluzione valida per DB

grandi e sistemi legacy (la limitazione di volume posta coincide con quella del DB relazionale sottostante)

utilizza le funzionalità di un engine relazionale

basse performance in termini di tempo di risposta: un’interrogazione su un sistema ROLAP corrisponde a una o più query SQL, quindi il tempo di esecuzione può essere alto se la base dati è voluminosa

le capacità di interrogazione sono limitate dalle funzionalità SQL (ad esempio è difficile eseguire calcoli complessi con SQL)

Tabella 2-4: Soluzioni ROLAP

VANTAGGI MOLAP SVANTAGGI MOLAP alte performance dovute agli indici

bitmapped e alle pre-aggregazioni eseguite all’atto del caricamento del cubo

può gestire calcoli, anche complessi, pre-generati alla creazione del cubo

può gestire un volume limitato di dati nel cubo e, nel caso di cubi derivati da grandi quantità di dati, sono incluse nel cubo solo le aggregazioni di alto livello

richiede investimenti: spesso infatti sono utilizzate tecnologie proprietarie che non pre-esistono nell’organizzazione (sono richieste anche competenze specifiche)

Tabella 2-5: Soluzioni MOLAP

Esistono inoltre soluzioni ibride, dette HOLAP (Hybrid OLAP), che tentano di combinare i vantaggi delle due soluzioni precedenti; in questo caso, i (molti)

45

Capitolo 2

dati originali sono mantenuti in un DB ROLAP, mentre i soli dati aggregati sono inseriti in strutture MOLAP. In questo modo, prima di accedere ai dati dettagliati, si dispone di una struttura MOLAP intermedia più veloce per la navigazione.

Un altro tipo di soluzione intermedia è costituita dal DOLAP (Desktop OLAP), cioè l’utilizzo di computer desktop per l’analisi in locale solamente dei Data Cubes di interesse per l’utente. In questo caso, il Data Warehouse risiede su un server ed il pc client riceve il cubo di interesse dal server: sarà suo compito l’elaborazione dei dati.

Alla luce della letteratura specialistica consultata, la principale differenza fra sistemi ROLAP e MOLAP consiste nel tradeoff tra flessibilità e velocità di risposta.

I sistemi ROLAP eseguono un’estrazione e un’aggregazione ad hoc dei dati, quindi offrono grande flessibilità di interrogazione (tramite linguaggio SQL) ma basse performance a fronte di basi di dati voluminose. I sistemi MOLAP, grazie a un caricamento dei dati in forma pre-aggregata, garantiscono un tempo di risposta inferiore ma possibilità di analisi pre-determinate dall’impostazione della struttura multidimensionale.

Si assiste a un progressivo avvicinamento delle due tecnologie, che ha dato vita a un insieme di soluzioni intermedie. Tutti i principali produttori di RDBMS hanno aggiunto infatti servizi multidimensionali tramite acquisizioni di aziende o licenze (Oracle con Express, Microsoft con Analysis Services, IBM con DB2 OLAP, ecc.); una volta ottenuti gli schemi ROLAP è possibile quindi passare alla progettazione MOLAP, evolvendo il sistema realizzato ad una nuova architettura più performante per l’analisi dei dati.

46

Figura 2.13 Comparazione delle principali soluzioni tecniche


2.5.1 Rappresentazione relazionale di un Data WarehouseIn una realizzazione ROLAP i dati di un fatto multidimensionale sono organizzati secondo una struttura relazionale detta schema a stella o star schema.

Lo schema a stella ha una struttura composta da: una entità principale, detta tabella dei fatti o fact table, che

memorizza le istanze di un fatto; varie entità ausiliarie, chiamate tabelle dimensione o dimension

tables, che memorizzano i membri della dimensione associati al fatto;

un insieme di vincoli di integrità referenziale, ognuno dei quali collega un attributo della tabella dei fatti a una tabella dimensione.

Un esempio di schema a stella viene riportato in figura 2.4 e corrisponde all’implementazione relazionale del fatto rappresentato dal cubo multidimensionale di figura 2.7 con l’aggiunta di un’ulteriore dimensione (il cliente della vendita).

Lo schema a stella possiede alcune caratteristiche che si possono osservare nella sua struttura. Distinguendo le caratteristiche della tabella dei fatti da quelle delle tabelle dimensioni:

Tabella dei fatti (fact table) generalmente ha una chiave composta da

attributi che sono riferimenti alle chiavi di tabelle dimensione;

contiene attributi (solitamente numerici) che rappresentano le misure del fatto

soddisfa la forma normale di Boyce-Codd.Tabella 2-6: Caratteristiche salienti di una fact table

Tabella dimensione (dimension table) ha una chiave semplice (un solo attributo); gli altri attributi rappresentano i livelli della

Figura 2.14 Uno schema a stella

47

Capitolo 2

dimensione oppure qualche loro proprietà e sono tipicamente testuali o descrittivi;

sono generalmente denormalizzate per motivi di efficienza.

Tabella 2-7 Caratteristiche salienti di una dimension table

Le tabelle dimensione si mantengono generalmente denormalizzate per motivi di efficienza: in questa maniera infatti, pur generando una certa ridondanza, si evitano nelle interrogazioni onerose operazioni di join tra tabelle.

Nel caso in cui si decida di normalizzare (sia pur parzialmente) uno schema a stella per ridurre la ridondanza degli schemi dimensionali, si ottiene una schema che, per la sua conformazione, viene detto schema a fiocco di neve o snowflake schema. Normalizzando (parzialmente) lo schema a stella sopra riportato si ottiene ad esempio lo schema a fiocco di neve di figura 2.15.

In linea generale, la presentazione relazionale di un Data Warehouse può ammettere la presenza di più tabelle contenenti fatti di analisi; in questo caso può essere opportuno analizzare ogni fatto con un diagramma relazionale separato.

2.5.1.1 Considerazioni sul grado di normalizzazioneA livello generale è sconsigliato procedere a normalizzazioni troppo spinte degli schemi a stella, perché generalmente il beneficio che si ottiene in termini di riduzione di spazio non compensa il degrado delle prestazioni che le operazioni di join, necessarie per ricostruire le dimensioni, possono generare.

Bisogna infatti tenere presente che una tabella dei fatti è tipicamente molto più grande (in termini di numero di record) di una tabella dimensione; ne consegue che, anche riducendo fortemente l’occupazione di memoria dovuta ad una tabella dimensione, l’occupazione di memoria complessiva si riduce, in percentuale, piuttosto limitatamente.

Un altro motivo per cui non è consigliato procedere ad una normalizzazione rigorosa delle tabelle dimensione è che gli aggiornamenti sulle dimensioni sono piuttosto rari (rispetto a quelli sulla fact table, che invece sono molto

48

Figura 2.15 Uno schema a fiocco di neve


frequenti); non si deve perciò affrontare in questo contesto il problema delle anomalie di aggiornamento delle relazioni non normalizzate.

Per concludere bisogna dire che, nonostante le considerazioni fatte, è necessario procedere caso per caso alla valutazione del livello di normalizzazione opportuno.

49

Capitolo 2

2.5.1.2 Operazioni su data mart relazionaliCome tutti i data warehouse server, i sistemi ROLAP offrono strumenti di analisi evoluti che presentano un data mart all’utente finale (l’analista) secondo un modello di rappresentazione di alto livello come quello multidimensionale. Questi strumenti trasformano poi le interrogazioni multidimensionali descritte nel paragrafo 2.3.2 in istruzioni SQL sullo schema a stella del data mart in questione.

Per esempio, l’operazione multidimensionale di roll-up si traduce in una interrogazione SQL del tipo:

select D1.L1, …, Dn.Ln, Aggr1(F.M1), …, Aggrk(F.Mk)from Fatti as F, Dimensione1 as D1, …, DimensioneN as Dnwhere join-predicate (F,D1) and … and join-predicate(F,Dn) and selection-predicate(F)group by D1.L1, …, Dn.Lnorder by D1.L1, …, Dn.Ln

In questa interrogazione, Fatti è il nome della tabella dei fatti, Mj è il nome della j-esima misura della tabella Fatti, Di è il nome della i-esima tabella dimensione, Li è il nome del livello della i-esima tabella dimensione rispetto al quale si vuole fare il roll-up, Aggrx indica una funzione aggregativa (per esempio sum), join-predicate (F,Di) indica la condizione di join che lega la tabella dei fatti e la i-esima tabella dimensione, infine selection-predicate (F) indica una eventuale condizione di selezione sulle tabelle dimensione.

La frequenza dell’uso delle aggregazioni nel contesto di operazioni OLAP ha suggerito l’introduzione nello standard SQL di un operatore detto data cube, che effettua tutte le possibili aggregazioni su una tabella basate sugli attributi di raggruppamento specificati. Si ha quindi un’espressione (linea 5 dello statement precedente):

group by cube (D1.L1, …, Dn.Ln)

che calcola le aggregazioni su tutte le possibili combinazioni di attributi presenti nella clausola group by cube; nel calcolare le aggregazioni, viene utilizzato il valore polimorfo ALL, che (come NULL) è presente in tutti i domini e corrisponde all’insieme di tutti i possibili valori presenti nel dominio.

Poiché la complessità della valutazione del data cube cresce in modo combinatorio col crescere del numero degli attributi di raggruppamento, è stata introdotta una diversa estensione di SQL in cui le aggregazioni sono progressive rispetto all’ordine degli attributi di raggruppamento: in questo modo le aggregazioni da calcolare crescono solo linearmente col crescere del numero di tali attributi. Tale estensione richiede la clausola rollup, che sostituisce la clausola cube (linea 5 dello statement precedente):

group by rollup (D1.L1, …, Dn.Ln)

Le clausole cube e rollup sono presenti in molti DBMS commerciali, anche se in forme diverse da quanto suggerito nello standard, per permettere di

50


effettuare semplici operazioni OLAP anche non disponendo di sistemi dedicati all’analisi dei dati.

51

Capitolo 2

2.6 Passaggio da un DB relazionale ad uno dimensionale (Data Warehouse)

Le fasi necessarie al design di una base dati dimensionale a partire da una singola sorgente informativa sono le seguenti:

i) individuazione dei fatti e delle dimensioni;ii) design delle fact tables;

iii) design delle dimension tables;iv) ristrutturazione dello schema concettuale;v) progettazione logica e fisica.

Tale procedimento richiede la specifica di almeno due tipologie di informazioni in ingresso: i requisiti e la descrizione della base dati.

I requisiti sono una descrizione, solitamente in linguaggio naturale o semi-strutturato, delle esigenze aziendali di analisi.

La descrizione della base dati comprende la struttura formale della base dati operativa disponibile accompagnata da una documentazione sufficiente per la sua comprensione (per esempio un glossario aziendale dei termini). Inoltre, spesso accade che l’analisi dei dati della realtà aziendale di interesse richieda (o debba essere predisposta) per la correlazione di tali dati con altri dati non di proprietà dell’azienda o generati da altri processi aziendali: è necessaria allora una descrizione anche degli schemi di tali sorgenti.

Una volta definiti i requisiti aziendali di analisi e analizzate le sorgenti informative di interesse, si può procedere alla definizione dei fatti e delle dimensioni.

Definizione dei fatti: è necessario individuare le transazioni che gestiscono i fatti chiave del business e le relative tabelle.

Definizione delle dimensioni: richiede di individuare le entità che descrivono gli aspetti secondo cui i fatti strategici verranno analizzati (temporali, geografici, tipologici, ecc.). E’ inoltre importante decidere con quale granularità minima ogni dimensione supporterà le query.

Nella fase di design delle tabelle dei fatti e delle dimensioni si eseguono delle azioni volte all’ottimizzazione della struttura dimensionale. Nel caso delle fact tables si mira principalmente a minimizzare l’occupazione on-line (cpu, memoria) e off-line (storage) del DW, mentre per quanto riguarda le dimension tables è importante aumentare le performance delle query di ricerca, minimizzando il numero di join. Alcune regole che possono essere seguite nella progettazione delle tabelle dei fatti e delle dimensioni sono riportate nelle tabelle seguenti.

DESIGN DELLE FACT TABLES riduzione del numero di colonne della tabella, eliminando ogni

campo superfluo ed i campi calcolati (dopo aver fatto un bilancio del tempo necessario a rigenerare in futuro i campi calcolati nelle query)

definizione del data type adatto ad ogni colonna (criterio della

52


minor occupazione) identificazione delle chiavi esterne relazionate a tabelle

dimensionali archivio dei dati storici (o con livello di dettaglio diverso) in

tabelle differentiTabella 2-8: Progettazione di fact tables

DESIGN DELLE DIMENSION TABLES definizione della granularità minima raggruppamento delle informazioni dimensionali in singole

tabelle, ciascuna contenente una sola dimensione identificazione dei livelli gerarchici denormalizzazione in 2a forma normale (a seguito di

considerazioni prestazionali) aggiunta di attributi dimensionali non presenti nella base dati

originaria ma da essa deducibili (in base ai requisiti di analisi)Tabella 2-9: Progettazione di dimension tables

L’introduzione di elementi dimensionali nella base dati porta a una ristrutturazione dello schema concettuale operazionale, attraverso la rappresentazione di fatti mediante entità, l’individuazione di nuove dimensioni (nuove tabelle) e il raffinamento dei livelli di ogni dimensione. Lo schema concettuale risultante è uno star schema (oppure uno snowflake schema) che costituisce lo schema concettuale del data warehouse.

Lo schema così ottenuto può essere implementato in un RDBMS attraverso una piattaforma (ad esempio Microsoft SQL Server) che offra servizi per l’analisi multidimensionale dei dati.

Il popolamento del DW avviene con dati provenienti da uno o più DB aziendali tramite un sistema di alimentazione (par. 2.2.2.2); si utilizzano strumenti di ETL (Extract, Transform, Load) per svolgere operazioni quali:

estrazione dei dati dalla/e sorgente/i validazione dei dati e data cleaning migrazione dei dati (eventuale) riformattazione di alcuni attributi caricamento dei dati nel DW.

Quest’ultimo in particolare avviene tipicamente in modo incrementale e con una periodicità da stabilire in base ai requisiti di analisi (ogni giorno, ogni settimana, ogni mese, ecc.).

Nel caso più generale di progettazione di un data warehouse a partire da più sorgenti informative, la metodologia di sviluppo è più complessa e comporta più passaggi, in quanto si tratta di integrare concettualmente gli schemi di più sorgenti e successivamente introdurvi elementi dimensionali (il procedimento completo è riportato in figura 2.16).

Le tecniche per la definizione e il design di fact tables e dimension tables da utilizzare per la costruzione dello schema dimensionale rimangono comunque quelle sopra esposte.

53

Capitolo 2

54


Figura 2.16 Una metodologia di sviluppo di Data Warehouse

55

Data Warehouse per l’analisi dei guasti

3. Data Warehouse per l’analisi dei guastiBasandosi sui concetti dei precedenti capitoli è ora possibile presentare il Data Warehouse che si è realizzato. Nel trattare le varie fasi del progetto si descriveranno, seppur brevemente, alcune caratteristiche degli strumenti utilizzati e si indicherà come i concetti teorici esposti trovino applicazione nel software di sviluppo.Il Data Warehouse è stato realizzato a partire da una sorgente dati relazionale e, al livello di sviluppo raggiunto, non si è ritenuto utile realizzare più Data Mart distinti; ciò potrebbe invece essere il risultato di un futuro arricchimento dell’applicazione realizzata.Si è scelto di impiegare la piattaforma Microsoft SQL Server 2005 e il relativo pacchetto di Analysis Services, nel seguito brevemente descritti per quanto riguarda le principali funzioni utilizzate.Il motore di database di Microsoft SQL Server 2005 ha consentito di creare e gestire la base di dati di tipo relazionale per il popolamento del Data Warehouse. Per la realizzazione delle strutture multidimensionali OLAP si è fatto uso di SQL Server Analysis Services 2005 (SSAS) sviluppando un progetto con SQL Server Business Intelligence Development Studio. Infine si è utilizzato Microsoft Excel 2003 come client per realizzare alcune interrogazioni sul Data Warehouse, che si presentano nel capitolo successivo.

3.1 Scopo del progettoLo scopo di questo progetto di Data Warehousing è molteplice:

consentire un’analisi flessibile e personalizzabile dei dati presenti nel Data Warehouse, in modo che questi risultino “navigabili” in base alle esigenze;

presentare i dati in forma chiara ed efficace anche a utenti non specialisti, attraverso forme che siano strumenti trasversali di comunicazione all’interno dell’organizzazione;

ottimizzare le performance di interrogazione, anche nel caso in cui quest’ultima (come spesso accade per le esigenze di analisi trattate nel progetto) coinvolge grandi moli di dati.

Per la realizzazione di questi obiettivi si è fatto ricorso alla modellizzazione multidimensionale (par. 2.4), in particolare attraverso le fasi necessarie ad una sua implementazione relazionale (par. 2.6).

3.2 Microsoft SQL Server 2005Microsoft SQL Server 2005 è una piattaforma completa per la gestione di database mediante strumenti integrati di Business Intelligence (BI). Sviluppato a partire dalle caratteristiche di SQL Server 2000, SQL Server 2005 si contraddistingue per la stretta integrazione con Microsoft Visual Studio, Microsoft Office System e una serie di nuovi strumenti di sviluppo, compreso Business Intelligence Development Studio. Nello schema seguente è riportato il layout della piattaforma dati SQL Server 2005.

56

Capitolo 3

Per lo sviluppo del progetto è stato utilizzato Microsoft SQL Server 2005 Standard Edition; la procedura di installazione è integrata e installa i seguenti componenti:

Motore di database relazionale SQL Server Integration Services Analysis Services Reporting Services SQL Server Management Studio (set di strumenti per la gestione di

database) Business Intelligence Development Studio (set di strumenti per lo

sviluppo di applicazioni BI).

SQL Server 2005 offre una piattaforma end-to-end per la Business Intelligence, con funzionalità OLAP (On Line Analytical Processing), di reporting, data mining, data warehousing, oltre a strumenti ETL per l’estrazione, la trasformazione e il caricamento dei dati.Nella tabelle seguente è riportata una panoramica sui componenti di un sistema di BI e sui componenti Microsoft SQL Server 2005 corrispondenti.

Componente SQL Server 2005Estrazione, trasformazione e caricamento

SQL Server Integration Services

Data warehouse relazionale

Database relazionale SQL Server 2005

Database multidimensionale

SQL Server Analysis Services

Data mining SQL Server Analysis ServicesReport gestiti SQL Server Reporting ServicesReport ad hoc SQL Server Reporting ServicesQuery e analisi ad hoc Prodotti Microsoft Office (Excel, Office Web

Components, Data Analyzer, SharePoint Portal)

Strumenti di sviluppo database

SQL Server Business Intelligence Development Studio

Strumenti di gestione database

SQL Server Management Studio

Tabella 3-10: Componenti BI in SQL Server 2005

Due nuovi componenti di SQL Server 2005 sono SQL Server Management Studio e SQL Server Business Intelligence Development Studio; gli altri componenti BI principali sono sostanzialmente un’evoluzione di quelli presenti in SQL Server 2000.

Figura 3.1 Componenti principali di SQL Server 2005

57


Secondo Microsoft (http://www.microsoft.com), la piattaforma dati SQL Server 2005 fornisce alle organizzazioni (indipendentemente dalle dimensioni) i seguenti vantaggi:

massimo sfruttamento del patrimonio di dati, grazie a funzionalità incorporate di report, analisi e data mining;

aumento della produttività, grazie a funzionalità di BI complete e all’integrazione con strumenti comuni quali Microsoft Office System, che permettono di disporre di informazioni aggiornate e adeguate alle esigenze di analisi in tempi brevi;

semplificazione del settore IT attraverso un ambiente di sviluppo flessibile per gli sviluppatori di applicazioni analitiche e settoriali, e strumenti di gestione integrati per gli amministratori di database;

riduzione del costo totale di proprietà (TCO – Total Cost of Ownership), poiché l’approccio integrato comporta costi più bassi nelle fasi iniziali, di implementazione e di gestione, a fronte di un rapido rendimento dell’investimento sul database.

58

Capitolo 3

In uno studio dell’Aprile 2007 Gartner Group ha valutato Microsoft e altri vendors leader di settore per le piattaforme BI secondo una “Business Intelligence Platforms Capability Matrix” (par. 2.1.1). I punteggi ottenuti dalla piattaforma Microsoft sono riportati di seguito (per i risultati completi di tutti i vendor e le modalità di indagine si rimanda a Gartner Research: “Business Intelligence Platforms Capability Matrix” – ID Number: G00146865, Pubblication Date: 23/04/2007).

VENDOR = MicrosoftArea Capability Gartner Evaluation

Information Delivery

Reports

Dashboards

Ad Hoc Query

Microsoft Office Integration

Integration

Infrastructure

Metadata

Development

Workflow and Collaboration

Analysis

OLAPVisualization

Predictive Modeling

Scorecards

All’inizio del 2008, Gartner Group ha pubblicato un altro studio nel quale i maggiori vendor nel mercato di piattaforme BI sono stati posizionati all’interno di un quadrante strategico, valutandone anche la direzione di sviluppo (per i dettagli dello studio si rimanda a Gartner Research: “Magic Quadrant for Business Intelligence Platforms, 2008” – ID Number: G00154227, Pubblication Date: 01/02/2008). I punti di forza che hanno permesso alla piattaforma BI di Microsoft di posizionarsi nei leader di mercato sono, secondo Gartner, l’integrazione con i prodotti Office e SQL Server, la convenienza economica, la qualità dei tool di sviluppo, oltre che una solida base di partner per i prodotti BI.

Tabella 3-11: Business Intelligence Capability Matrix per Microsoft (Gartner Group)

Figura 3.11 Magic Quadrant for BI Platforms, 2008

59


60

Capitolo 3

3.3 Importazione della base di datiLa sorgente dei dati per il Data Warehouse consiste in un database sviluppato con Microsoft Access 2003 (capitolo 1), in cui sono contenuti tutti i dati di interesse per lo sviluppo dell’applicazione OLAP.

Per l’importazione dei dati è stato utilizzato Microsoft SQL Server Migration Assistant for Access (SSMA), un tool per la migrazione di database Access (versioni dalla 1997 alla 2003) a Microsoft SQL Server 2005. SSMA converte gli oggetti di un database Access in oggetti di SQL Server, carica tali oggetti in SQL Server e infine migra (copia) i dati da Access a SQL Server. Se necessario, è possibile linkare le tabelle Access alle tabelle in SQL Server, così da continuare a utilizzare Access come applicazione front-end.

Per usare SSMA è necessario installarlo in un computer che abbia accesso sia al database di cui si desidera eseguire l’upsize, sia all’istanza SQL Server di destinazione. Il software è scaricabile gratuitamente dal sito web della Microsoft; la versione utilizzata è la 1.0.

Per iniziare la migrazione è sufficiente avviare SSMA Migration Wizard (fig. 3.3), che guida l’utente nei seguenti passaggi:

1. creazione di un nuovo progetto SSMA;2. aggiunta di un database Access al progetto appena creato;3. selezione degli oggetti per la migrazione;4. connessione a SQL Server;5. link delle tabelle Access alla tabelle in SQL Server (opzionale);6. conversione degli oggetti, caricamento nel database e migrazione

dei dati.

Figura 3.12 SSMA Migration Wizard

61


La prima operazione richiesta dal Wizard è quella di assegnare un nome e una locazione al nuovo progetto SSMA. Al passo successivo si ha la possibilità di selezionare il database di cui si desidera effettuare la migrazione; a questo punto il software pre-carica tutti gli oggetti presenti nel database e quindi richiede di selezionare gli oggetti che si vogliono caricare in SQL Server (di default sono selezionate tutte le tabelle e deselezionate tutte le query).

Nel caso specifico, sono state selezionate tutte e sole le tabelle necessarie all’implementazione del modello multidimensionale per l’analisi OLAP; vengono mantenuti automaticamente anche gli indici e le chiavi creati per ogni tabella.

Successivamente si selezionano il server e il database di destinazione, oltre al tipo di autenticazione (Windows Authentication oppure SQL Server Authentication); se il database specificato non esiste, si ha la possibilità di crearlo a runtime.

Al passo successivo viene richiesto se si desidera linkare le tabelle Access alle tabelle in SQL Server; l’effetto del linking è quello di far sì che tutte le pagine di accesso ai dati nell’applicazione Access si riferiscano ai dati presenti nel server. Non si è utilizzata questa opzione, in quanto l’automatizzazione del processo di alimentazione del Data Warehouse esula dagli scopi di questo specifico progetto.

62

Figura 3.13 Finestra di selezione degli oggetti per la migrazione

Capitolo 3

Nell’ultima fase SSMA esegue, nell’ordine, le operazioni di conversione, caricamento e migrazione (fig. 3.5); durante l’esecuzione compare una barra di stato che indica la percentuale progressiva di completamento del processo e, per ogni operazione conclusa, vengono indicati il numero di errori, di warning e di messaggi informativi generati. Questa fase si conclude con successo se tutte le operazioni sono completate senza errori.

E’ inoltre possibile accedere a due tipi di report generati da SSMA: il primo riguardante le statistiche di conversione e una categorizzazione degli oggetti convertiti (fig. 3.6), il secondo riportante i dettagli di migrazione per ogni singola tabella (nome assegnato in SQL Server, numero righe totali, numero righe migrate e percentuale di righe migrate).

Figura 3.14 Conversione, caricamento e migrazione del database con SSMA

Figura 3.15 Report SSMA per la conversione effettuata

63


A partire dal report in figura è anche possibile visualizzare il contenuto di Warning e Information Message generati nella fase di conversione. In questa fase infatti SSMA esegue automaticamente delle modifiche degli oggetti di origine qualora questi presentino caratteristiche che non permetterebbero la loro importazione in SQL Server, alleggerendo così le difficoltà che si incontrerebbero nella fase di upsize.

Ad esempio Access supporta chiavi primarie che ammettono valori NULL, invece SQL Server non permette una tale configurazione (verrebbe quindi bloccato il processo di importazione): SSMA invece assegna di default il vincolo NOT NULL per tutti i campi che sono chiave primaria, generando un warning. Similmente avviene per i nomi di oggetti Access che includono spazi o caratteri speciali: SSMA si preoccupa di racchiudere tali nomi tra parentesi quadre ([ ]).

Anche gli Information Message documentano operazioni svolte da SSMA durante la conversione; alcune delle più frequenti sono:

conversione del flag “Zero-length-not-allowed”; creazione del campo Timestamp (un campo di sistema per il quale

SQL Server genera valori che servono ad identificare univocamente ogni record di un database in un determinato stato);

avviso di mancata conversione delle relazioni per cui non è implementata l’integrità referenziale.

Durante il processo di conversione SSMA si occupa anche di gestire il “data type mapping” da Access a SQL Server. La tabella presenta la mappatura di default tra i tipi di dati migrati dal motore Jet 3.5 o 4.0 (Access) a SQL Server 2005.

Jet 3.5 o 4.0 SQL Server 2005TEXT(size) nvarchar(size)

varchar(size)*MEMO nvarchar(max)

varchar(max)*BYTE tinyintINTEGER smallintLONG INTEGER integerSINGLE realDOUBLE floatDECIMAL floatGUID uniqueidentifierDATE datetimeCURRENCY moneyYES/NO bit/tinyintLONGBINARY varbinary(max)BINARY(size) varbinary(size)* Jet 3.5

Tabella 3-12: Data type mapping

Il risultato ottenuto in questa prima fase è la creazione di due file:

64

Capitolo 3

un file con estensione *.mdf (SQL Server Database Primary Data File) che contiene gli oggetti e i dati presenti nella base dati Access sorgente;

un file con estensione *.LDF (SQL Server Database Transaction Log File) contenente le transazioni.

A questo punto è possibile connettersi al Database Engine di SQL Server Management Studio per accedere ai dati contenuti nella sorgente relazionale del Data Warehouse, che è stata rinominata “DW Rientri Utenza”.

E’ possibile utilizzare il linguaggio SQL per effettuare interrogazioni sui dati e accedere in modifica alle proprietà degli oggetti creati con l’importazione (fig. 3.7).

Attraverso la finestra Database Properties di DW Rientri Utenza è possibile impostare diversi tipi di proprietà, quali il nome del database, il nome e il percorso del file di dati e del file di log, fino alle definizione dei ruoli e dei permessi e alla configurazione del mirroring.

65


Figura 3.7 Database Engine di SQL Management Studio

66

Capitolo 3

3.4 SQL Server Analysis Services 2005Microsoft SQL Server Analysis Services (SSAS) permette la condivisione e la gestione dei database multidimensionali e fornisce funzionalità di elaborazione analitica in linea (OLAP) e di data mining mediante una combinazione di tecnologie client e server, ulteriormente potenziata tramite l’utilizzo di un ambiente di sviluppo e gestione specializzato, associato a un modello di oggetti ben definito per la progettazione, la creazione, la distribuzione e la manutenzione delle applicazioni di Business Intelligence.

3.4.1 Architettura di Analysis ServicesAnalysis Services utilizza componenti server e client per offrire funzionalità di OLAP e di data mining per le applicazioni di Business Intelligence. Il protocollo nativo di Analysis Services è XML for Analysis (XMLA); sono disponibili svariate interfacce di accesso ai dati per le applicazioni client, ma tutti questi componenti comunicano con un’istanza di Analysis Services tramite XML for Analysis.

Il componente server di Microsoft SSAS è l’applicazione “msmdsrv.exe”, che è costituita da componenti di protezione, un componente listener XLM for Analysis (che gestisce tutte le comunicazioni XMLA tra Analysis Services e i relativi client), un componente di elaborazione delle query e numerosi altri componenti interni che svolgono le funzioni di:

analisi di istruzioni ricevute dai client; gestione di metadati; gestione di transazioni; elaborazione di calcoli; archiviazione di dati relativi a dimensioni e celle; creazione di aggregazioni; pianificazione di query; memorizzazione di oggetti nella cache; gestione di risorse del server.

Il motore di calcolo di Analysis Services è basato interamente sul server, pertanto tutte le query vengono risolte nel server; per ogni query è quindi necessario un solo round trip tra il client e il server, il che significa che le prestazioni sono scalabili all’aumentare della complessità delle query.

I comandi di query possono essere eseguiti tramite i linguaggi SQL, MDX (Multidimensional Expressions) o DMX (Data Mining Extensions). Analysis Services supporta inoltre un motore di cubi locali, che consente alle applicazioni su client senza connessione di esplorare dati multidimensionali archiviati localmente.

Con Analysis Services vengono forniti svariati provider per il supporto di diversi linguaggi di programmazione. Un provider comunica con un server Analysis Services mediante l’invio e la ricezione di XMLA in pacchetti SOAP, attraverso il protocollo TCP/IP oppure HTTP (tramite IIS, Internet Information Services).

67


Analysis Services inoltre è dotato di un’architettura Web con un livello intermedio scalabile (che ne consente la distribuzione in organizzazioni sia di grandi che di piccole dimensioni) e offre un esteso supporto del livello intermedio per servizi Web (le applicazioni ASP sono supportate tramite OLE DB per OLAP e ADO MD, mentre le applicazioni ASP.NET sono supportate tramite ADOMD.NET).

68

Capitolo 3

3.4.2 Modello UDM (Unified Dimensional Model)Analysis Services combina i vantaggi dell’analisi tradizionale basata su OLAP e della creazione di report basata su modelli relazionali, consentendo agli sviluppatori di definire un unico modello di dati, denominato modello UDM (Unified Dimensional Model), per una o più origini dei dati fisiche. Tutte le query degli utenti finali provenienti da applicazioni OLAP e di Business Intelligence personalizzate accedono ai dati nell’origine dei dati sottostante tramite il modello UDM, che offre una singola visualizzazione aziendale dei dati relazionali.

Figura 3.8 Architettura di Analysis Services

69


70

Figura 3.9 Funzione del modello UDM

Capitolo 3

Il ruolo di un modello UDM è quello di fungere da “bridge” tra l’utente e le origini dei dati (fig. 3.9). Un modello UDM viene creato sulla base di una o più origini dei dati fisiche e l’utente finale esegue le query sul modello UDM, utilizzando svariati strumenti client (ad esempio Microsoft Excel). Tuttavia esistono vantaggi anche quando il modello UDM viene creato solo come livello sottile sull’origine dei dati: un modello dei dati più semplice e comprensibile, l’isolamento dall’origine dei dati back-end e un miglioramento delle prestazioni per le query che comportano riepiloghi delle informazioni.

Il modello UDM consiste nella definizione di un insieme di cubi e dimensioni per costruire un modello dimensionale a partire da quello relazionale, definito nel server. La struttura dati così definita costituisce un archivio di metadati; in SQL Server 2000 l’archivio di metadati veniva fornito come database Microsoft Access, mentre con Analysis Services 2005 le informazioni sui metadati sono memorizzate come file XML e gestite da Analysis Services stesso.

Per quanto riguarda i componenti per lo sviluppo di applicazioni di Business Intelligence forniti con Microsoft SQL Server 2005, è consigliato utilizzare Business Intelligence Development Studio per sviluppare e SQL Server Management Studio per utilizzare e gestire gli oggetti di database BI.

3.5 Progettazione del modello multidimensionale per il Data Warehouse

In questa fase si sono identificati, a partire dallo schema relazionale transazionale (par. 1.2.9), i fatti, le dimensioni e le misure da introdurre nello schema dimensionale per il Data Warehouse. Con riferimento alle dimensioni, si sono individuate le gerarchie da rendere disponibili per le elaborazioni analitiche, specificando se gli attributi costituenti una data gerarchia fossero attributi dimensionali già presenti nell’origine dati oppure attributi da essa deducibili.La progettazione del modello multidimensionale svolta non ha coinvolto la totalità degli oggetti presenti nella base dati di partenza, poiché non tutti risultavano utili ai fini dell’elaborazione analitica proposta, pur essendo gestiti dall’applicazione transazionale (es: spedizioni al fornitore).La progettazione del modello multidimensionale si è conclusa con la definizione di una ristrutturazione dello schema relazionale da eseguire nella sorgente dei dati per l’applicazione OLAP da realizzare.

Negli sviluppi futuri dell’applicazione potrebbero essere considerate altre sorgenti di dati nella definizione del modello UDM (par. 3.4.2), per cui i fatti, le misure e le dimensioni del modello multidimensionale di seguito esposto potrebbero subire estensioni.

3.5.1 Fatti nel modello multidimensionaleNel modello multidimensionale, un fatto è un concetto del sistema informativo considerato sul quale ha senso svolgere un processo di analisi orientato al supporto alle decisioni (par. 2.4.1).

71


Per la realizzazione dell’applicazione OLAP qui trattata, il fatto aziendale di interesse per l’elaborazione analitica consiste nell’analisi effettuata dal laboratorio su un sottoassieme di prodotto finito (elettrodomestico) rientrato dall’utenza in seguito ad una sostituzione.

L’analisi di un insieme di istanze di questo fatto (eventi) è di supporto al processo decisionale, in quanto consente di intraprendere azioni correttive e preventive per il miglioramento della qualità del prodotto.

72

Capitolo 3

3.5.2 Misure nel modello multidimensionaleUna misura è una proprietà atomica di un fatto di interesse per l’analisi ed è tipicamente costituita da un attributo numerico del fatto o da un conteggio delle sue istanze (par. 2.4.1).

La misura considerata nell’applicazione OLAP realizzata è il conteggio delle istanze del fatto; essa, per gli scopi dell’applicazione, è totalmente additiva.Il fatto considerato possiede tuttavia degli attributi numerici, ma per tali attributi non vale la proprietà di additività (né di semiadditività, par. 2.4.2) e quindi non ha senso che siano considerati come misure.

3.5.3 Dimensioni nel modello multidimensionaleLe dimensioni corrispondono alle prospettive secondo cui può essere analizzato un fatto; si è visto inoltre come le dimensioni possano essere organizzate in gerarchie di livelli di aggregazione, corrispondenti a diversi livelli di dettaglio (par. 2.4.1).

Nel realizzare il modello multidimensionale per il Data Warehouse dei rientri utenza si sono individuate dimensioni di analisi a partire da diversi elementi dello schema transazionale di partenza (par. 1.2.9):

alcune dimensioni di analisi si trovano codificate in tale schema in tabelle di lookup già relazionate alla tabella centrale del fatto; queste dimensioni sono: Fornitore, Mercato, Area, Difetto, Causa Difetto, Famiglia, Componente e Dettaglio Componente, Componente Assistenza Tecnica, Difetto Assistenza Tecnica;

altre dimensioni di analisi sono già presenti nello schema transazionale, ma solo ad un determinato livelli di dettaglio (il più basso); si tratta delle dimensioni temporali, contenute in vari formati nella tabella centrale del fatto: esse riguardano la Data Inserimento, la Matricola del Componente e la Matricola dell’Apparecchiatura (elettrodomestico);

potrebbe inoltre essere utile analizzare il fatto classificando il numero delle sue occorrenze in base a particolari attributi contenuti nella fact table stessa (ad es. l’ultimo errore memorizzato, se disponibile).

Già in fase di analisi dell’applicazione OLTP (par. 1.2.3) sono state individuate alcune gerarchie, in particolare la gerarchia

Famiglia Componente Dettaglio Componenteper descrivere la localizzazione del difetto, e la gerarchia

Difetto Causa Difettoper descrivere la tipologia del difetto riscontrato.

Deve essere inoltre possibile utilizzare le dimensioni temporali a vari livelli di aggregazione (ad es: Anno Mese Giorno) che, anche se non direttamente presenti, sono deducibili a partire dagli attributi del fatto.

73


E’ necessario implementare queste gerarchie nel modello multidimensionale del Data Warehouse al fine di consentire, in fase di analisi, operazioni di roll-up e drill-down lungo vari livelli di aggregazione.

74

Capitolo 3

Alla luce delle considerazioni fatte, i componenti del modello multidimensionale risultano essere quelli riportati in tabella.

Elementi del modello multidimensionale

Oggetti corrispondenti

FATTO Analisi in laboratorio di componenti rientrati dall’utenza

MISURA Conteggio delle istanze del fattoDIMENSIONI Mercato

FornitoreLocalizzazione DifettoTipo DifettoAreaData InserimentoMatricola ComponenteMatricola ApparecchiaturaComponente Assistenza TecnicaDifetto Assistenza Tecnica

GERARCHIE (livello di dettaglio crescente)

Dimensione: Localizzazione Difetto

Famiglia Componente Dettaglio

ComponenteDimensione: Tipo Difetto Difetto

Causa DifettoData Inserimento e Matricola Componente (attributi della fact table)

Anno Trimestre Mese Giorno

Matricola Apparecchiatura (attributo della fact table)

Anno Settimana di

produzione

Tabella 3-13 Elementi dimensionali da introdurre nel Data Warehouse

75


3.6 Ristrutturazione dello schema relazionaleL’implementazione del modello multidimensionale per il Data Warehouse secondo quanto visto nel paragrafo precedente richiede una ristrutturazione dello schema relazionale rispetto a quello utilizzato per l’applicazione di origine dati.

La ristrutturazione si è concentrata in particolare nel raggruppamento in apposite tabelle degli attributi riguardanti tutti i diversi livelli gerarchici di una data dimensione; una tale ristrutturazione è risultata preliminare alla strutturazione delle gerarchie in Analysis Services. Le dimensioni interessate sono state quelle temporali e quelle relative alla Localizzazione e al Tipo di difetto.Si sono infine fatte alcune considerazioni che hanno portato a determinare il livello di normalizzazione opportuno per la rappresentazione relazionale del Data Warehouse.

3.6.1 Dimensioni temporaliPer quanto riguarda le dimensioni temporali si è trattato di creare delle tabelle denormalizzate, contenenti i diversi livelli di dettaglio pre-calcolati a partire dal livello di dettaglio più basso analizzabile (ad es. la data nel formato gg/mm/aaaa).

Per fare questo si è utilizzato un generatore apposito per la dimensione Tempo, disponibile all’indirizzo “http://www.regnecentralen.dk/time_dimension_generator.html”, per generare una tabella contenente tutti i livelli di aggregazione per le date dal 01/01/2000 fino al 31/12/2010 (la tabella comprende quindi una riga per ogni giorno presente in questo intervallo temporale).

Dopo aver impostato alcuni parametri, il generatore è in grado di fornire un file testo contenente la transazione SQL completa per generare una tabella dimension_time che associa ad ogni data compresa nella finestra temporale selezionata (max 10 anni) un insieme di attributi da essa deducibili in base al

76

Figura 3.10 Scomposizioni effettuate dal generatore della dimensione Tempo

http://www.regnecentralen.dk/time_dimension_generator.html

Capitolo 3

calendario, quali ad esempio giorno della settimana (lunedì domenica), settimana (153 a causa degli anni bisestili), mese, stagione, trimestre, semestre e anno, ognuno in vari formati.

A questo punto è sufficiente copiare la transazione ottenuta ed eseguirla come query sul database “DW Rientri Utenza” in SQL Management Studio per aggiungere al database la tabella contenente tutti i livelli gerarchici della dimensione tempo (fig. 3.11).

Figura 3.11 Risultato della transazione generata dal Time Dimension Generator

Poiché gli attributi Data Inserimento e Matricola Componente sono presenti nella tabella del fatto nel formato ‘datetime’, si è deciso di impostare l’attributo Day_Timestamp della tabella appena generata come chiave primaria, in modo da poter creare agevolmente la relazione tra le due tabelle, senza l’aggiunta di ulteriori campi.

Nella fact table è presente una terza dimensione temporale di interesse per l’analisi, data dall’attributo Matricola Apparecchiatura; quest’ultimo è un campo di 8 cifre contenente la matricola di produzione dell’elettrodomestico, in cui la prima cifra (09) indica l’ultima cifra dell’anno di produzione (anni

77


dal 2000 al 2009), mentre la seconda e la terza cifra (0053) indicano la settimana di produzione all’interno dell’anno.

E’ evidente che una tale dimensione non è analizzabile tramite la tabella dimension_time prima creata, in quanto una settimana dell’anno corrisponde (fino) a 7 date complete distinte.

Si è quindi creata una tabella apposita (dimension_week) per permettere di analizzare anche questa dimensione; le istruzioni SQL utilizzate sostanzialmente estraggono un sottoinsieme delle informazioni presenti nella tabella dimension_time.

Istruzioni SQL per la creazione della dimensione SettimanaCREATE TABLE dim_week (Week_Key int not null primary key,Week_Name nvarchar(32) not null,Week_Text nvarchar(32) not null,Week_NumberInYear int not null);

INSERT INTO dim_weekSELECT distinct Week_Key, Week_Name, Week_Text, Week_NumberInYearFROM dbo.dimension_time_weekORDER BY Week_Key, Week_Name, Week_Text, Week_NumberInYear;

La chiave esterna di collegamento a questa dimensione sarà creata direttamente nella vista della sorgente dati nel progetto di Analysis Services sviluppato con Business Intelligence Development Studio (par. 3.7.8.3).

Le tabelle create contengono tutti i livelli di dettaglio necessari all’analisi secondo le varie dimensioni temporali e sono mantenute denormalizzate per motivi di efficienza: sarebbe infatti oneroso dal punto di vista delle performance procedere a calcoli di aggregazione e disaggregazione temporale al momento dell’interrogazione dei dati presenti nel Data Warehouse.

3.6.2 Ristrutturazione della dimensione Localizzazione DifettoLa dimensione Localizzazione Difetto è costituita dai seguenti attributi, in ordine di dettaglio crescente:

Famiglia Componente Dettaglio Componente

il cui significato è stato chiarito al par. 1.2.3.

Per poter strutturare una gerarchia all’interno di una dimensione occorre però che gli attributi coinvolti appartengano tutti ad una stessa tabella (caso de normalizzato, star schema) oppure appartengano a tabelle diverse ma collegate in cascata alla tabella centrale del fatto (caso normalizzato, snowflake schema).

78

Capitolo 3

Per poter creare la suddetta gerarchia all’interno della dimensione Localizzazione Difetto bisogna quindi ristrutturare lo schema relazionale, modificandolo rispetto a quello utilizzato nella sorgente dei dati (par. 1.2.9).

E’ necessario infatti creare un’unica chiave esterna nella fact table che si riferisca alla dimensione Localizzazione Difetto e rendere i vari livelli gerarchici di questa dimensione tutti accessibili mediante una stessa tabella (la dimension table appunto), non mediante tre tabelle di lookup distinte come avviene nella sorgente dei dati.

Sono possibili diverse soluzioni, tra le quali si è scelta quella di creare nella tabella centrale un unico codice parlante, ricavato concatenando i tre codici Famiglia, Componente e Dettaglio Componente (prima utilizzati per il lookup), da utilizzare come chiave esterna verso una tabella dimensione denominata Localizzazione Difetto. Quest’ultima tabella utilizzerà il codice parlante come chiave primaria e, attraverso le parti di tale codice, estrarrà dalle tabelle di lookup le descrizioni relative ai vari livelli gerarchici.

Il codice parlante relativo alla dimensione Localizzazione Difetto è stato chiamato CodiceDifetto ed è stato aggiunto per semplicità direttamente nella tabella centrale del fatto.

Di seguito si riportano le istruzioni SQL utilizzate per questo passaggio di ristrutturazione.

Istruzione SQL per la scrittura del campo CodiceDifetto (codice parlante)UPDATE dbo.tblSchedeRientriSET CodiceDifetto = (case when Famiglia is null then '0' else Famiglia end +'-' +case when Componente is null then '0' else Componente end +'-' +case when DettaglioComponente is null then '0' else DettaglioComponente end);

Istruzioni SQL per la creazione e la scrittura della dimension table LocalizzazioneDifettoCREATE TABLE LocalizzazioneDifetto (CodiceDifetto nvarchar(20) not null primary key,Famiglia nvarchar(3),Componente nvarchar(3),DettaglioComponente nvarchar(3));INSERT INTO dbo.LocalizzazioneDifettoSELECT distinct CodiceDifetto, Famiglia, Componente, DettaglioComponenteFROM dbo.tblSchedeRientriORDER BY CodiceDifetto, Famiglia, Componente, DettaglioComponente;

Infine si sono aggiunte nella tabella Localizzazione Difetto tre colonne relative alle descrizioni, (rispettivamente DescrFamiglia, DescrComponente e DescrDettaglioComponente), che sono state scritte tramite una query di update

79


utilizzando le tabelle di lookup. A titolo di esempio, si riporta l’istruzione utilizzata per la scrittura della colonna DescrFamiglia..

Istruzione SQL per il lookup delle descrizione DescrFamiglia nella dimension tableUPDATE LocalizzazioneDifettoSET DescrFamiglia = (case when Famiglia is null then null else (SELECT dbo.[Dizionario-famiglie].DescrizioneFamigliaFROM dbo.[Dizionario-famiglie]WHERE dbo.[Dizionario-famiglie].CodFamiglia=dbo.LocalizzazioneDifetto.Famiglia)end );

Il risultato è una tabella Localizzazione Difetto composta da un totale di 370 record (fig. 3.13). E’ stata infine creata la relazione tra la tabella del fatto e la tabella Localizzazione Difetto(fig. 3.12), rinforzando l’integrità referenziale.

Figura 3.13 Tabella ristrutturata per l’analisi della dimensione Localizzazione Difetto

3.6.3 Ristrutturazione della dimensione Tipo DifettoLa dimensione Tipo Difetto è costituita dai seguenti attributi, in ordine di dettaglio crescente:

80

Figura 3.12 Impostazione della relazione dimensionale

Capitolo 3

Difetto Causa Difetto

il cui significato è stato chiarito al par. 1.2.3.

Per gli stessi motivi esposti nel paragrafo precedente, si è reso necessario ristrutturare lo schema relazionale per creare un’unica chiave esterna nella fact table di riferimento per la dimensione Tipo Difetto, in modo da rendere i vari livelli gerarchici di questa dimensione tutti accessibili mediante una stessa tabella.

La strategia seguita è del tutto simile a quella utilizzata per la ristrutturazione della dimensione Localizzazione Difetto. Il codice parlante utilizzato in questo caso è stato chiamato CodiceDiagnosi ed è stato aggiunto per semplicità direttamente nella tabella centrale del fatto.

81


Di seguito si riportano le istruzioni SQL utilizzate per questo passaggio di ristrutturazione.

Istruzione SQL per la scrittura del campo CodiceDiagnosi (codice parlante)UPDATE dbo.tblSchedeRientriSET CodiceDiagnosi = (case when Difetto is null then '0' else Difetto end +'-' +case when CausaDifetto is null then '0' else CausaDifetto end);

Istruzioni SQL per la creazione e la scrittura della dimension table TipoDifettoCREATE TABLE TipoDifetto (CodiceDiagnosi nvarchar(20) not null primary key,Difetto nvarchar(3),CausaDifetto nvarchar(3));INSERT INTO dbo.TipoDifettoSELECT distinct CodiceDiagnosi, Difetto, CausaDifettoFROM dbo.tblSchedeRientriORDER BY CodiceDiagnosi, Difetto, Causa Difetto;

Infine si sono aggiunte nella tabella Tipo Difetto due colonne relative alle descrizioni (rispettivamente DescrDifetto e DescrCausaDifetto), che sono state scritte tramite una query di update utilizzando le tabelle di lookup. A titolo di esempio, si riporta l’istruzione utilizzata per la scrittura della colonna DescrCausaDifetto.

Istruzione SQL per il lookup delle descrizione DescrCausaDifetto nella dimension tableUPDATE TipoDifettoSET DescrCausaDifetto = (case when CausaDifetto is null then null else (SELECT dbo.[Dizionario-CausaDifetto].DescrizioneCausaDifettoFROM dbo.[Dizionario-CausaDifetto]WHERE dbo.[Dizionario-CausaDifetto].CodDifetto=dbo.TipoDifetto.Difettoand dbo.[Dizionario-CausaDifetto].CodCausaDifetto=dbo.TipoDifetto.CausaDifetto)end );

Si è ottenuta una tabella Tipo Difetto contenente un totale di 88 diverse associazioni di Difetto e Causa Difetto ed è stata creata la relazione tra la tabella del fatto e la tabella Tipo Difetto, rinforzando l’integrità referenziale.

82

Capitolo 3

83


3.6.4 Rappresentazione relazionale del Data WarehouseLe operazioni di ristrutturazione descritte nei paragrafi precedenti hanno portato ad una struttura a stella per la rappresentazione relazionale del Data Warehouse (fig. 3.14). Tutte le informazioni dimensionali infatti sono direttamente relazionate alla tabella del fatto.Si può osservare come i livelli gerarchici riguardanti la Localizzazione Difetto siano tutti contenuti nell’omonima tabella dimensionale, e non più in tre tabelle di lookup distinte (par. 3.6.2). Una ristrutturazione simile è stata eseguita per la dimensione Tipo Difetto (par. 3.6.3).

Figura 3.14 Rappresentazione relazionale per il DW Rientri Utenza

84

Capitolo 3

3.6.4.1 Considerazioni sul grado di normalizzazioneNon si è ritenuto opportuno procedere ad una normalizzazione dello schema a stella in quanto la tabella contenente il fatto risulta essere di due ordini di grandezza più voluminosa rispetto alle tabelle dimensione (tabella 3-5), quindi la riduzione di occupazione di memoria dovuta alla normalizzazione sarebbe, in percentuale, trascurabile.

Una tale asimmetria nel numero di record è destinata a mantenersi nel tempo, in quanto la tabella del fatto viene aggiornata molto più frequentemente rispetto alle tabelle dimensionali.

Una normalizzazione inoltre richiederebbe la soluzione di almeno due join in fase di query per decodificare completamente un’informazione dimensionale contenuta nella tabella del fatto e ciò penalizzerebbe le prestazioni.

TABELLA N° RECORDCodifica Assistenza Tecnica ≈ 100Componenti Assistenza Tecnica

≈ 100

Localizzazione Difetto ≈ 400Tipo Difetto ≈ 100Area 5Mercato ≈ 50Fornitori ≈ 100Tempo ≈ 3600Schede Rientri ≈ 15000

Tabella 3-14: Volumi delle tabelle nel DW

85


3.7 Sviluppo del progetto con SSAS 2005

3.7.1 Creazione del progettoE’ possibile definire un progetto di Microsoft SQL Server 2005 Analysis Services (SSAS) in Business Intelligence Development Studio mediante il modello Progetto di Analysis Services (fig. 3.15); verrà aperto un progetto modello in cui è possibile definire origini dei dati, viste origini dati, cubi, dimensioni, ruoli e altri oggetti di Analysis Services.

Figura 3.15 Creazione di un progetto Analysis Services con BI Development Studio

Sia BI Development Studio che SQL Server Management Studio gestiscono progetti organizzati in soluzioni: una soluzione può contenere più progetti e un progetto contiene in genere più elementi. Durante la creazione di un progetto viene generata automaticamente una nuova soluzione e, se necessario, è possibile aggiungere ulteriori progetti a una soluzione esistente.

Quando viene creata una nuova soluzione, BI Development Studio aggiunge una directory avente il nome assegnato alla soluzione e crea due file con estensione *.sln e *.suo. Il primo contiene informazioni riguardo la soluzione creata e i progetti che ne fanno parte, il secondo contiene informazioni sulle opzioni impostate dall’utente per lavorare con la soluzione (Visual Studio Solution User Options).

86

Capitolo 3

Dopo essere stato creato, un progetto contiene diverse cartelle, utilizzate per organizzare gli elementi che verranno inclusi nel progetto (fig. 3.16).

3.7.2 Origine dei dati Un’origine dei dati in Microsoft SQL Server 2005 Analysis Services (SSAS) rappresenta una connessione a un’origine dei dati e contiene la stringa di connessione che definisce le modalità di connessione di Analysis Services a un archivio dati fisico tramite un provider.

Per impostare l’origine dati relativa al progetto SSAS si può utilizzare il Data Source Wizard, attivabile dal pannello Solution Explorer cliccando con il tasto destro in corrispondenza della cartella Data Sources. E’ possibile basarsi su una connessione già esistente oppure crearne una nuova; nel secondo caso attraverso la finestra Connection Manager (fig. 3.17) è necessario definire un provider, un server, un database e le modalità di autenticazione al server.

Figura 3.16 Struttura di un progetto Analysis Services

Figura 3.17 SSAS Connection Manager87


88

Capitolo 3

La creazione di un’origine dati si conclude con la costruzione di una stringa di connessione che include informazioni relative a nome del server, database, protezione, timeout e altre informazioni sulla connessione. Per questo progetto è stato assegnato all’origine dati il nome “DW Rientri Utenza”, associato alla seguente stringa di connessione.

Provider=SQLOLEDB.1;Data Source=localhost;Integrated Security=SSPI;Initial Catalog=DW Rientri Utenza

A questo punto, nella cartella relativa al progetto DW Rientri Utenza viene memorizzato anche il file di origine dei dati (<NomeOrigineDati>.ds), contenente gli elementi ASSL (Analysis Services Scripting Language) che definiscono i metadati dell’origine dati associata. Per la realizzazione del progetto di Data Warehouse Rientri Utenza verrà utilizzata un’unica origine dati.

3.7.3 Vista origine datiUna vista origine dati è la definizione dei metadati, in formato XML, degli elementi dello schema utilizzati dal modello UDM (Unified Dimensional Model, par. 3.4.2) ed ha le seguenti caratteristiche:

può essere creata a partire da una o più origini dei dati (questo consente la definizione di oggetti OLAP che integrino i dati di più origini);

può contenere relazioni, chiavi primarie, nomi degli oggetti, colonne calcolate e query non presenti nell’origine dei dati;

non è visibile e non è possibile eseguire query al suo interno tramite applicazioni client.

Una vista origine dati offre flessibilità nella creazione di oggetti in SQL Server 2005 Analysis Services (SSAS), in quanto gli oggetti di database di Analysis Services sono associati agli oggetti logici contenuti nella vista origine dati, anziché direttamente agli oggetti fisici inclusi nell’origine dei dati sottostante.

E’ disponibile in SSAS un Data Source View Wizard per creare viste origine dati; viene richiesto di selezionare l’origine dati corrispondente e poi si ha la possibilità di selezionare gli oggetti del database relazionale che si vogliono includere nella vista.

Per il progetto DW Rientri Utenza sono state selezionate solo le tabelle di interesse per la realizzazione dell’applicazione OLAP, trascurando quelle gestite dal database relazionale solo a fini transazionali (es: spedizioni al fornitore). Per coerenza, si è assegnato anche alla vista il nome “DW Rientri Utenza”.Viene creato quindi nella cartella corrispondente al progetto un file <NomeVistaOrigineDati>.dsv, contenente gli elementi ASSL che definiscono i metadati della vista origine dati.

Sono state definite un’origine dati e una vista di tale origine dati per il progetto DW Rientri Utenza, come si vede nel pannello Solution Explorer (fig.

89


3.18); nel pannello di Design della vista sono raffigurati tutti gli oggetti database inclusi nella vista origine dati.

Figura 3.18 Vista dell’origine dati

90

Capitolo 3

3.7.4 Creazione del cuboUn cubo è un set di dimensioni e misure relative a un Data Warehouse, il cui contenuto viene organizzato in strutture di tipo multidimensionale (par. 2.4). Un cubo corrisponde essenzialmente a un modello UDM (par. 3.4.2) e in Microsoft SSAS viene sviluppato a partire da tabelle e viste modellate in una vista origine dati.

Per creare un nuovo cubo attraverso Cube Wizard, dopo aver specificato la vista origine dati di riferimento, è necessario identificare fatti e dimensioni incluse nella vista (fig. 3.19).

Se tra le tabelle dimensionali si è specificata anche una dimensione temporale, il software richiede di associare ad alcuni livelli di aggregazione temporale predefiniti (ad es. data, mese, anno, ecc.) i corrispondenti attributi della tabella dimensionale. Ciò permette la creazione automatica di una gerarchia temporale con il processamento del cubo; tale gerarchia può essere tuttavia successivamente modificata.

In base alla fact table precedentemente identificata (fig. 3.19), la procedura di creazione del cubo richiede di selezionare le relative misure di interesse per l’analisi; il programma propone automaticamente, come possibili scelte, gli attributi numerici presenti nella fact table e il conteggio delle sue istanze; alla luce dei componenti del modello multidimensionale precedentemente individuati (par. 3.5), è stata selezionata solo questa seconda possibilità.

La struttura iniziale del cubo, definita con la creazione guidata , può essere successivamente modificata attraverso appositi tool disponibili in SSAS.

Figura 3.19 Passaggio intermedio nella creazione di un cubo

91


Una volta specificati la tabella del fatto sorgente, la misura da utilizzare e le dimensioni, il cubo è stato logicamente definito e vengono creati diversi file (*.cube, *.dim, *.partitions) nella directory del progetto, contenenti i metadati della struttura. In questo caso, il Data Cube corrisponde a uno schema a stella, in cui la tabella del fatto viene visualizzata nell’editor grafico in blu e le tabelle dimensioni in giallo.

Figura 3.20 Fatto (giallo) e dimensioni (blu) del cubo

Il cubo però fisicamente ancora non esiste; esso è stato solo logicamente definito e memorizzato nei repository dei metadati di Analysis Services (file XML). Per organizzare fisicamente i dati contenuti nel cubo secondo la struttura multidimensionale definita è necessario processare il cubo e le sue dimensioni.

Il processamento degli oggetti in un’istanza di Analysis Services consente di copiare i dati dalla sorgente dei dati sottostante al Data Cube (par. 3.7.7).

Quando Microsoft SSAS processa una dimensione, tutti i diversi valori per quella dimensione nella tabella sottostante vengono riconosciuti come possibili membri per la dimensione; per non incontrare errori nel processamento è necessario specificare come gestire la presenza di membri non definiti (Unknowm Member) per una dimensione (par. 3.7.5). Nella fasi di design del cubo e raffinamento della struttura multidimensionale è possibile inoltre definire il tipo di relazione tra fact table e dimension table e raffinare l’organizzazione delle dimensioni .

92

Capitolo 3

3.7.5 Design del cuboUna volta definita la struttura logica del cubo (par. 3.7.4), è opportuno rivederne e raffinarne il design prima di passare al suo processamento.

Attraverso la scheda Dimension Usage del Cube Designer è possibile rivedere la struttura del cubo creato, e in particolare le dimensioni associate a ogni misura definita per il cubo. Infatti, quando per un cubo sono definiti più gruppi di misure, ogni dimensione può essere utilizzata per l’analisi di alcune misure, non obbligatoriamente tutte. Nel cubo DW Rientri Utenza, invece, tutte le dimensioni definite servono all’analisi del conteggio delle istanze del fatto.

La finestra di definizione delle relazioni (fig. 3.21) permette di impostare le proprietà della relazione tra fact table e dimension table. Per il Data Cube definito nel paragrafo precedente sono state utilizzate tutte relazioni di tipo Regular, il che significa che la tabella dimensione è direttamente collegata alla tabella del fatto (siamo infatti in presenza di uno star schema). La granularità della dimensione è sempre impostata al livello più basso e, nella parte inferiore della finestra, sono specificate le colonne che partecipano alla relazione.

Attraverso il pulsante Advanced è possibile definire il tipo di processamento per i membri della dimensione non specificati (Unknown Member). Se infatti tra la tabella del fatto e la tabella dimensione sussiste un legame del tipo left join, può accadere che non sempre i valori di un membro siano definiti; è importante quindi gestire i valori NULL in modo da includerli nell’analisi, poiché anch’essi sono fonte di informazione. Inoltre se le impostazioni per il processamento di questi valori non sono coerenti il Deployment fallisce.

Figura 3.21 Impostazioni di una relazione dimensionale

93


A questo proposito, nella finestra Measure Group Bindings è possibile definire il tipo di Null Processing (fig. 3.22).

94

Capitolo 3

Nel progetto DW Rientri Utenza si è voluto gestire i valori NULL come membri della dimensione (in presenza di left join) e quindi si è selezionata l’opzione Unkown Member; per non provocare errori nel Deployment è necessario inoltre aprire il Designer per la dimensione relativa (ad es. Dimension Time.dim [Design]) e impostare la proprietà UnknownMember a Visible (di default è settata a None).

Figura 3.22 Livelli gerarchici e Null Processing per la dimensione temporale

95


3.7.5.1 Storage DesignIn questa fase si parla anche di Storage Design, per indicare la necessità di definire e garantire prestazioni di accesso ai dati accettabili attraverso una opportuna struttura fisica del cubo.

In SSAS questo aspetto viene gestito dimensione per dimensione, attraverso un gruppo di proprietà, dette proprietà di Storage della dimensione. Attraverso tali proprietà è possibile impostare le configurazioni relative alla struttura di memorizzazione dei dati e delle aggregazioni, al loro aggiornamento e processamento.

Le strutture fisiche di memorizzazione possibili sono quelle descritte al paragrafo 2.5. Il tradeoff tra ROLAP e MOLAP si ripropone come compromesso tra spazio di memorizzazione e performance di query; scegliere uno storage di tipo MOLAP per una dimensione significa disporre delle aggregazioni precalcolate per i membri di quella dimensione in una struttura MOLAP compressa, mentre scegliere uno storage di tipo ROLAP significa memorizzare solo la definizione della dimensione in una struttura MOLAP, procedendo al calcolo delle aggregazioni per membri al momento della query.

96

Figura 3.23 Impostazioni per la struttura di memorizzazione

Capitolo 3

Per il progetto DW Rientri Utenza la modalità di storage definita per tutte le dimensioni è quella MOLAP (fig. 3.23); si dispone quindi di aggregazioni precalcolate sui dati presenti nel cubo, il cui aggiornamento deve essere avviato manualmente.

97


3.7.6 Impostazioni per il processamento del cuboE’ possibile impostare diverse configurazioni per l’implementazione e il processamento del progetto. Cliccando con il tasto destro sul nome del progetto nel pannello Solution Explorer, attraverso la voce “Properties”, è possibile accedere a tali configurazioni.

In particolare, la proprietà Output Path specifica la locazione in cui verranno salvati gli script XMLA (XML for Analysis) all’implementazione del progetto in una specifica istanza Analysis Services. E’ possibile accedere inoltre alle configurazioni per il processamento (Configuration Properties: Deployment): per il progetto DW Rientri Utenza è stata scelta la modalità di processamento incrementale (Deploy changes only) nell’istanza di default nel computer locale (localhost), mantenendo per le altre impostazioni il valore di default (fig. 3.24).

98

Figura 3.24 Impostazioni per il processamento incrementale del cubo

Capitolo 3

3.7.7 Processamento del cuboPer analizzare i dati contenuti in un Data Cube è necessario processarlo, cioè realizzare ed alimentare la sua struttura a livello fisico.

Quando si processa un cubo, Analysis Services processa automaticamente tutte le sue dimensioni e procede al calcolo delle aggregazioni in base a quanto impostato dal progettista nella fase di configurazione e Storage Design. In questa fase vengono copiati i dati dal database sorgente (strutturato in modo da agevolare questo passaggio) alla struttura dati proprietaria.

Il processamento è stato eseguito selezionando Deploy DW Rientri Utenza dal menù Build.

BI Development Studio esegue il processamento utilizzando uno script e ne visualizza la progressione in due finestre. Nella finestra Deployment Progress vengono visualizzati i vari step eseguiti nel processamento (fig. 3.25), mentre nella finestra Output vengono visualizzate delle informazioni riassuntive.

Espandendo i nodi della finestra Deployment Progress è possibile visualizzare le query eseguite dal software per calcolare i membri di una dimensione a partire dalla sorgente dati relazionale. Ad esempio, per calcolare i membri del

Figura 3.25 Passaggi eseguiti nel Deployment

99


livello Difetto della gerarchia Tipo Difetto il software ha eseguito la query in figura 3.26.

Le tecniche di compressione e indicizzazione avanzate presenti nel software permettono di ottenere un’occupazione ridotta su disco, eliminando in parte il problema della sparsità dei cubi MOLAP (par 2.4.1).

Il processamento può richiedere molto tempo e per questo è necessario calibrare il numero di aggregazioni ottimali nel caso siano richiesti aggiornamenti frequenti (grazie alle configurazioni 3.7.6 verranno processati infatti solo gli aggiornamenti). Nel caso si necessiti di un maggior controllo sulle prestazioni e i tempi di accesso è possibile utilizzare la tecnica del partizionamento dei cubi.

La tecnica del partizionamento separa i dati contenuti in un cubo in memorizzazioni fisiche distinte ed è quindi uno strumento utile per la gestione dei cubi di grandi dimensioni, poiché consente di migliorarne le prestazioni di query nonché di semplificare le operazioni di manutenzione. Le partizioni sono trasparenti agli utenti aziendali del cubo, infatti il Data Cube riflette il contenuto di tutte le partizioni contemporaneamente.

Tuttavia, viste le dimensioni del Data Cube DW Rientri Utenza e le performance ottenute in termini di tempi di risposta, è stata utilizzata una singola partizione per la gestione del cubo.

100

Figura 3.26 Query eseguita dal software per calcolare i membri

Capitolo 3

3.7.8 Raffinamento della struttura multidimensionale

3.7.8.1 Definizione di gerarchieIn seguito ala ristrutturazione dello schema relazionale (par. 3.6.3) è possibile definire delle gerarchie di analisi per le dimensioni Localizzazione Difetto e Tipo Difetto.

Per inserire una nuova gerarchia è sufficiente cliccare due volte sulla rispettiva dimensione nel pannello Solution Explorer e trascinare gli attributi desiderati nell’area Hierarchies and Levels, andando a disporli in ordine di dettaglio crescente. Ad esempio, per la dimensione Localizzazione Difetto è stata creata tramite l’editor grafico la gerarchia a tre livelli di figura 3.27.

Per vedere il risultato della creazione della gerarchia applicato ai dati presenti nel cubo è necessario processare la dimensione Localizzazione Difetto. Una volta concluso il processamento, attraverso il pannello Browser è possibile esplorare il contenuto della gerarchia per controllare se corrisponde all’effetto desiderato.

In figura 3.28 appaiono i membri della dimensione Localizzazione Difetto organizzati secondo la gerarchia appena creata.

Figura 3.28 Browser per la Gerarchia Localizzazione Difetto

Figura 3.27 Gerarchia di localizzazione del difetto

101


Un procedimento del tutto analogo è stato utilizzato per creare la gerarchia relativa al Tipo Difetto, formata da due livelli di dettaglio, Difetto e Causa Difetto.

Poiché entrambe le gerarchie gestiscono membri NULL (par.3.7.5) la lista dei valori assunti dai membri contiene in entrambi i casi il valore “Unknown”, secondo cui saranno conteggiate le istanze del fatto a cui non è stato assegnato un valore per quella dimensione.

3.7.8.2 Modifica della dimensione temporaleIn fase di costruzione del cubo è stata già definita una struttura gerarchica per la dimensione Tempo (par. 3.7.4); tuttavia questa struttura può essere modificata, utilizzando nella gerarchia attributi di più immediata comprensibilità per l’utente.

Ad esempio, è migliore per l’utente una classificazione dei mesi in base al nome piuttosto che in base al loro numero progressivo, oppure una scrittura descrittiva e abbreviata per la data piuttosto che il classico formato gg/mm/aaaa.

Per apportare queste modifiche si è sfruttata la possibilità di creare relazioni tra gli attributi di una dimensione e di utilizzare tali relazioni per l’ordinamento. Dopo aver creato una relazione tra due attributi, è stata modificata la proprietà Order By dell’attributo da utilizzare nella gerarchia.

In questo modo un attributo testuale (ad es. il nome del mese) può essere ordinato in base ad un attributo numerico ad esso relazionato (ad es. il numero del mese), semplicemente settando la proprietà Order By a AttributeKey e specificando nella proprietà Order By Attribute il nome dell’attributo che costituisce il criterio per l’ordinamento. Per tutte le relazioni create inoltre è stata impostata la proprietà Relationship Type a Rigid. Infine è sempre possibile modificare i nomi degli attributi per renderli più “friendly”, senza per questo modificare il nome dell’attributo nella sorgente dati sottostante.

Con il procedimento descritto è stata modificata la dimensione temporale come mostrato in figura 3.29.

102

Figura 3.29 Raffinamento della dimensione temporale

Capitolo 3

Poiché a questo punto sono presenti nella dimensione attributi che vengono utilizzati esclusivamente per l’ordinamento, è possibile modificare le configurazioni di default in modo che tali attributi non siano visibili all’utente e non siano indicizzati, in modo da ridurre il tempo di processamento.

Le proprietà degli attributi su cui bisogna agire in questo senso sono le seguenti:

Attribute Hierarchy Enabled: deve essere settata a False, in modo che nel processamento non sia creata una gerarchia per quell’attributo;

Attribute Hierarchy Optimized State: per migliorare le performance di processamento, evitando di creare un indice per l’attributo, deve essere impostata a Not Optimized;

Attribute Hierarchy Ordered: se impostata a False può migliorare le performance di processamento, poiché i membri dell’attributo non vengono ordinati.

Gli attributi modificati sono riconoscibili dall’icona di colore diverso (grigia anziché viola, fig. 3.29) nel pannello Attributes.

Per vedere i cambiamenti apportati è sempre prima necessario processare la dimensione. Solo conclusosi il processamento, nella scheda di Browser è possibile vedere il risultato delle modifiche apportate alla dimensione temporale (fig. 3.30).

Figura 3.30 Risultato delle modifiche apportate alla dimensione temporale

103


3.7.8.3 Estensione dello schema relazionaleIn SSAS è possibile estendere lo schema relazionale della vista origine dati senza modificare la sorgente dei dati sottostante.

Si è sfruttata questa possibilità per aggiungere una dimensione di analisi, la dimensione Settimana, implicita nell’attributo Matricola Apparecchiatura della tabella del fatto; la relativa tabella dimensione è stata precedentemente predisposta (par. 3.6.1), ma non relazionata alla tabella del fatto per mancanza di una chiave esterna adatta. La chiave esterna per la relazione è stata creata in questa fase con l’aggiunta di una colonna calcolata alla vista della sorgente dei dati.

Per aggiungere una colonna calcolata è sufficiente selezionare la tabella di interesse e scegliere l’opzione New Named Calculation. In questo modo si apre una finestra che permette di assegnare un nome alla colonna da creare e di specificare lo statement SQL con cui scriverne il contenuto. Nella vista origine dati è stata aggiunta quindi alla tabella del fatto una colonna calcolata, chiamata “Week_key”, con lo statement riportato in figura 3.31. E’ stata inoltre creata una colonna calcolata nella tabella dimensione dim_week (par. 3.6.1) per estrarre dal codice univoco Week_Key le 4 cifre indicanti l’anno.

A questo punto è possibile inserire la tabella dim_week nella vista della sorgente e creare la relazione tra la colonna calcolata Week_key e la chiave primaria della tabella dimensione.

La sola estensione dello schema relazionale però non basta ad aggiornare la struttura multidimensionale in cui sono organizzati i dati.

104

Figura 3.31 Aggiunta di una colonna calcolata nella fact table

Capitolo 3

Per poter aggiungere una dimensione al cubo è necessario prima eseguire il Deployment, poi selezionare Add Cube Dimension e seguire la procedura guidata per la creazione della dimensione.Poiché la nuova dimensione deve gestire anche valori Null è necessario impostare le configurazioni necessarie al Null Processing (par. 3.7.5), in modo da non incontrare errori nel processamento. A questo punto la dimensione potrà essere processata con successo e utilizzata per il browsing del cubo (par. 3.7.9).

3.7.8.4 Aggiunta di una fact dimensionUna fact dimension è una dimensione basata su un attributo contenuto nella fact table; le fact dimension possono essere utili a raggruppare le righe di una tabella in base al valore di un determinato attributo, ove non si ritenga opportuno creare una apposita tabella dimensione.

Per aggiungere una fact dimension al Data Cube bisogna seguire la procedura Add Cube Dimesion, selezionando come Main Dimension Table proprio la tabella del fatto e come Dimension Attribute l’attributo di interesse.

Nel progetto DW Rientri Utenza è stata creata una fact dimension basata sull’attributo CodErrore della tabella del fatto, poiché per le analisi sulla difettosità risulta spesso utile classificare i componenti anche in base all’ultimo errore registrato (ove disponibile). Anche per questo tipo di dimensione è stato scelto una storage di tipo MOLAP (par. 3.7.5.1). Una fact dimension è facilmente riconoscibile nella scheda Dimension Usage grazie all’icona che la caratterizza (fig. 3.32).

Figura 3.32 Aggiunta di una fact dimension

105


La relazione tra una fact dimension e la misura di un fatto è detta fact relationship e la sua granularità deve sempre corrispondere all’attributo chiave della tabella del fatto, stabilendo così una relazione uno-a-uno tra la dimensione e i fatti contenuti nella tabella del fatto.

Dopo aver eseguito il Deployment, anche la fact dimension è disponibile per il browsing del cubo (par. 3.7.9) come una possibile prospettiva di analisi.

106

Capitolo 3

3.7.8.5 Raggruppamento automatico di membriPer alcuni tipi di attributo, può risultare utile creare dei raggruppamenti basati sulla distribuzione dei membri in classi di appartenenza. In questo modo è possibile limitare il numero di livelli presentati all’utente, raggruppando gli attributi non in base al valore assunto ma in base all’appartenenza di tale valore a un intervallo di ampiezza nota. Qualora infatti l’analisi coinvolga un gran numero di valori possibili per un attributo, disporre automaticamente di un’informazione di sintesi può rendere l’analisi più efficace.

La proprietà Discretization Method determina l’applicazione e il tipo di raggruppamento effettuato sull’attributo. I metodi di raggruppamento possibili sono tre:

Automatic: SSAS determina automaticamente il tipo di raggruppamento basandosi sulla struttura dell’attributo;

Equal Areas: vengono creati dei range in modo che i membri della dimensione siano equamente distribuiti tra i gruppi;

Clusters: i gruppi vengono determinati con un clustering uni-dimensionale sui valori assunti dall’attributo, usando il metodo del K-Means clustering per una distribuzione gaussiana (opzione valida solo per attributi numerici).

Dopo aver scelto il metodo di raggruppamento, è necessario specificare il numero di gruppi da utilizzare attraverso la proprietà Discretization Bucket Count dell’attributo.

Per il Data Cube DW Rientri Utenza è stata usata l’opzione di raggruppamento automatico per il livello Settimana della gerarchia indicante il periodo di produzione dell’apparecchiatura. Infatti, essendo i dati contenuti nel DW distribuiti lungo tutte le settimane dell’anno, disporre in un primo momento di un raggruppamento per intervalli temporali può essere utile per localizzare il manifestarsi di una concentrazione di difetti sulla produzione.

E’ stato scelto il tipo di raggruppamento automatico con numero di gruppi pari a 5 e, dopo aver processato la relativa dimensione, è stata ottenuta una discretizzazione in intervalli temporali di uguale durata (circa 10 settimane).

107


Figura 3.33 Time bucket per la dimensione Settimana di Produzione

108

Capitolo 3

3.7.9 BrowsingDopo il processamento, è possibile visualizzare i dati contenuti nel Data Warehouse secondo la struttura multidimensionale implementata. Operazione preliminare e necessaria al browsing è quindi il processamento del cubo (par. 3.7.7), cioè l’alimentazione della sua struttura multidimensionale con i dati contenuti nella sorgente.

Durante la fase di sviluppo di un progetto Analysis Services, poter “navigare” il cubo processato è molto utile per capire le modifiche da apportare per migliorare la funzionalità del Data Cube, ad esempio definendo criteri di ordinamento, eliminando attributi superflui, modificando le gerarchie create o configurando opportuni raggruppamenti degli attributi in gruppi omogenei. Attraverso il browsing è possibile inoltre provare direttamente sui dati presenti nel Data Cube le operazioni definite per il modello multidimensionale dei dati (par. 2.4.2).

L’operazione più interessante per testare la funzionalità del cubo realizzato è il browsing del cubo attraverso la scheda di Browser del Cube Designer, che permette di esaminare il cubo così come apparirebbe agli utenti nei tool di reporting o in qualsiasi altra applicazione client.

Una generica finestra di Browser del cubo è organizzata secondo tre aree (fig. 3.34):

l’area dei metadati (metadata pane), dove è possibile esaminare la struttura logica del cubo;

l’area dei filtri (filter pane), dove è possibile definire, attraverso una o più condizioni, il sottocubo che si vuole utilizzare per l’analisi dei dati;

l’area dei dati (data pane), dove è possibile costruire tabelle pivot ed effettuare operazioni di drill-down e roll-up lungo le gerarchie definite per le dimensioni.

109


Figura 3.34 Organizzazione del pannello di Browser del cuboLa tecnica di creazione interattiva delle tabelle pivot è semplice e intuitiva, infatti si basa sul drag and drop degli oggetti di interesse dal Metadata pane al Data pane. Nel Filter pane invece è possibile effettuare operazioni di slicing del Data Cube; dopo aver specificato una dimensione e una gerarchia, è possibile costruire le espressioni di filtraggio utilizzando diversi operatori quali: Equal, Not equal, In, Not in, Range (Inclusive), Range (Exclusive), MDX Expression. Si può quindi analizzare il contenuto del cubo secondo le selezioni fatte.

Nel Data Pane è possibile eseguire ulteriori operazioni di slicing, selezionando dal menu a tendina solo i membri della dimensione che si desidera visualizzare (ad esempio, non tutte le famiglie, ma solo alcune); ove sono state definite delle gerarchie, si possono testare inoltre le analisi in drill-down lungo i vari livelli gerarchici (fig. 3.35).

110

Filter pane

Data pane

Metadata pane

Capitolo 3

Figura 3.35 Esempio di funzionamento del Browser

Dal pannello Browser è possibile inoltre eseguire alcune funzioni base di filtraggio dei dati, come l’ordinamento (crescente o decrescente) o la selezione dei primi/ultimi n elementi sulla base di una misura. Il browsing in fase di sviluppo di un progetto Analysis Services permette di ricavare informazioni importanti, quali le performance in fase di interrogazione, il funzionamento delle direzioni di analisi lungo le dimensioni (drill-down e criteri di ordinamento) e il livello di user-friendliness della struttura; in questo modo si può disporre di un prototipo del funzionamento dell’applicazione lato client.

111

Elaborazione e rappresentazione dei dati relativi alla difettosità analizzata

4. Elaborazione e rappresentazione dei dati relativi alla difettosità analizzata

Attraverso la metodologia di sviluppo per un Data Warehouse multidimensionale esposta nel capitolo 2, è stato realizzato il Data Warehouse dei Rientri Utenza (capitolo 3) utilizzando la tecnologia Microsoft SQL Server Analysis Services disponibile nel pacchetto Business Intelligence Development Studio di SQL Server 2005.

La struttura multidimensionale dei dati è stata logicamente creata in termini di dimensioni, misure, cubi e partizioni rispetto all’origine dati specificata ed è stata successivamente popolata con il contenuto del Data Warehouse. Il tipo di storage scelto (MOLAP) rispecchia l’esigenza di massimizzare le performance di query, disponendo di aggregazioni calcolate a vari livelli. Il processo di browsing ha permesso infine di testare la funzionalità e l’efficacia delle modifiche apportate alla struttura dati.

Il Data Warehouse così definito e implementato è la parte centrale del modello di riferimento per il Data Warehousing definito al paragrafo 2.3.2, che consente alle applicazioni client di reporting e di analisi di interfacciarsi con una struttura separata dalle applicazioni transazionali e ottimizzata per l’interrogazione multidimensionale dei dati.

Come esempio di applicazione client per l’accesso al Data Cube è stato utilizzato il foglio elettronico Microsoft Excel 2003. Un’integrazione gratuita dell’applicazione (dal sito www.microsoft.com) ha consentito di risolvere i problemi di retro-compatibilità con SQL Server 2005 Analysis Services. Tuttavia a partire dal pacchetto Office 2007 sono già disponibili strumenti di integrazione Business Intelligence per i prodotti di SQL Server 2005.

4.1 Microsoft Excel 2003 come client OLAPTra le diverse possibilità di accesso ad un Data Warehouse si è scelto di utilizzare Microsoft Excel 2003, fornito nel pacchetto Office 2003, in quanto in ambito aziendale è ancora uno degli strumenti più diffusi e conosciuti per l’elaborazione dei dati.I fogli elettronici offrono ottime possibilità di integrazione con un sistema di Data Warehouse e quindi si prestano ottimamente per essere utilizzati come client in ambito Business Intelligence. Tramite questi software è possibile analizzare sia on-line che off-line i dati multidimensionali, interagendo con essi in modo semplice e intuitivo.

112

Figura 4.1 Microsoft Excel come client OLAP

http://www.microsoft.com/

Capitolo 4

113


4.1.1 Componenti necessari per accedere alle origini dati OLAPPer poter utilizzare Excel come client OLAP sono necessari alcuni componenti software, che sono di seguito brevemente descritti.

Origine dati. Insieme memorizzato di informazioni sull’origine dei dati utilizzata per la connessione a un database; un’origine dati può includere il nome e la posizione del server di database, il nome del driver di database e le informazioni necessarie per l’accesso. Dopo aver creato un’origine dati OLAP, è possibile basarvi i rapporti e restituire i dati a Excel sotto forma di rapporto di tabella pivot o grafico pivot.

Provider OLAP. Un provider OLAP è un software che fornisce l’accesso a

un determinato tipo di database OLAP; tale software può contenere un driver di origine dati e un software client necessario per la connessione a un database. Per impostare le origini dati OLAP per Excel è necessario uno dei provider OLAP seguenti:

Provider OLAP Microsoft: Excel include il driver dell’origine dati e il software client necessari per accedere ai database creati con Microsoft SQL Server OLAP Services versione 7.0, Microsoft SQL Server OLAP Services versione 2000 (8.0) e Microsoft SQL Server 2005 Analysis Services (9.0); quest’ultimo richiede l’installazione di un add-in per Excel 2003, in quanto si tratta di una versione precedente a SSAS 2005.

Provider OLAP di altri produttori: per altri prodotti OLAP, è necessario installare programmi client e driver aggiuntivi. Per utilizzare le funzioni di Excel per la gestione dei dati OLAP, il prodotto di altre società deve essere conforme agli standard di OLE-DB per OLAP e deve essere compatibile con Microsoft Office.

Database del server e file cubo. Il programma client per OLAP di Excel supporta due tipi di collegamenti ai dati OLAP. Se un database su un server OLAP è disponibile in rete, è possibile recuperare i dati di origine direttamente dalla rete. Se si dispone di un file cubo non in linea (file creato nel disco rigido o in una condivisione di rete per memorizzare i dati di origine OLAP per un rapporto di tabella pivot o grafico pivot, in modo da poter disporre dei dati anche in mancanza di connessione al server OLAP) o di un file di definizione del cubo (informazioni, memorizzate in un file oqy, che definiscono la modalità di creazione in memoria di un cubo OLAP con i dati recuperati da un database relazionale) è possibile collegarsi al file per recuperare i dati di origine.

Microsoft Query. Consente di recuperare dati da database esterni, quali quelli di Microsoft SQL Server o Microsoft Access; non occorre utilizzare Query per recuperare i dati da una tabella pivot OLAP connessa a un file cubo.

114

Capitolo 4

4.1.2 Microsoft Office Excel Add-in for SQL Server Analysis ServicesPer poter connettere Microsoft Excel 2003 (o 2002) a SQL Server 2005 Analysis Services è necessario installare un apposito add-in, fornito gratuitamente da Microsoft nell’area Download di www.microsoft.com. Tramite questo add-in è possibile connettersi con Excel a sorgenti di dati quali cubi OLAP generati con Analysis Services 2005 e disporre di funzionalità di analisi aggiuntive e personalizzabili.Ciò consente agli utenti di utilizzare un unico strumento (peraltro familiare anche a coloro che non sono professionisti IT) per accedere ai dati e analizzarli, senza duplicare o copiare dati da uno o più sistemi.

Gestire la connessione a uno o più cubi di Analysis Services consente di assicurare consistenza e integrità dei dati, oltre che di combinare dati da più sorgenti informative, analizzandoli unitamente. Le funzionalità native di Excel per l’analisi dei dati vengono inoltre estese con funzionalità di drill-through e what-if analysis. Infine, la possibilità di formattare e aggiornare i report in base alle esigenze rinforza ulteriormente le potenzialità di Excel come strumento di Business Intelligence.

La versione installata per le successive elaborazioni dei dati è “Excel 2002/2003 Add-in for SQL Server Analysis Services SP1” v. 1.5 (data di pubblicazione 16/12/2005, non sono state rilasciate successive release). I sistemi operativi supportati sono Windows 2000 Server, Windows 2000 (SP2, SP3 e SP4), Windows Server 2003, Windows XP e Windows XP SP1.Per utilizzare l’add-in con Analysis Services, devono essere stati installati precedentemente all’add-in, MSXML (v. 6.0), PivotTable Service 9.0 e Microsoft OLE DB Provider for Analysis Services 9.0 (fig. 4.2).

Figura 4.2 Provider necessario alla connessione 115


4.1.3 Accesso al databasePer creare una nuova origine da utilizzare per accedere ai dati tramite Microsoft Excel si può seguire la seguente procedura: si seleziona dal menù Dati la voce Importa dati esterni – Nuova query su database e si sceglie come origine dei dati l’opzione Cubi OLAP. Una volta impostati correttamente il provider (Microsoft OLE DB Provider for Analysis Services 9.0), il nome del server, l’account e il database Analysis Services è possibile accedere alle informazioni rese disponibili nel cubo OLAP scelto.

Lo strumento utilizzato per accedere ai dati è la tabella pivot, che permette un’analisi flessibile in quanto consente di selezionare, raggruppare e riassumere i dati in modo immediato.La creazione guidata di tabelle e grafici pivot permette di estrarre in modo semplice e intuitivo i dati contenuti nel Data Warehouse e di realizzare report a diversi livelli di dettaglio.

116

Figura 4.16 Cubi OLAP in Microsoft Excel 2003

Capitolo 4

Figura 4.4 Creazione guidata di una tabella pivot (Layout)

Una volta inseriti nel layout della tabella i dati di interesse è possibile esplorare a vari livelli di dettaglio le dimensioni presenti tramite le funzioni di drill-down e roll-up. E’ possibile inoltre utilizzare i valori come dati parziali per calcoli di formule oppure per la rappresentazione grafica.

Figura 4.5 Accesso OLAP con tabelle pivot

117


118

TOP 20 2008, Quarter 1

0

20

40

60

80

100

120

140

160

EW

M 1

000

Res

iste

nza

lava

ggio

WM

con

NT

C

2100

EN

V06

EW

M 2

000

EV

O

Ele

ttro

valv

ola

3 V

ie

2500

EN

V06

FC

V (

sch

eda

inve

rter

)

1100

EN

V06

EW

M 1

000

PLU

S

Ele

ttro

valv

ola

2 V

ie

Unk

now

n

Mot

ore

Col

lett

ore

Res

iste

nza

dopp

ioT

F

Blo

ccop

orta

ista

ntan

eo

3500

EN

V06

Blo

ccop

orta

Filt

ro A

ntid

istu

rbo

Mot

ore

Trif

ase

Ele

ttro

valv

ola

FC

V E

NV

06(s

ched

a in

vert

er)

Localizzazione difetto

Nu

mer

o r

ien

tri

Capitolo 4

4.2 Elaborazione dei datiLe possibilità di elaborazione dei dati fornite dallo strumento Excel unito alla struttura multidimensionale del Data Warehouse sono molteplici. I vantaggi principali consistono sicuramente nella flessibilità di analisi e in un livello di dettaglio scalabile, non definito a priori. Pur essendo Excel uno strumento informatico semplice, alla portata della maggior parte degli utenti, può essere sfruttato in maniera efficace per eseguire interrogazioni personalizzate sui dati presenti nel Data Warehouse, consentendo di realizzare una base per la comunicazione trasversale dei dati all’interno dell’organizzazione e concretizzando così il valore dell’informazione di sintesi.

Nei paragrafi seguenti sono state riportate alcune esemplificazioni dei risultati ottenibili; esse non sono riportate con la pretesa di ricavare informazioni di valore aziendale, ma solo al fine di dimostrare le potenzialità dello strumento proposto.

4.2.1 Diagrammi di ParetoI diagrammi di Pareto sono una rappresentazione grafica di facile e immediata lettura dei dati che si sono presentati con maggiore frequenza in un determinato periodo di analisi.

Essi si basano sul cosiddetto principio di Pareto (“the vital few, the trivial many”), secondo cui il 20% dei problemi causa l’80% dei danni. In altre parole, ci sono poche caratteristiche vitali che generano la maggior parte dei problemi e queste caratteristiche sono quelle su cui, operando logicamente, bisogna agire in modo prioritario per ottenere un miglioramento più che proporzionale.La forma tipica di un diagramma di Pareto è quella dell’istogramma, in cui le barre sono ordinate in maniera decrescente per frequenze.

I diagrammi di Pareto sono utilizzati spesso nelle aziende per migliorare la qualità attraverso l’individuazione delle cause primarie di non conformità dei prodotti/servizi. Ad esempio, nel seguente grafico è stato fatto un diagramma di Pareto selezionando i primi 20 elementi della gerarchia Localizzazione Difetto sulla base del numero dei rientri analizzati nel primo trimestre del 2008.

Grafico 1 Diagramma di Pareto per famiglie in base al numero dei rientri

119


L’ordinamento dei dati in base a un campo e la visualizzazione automatica dei primi n elementi (sia in ordine crescente che decrescente) possono essere impostati dal menù “Tabella pivot – Ordina e mostra i primi 10...”.Eseguendo operazioni di drill-down e roll-up sulla tabella pivot associata al grafico, esse si riflettono automaticamente nella rappresentazione grafica, consentendo analisi con un livello di dettaglio flessibile e anche asimmetrico: è possibile ad esempio espandere la gerarchia solo per uno degli elementi visualizzati, di cui si desidera un’informazione più dettagliata. Nel caso del grafico sopra riportato, riducendo la selezione ai primi 10 elementi, si ottiene ad esempio la seguente rappresentazione tabellare.

Descr Famiglia Descr Componente Numero rientri

EWM 1000

Circuito integrato 1

Componente 23

Condensatore 1

Copertuta plastica 79

Pcb 32

Relè 1

Resistenza 4

Selettore 2

Tasto 1

Triac 5

EWM 1000 Totale 149

Resistenza lavaggio WM con NTC 59

2100 ENV06 53

EWM 2000 EVO 41

Elettrovalvola 3 Vie 27

2500 ENV06 26

1100 ENV06 24

FCV ( scheda inverter ) 24

EWM 1000 PLUS 23

Elettrovalvola 2 Vie 17

Totale complessivo 443Tabella 4-15 Operazione di drill-down su una tabella pivot

120

Capitolo 4

In un diagramma di Pareto potrebbe inoltre essere utile confrontare il contributo di ciascun valore al totale in più categorie, ordinate in modo decrescente. Questo è possibile grazie a un tipo di grafico disponibile in Excel, detto “Istogramma in pila” (versione 2D e 3D), che permette, ad esempio, di analizzare un diagramma di Pareto per il numero dei rientri rispetto ai fornitori, utilizzando come informazione aggiuntiva la famiglia di localizzazione del difetto (grafico 2).

Rispetto al caso precedente, la creazione di un tale grafico presuppone una struttura più complessa della tabella pivot sottostante; il rapporto pivot è strutturato utilizzando la dimensione temporale di inserimento come campo pagina, la descrizione del fornitore come campo riga e la descrizione della famiglia come campo colonna.

La tabella pivot è quindi in questo caso la rappresentazione tabellare di un’operazione di slice-and-dice (par. 2.4.2) sul Data Cube, in cui ogni cella è riempita col valore della misura (numero dei rientri); tramite una tabella di questo tipo è possibile evidenziare la sparsità del Data Cube, legata all’esistenza di celle vuote (per cui il valore della misura è zero). Questo problema tuttavia è gestito efficacemente dalla struttura MOLAP.

121


PR

OC

ON

D

IRC

A

PR

OS

A S

YS

TE

M

AK

O

ELB

I

DE

LPH

I

PO

WE

R-O

NE

C.E

.SE

T.

INV

EN

SY

S S

.A.M

. (M

C)

BIT

RO

N A

LAT

RI

0

20

40

60

80

100

120

140

160

180

Nu

mer

o r

ien

tri

Fornitore

TOP 10 2008, Quarter 1

Unknown

Resistenza lavaggio WM con NTC

Resistenza doppio TF

Pressostato Analogico

Motore Trifase

Motore Collettore

Filtro Antidisturbo

FCV ENV06 (scheda inverter)

FCV ( scheda inverter )

EWM 2000 EVO

EWM 1000 PLUS

EWM 1000

Elettrovalvola 3 Vie

Elettrovalvola 2 Vie

Elettrovalvola

Bloccoporta istantaneo

Bloccoporta

3500 ENV06

2500 ENV06

2100 ENV06

1100 ENV06

Grafico 2 Diagramma di Pareto tramite istogramma in pila 3D

Altri tipi di diagramma di Pareto sono realizzabili sulla base dei dati contenuti nel Data Warehouse; si tratta comunque di scegliere una prospettiva di analisi e successivamente utilizzare le opzioni di selezione, ordinamento e rappresentazione incorporate in Excel.

4.2.2 Analisi di una serie temporaleNella progettazione del modello multidimensionale per il Data Warehouse (par. 3.5) sono state introdotte più dimensioni temporali, organizzate in opportune gerarchie. Tali dimensioni possono essere utilizzate in fase di analisi per valutare l’andamento nel tempo di uno o più fenomeni o per effettuare confronti tra variabili temporali.

Ad esempio, è possibile, fissato un periodo di tempo per l’analisi, classificare i componenti rientrati sulla base del periodo di produzione del prodotto finito, deducibile dalla matricola (ove questa informazione sia disponibile).

La distribuzione dei rientri del primo trimestre del 2008 rispetto al periodo di produzione è riportata nel grafico 3 ed evidenzia una distribuzione delle frequenze concentrata intorno alla seconda metà del 2006 e alla prima metà del 2007.

122

Produzione 2006, 2007

0

5

10

15

20

25

30

35

1 - 10

11 - 20

21 - 31

32 - 41

42 - 53

1 - 10

11 - 20

21 - 31

32 - 41

2006 2007

Anno e settimana di produzione

Nu

mer

o r

ien

tri

Motore Asincrono Motore Collettore Motore Trifase Motoventilatore WD

Capitolo 4

Quarter 1, 2008

0

10

20

30

40

50

60

70

80

90

100

11 - 20

32 - 41

42 - 53

1 - 10

11 - 20

21 - 31

32 - 41

42 - 53

1 - 10

11 - 20

21 - 31

32 - 41

42 - 53

1 - 10

11 - 20

21 - 31

32 - 41

2004 2005 2006 2007

Anno e settimana di produzione

Nu

mer

o r

ien

tri

Grafico 3 Distribuzione delle frequenze (assolute) in base al periodo di produzione del prodotto finito

L’andamento di diverse serie nel tempo può essere analizzato, ad esempio, per approfondire se vi siano state concentrazioni di difettosità in determinati intervalli di tempo, al fine di individuarne le cause. Nel grafico seguente si è considerato, a titolo esemplificativo, una famiglia di motori per la produzione di prodotto finito degli anni 2006 e 2007.

Grafico 4 Confronto di serie nel tempo

123


Essendo presenti nel Data Warehouse diverse serie temporali (data inserimento, matricola del componente e matricola del prodotto finito) potrebbe risultare utile confrontare i loro valori per un set di dati.

In questo modo è possibile ad esempio confrontare le informazioni riguardanti rispettivamente la matricola del componente (prodotto dal fornitore esterno) e la matricola del prodotto finito (prodotto internamente). Bisogna tenere presente che questi due dati non sempre sono presenti contemporaneamente (può essere conosciuto l’uno e non l’altro), ma, in linea generale, l’andamento della difettosità rispetto alla produzione del componente dovrebbe anticipare sempre quello della difettosità rispetto alla produzione del prodotto finito di un tempo pari al lead time che trascorre dalla fornitura al montaggio del componente.

Questo viene ben evidenziato dal grafico 5 per le settimane dalla 37 alla 40 dell’anno 2006, in cui si è avuto un massiccio rientro di componenti; le cause specifiche possono essere approfondite con ulteriori analisi.

ANNO 2006

0

20

40

60

80

100

120

140

160

1 4 7 10 13 16 19 22 25 28 31 34 37 40 43 46 49 52

Settimana di produzione

Nu

mer

o r

ien

tri

Electrolux

Fornitori

Grafico 5 Confronto tra due serie temporali

Una volta localizzato un componente o un difetto di interesse per l’analisi è possibile con metodi simili rappresentarne l’andamento del tempo.

124

Capitolo 4

Può risultare utile inoltre quantificare il contributo di un membro al totale, per valutarne l’incidenza (assoluta o relativa). Una visualizzazione efficace a questo proposito risulta ad esempio un grafico personalizzato linee-colonne, in cui si può scegliere di utilizzare uno o due assi per le ordinate.

Una tale rappresentazione può permettere di evidenziare se esiste uno specifico componente a cui attribuire la maggior parte della difettosità riscontrata in una data famiglia in un certo intervallo di tempo. Un esempio è riportato nel grafico seguente, dove si è analizzata l’incidenza (assoluta) del membro “Pcb” (=Printed circuit board) all’interno della famiglia “EWM 1000 PLUS” per l’anno di produzione 2006.

EWM 1000 PLUS, 2006

0

2

4

6

8

10

12

14

16

18

1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49 51

Settimana di produzione

Nu

mer

o r

ien

tri

Tot. EWM 1000 PLUS Pcb

Grafico 6 Incidenza (assoluta) di un membro sul totale

125

2,38%

1,90%

13,95%59,93%

BELGIO DANIMARCA FRANCIA GERMANIA HONG KONG ITALIA OLANDA QUELLE RUSSIA SPAGNA THAILANDIA U.K.

Mercati di provenienza, 2007


4.2.3 Altri tipi di graficoUn’esposizione esaustiva dei grafici utili all’analisi non sarebbe in questa sede possibile né opportuna. Per dare tuttavia un’idea della flessibilità e delle potenzialità della soluzione proposta, in questo paragrafo sono riportate altre tipologie di grafico ottenute elaborando i dati presenti nel Data Warehouse.

Una delle possibilità offerte dal rapporto tabella pivot è quella di trattare la misura non solo come conteggio delle istanze (quindi come una misura assoluta), ma anche come frequenza relativa rispetto a un set di dati definito. Per le celle che contengono la misura è possibile infatti impostare diverse modalità di visualizzazione dei dati attraverso il menù Tabella pivot – Imposta campo – Opzioni (fig. 4.6).

Utilizzando l’opzione di visualizzazione della misura come percentuale del totale, è immediato, ad esempio, creare una rappresentazione grafica dei mercati di provenienza dei componenti analizzati dal laboratorio nell’anno 2007. Nel grafico inoltre, è visualizzata un’etichetta per quei mercati con incidenza superiore all’1%.

126

Figura 4.6 Impostazioni per il campo contenente la Misura

1100 EN

V06

2100 EN

V06

2500 EN

V06

EW

M 1000

EW

M 1000 P

LUS

EW

M 2000 E

VO

EW

M 2000 O

LD

EW

M 3000

Circuito integrato

Resistenza

Condensatore

Triac

Pcb

0

100

200

300

400

500

600

700

800

Nu

mer

o r

ien

tri

Difettosità per famiglia e per componente

Capitolo 4

La struttura multidimensionale del Data Warehouse rende possibile anche analizzare separatamente livelli diversi di una stessa gerarchia. Nel grafico 8 si è considerata, ad esempio, la gerarchia Localizzazione Difetto, presupponendo di voler valutare se la difettosità su uno stesso componente sia estesa a una o più famiglie selezionate.

Le opportunità di rappresentazione incorporate dal foglio elettronico consentono di scegliere di volta in volta la rappresentazione che meglio si adatta a rappresentare i dati, in modo da consentirne un’interpretazione chiara ed efficace.

Il tipo di grafico “Radar”, ad esempio, può essere utilizzato qualora si voglia trasmettere una informazione immediata dell’entità di un fenomeno lungo vari assi. Nella rappresentazione che segue (grafico 9) è stato utilizzato per visualizzare il conteggio delle istanze rispetto a un insieme di famiglie selezionate. Anche in questo grafico, come nel precedente, non sono state effettuate selezioni sulle dimensioni temporali, quindi il grafico si riferisce all’intero contenuto del Data Warehouse.

Grafico 7 Rappresentazione delle incidenze percentuali di ogni mercato

Grafico 8 Estensione della difettosità di un componente a più famiglie

127


Famiglie analizzate

0

500

1000

1500

2000

2500Bloccoporta istantaneo

EWM 1000

EWM 1000 PLUS

Pompa scarico

Bloccoporta

EWM 2000 OLD

Elettrovalvola

Motore Collettore

Pompa Ricircolo

Pompa scarico WD

Grafico 9 Grafico “Radar” per le famiglie presenti nel Data Warehouse

Una tipologia di diagramma già vista in precedenza (diagramma di Pareto, par. 4.2.1) può essere sfruttata per ottenere precise indicazioni dai dati presenti nel Data Warehouse.

Può essere interessante, ad esempio, confrontare l’esito dell’analisi svolta dall’Assistenza Tecnica al momento della sostituzione con l’esito dell’analisi svolta dal laboratorio Q/SQA. A questo proposito, può risultare opportuno filtrare in primis i dati in base al tipo di diagnosi effettuata dall’Assistenza e rappresentare poi tramite un grafico l’esito dell’analisi di laboratorio per tali dati.

A titolo esemplificativo, il focus è stato posto su quei componenti rientrati con diagnosi di difetto elettrico sulla basetta elettronica principale da parte dell’Assistenza Tecnica. I corrispondenti risultati emersi dall’analisi in laboratorio sono rappresentati nel seguente diagramma di Pareto (grafico 10); per chiarezza di esposizione, sono visualizzate solo le prime 10 famiglie per volume di istanze.

128

Capitolo 4

0,00% 5,00% 10,00% 15,00% 20,00% 25,00% 30,00% 35,00% 40,00%

Pcb

Componente

Copertuta plastica

Resistenza

Prove

Trimer

Triac

Relè

VDR

Circuito integrato

EWM 1000, Basetta elettronica principale - Difetto Elettrico2006-2007

Saldatura difettosa / mancante

Rotture

Non riscontrato difetto

Montaggio errato

Interrotto

In analisi / Ciclature

Impurita' / Residui / acqua

Esploso

Difettoso

Corto circuito esterno

Grafico 10 Confronto tra la diagnosi dell’Assistenza Tecnica e quella del laboratorio

Si vuole infine riportare un esempio che dimostri come si possano utilizzare le funzionalità di calcolo proprie di Excel per l’analisi dei dati provenienti dal Data Warehouse (free-form report, par. 4.3).

E’ possibile infatti impostare calcoli nel foglio elettronico con riferimenti a valori contenuti nelle celle del Data Cube. Quando il foglio verrà aggiornato, automaticamente si aggiorneranno i valori della misura per quelle celle e di conseguenza anche i campi calcolati su esse basati. Le modalità di aggiornamento verranno approfondite nel par.4.4.

Un’operazione di calcolo molto semplice come, ad esempio, la media mobile può essere utilizzata per analizzare l’andamento di un fenomeno nel tempo. La media mobile è definita come una funzione di parametro N tale che:

dove Di è il valore dell’osservazione al tempo i. Il valore di N permette di regolare la sensibilità della media rispetto a fluttuazioni dei valori della serie osservata.

Nella tabella 4-2 e nel rispettivo grafico 11 sono riportati i risultati dell’applicazione della media mobile con N=3 al numero dei rientri registrati tra Luglio 2007 e Marzo 2008, sia in totale che per un insieme di famiglie scelto arbitrariamente.

129


Q.tà di rientri July2007

Aug.2007

Sept.2007

Oct.2007

Nov.2007

Dec.2007

Jan.2008

Febr.2008

March2008

ALL 112 104 90 20 28 84 245 193 48 MA(3) 112 104 102 71 46 44 119 164 172

EWM 1000 78 103 58 7 2 0 131 18 0 MA(3) 78 103 80 56 22 3 44 50 50

Motore Collettore 0 0 0 4 11 47 0 11 0 MA(3) 0 0 0 1 5 21 19 19 4

Resistenza lavaggio WM

1 1 0 0 0 0 2 41 16

MA(3) 1 1 1 0 0 0 1 14 20

Tabella 4-16 Tabella per il calcolo della media mobile

130

Media mobile N=3, Giugno 2007-Marzo 2008

020406080

100120140160180200

July

Au

gu

st

Se

pte

mb

er

Octo

be

r

No

vem

be

r

De

cem

be

r

Jan

ua

ry

Fe

bru

ary

Ma

rch

Mese

Nu

me

ro r

ien

tri

All EWM 1000 Motore Collettore Resistenza lavaggio WM con NTC

Capitolo 4

Similmente potrebbe essere calcolata una media MA(N) pesata con opportuni coefficienti oppure si potrebbe utilizzare la funzione MA(N) per effettuare previsioni, ove necessario.

Le opportunità di analisi dei dati utilizzando Excel come client OLAP risultano quindi diversificate, flessibili e personalizzabili. La possibilità di analizzare i dati secondo le varie dimensioni e a diversi livelli di dettaglio mediante uno strumento come la tabella pivot si coniuga alla possibilità di utilizzare questi stessi dati applicandovi le funzionalità proprie di un foglio elettronico, come campi calcolati e grafici dinamici.

Grafico 11 Andamento delle medie mobili calcolate

131


4.3 Utilizzo delle connessioni per la creazione di reportMicrosoft Office Excel Add-in for SQL Server Analysis Services installa un menù aggiuntivo chiamato “Cube Analysis”, attraverso il quale è possibile gestire le connessioni con le sorgenti dei dati multidimensionali e creare report.

Nel paragrafo 4.1.3 si è visto come effettuare l’accesso al database creando una opportuna origine dati per i cubi OLAP. Il procedimento seguito consiste in ultima analisi nella creazione di un file di query OLAP (*.oqy), che viene utilizzato da Excel per accedere ai dati.

Dopo aver installato l’Add-in però è possibile anche connettersi direttamente ai cubi Analysis Services, grazie a un apposito strumento di gestione delle connessioni. Attraverso l’opzione Manage Connection dal menù Cube Analysis si accede a una finestra dalla quale è possibile creare, modificare, eliminare connessioni; ogni connessione è definita tramite il server a cui si desidera connettersi, il database e il Data Cube da cui estrarre i dati oppure tramite un file cubo (*.cub) di riferimento.

Quando si crea una connessione direttamente al server che ospita il cubo (o i cubi) Analysis Services di interesse, viene creata una stringa di identificazione della connessione formata da <nome del server – nome del database – nome del cubo> a cui ci si connette. Una volta creata, la connessione è per default chiusa (Status = Closed); per attivarla è sufficiente cliccare su Connect (fig. 4.7).

Una volta creata una connessione è possibile costruire report basandosi su di essa attraverso il menù Cube Analysis – Build Report. Appare la finestra di figura 4.8, attraverso cui è possibile scegliere la connessione da utilizzare per il report. Nel momento in cui si seleziona una

132

Figura 4.7 Gestione delle connessioni con Cube Analysis

Capitolo 4

connessione, essa viene automaticamente aperta (Status = Open) ed è possibile iniziare a importare dati dalla sorgente. E’ possibile accedere alle dimensioni, alle gerarchie e agli attributi impostati per ogni dimensione, nonché alle misure definite per il Data Cube a cui si è connessi.

Prima di iniziare a costruire il report bisogna scegliere se si vuole realizzare uno structured report o un free-form report. Cube Analysis infatti mette a disposizione dell’utente queste due tipologie di reporting, abbastanza diverse tra loro. Per effettuare questa decisione bisogna considerare vantaggi e svantaggi delle due soluzioni rispetto alle proprie esigenze di analisi.

133


FREE FORM REPORTVANTAGGI SVANTAGGI

supporta connessioni a fonti diverse nello stesso report

dati OLAP ed Excel funzioni native di

Excel (sorting e formatting)

Insert di righe e colonne

azioni di Analysis Services, drill through, write back e server side formatting

no pivoting navigazione limitata il Refresh non “vede”

nuovi membri

L’idea di base che motiva l’utilizzo di free-form report e structured report è la volontà di andare oltre le limitazioni della tabella pivot. Essa infatti è uno strumento efficace per l’analisi dei dati multidimensionali, ma potrebbe risultare rigida per alcune tipologie di analisi che, ad esempio, richiedano di manipolare in qualche modo i dati oltre che di visualizzare semplicemente il contenuto del Data Warehouse.

I due tipi di report possono essere considerati speculari, nel senso che gli svantaggi dell’uno coincidono praticamente con i vantaggi dell’altro (come si vede dalle relative tabelle).

Per quanto riguarda la modalità free-form report, si può dire che consente di importare i dati del cubo in Excel come se fossero stati immessi manualmente,

134

STRUCTURED REPORTVANTAGGI SVANTAGGI

espressioni custom per filtri

roll-up, drill-down, expand, collapse, eliminate e pivoting

il Refresh “vede” nuovi membri

espressioni dinamiche sugli assi

azioni di Analysis Services, drill through, write back e server side formatting

report da fonti single no Insert di righe e

colonne no dati esterni

Figura 4.8 Report basato su una connessione

Initial layout

Additional elements

Initial layout

Additional elements

Capitolo 4

quindi offre la massima flessibilità nella manipolazione dei dati; è possibile eliminare righe e colonne, applicare ordinamento e formattazione, utilizzando senza limitazioni tutte le funzionalità native di Excel (campi calcolati, formattazione condizionale, ecc.).

Un altro grande vantaggio offerto da questo tipo di reporting è la possibilità di confrontare, nello stesso foglio, dati presenti in diversi cubi OLAP e diverse fonti. La mancanza della possibilità di fare pivoting è dovuta al fatto che il free-form report è uno strumento sostanzialmente diverso dalla pivot table, più orientato all’elaborazione personalizzata dei dati.

Lo structured report come modalità di reporting è molto simile alla pivot table. Si seleziona infatti un layout iniziale per il report (fig. 4.9) e vi si inseriscono le dimensioni e le misure di analisi. La struttura iniziale può essere successivamente ampliata aggiungendo nuovi segmenti al layout.

La modalità structured report non supporta connessioni a fonti diverse nello stesso report, nè l’inserimento di righe e colonne con dati Excel nell’area del report. I vantaggi principali di questo tipo di reporting sono la possibilità di effettuare le operazioni proprie della struttura multidimensionale (roll-up, drill-down, collapse, expand, pivoting, ecc.) e di definire espressioni custom per filtrare i dati, esprimendo delle condizioni sulla misura (is equal to, is less/greater than, is between, is top/bottom percent, is top/bottom count, ecc.)

Poiché la modalità structured report risulta molto simile alla tabella pivot, si è scelto di utilizzare la modalità free-form report per personalizzare i dati nel foglio elettronico, includendovi campi calcolati e confrontando informazioni che non sarebbe stato possibile includere nella stessa tabella pivot.

In questo modo, ad esempio, è stato costruito il grafico 5, confrontando il numero di rientri aggregati in base alla settimana di produzione del prodotto finito con il numero di rientri aggregati in base alla settimana di produzione del componente fornito.

Figura 4.9 Struttura di una Structured Report

135


Un altro grafico realizzato attraverso la tipologia free-form è quello linee-colonne (grafico 6). In questo caso, per calcolare l’incidenza di una parte sul totale, sono stati estratti sullo stesso foglio elettronico il numero di rientri totale e il numero di rientri assegnati a un determinato componente (“Pcb”) per lo stesso intervallo di tempo.

Infine, anche l’analisi dei rientri per famiglia tramite la media mobile (grafico 11 e tabella 4-2) è stata realizzata sfruttando le caratteristiche del free-form report, quali inserimento di righe, utilizzo di dati Excel nel report (campi calcolati) e formattazione.

136

Capitolo 4

4.4 Aggiornamento dei reportNei paragrafi precedenti sono state esposte due modalità di importazione in Excel dei dati contenuti nel Date Warehouse a fini di analisi degli stessi. E’ importante a questo punto poter aggiornare i report in istanti successivi, in modo che, mantenendo la stessa struttura, essi rispecchino i dati presenti nel Data Warehouse.

Per i report basati su importazione dei dati tramite la creazione di un’opportuna origine dati per i cubi OLAP (Dati – Importa dati esterni – Nuova query su database), l’aggiornamento può essere effettuato tramite il menù Tabella pivot (o Grafico pivot) alla voce Aggiorna dati (fig. 4.10).

Durante l’aggiornamento dei dati viene eseguita una query per l’importazione dei dati esterni in Excel. Siccome alcune query potrebbero essere utilizzate per acceder a informazioni riservate o per eseguire altre operazioni dannose, può essere richiesta una conferma da parte dell’utente prima di eseguire la query.

Se i report sono stati creati invece basandosi sulla gestione delle connessioni con Cube Analysis, l’aggiornamento dei dati si avvia a partire dal menù Cube Analysis. E’ possibile eseguire il Refresh per tutti i dati presenti nel foglio elettronico (indipendentemente dalla connessione) oppure eseguire il Refresh per i soli dati provenienti da una specificata connessione; queste due opzioni corrispondono rispettivamente alle voci Refresh Sheet e Refresh Connection (fig. 4.11).

Figura 4.10 Aggiornamento di una tabella pivot

Figura 4.11 Aggiornamento di un report

137


4.4.1 Cubi off-lineE’ stato visto come il programma client per OLAP di Excel supporti due tipi di collegamenti ai dati OLAP: quello in linea (on-line) e quello non in linea (off-line). E’ possibile infatti memorizzare i dati di origine OLAP per un rapporto di tabella pivot o grafico pivot in un file nel disco rigido o in una condivisione di rete, in modo da poter disporre ugualmente dei dati anche in mancanza di connessione al server OLAP. Si parla, in questo caso, di file cubo non in linea (off-line cube).

Per creare un file cubo non in linea è possibile avviare una procedura guidata dal menù Tabella pivot – OLAP non in linea (fig. 4.12).

Selezionando “Creazione file dati non in linea in corso” si avvia una procedura che consente di definire un sottoinsieme dei dati del cubo presente sul server per creare un file cubo locale. Una volta definito il file cubo, sarà possibile utilizzare la tabella pivot senza essere connessi al server. I dati non inclusi nel file cubo non saranno disponibili per la tabella pivot fino alla successiva connessione al server.

La procedura richiede di scegliere le dimensioni, i livelli e le misure da includere nel cubo (un passaggio è riportato in fig. 4.13) e infine il percorso di memorizzazione per il file. Il risultato è la creazione di un file *.cub compatibile con Microsoft Office Excel 2003.

138

Figura 4.12 OLAP on-line e off-line

Figura 4.13 Passaggio per la creazione di un cubo non in linea

Capitolo 4

139

Conclusioni

140

Conclusioni

5. Conclusioni

Impiegando le tecniche di rappresentazione multidimensionale dei dati, si sono identificate nella sorgente dei dati le componenti del modello multidimensionale e se ne è realizzata una rappresentazione relazionale. A partire da una tale progettazione e attraverso un opportuno software di sviluppo, si sono successivamente definite le strutture dati fisiche di supporto per le analisi OLAP.

In questo senso, gli obiettivi posti sono stati pienamente raggiunti. Si è realizzato il progetto di Data Warehouse relativo alla difettosità analizzata, fornendo un modello di riferimento che si interpone tra la sorgente dei dati e gli strumenti di analisi. Le interrogazioni degli utenti finali, provenienti da applicazioni OLAP (o di Business Intelligence in generale), accedono quindi ai dati tramite tale modello, che offre sia un isolamento dall’origine dei dati back-end sia un miglioramento delle prestazioni per le query che comportano riepiloghi delle informazioni.

La rappresentazione multidimensionale realizzata risulta composta da una fact table contenente undici attributi dimensionali, che vengono analizzati attraverso otto dimension tables distinte. Le gerarchie implementate in totale sono sette e corrispondono ai livelli di dettaglio individuati in fase di analisi. La misura (totalmente additiva) considerata nell’applicazione è il conteggio delle istanze del fatto. Alcune tabelle dimensionali (due) sono state create direttamente nel Data Warehouse, sfruttando e de-normalizzando per motivi prestazionali informazioni contenute nella sorgente. La fase di ristrutturazione dello schema relazionale per l’implementazione del modello multidimensionale ha inoltre coinvolto cinque delle tabelle presenti nella base dati originaria.A causa dell’estensione del progetto a una singola sorgente dei dati, non si è ritenuta opportuna a questo livello la realizzazione di più Data Mart distinti.

Con riferimento agli obiettivi del lavoro di tesi, i seguenti punti sono stati consecutivamente raggiunti nel corso dello svolgimento dello stesso:

identificazione degli oggetti del modello multidimensionale (fatti, dimensioni, misure) e loro applicazione alla realtà di interesse per il progetto;

progettazione, implementazione e processamento di una struttura dati multidimensionale attraverso la tecnologia Microsoft SQL Server 2005 Analysis Services;

utilizzo di un programma client per la realizzazione di grafici e risultati tabellari a partire dai dati multidimensionali OLAP, testando e verificando quindi le potenzialità della soluzione realizzata.

Le motivazioni che hanno portato allo sviluppo dell’applicazione confermano la validità di un’architettura basata sulla separazione degli ambienti OLTP e OLAP, in cui i sistemi OLTP svolgono il ruolo di sorgenti di dati (data source) per l’ambiente OLAP. I requisiti alla base dei due tipi di sistemi sono infatti sostanzialmente contrastanti, essendo gli uni ottimizzati per le elaborazioni transazionali (OLTP), gli altri per le elaborazioni analitiche (OLAP).

141

Conclusioni

Rispetto ad altre metodologie di analisi classiche per basi di dati come, ad esempio, entità-relazione, la metodologia proposta consente di concentrarsi sul fatto di interesse aziendale piuttosto che sull’organizzazione dei dati, dimostrandosi efficiente ed efficace di fronte alla necessità di comprendere, sintetizzare e gestire informazioni.

Per quanto riguarda le possibilità di sviluppo di questo progetto, uno dei principali obiettivi è quello di estendere le possibilità di analisi integrando altre basi di dati, in modo da fornire nuove aree tematiche di interesse per gli utenti. La metodologia utilizzata risulta infatti scalabile (grazie ad appositi strumenti di gestione dei metadati) e applicabile anche a realtà più complesse ed estese. Di notevole interesse per lo sviluppo futuro è quindi la possibilità di realizzare un modello dei dati orientato all’analisi che offra una visualizzazione unificata a livello aziendale dei dati appartenenti a diverse aree funzionali.

In questa prospettiva, uno sviluppo futuro potrebbe prevedere la realizzazione di applicazioni di Business Performance Management basate su Microsoft Analysis Services 2005, utilizzando come strumento di reporting Microsoft Excel o Microsoft Reporting Services. Se, come spesso accade, lo strumento aziendale di uso quotidiano per le analisi e il reporting è Excel, esso va reso uno strumento di lavoro “condiviso”, “certificato” e “integrato” per applicazioni divisionali, direzionali, fino a progetti enterprise. Da un tale sviluppo potrebbe derivare, ad esempio, la possibilità di costruire un dashboard (insieme di indicatori di performance che vanno a costituire un “cruscotto”) su Excel e pubblicarlo sul Web.

La metodologia proposta risulta tuttavia insufficiente a far fronte all’intero ciclo di sviluppo del Data Warehousing. Innanzitutto bisognerebbe prevedere la progettazione di una procedura per un’alimentazione corretta e ottimizzata del Data Warehouse: essa risulta spesse volte complessa, in quanto legata alla qualità dei dati resi disponibili, alle sorgenti e alla loro struttura. Inoltre l’effettiva produttività della soluzione deve essere valutata con un test estensivo e un porting in produzione, che non rientrano negli scopi di questa tesi.

Concludendo, la modellazione multidimensionale è stata applicata con successo a questo progetto, ottenendo una struttura dati OLAP su cui attuare i processi di Business Intelligence rivolti a sfruttare il patrimonio informativo in modo attivo per analisi statistiche e previsionali.

142

Bibliografia

Bibliografia

ATZENI P., CERI S., FRATERNALI P., PARABOSCHI S., TORLONE R. (2007), Basi di dati: Architetture e linee di evoluzione, 2a edizione, Milano, McGraw-Hill (Collana di istruzione scientifica)

ATZENI P., CERI S., FRATERNALI P., PARABOSCHI S., TORLONE R. (2006), Basi di dati: Modelli e linguaggi di interrogazione, 2a edizione, Milano, McGraw-Hill (Collana di istruzione scientifica)

CORNELL P. (2005), Microsoft Excel: Analisi e accesso ai dati, 2a edizione, Milano, Mondadori Informatica

DATTA A., THOMAS H. (1999), The cube data model: a conceptual model for on-line analytical processing in data warehouses, Decision Support Systems 27, pp. 289-301

DYCHE J. (2000), E-data: Turning Data Into Information with Data Warehousing, New York, Addison-Wesley Professional

GOLAFARELLI M., RIZZI S. (2006), Data Warehouse: Teoria e pratica della progettazione (2006), 2a edizione, Milano, McGraw-Hill (Workbooks)

HAN J., KAMBER M. (2006), Data Mining: Concepts and Techniques, 2nd ed., S. Francisco, Morgan Kaufmann (The Morgan Kaufmann Series in Data Management Systems)

HUNG E., CHEUNG D.W., KAO B. (2004), Optimization in Data Cube System Design, Journal of Intelligent Information Systems 23:1, pp. 17-25.

KIMBALL R., Fact and Dimension Tables: the logical foundation of dimensional modeling, Intelligence Enterprise Magazine, January 2003

KIMBALL R., W.H. Inmon (1996), The data warehouse toolkit: practical techniques for building dimensional data warehouses, New York, J. Wiley and Sons (Wiley computer publishing)

PAYNE A., Microsoft, Business Intelligence e Data Warehousing in SQL Server 2005, <http://www.microsoft.com/italy/technet/prodtechnol/sql/2005/dwsqlsy.mspx>, 2004, aggiornato il 13/02/2006

RICHARDSON J., SCHLEGEL K, HOSTMANN B., MCMURCHY N. (Febbraio 2008), Magic Quadrant for Business Intelligence Platforms 2008, Gartner RAS Core Research Note G00154227

SCHLEGEL K., SOOD B. (2007), Business Intelligence Platform Capability Matrix, Gartner Research ID Number G00146865

143

http://www.microsoft.com/italy/technet/prodtechnol/sql/2005/dwsqlsy.mspx

Siti web e documentazione on-line

SINCLAIR R. (2006), Da Access a SQL Server, Milano, Arnoldo Mondadori Editore (Mondadori Informatica)

SOMMERVILLE I. (2005), Ingegneria del software, Milano, Pearson Education Italia S.r.l.

TSENG F.S.C. (2005), Design of a multidimensional query expression for document warehouses, Information Sciences 174, pp. 55-79

Siti web e documentazione on-line

BILLINMON.COM, <http://www.billinmon.com/>

BUSINESS INTELLIGENCE AND DATA WAREHOUSE RESOURCE CENTER (a cura di Vincenzi A .) <http://www.olap.it/>

BUSINESS INTELLIGENCE BEST PRACTISES (Forum interattivo ideato da TDWI e "The Business Intelligence Network"), <http://www.bi-bestpractices.com/>

BUSINESS INTELLIGENCE. COM: Resource For BI, <http:// www.businessintelligence.com/>

DATA MANAGEMENT REVIEW, < http://www.dmreview.com/>

GARTNER GROUP, <http://www4.gartner.com/>

MICROSOFT BUSINESS INTELLIGENCE, <http://www.microsoft.com/bi/>

MICROSOFT OFFICE EXCEL ADD-IN FOR SQL SERVER ANALYSIS SERVICES: Installation and Setup Guide, <http://www.microsoft.com/downloads>

MICROSOFT SQL SERVER 2005 ANALYSIS SERVICES (Product Information), <http://www.microsoft.com/Sqlserver/2005/en/us/analysis-services.aspx>

MSDN LIBRARY, Documentazione di SQL Server 2005, <http://msdn.microsoft.com/it-it/library/default.aspx>

REGNECENTRALEN/NDCAC (National Danish Centre for Advanced Calculation), Time Dimension Generator Builder, < http://www.regnecentralen.dk/time_dimension_generator.html>

SQL SERVER MAGAZINE: The Smart Guide to Build World-Class Applications (partnership Windows IT Pro), <http://www.sqlmag.com/ >

TDWI (The Data Warehousing Institute): Data Warehousing Education & Solutions, <http://www.tdwi.org/>

144

http://www.tdwi.org/

http://www.sqlmag.com/

http://www.regnecentralen.dk/time_dimension_generator.html

http://msdn.microsoft.com/it-it/library/default.aspx

http://www.microsoft.com/Sqlserver/2005/en/us/analysis-services.aspx

http://www.microsoft.com/downloads

http://www.microsoft.com/bi/

http://www4.gartner.com/

http://www.dmreview.com/

http://www.bi-bestpractices.com/

http://www.bi-bestpractices.com/

http://www.olap.it/

http://www.billinmon.com/

Bibliografia

THE OLAP REPORT, <http://www.olapreport.com/>

145

http://www.olapreport.com/

Piccin Elisa

Documents

Transcript of Piccin Elisa