Appunti per il Corso di Data Warehousing

Università degli Studi Mediterranea di Reggio Calabria Corsi per il Personale Tecnico Amministrativo Appunti per il Corso di Data Warehousing Autori: Ing. Giovanni Quattrone, Prof. Domenico Ursino Anno Accademico 2007-2008

Indice 1 I fondamenti del Data Warehousing............................................ 1 1.1 Motivazioni.................................................................. 1 1.2 I sistemi di supporto alle decisioni.............................................. 2 1.3 Il Data Warehousing.......................................................... 3 1.4 Architetture per il Data Warehousing........................................... 5 1.4.1 Architettura ad un livello................................................ 5 1.4.2 Architettura a due livelli................................................ 6 1.4.3 Architettura a tre livelli................................................. 8 1.5 I Metadati................................................................... 10 1.6 Qualità di un Data Warehouse................................................. 10 2 Il modello multidimensionale e l OLAP......................................... 11 2.1 Il modello multidimensionale................................................... 11 2.1.1 Restrizione............................................................ 14 2.1.2 Aggregazione.......................................................... 15 2.2 Tool e tecnologie per il Data Warehousing....................................... 16 2.2.1 Reportistica........................................................... 16 2.2.2 OLAP................................................................ 16 2.3 ROLAP e MOLAP........................................................... 22 3 Modelli logici a supporto del Data Warehousing................................ 25 3.1 Lo schema a stella............................................................ 25 3.2 Lo schema a fiocco di neve..................................................... 26 3.3 Le viste..................................................................... 29 3.3.1 Schemi relazionali in presenza di dati aggregati............................. 30 4 Progettazione di un Data Warehouse........................................... 33 4.1 Metodologia di progettazione di un Data Warehouse.............................. 33 4.2 Passo 1: Scelta del processo.................................................... 33 4.3 Passo 2: Scelta della granularità................................................ 34 4.4 Passo 3: Identificare e rendere conformi le dimensioni............................. 35 4.5 Passo 4: Scelta delle misure.................................................... 35 4.6 Passo 5: Memorizzare pre-calcoli nella tabella dei fatti............................ 36 4.7 Passo 6: Completare la tabella delle dimensioni................................... 36 4.8 Passo 7: Scelta della durata del database........................................ 37 4.9 Passo 8: Tracciare le slowly changing dimension................................ 37 4.10 Passo 9: Decidere le priorità sulle query e sulle modalità di query................... 38 4.11 Integrazione dei Data Mart.................................................... 39 5 Data Warehousing e Oracle: Analytical Workspace Manager.................... 41 5.1 Analytical Workspace Manager................................................. 41 5.2 Oracle Spreadsheet Add In.................................................... 67

Elenco delle figure 1.1 Il valore dell informazione in funzione della quantità............................... 2 1.2 Architettura ad un livello per un sistema di Data Warehousing...................... 6 1.3 Architettura a due livelli per un sistema di Data Warehousing...................... 7 1.4 Architettura a due livelli con Data Mart indipendenti.............................. 8 1.5 Architettura a tre livelli per un sistema di Data Warehousing....................... 9 2.1 Il cubo a tre dimensioni che modella le vendite in una catena di negozi............... 12 2.2 Gerarchie di aggregazione sulle dimensioni prodotto e negozio..................... 13 2.3 Slicing di un cubo tridimensionale............................................... 14 2.4 Due livelli di aggregazione a partire dai dati elementari............................. 16 2.5 Presentazione di un rapporto: tabelle, diagramma, torta............................ 17 2.6 Le gerarchie di attributi nel V-Mall; le frecce indicano dipendenze funzionali.......... 17 2.7 Roll-up sulla gerarchia temporale................................................ 18 2.8 Roll-up con eliminazione della gerarchia cliente.................................. 18 2.9 Roll-up (a sinistra) e drill-down (a destra) su un cubo.............................. 19 2.10 Drill-down sulla gerarchia del cliente............................................. 19 2.11 Drill-down con l aggiunta di una dimensione...................................... 20 2.12 Slicing (sopra) e selezione (sotto) di un cubo...................................... 20 2.13 Slicing sul predicato Year = 1998............................................... 20 2.14 Selezione su un predicato complesso............................................. 21 2.15 Pivoting di un cubo........................................................... 21 2.16 Pivoting su una tabella bidimensionale........................................... 21 2.17 Pivoting su una tabella tridimensionale.......................................... 22 2.18 Drill-across tra due cubi........................................................ 22 2.19 Drill-across tra il cubo delle vendite (misura Dollar Sales) e quello delle promozioni (misura Discount)............................................................ 22 2.20 Architettura ROLAP.......................................................... 23 3.1 Schema a stella per le vendite; in corsivo sono rappresentate le chiavi delle relazioni.... 26 3.2 Una possibile istanza dello schema a stella di Figura 3.1............................ 27 3.3 Un possibile schema a fiocco di neve per lo schema a stella presentato in Figura 3.1; in corsivo sono rappresentate le chiavi delle relazioni................................. 28 3.4 Uno schema snowflake scorretto per lo schema a stella presentato in Figura 3.1........ 29 3.5 Alcune viste ottenibili a partire dallo schema a stella presentato in Figura 3.1......... 30 3.6 Memorizzazione di dati aggregati utilizzando una sola fact table..................... 30 3.7 Memorizzazione dei dati aggregati, tramite constellation schema, per lo schema delle vendite....................................................................... 31 3.8 Memorizzazione dei dati aggregati, utilizzando più schemi a stella, per lo schema delle vendite....................................................................... 32 3.9 Memorizzazione dei dati aggregati, tramite snowflake schema, per lo schema delle vendite....................................................................... 32 4.1 Diagramma E/R per la gestione di un agenzia immobiliare.......................... 34

VI Elenco delle figure 4.2 Parte del Diagramma E/R di Figura 4.1 che rappresenta i dati coinvolti nel processo di vendita degli immobili di un agenzia immobiliare................................ 35 4.3 Schema a stella associato alle vendite............................................ 36 4.4 Schema a stella per gli affitti degli immobili; questo è un esempio di una Fact Table strutturata male.............................................................. 37 4.5 Schema a stella per gli affitti degli immobili; questo è lo schema della Figura 4.4 con i problemi corretti.............................................................. 38 4.6 Schema a stella per la vendita e la pubblicità degli immobili con le Dimension Table Time, PropertyForSale, Branch e Promotion conformi............................ 39 4.7 Costellazione dei fatti per il Data Warehouse associato all agenzia immobiliare........ 40

Elenco delle tabelle 1.1 Ruolo dei Sistemi di Supporto alle Decisioni...................................... 3 1.2 Principali differenze tra database operazionali e Data Warehouse.................... 5 2.1 Aggregazione sulla gerarchia temporale operata sulle quantità vendute per un dato prodotto in tre negozi.......................................................... 15 4.1 Fact Table e Dimension Table per ciascun Data Mart dell agenzia immobiliare in esame 40

1 I fondamenti del Data Warehousing In questo capitolo tratteremo i fondamenti del Data Warehousing. Dopo una breve trattazione sulle motivazioni che possono spingere all utilizzo di tale tecnologia, introdurremo i sistemi di supporto alle decisioni; successivamente descriveremo, in via del tutto generale, il processo di Data Warehousing. A questo punto concentreremo la nostra attenzione sulle architetture di Data Warehouse; infine, esamineremo i metadati e chiuderemo con il problema della misurazione della qualità di un Data Warehouse. 1.1 Motivazioni L informazione è un bene a valore crescente, necessario per pianificare e controllare le realtà aziendali con efficacia; essa costituisce, di fatto, la materia prima che viene trasformata dai sistemi informativi come i semilavorati vengono trasformati dai sistemi di produzione. Purtroppo, l equazione: dati = informazione non è sempre corretta: spesso, infatti, la disponibilità di troppi dati rende arduo, se non impossibile, estrapolare le informazioni veramente importanti. Il fenomeno del Data Warehousing nasce proprio dall enorme accumulo di dati registrato nell ultimo decennio e dalla pressante richiesta di utilizzare attivamente questi dati per scopi che superino quelli, di routine, legati all elaborazione giornaliera. Uno scenario tipico è quello di una grande azienda, con numerose filiali, i cui dirigenti desiderano quantificare e valutare il contributo dato da ciascuna di esse al rendimento commerciale globale dell impresa. Essendo i dati elementari sulle attività svolte disponibili nel database aziendale, un approccio possibile consiste nel chiedere ai tecnici che lo amministrano di formulare un interrogazione ad hoc che effettui i calcoli necessari sui dati (in genere aggregazioni). Quando i tecnici saranno riusciti a formulare l interrogazione voluta (tipicamente in SQL, dopo avere a lungo consultato i cataloghi del database), e una volta terminata la sua elaborazione (il che richiederà probabilmente alcune ore, dato l elevato volume dei dati, la complessità dell interrogazione e la contemporanea incidenza sui dati delle interrogazioni facenti parte del normale carico di lavoro), ai dirigenti verrà restituito un rapporto, sotto forma di foglio elettronico, su cui basare le decisioni future. Già da parecchi anni si è capito che questa via è difficilmente percorribile, perché porta ad un inutile consumo di tempo e risorse e, al contempo, non sempre produce il risultato desiderato. Tra l altro, mescolare questo tipo di interrogazioni analitiche con quelle transazionali di routine porta ad inevitabili rallentamenti che rendono insoddisfatti gli utenti di entrambe le categorie. L idea alla base del Data Warehousing è, allora, quella di separare l elaborazione di tipo analitico (OLAP, On-Line Analytical Processing) da quella legata alle transazioni (OLTP, On-Line Transactional Processing), costruendo un nuovo raccoglitore di informazioni che integri i dati elementari provenienti da sorgenti di varia natura, li organizzi in una forma appropriata e li renda quindi disponibili per scopi di analisi e valutazione finalizzati alla pianificazione e al processo decisionale.

2 1 I fondamenti del Data Warehousing Passiamo velocemente in rassegna alcune delle aree in cui le tecnologie di Data Warehousing vengono impiegate con successo: commercio: analisi delle vendite e dei reclami, controllo di spedizioni e inventari, cura del rapporto con i clienti; manifattura: controllo dei costi di produzione, supporto ai fornitori e agli ordini; servizi finanziari: analisi del rischio e delle carte di credito, rilevazioni di frodi; trasporti: gestione del parco mezzi; telecomunicazioni: analisi del flusso delle chiamate e del profilo dei clienti; sanità: analisi di ricoveri e dimissioni, contabilità per centri di costo. D altronde, il campo di utilità dei sistemi di Data Warehousing non è ristretto al dominio aziendale e di impresa; esso, infatti, spazia ulteriormente dall area medico-epidemiologica a quella demografica, dall area delle scienze naturali a quella didattica. Caratteristica comune a tutti questi campi è la necessità di strumenti di archiviazione e interrogazione che consentono di ottenere facilmente e in tempi ridotti, dall enorme quantità di dati memorizzati nei database o resi disponibili su Internet, informazioni di sintesi che permettano la valutazione di un fenomeno, la scoperta delle correlazioni significative e, in definitiva, l acquisizione di conoscenza utile come supporto alle decisioni. 1.2 I sistemi di supporto alle decisioni La funzione svolta dalle basi di dati in ambito aziendale è stata fino a qualche anno fa solo quella di memorizzare dati operazionali, ossia dati generati da operazioni, principalmente di carattere amministrativo, svolte all interno dei processi gestionali (per esempio, gestione degli acquisti, gestione delle vendite, fatturazione). D altronde, per ciascuna azienda, è fondamentale poter disporre, in maniera rapida e completa, delle informazioni necessarie al processo decisionale; le indicazioni strategiche vengono estrapolate principalmente dalla mole di dati operazionali contenuti nei database aziendali, attraverso un procedimento di selezione e sintesi progressiva, schematizzato nella Figura 1.1. Valore Indicazioni strategiche Rapporti Informazioni selezionate Fonti informative primarie Quantità Figura 1.1. Il valore dell informazione in funzione della quantità Ben presto, l aumento esponenziale del volume dei dati operazionali ha reso il calcolatore l unico supporto adatto al processo decisionale svolto dai dirigenti aziendali. Proprio a causa di ciò il ruolo delle basi di dati, a partire dagli anni 80, ha subito profonde modifiche che hanno portato, tra l altro, alla nascita dei sistemi di supporto alle decisioni (Decision

1.3 Il Data Warehousing 3 Support System), termine con cui si intende l insieme delle tecniche e degli strumenti informatici atti a estrapolare informazioni da un insieme di dati memorizzati su supporti elettronici. I diversi ruoli dei sistemi di supporto alle decisioni in ambiente aziendale sono riassunti nella Tabella 1.1. Nel Passato Nel Futuro Descrivere il passato Anticipare il futuro Descrivere i problemi Suggerire i cambiamenti da apportare Ridurre i costi Aumentare i profitti Tabella 1.1. Ruolo dei Sistemi di Supporto alle Decisioni Tra le problematiche da affrontare per la realizzazione di un sistema di supporto alle decisioni, ricordiamo la necessità: di gestire grandi moli di dati; di accedere a diverse fonti di dati, presenti, eventualmente, su piattaforme eterogenee; di garantire l accesso a più utenti per interrogazioni, analisi in tempo reale e simulazioni; di gestire versioni storiche dei dati. 1.3 Il Data Warehousing Tra i sistemi di supporto alle decisioni i sistemi di Data Warehousing sono probabilmente quelli su cui negli ultimi anni si è maggiormente focalizzata l attenzione sia del mondo accademico che di quello industriale. Informalmente, un Data Warehouse può essere definito come una collezione di metodi, tecnologie e strumenti di ausilio al cosiddetto lavoratore della conoscenza (knowledge worker - dirigente, amministratore, gestore, analista) per condurre analisi dei dati finalizzate all attuazione di processi decisionali e al miglioramento del patrimonio informativo. Questa definizione, volutamente molto generale, rende un idea degli scopi del processo ma non ne esprime le peculiarità. Per capire a fondo il ruolo e l utilità del Data Warehousing occorre allora analizzare le esigenze che ne hanno decretato la nascita. Alcune lamentele ricorrenti da parte degli utenti finali dei sistemi informativi tradizionali sono efficacemente riassunte da Kimball: Abbiamo montagne di dati ma non possiamo accedervi! Questa frase esprime la frustrazione da parte di chi ha il ruolo e la competenza per decidere del futuro aziendale ma non possiede gli strumenti tecnici per ottenere, nella forma desiderata, i dati necessari. Come è possibile che persone che svolgono lo stesso ruolo presentino risultati sostanzialmente diversi? In un contesto aziendale medio-grande sono tipicamente presenti più basi di dati, ciascuna relativa ad una diversa area del business, spesso memorizzate su piattaforme logico-fisiche differenti e non integrate dal punto di vista concettuale. I risultati prodotti all interno delle diverse aree saranno, allora, molto probabilmente inconsistenti tra loro. Vogliamo selezionare, raggruppare e manipolare i dati in ogni modo possibile! Il processo decisionale è difficilmente pianificabile a priori. L utente finale vorrebbe disporre di uno strumento sufficientemente amichevole e flessibile da consentirgli di condurre l analisi in modo estemporaneo, lasciandosi guidare dalle informazioni via via ottenute per decidere sul momento quali nuove correlazioni ricercare. Vogliamo mostrare solo ciò che è importante! Esaminare i dati al massimo livello di dettaglio è non solo inutile ma, addirittura, controproducente per il processo decisionale perchè non consente di focalizzare l attenzione sulle informazioni veramente significative. Tutti sanno che alcuni dati non sono corretti! Questo è un altro punto dolente. Una percentuale non trascurabile dei dati transazionali è non corretta, o addirittura assente. Evidentemente, basare il procedimento analitico su dati errati e incompleti non permette di raggiungere risultati validi.

4 1 I fondamenti del Data Warehousing Da questo elenco di difficoltà e problemi possiamo facilmente estrarre un elenco di parole chiave che diventano fattori distintivi e requisiti indispensabili del processo di Data Warehousing, ossia del complesso di attività che consentono di trasformare i dati operazionali in conoscenza a supporto delle decisioni: accessibilità a utenti con conoscenze limitate di informatica e strutture dati; integrazione dei dati sulla base di un modello standard dell impresa; flessibilità di interrogazione per trarre il massimo vantaggio dal patrimonio informativo esistente; sintesi per permettere analisi mirate ed efficaci; rappresentazione multi-dimensionale per offrire all utente una visione intuitiva ed efficacemente manipolabile delle informazioni; correttezza e completezza dei dati integrati. Al centro del processo, il Data Warehouse (letteralmente, magazzino dei dati) è un contenitore (repository) di dati che diventa garante dei requisiti esposti. Una definizione corretta e completa di Data Warehouse è tratta dal testo di Inmon: Un Data Warehouse (DW) è una collezione di dati di supporto per il processo decisionale che presenta le seguenti caratteristiche: è orientata ai soggetti di interesse; è integrata e consistente; è rappresentativa dell evoluzione temporale e non volatile. Si intende che il DW è orientato ai soggetti perchè si incentra sui concetti di interesse dell azienda, quali i clienti, i prodotti, le vendite, gli ordini. Viceversa, i database operazionali sono organizzati intorno alle diverse applicazioni del dominio aziendale. L accento sugli aspetti di integrazione e consistenza è importante poichè il DW si appoggia a più fonti di dati eterogenee: dati estratti dall ambiente di produzione, e quindi originariamente archiviati in basi di dati aziendali o, addirittura, provenienti da sistemi informativi esterni all azienda. Di tutti questi dati il DW si impegna a restituire una visione unificata. In linea di massima, si può dire che la costruzione di un sistema di Data Warehousing non comporta l inserimento di nuove informazioni bensì la riorganizzazione di quelle esistenti e implica, pertanto, l esistenza di un sistema informativo. Mentre i dati operazionali coprono un arco temporale di solito piuttosto limitato, poichè la maggior parte delle transazioni coinvolge i dati più recenti, il DW deve permettere analisi che spazino sulla prospettiva di alcuni anni. Per tale motivo, il DW è aggiornato ad intervalli regolari, a partire dai dati operazionali, ed è in continua crescita. Volendo fare un paragone possiamo supporre che, a intervalli regolari, venga scattata una fotografia istantanea dei dati operazionali. La progressione delle fotografie scattate viene memorizzata nel DW dove genera un film che documenta la situazione aziendale da un istante zero fino al tempo attuale. Proprio per il fatto che, in linea di principio, non vengono mai eliminati dati dal Data Warehouse e che gli aggiornamenti sono tipicamente eseguiti a freddo, ossia quando il DW è fuori linea, un DW può essere fondamentalmente considerato come un database a sola lettura. Tale caratteristica, insieme all esigenza degli utenti di contenere i tempi di risposta alle interrogazioni di analisi, ha importanti conseguenze a vari livelli. Innanzitutto essa incide sulle tecnologie adottate dai DBMS specializzati per il Data Warehousing: non sono, infatti, più necessarie le tecniche sofisticate di gestione delle transazioni richieste dalle applicazioni operazionali. Inoltre, il fatto di operare in sola lettura differenzia profondamente le soluzioni di progettazione logica per i DW da quelle utilizzate per i database operazionali: l aspetto forse più evidente nelle implementazioni relazionali è che la pratica della normalizzazione delle tabelle viene abbandonata a favore di una parziale denormalizzazione, mirata al miglioramento delle prestazioni. Ulteriori e fondamentali differenze tra database operazionali e DW sono legate alle tipologie di interrogazioni. Per i primi, le interrogazioni eseguono transazioni che in genere leggono e scrivono un ridotto numero di record da diverse tabelle legate da semplici relazioni: per esempio, si ricercano i dati di un cliente per inserire un suo nuovo ordine. Questo tipo di elaborazione viene comunemente detto On-Line Transactional Processing (OLTP). Al contrario, il tipo di elaborazione per cui nascono i DW viene detto On-Line Analytical Processing (OLAP), ed è caratterizzato da un analisi dinamica e

1.4 Architetture per il Data Warehousing 5 multidimensionale che richiede la scansione di un enorme quantità di record per calcolare un insieme di dati numerici di sintesi che quantifichino le prestazioni dell azienda. È importante osservare che, mentre nei sistemi OLTP il nucleo sostanziale del carico di lavoro è congelato all interno dei programmi applicativi, e solo occasionalmente vengono lanciate interrogazioni estemporanee o di manutenzione straordinaria sui dati, in un DW l interattività è una caratteristica irrinunciabile delle sessioni di analisi e fa si che il carico di lavoro effettivo vari continuamente nel tempo. Le peculiarità delle interrogazioni OLAP fanno si che i dati nel DW vengano normalmente rappresentati in forma multidimensionale. L idea di base è quella di vedere i dati come punti in uno spazio le cui dimensioni corrispondono ad altrettanti possibili dimensioni di analisi; ciascun punto, rappresentativo di un evento accaduto nell azienda, viene descritto tramite un insieme di misure di interesse per il processo decisionale. Le principali differenze tra database operazionali e Data Warehouse vengono riassunte nella Tabella 1.2. Caratteristiche Database Operazionali Data Warehouse Utenti Migliaia Centinaia Carico di Lavoro Transazioni Predefinite Interrogazioni di analisi ad hoc Acceso A centinaia di record, in lettura e scrittura A milioni di record, per lo più in lettura Scopo Dipende dall applicazione Supporto alle decisioni Dati Elementari, sia numerici che alfanumerici Di sintesi, prevalentemente numerici Integrazione dei dati Per applicazione Per soggetto Qualità In termini di integrità In termini di consistenza Copertura temporale Solo dati correnti Dati correnti e storici Aggiornamenti Continui Periodici Modello Normalizzato Denormalizzato e multidimensionale Ottimizzazione Per accessi OLTP su una frazione del database Per accessi OLAP su gran parte del database Sviluppo A cascata Iterativo Tabella 1.2. Principali differenze tra database operazionali e Data Warehouse 1.4 Architetture per il Data Warehousing In questa sezione vengono analizzate e discusse le architetture tipiche dei sistemi di Data Warehousing, ossia dei sistemi che implementano il processo di Data Warehousing. Molto spesso, il termine Data Warehouse viene colloquialmente usato in modo esteso per denotare tutto il sistema di Data Warehousing, anzichè il solo contenitore dei dati di sintesi. Laddove riterremo che non si generi confusione, adotteremo anche noi questa comoda abbreviazione. Le caratteristiche architetturali irrinunciabili per un sistema di Data Warehousing possono essere così enunciate: Separazione: l elaborazione analitica e quella transazionale devono essere mantenute il più possibile separate. Scalabilità: l architettura hardware e software deve poter essere facilmente ridimensionata a fronte della crescita nel tempo dei volumi di dati da gestire ed elaborare e del numero di utenti da soddisfare. Estendibilità: deve essere possibile accogliere nuove applicazioni e tecnologie senza riprogettare integralmente il sistema. Sicurezza: il controllo sugli accessi è essenziale a causa della natura strategica dei dati memorizzati. Amministrabilità: la complessità dell attività di amministrazione non deve risultare eccessiva. 1.4.1 Architettura ad un livello Obiettivo di questa architettura, a dire il vero poco utilizzata nella pratica, è la minimizzazione dei dati memorizzati, ottenuta eliminando le ridondanze.

6 1 I fondamenti del Data Warehousing Dati operazionali Livello delle Sorgenti Middleware Livello del Warehouse Livello di Analisi Strumenti di reportistica Strumenti OLAP Figura 1.2. Architettura ad un livello per un sistema di Data Warehousing Come mostrato nella Figura 1.2, il Data Warehouse è in questo caso virtuale, nel senso che viene implementato come una vista multidimensionale dei dati operazionali generata da un apposito middleware, ovvero da uno strato di elaborazione intermedio. Il primo punto debole di questa architettura è che non rispetta il requisito di separazione tra l elaborazione analitica OLAP e quella transazionale OLTP. Le interrogazioni di analisi vengono, infatti, redirette sui dati operazionali dopo essere state reinterpretate dal middleware, interferendo, così, con il normale carico di lavoro transazionale. Inoltre, mentre con questa architettura è possibile (anche se complesso) rispondere ai requisiti di integrazione e correttezza dei dati, diventa impossibile esprimere un livello di storicizzazione superiore a quello delle sorgenti. Per questi motivi, l approccio virtuale al Data Warehousing ha avuto successo soltanto in contesti in cui le esigenze di analisi sono particolarmente limitate e il volume dei dati da esaminare è molto ampio. 1.4.2 Architettura a due livelli Il requisito di separazione gioca un ruolo fondamentale nel determinare la classica architettura di un sistema di Data Warehousing, rappresentata in Figura 1.3. Sebbene tradizionalmente denominata architettura a due livelli, per evidenziarne la separazione tra il livello delle sorgenti e quello del DW, essa, in realtà, si articola complessivamente su quattro livelli distinti, che descrivono stadi successivi del flusso di dati. Tali livelli sono: Livello delle sorgenti. Il DW utilizza fonti di dati eterogenei estratti dall ambiente di produzione e, quindi, archiviati originariamente in database aziendali, relazionali o legacy, oppure provenienti da sistemi informativi esterni all azienda. Livello dell alimentazione. I dati memorizzati nelle sorgenti devono essere estratti, ripuliti (per eliminare le inconsistenze e completare eventuali parti mancanti) e integrati (per fondere sorgenti eterogenee secondo uno schema comune). I cosiddetti strumenti ETL (Extraction, Transformation and Loading) permettono di integrare schemi eterogenei, nonchè di estrarre, trasformare, ripulire, validare, filtrare e caricare i dati dalle sorgenti nel DW. Dal punto di vista tecnologico vengono trattate problematiche tipiche dei servizi informativi distribuiti, come la gestione di dati inconsistenti e delle strutture dati incompatibili. Livello del Warehouse. Le informazioni vengono raccolte in un singolo contenitore (il Data Warehouse), centralizzato logicamente. Esso può essere direttamente consultato, ma anche usato come sorgente per costruire data mart; questi ultimi sono orientati verso specifiche aree dell impresa e, di fatto, costituiscono una replica parziale del Data Warehouse. Accanto al Data Warehouse, il contenitore dei metadati mantiene informazioni sulle sorgenti, sui meccanismi di accesso, sulle procedure di pulitura ed alimentazione, sugli utenti, sugli schemi dei data mart, ecc.

1.4 Architetture per il Data Warehousing 7 Dati operazionali Dati esterni Livello delle Sorgenti Strumenti ETL Livello di alimentazione Data Warehouse Metadati Data mart Livello del Warehouse Strumenti di reportistica Strumenti per l analisi what-if Livello di Analisi Strumenti OLAP Strumenti di Data Mining Figura 1.3. Architettura a due livelli per un sistema di Data Warehousing Livello di Analisi. Permette la consultazione efficiente e flessibile dei dati integrati per la stesura dei report nonchè per le attività di analisi e di simulazione. Dal punto di vista tecnologico sono richieste capacità di gestione dei dati aggregati, ottimizzazione di interrogazioni complesse, tecniche di indicizzazione avanzate e interfacce visuali amichevoli. La distinzione tra Data Warehouse e Data Mart, introdotta nell architettura, merita un approfondimento. Il blocco che va sotto il nome di Data Warehouse viene, spesso, denominato anche Data Warehouse primario o Data Warehouse aziendale, e svolge il ruolo di contenitore centrale e globale dei dati di sintesi. I Data Mart possono essere visti come piccoli DW locali che replicano (ed eventualmente sintetizzano ulteriormente) la porzione di DW primario di interesse per una particolare area applicativa. Con il termine Data Mart si intende un sottoinsieme o un aggregazione dei dati presenti nel DW primario, contenente l insieme delle informazioni rilevanti per una particolare area del business, una particolare divisione dell azienda, oppure una particolare categoria di soggetti. I Data Mart alimentati dal DW primario sono spesso detti dipendenti. Sebbene, in linea di principio non strettamente necessari, per i sistemi collocati all interno di realtà aziendali medio-grandi essi costituiscono un utilissima risorsa: come blocchi costruttivi durante la realizzazione incrementale del DW; in quanto delineano i contorni delle informazioni necessarie ad una particolare tipologia di utenti; in quanto permettono di raggiungere prestazioni migliori, essendo di dimensioni inferiori al DW primario. In alcuni contesti, principalmente per motivi organizzativi e politici, si preferisce adottare l architettura di Figura 1.4, in cui i data mart vengono alimentati direttamente dalle sorgenti e vengono, pertanto, detti indipendenti. L assenza di un DW primario snellisce le fasi progettuali ma determina uno schema complesso per l accesso ai dati e ingenera il rischio di inconsistenza tra i Data Mart.

8 1 I fondamenti del Data Warehousing Dati sorgente Dati sorgente Dati sorgente Livello delle Sorgenti Strumenti ETL Livello di alimentazione Metadati Data mart Metadati Data mart Livello del Warehouse Strumenti di reportistica Strumenti per l analisi what-if Livello di Analisi Strumenti OLAP Strumenti di Data Mining Figura 1.4. Architettura a due livelli con Data Mart indipendenti Per tale ragione, a volte, pur rispettando l indipendenza dei Data Mart, si preferisce creare comunque un DW centrale; in quest ultimo caso, rispetto all architettura standard a due livelli, i ruoli dei Data Mart e del DW sono, di fatto, invertiti; infatti, il DW, in questo caso, viene alimentato dai Data Mart e può essere direttamente interrogato al fine di semplificare l accesso ai dati. Le principali motivazioni a sostegno dell architettura a due livelli, in cui il livello del warehouse funge da separatore tra le sorgenti e le applicazioni di analisi, sono così riassumibili: A livello del DW è continuamente disponibile informazione di buona qualità anche quando, per motivi tecnici oppure organizzativi, è temporaneamente precluso l accesso alle sorgenti. L interrogazione analitica effettuata sul DW non interferisce con la gestione delle transazioni a livello operazionale, la cui affidabilità è essenziale per il funzionamento dell azienda. L organizzazione logica del DW è basata sul modello multidimensionale, mentre le sorgenti presentano, in genere, modelli relazionali o semi-strutturati. C è una discordanza temporale e di granularità tra sistemi OLTP, che trattano dati correnti e al massimo livello di dettaglio, e sistemi OLAP, che operano su dati storici e di sintesi. A livello del DW è possibile utilizzare tecniche specifiche per ottimizzare le prestazioni per applicazioni di analisi e reportistica. È utile osservare che alcuni autori, con riferimento all architettura analizzata in questa sezione, utilizzano la stessa terminologia per indicare concetti differenti. In particolare, essi considerano il DW come un contenitore di dati integrati e consistenti, ma ancora in forma operazionale, introducendo la rappresentazione multidimensionale dei dati solo a livello dei Data Mart. Nella nostra terminologia questa visione operazionale del DW corrisponde, sostanzialmente, al livello dei dati riconciliati nelle architetture a tre livelli, trattate nella prossima sezione. 1.4.3 Architettura a tre livelli Il terzo livello introdotto in questa architettura è il cosiddetto livello dei dati riconciliati, detto anche operational data store, che materializza i dati operazionali ottenuti a valle del processo di integrazione

1.4 Architetture per il Data Warehousing 9 e ripulitura dei dati sorgente: si ottengono, quindi dati integrati, consistenti, corretti, volatili, correnti e dettagliati. Come illustrato nella Figura 1.5, il DW non viene più alimentato direttamente dalle sorgenti, bensì dai dati riconciliati. Il vantaggio principale del livello dei dati riconciliati è che esso crea un modello di dati comune e di riferimento per l intera azienda, introducendo, al contempo, una separazione netta tra le problematiche legate all estrazione e integrazione dei dati dalle sorgenti e quelle inerenti l alimentazione del DW. Dati operazionali Dati esterni Livello delle Sorgenti Strumenti ETL Dati riconciliati Livello di alimentazione Caricamento Metadati Data Warehouse Data mart Livello del Warehouse Strumenti di reportistica Strumenti per l analisi what-if Livello di Analisi Strumenti OLAP Strumenti di Data Mining Figura 1.5. Architettura a tre livelli per un sistema di Data Warehousing D altro canto, i dati riconciliati introducono un ulteriore ridondanza rispetto ai dati operazionali sorgente. Va, comunque, detto che, in realtà, si può assumere che anche nelle architetture a due livelli sia presente un livello riconciliato, che non sarà, in quel caso, materializzato ma soltanto virtuale, essendo definito come una vista integrata e consistente dei dati memorizzati nelle sorgenti operazionali.

10 1 I fondamenti del Data Warehousing 1.5 I Metadati Il termine Metadati si applica ai dati usati per descrivere altri dati. Nel contesto del Data Warehousing, in cui giocano un ruolo sostanziale, essi indicano le sorgenti, il valore, l uso e le funzioni dei dati memorizzati nel DW e descrivono come i dati vengono alterati e trasformati durante il passaggio attraverso i diversi livelli dell architettura. Come mostrato nelle Figure 1.3, 1.4 e 1.5, il contenitore dei metadati è strettamente collegato al DW vero e proprio; le applicazioni ne fanno un intenso uso sia dal lato dell alimentazione che da quello dell analisi. È possibile distinguere due categorie di metadati, parzialmente sovrapposte, in base ai diversi utilizzi che ne fanno l amministratore del sistema e gli utenti finali. I metadati interni, di interesse per l amministratore, descrivono, tra le altre cose, le sorgenti, le trasformazioni, le politiche di alimentazione, gli schemi logici e fisici, i vincoli e i profili degli utenti. I metadati esterni, di interesse per gli utenti, riguardano, per esempio, le definizioni, la qualità, le unità di misura e le aggregazioni significative. I metadati vengono memorizzati in un apposito contenitore al quale possono accedere tutti gli altri componenti dell architettura. Requisiti desiderabili per lo strumento di gestione dei metadati sono i seguenti: permettere di svolgere funzioni di amministrazione, legate, in particolare, alla sicurezza; rendere possibile il browsing e l interrogazione dei metadati da parte degli utenti finali; essere dotato di un interfaccia grafica; permettere l estensione dei metadati da parte degli utenti; essere aperto a importazioni/esportazioni dei metadati verso altri strumenti e formati standard. Per quanto concerne il formato di rappresentazione, OMG ha recentemente proposto uno standard denominato Common Warehouse Metamodel (CWM), che si poggia su tre standard affermati quali UML (Unified Modeling Language), XML (extensible Markup Language) e XMI (XML Metadata Interchange) ed è stato elaborato grazie allo sforzo congiunto di vari partner tra cui IBM, Unisys, NCR e Oracle. CWM descrive lo scambio di metadati tra tecnologie legate al Data Warehousing, alla Business Intelligence, alla gestione della conoscenza e ai portali Web. 1.6 Qualità di un Data Warehouse La qualità di un processo misura la sua aderenza agli obiettivi degli utenti. Nel caso di sistemi di Data Warehousing, in virtù della loro natura e del loro utilizzo, la qualità deve essere intesa non solo a livello dei singoli dati ma, soprattutto, con riferimento all intero sistema integrato. Il problema di definire, misurare e massimizzare la qualità di un sistema di DW è molto complesso. Ci limitiamo, pertanto, a segnalare alcuni tra i fattori che caratterizzano la qualità dei dati: Accuratezza: il valore memorizzato è conforme a quello reale. Attualità: il dato memorizzato non è obsoleto. Completezza: non mancano informazioni. Consistenza: la rappresentazione dei dati è uniforme. Disponibilità: i dati sono facilmente disponibili all utente. Tracciabilità: è possibile risalire alla fonte di ciascun dato. Chiarezza: i dati sono facilmente interpretabili.

2 Il modello multidimensionale e l OLAP Questo capitolo ha lo scopo di illustrare due aspetti molto importanti del Data Warehousing, ovvero il modello multidimensionale e l OLAP. Più specificatamente, la prima parte del capitolo illustra le caratteristiche del modello multidimensionale; successivamente vengono prese in esame le varie tipologie di strumenti per l analisi dei dati memorizzati in un Data Warehouse. In particolare, esamineremo dapprima la reportistica e, successivamente, l OLAP. Per quanto riguarda quest ultima tecnica, esamineremo in dettaglio i vari operatori previsti da essa e, successivamente, illustreremo la differenza tra ROLAP e MOLAP. 2.1 Il modello multidimensionale Negli ultimi anni le basi di dati multidimensionali hanno suscitato un vasto interesse di ricerca e di mercato, essendo alla base di varie applicazioni per il supporto alle decisioni, tra cui, in particolare, quelle di Data Warehousing. Il motivo per cui il modello multidimensionale viene adottato come paradigma di rappresentazione dei dati nei DW è, fondamentalmente, legato alla sua semplicità ed intuitività anche per utenti non esperti di informatica; tali proprietà sono, a loro volta, dovute alla vasta diffusione di applicazioni di tipo spreadsheet come strumento di produttività individuale. Per un approccio efficace al modello multidimensionale, forse, il miglior punto di partenza è una descrizione del tipo di interrogazioni alla cui soddisfazione esso si presta maggiormente. Alcune classiche interrogazioni orientate al processo decisionale sono le seguenti: Che incassi sono stati registrati l anno scorso per ciascuna regione e ciascuna categoria di prodotto? Che correlazione esiste tra l andamento dei titoli azionari dei produttori di PC e i profitti trimestrali lungo gli ultimi 5 anni? Quali sono gli ordini che massimizzano gli incassi? Quale di due nuove terapie comporterà una diminuzione della durata media di un ricovero? Che rapporto c è tra i profitti realizzati con spedizioni con meno di 10 elementi e quelli realizzati con spedizioni con più di 10 elementi? È chiaro che esprimere interrogazioni di questa natura tramite linguaggi tradizionali come SQL risulta alquanto complesso ed è altrettanto chiaro che la loro esecuzione su database operazionali porterebbe a tempi di risposta difficilmente accettabili. Il modello multidimensionale prende le mosse dalla constatazione che gli oggetti che influenzano il processo decisionale sono fatti del mondo aziendale, quali, per esempio, le vendite, le spedizioni, i ricoveri, gli interventi chirurgici. Le occorrenze di un fatto corrispondono ad eventi accaduti: ciascuna vendita o spedizione effettuata è un evento. Per ciascun fatto interessano, in particolare, i valori di un insieme di misure che descrivono quantitativamente gli eventi: l incasso di una vendita, la quantità spedita, il costo di un ricovero, la durata di un intervento chirurgico. Gli eventi che accadono nell azienda sono, evidentemente, tantissimi, troppi per poter essere analizzati singolarmente. Per poterli selezionare e raggruppare agevolmente si immagina, allora, di collocarli in uno spazio n-dimensionale i cui assi, chiamati, appunto, dimensioni di analisi, definiscono varie prospettive per la loro identificazione.

12 2 Il modello multidimensionale e l OLAP Per esempio, le vendite in una catena di negozi possono essere rappresentate in uno spazio tridimensionale le cui dimensioni sono i prodotti, i negozi e le date. Per le spedizioni, le dimensioni possono essere il prodotto, la data di spedizione, l ordine, la destinazione e la modalità. I ricoveri possono essere identificati dalla terna reparto, data, paziente, mentre per gli interventi chirurgici occorre aggiungere il tipo di intervento. È, proprio, il concetto di dimensione che ha dato origine alla diffusissima metafora del cubo per la rappresentazione dei dati multidimensionali. Secondo questa metafora, gli eventi corrispondono a celle di un cubo i cui spigoli rappresentano le dimensioni di analisi (se le dimensioni sono più di tre, si tratta più propriamente di un ipercubo). Ciascuna cella del cubo contiene un valore per ogni misura. La Figura 2.1 mostra una rappresentazione grafica intuitiva di un cubo in cui il fatto descritto è la vendita in una catena di negozi. Le dimensioni di analisi sono negozio, prodotto e data; un evento corrisponde alla vendita di un determinato prodotto in un determinato negozio in un particolare giorno, ed è descritto da due misure: la quantità venduta e l incasso. Figura 2.1. Il cubo a tre dimensioni che modella le vendite in una catena di negozi La figura mette in evidenza il fatto che il cubo è sparso, ossia che molti eventi non si sono, in effetti, verificati: chiaramente, non tutti i prodotti possono essere venduti tutti i giorni in tutti i negozi! Se si volesse rappresentare il cubo delle vendite mediante il modello relazionale, lo si potrebbe fare tramite lo schema relazionale: VENDITE(negozio, prodotto, data, quantità, incasso) in cui gli attributi sottolineati sono quelli che costituiscono la chiave primaria e gli eventi corrispondono a tuple (per esempio, DiTutto, Brillo, 5/4/01, 10, 25 ). Il vincolo espresso dalla chiave primaria asserisce che non possono esistere due eventi associati alla stessa terna di valori di negozio, prodotto e data, ma anche che ciascuna terna di valori determina funzionalmente un unico valore di quantità e un unico valore di incasso. In altre parole, esiste una dipendenza funzionale del tipo: negozio, prodotto, data quantità, incasso La definizione di dipendenza funzionale proviene dalla teoria relazionale. Dato uno schema relazionale R e due insiemi di attributi X = a 1,...,a n e Y = b 1,...,b m, si dice che X determina funzionalmente Y (scritto X Y ) se e solo se, per tutte le istanze legali r di R, per ciascuna coppia di tuple t 1 e t 2 di r si ha che t 1 [x] = t 2 [x] implica t 1 [y] = t 2 [y]. Per estensione, nel seguito, diremo che esiste una dipendenza funzionale tra due insiemi di attributi X ed Y quando a ciascun insieme di valori di X corrisponde, necessariamente, nel dominio applicativo, un unico insieme di valori di Y. Per semplicità di notazione, nell enumerare gli elementi di ciascun insieme, elimineremo le parentesi graffe. Per evitare malintesi sul significato del termine evento, è importante, a questo punto, precisare che l insieme delle dimensioni prescelte per rappresentare un fatto identifica univocamente un evento nel modello multidimensionale, ma non necessariamente un evento del dominio applicativo. Per chiarire questa affermazione apparentemente strana, si consideri ancora il caso delle vendite. Nel dominio applicativo un singolo evento di vendita corrisponde, presumibilmente, all acquisto, da parte di un

2.1 Il modello multidimensionale 13 cliente, di un insieme di prodotti in un negozio in una certa data: in pratica, al concetto di scontrino. Dal punto di vista del modello multidimensionale, invece, se il fatto VENDITE ha dimensioni prodotto, negozio e data, un evento corrisponde al venduto giornaliero complessivo di un determinato prodotto in uno specifico negozio. Come è evidente, la differenza tra le due interpretazioni dipende, da un lato, dal fatto che uno scontrino contiene, in generale, più prodotti, dall altro dal fatto che uno stesso prodotto viene, in generale, venduto più volte nello stesso giorno e nello stesso negozio. Nel seguito, quando non diversamente specificato, useremo il termine evento, e di conseguenza il termine fatto, con riferimento alla granularità che esso assume nel modello multidimensionale. Normalmente, ciascuna dimensione è associata ad una gerarchia di livelli di aggregazione (chiamata, a volte, gerarchia di roll-up) che ne raggruppa i valori in diversi modi. Chiameremo attributi dimensionali i livelli che compongono una gerarchia. La Figura 2.2 propone un piccolo esempio di gerarchie sulle dimensioni prodotto e negozio: i prodotti sono raggruppati in tipi, ulteriormente suddivisi in categorie; i negozi si trovano in città che, a loro volta, fanno parte di regioni. In cima a ciascuna gerarchia si trova un livello fittizio che raggruppa tutti i valori relativi a una dimensione. Prodotto Tipo Categoria Brillo Sbianco Lucido Manipulite Scent Latte fresco slurp Latte UHT slurp Yogurt slurp Bevimi Colissima Detersivo Sapone Latticino Bibita Pulizia casa Alimentari Tutti i prodotti Negozio Città Regione DiTutto2 Bologna Emilia Romagna Tutti i negozi Nonsolopappa Milano DiTutto Lombardia DiTutto3 Como Figura 2.2. Gerarchie di aggregazione sulle dimensioni prodotto e negozio Dal punto di vista della teoria relazionale, una gerarchia è esprimibile tramite un insieme di dipendenze funzionali tra attributi dimensionali: prodotto tipo categoria negozio città regione Riassumendo, un cubo multidimensionale è incentrato su un fatto di interesse per il processo decisionale. Esso rappresenta un insieme di eventi descritti quantitativamente da misure numeriche. Ogni asse del cubo rappresenta una possibile dimensione di analisi; ciascuna dimensione può essere vista a più livelli di dettaglio, individuati da attributi strutturati in gerarchie. Osserviamo, ora, che le informazioni rappresentate nel cubo multidimensionale, pur costituendo, di fatto, una sintesi di quelle memorizzate nella base di dati operazionale (dove, per esempio, vengono distinte le singole vendite), sono ancora difficilmente fruibili dall utente a causa della loro quantità. Se la catena comprende 50 negozi che vendono complessivamente 1000 prodotti, e il DW copre 3 anni di transazioni (circa 1000 giorni), il numero totale di eventi possibili risulta pari a 50 1000 1000 = 5 10 7. Anche supponendo che, in ciascun giorno, ogni negozio riesca a vendere solo il 10% dei prodotti disponibili, il numero complessivo degli eventi risulta pari a 5 10 6, ancora troppi per poter essere analizzati da un utente senza far ricorso a strumenti automatici.

14 2 Il modello multidimensionale e l OLAP Le tecniche per ridurre la quantità dei dati e ottenere, così, informazioni utili sono essenzialmente due: la restrizione e l aggregazione; per entrambe, come vedremo nei due paragrafi seguenti, la metafora del cubo offre un agile e intuitiva chiave di interpretazione. 2.1.1 Restrizione Restringere i dati significa ritagliare una porzione del cubo circoscrivendo il campo di analisi; ciò implica, nella terminologia dell Algebra Relazionale, effettuare selezioni e/o proiezioni. La forma più semplice di restrizione è il cosiddetto slicing (letteralmente, affettatura) dei dati, illustrato nella Figura 2.3, in cui si riduce la dimensionalità del cubo fissando un valore per una o più dimensioni. Figura 2.3. Slicing di un cubo tridimensionale Vediamo un esempio per il cubo delle vendite. Se si fissa un valore per una delle dimensioni, per esempio negozio = DiTutto, si ottiene come risultato l insieme degli eventi associati alle vendite effettuate presso il negozio DiTutto; secondo la metafora si tratterà di un piano, ovvero una fettina di dati agevolmente visualizzabile all interno di un foglio elettronico (secondo le ipotesi sui volumi di dati introdotte in precedenza, si avranno circa 10 5 eventi). Se vengono fissate due dimensioni, per esempio negozio = DiTutto e data = 5/4/2001, il risultato sono tutte le vendite di prodotti distinti effettuate presso DiTutto il 5/4/2001 (circa 100 eventi); ciò è rappresentato, graficamente, dall intersezione di due piani perpendicolari, ovvero una retta. Infine, se tutte le dimensioni vengono fissate, si identifica un unico evento corrispondente ad un punto nello spazio tridimensionale delle vendite. La selezione è una generalizzazione dello slicing in cui si riduce la grandezza del cubo esprimendo condizioni sugli attributi dimensionali. Per esempio, si possono selezionare le sole vendite di detersivo Brillo nei negozi di Bologna nei giorni di gennaio 2001. In questo modo, se i 50 negozi sono uniformemente distribuiti su 10 città, il numero di eventi da esaminare passa a 5 31 = 155, comodamente visionabile all interno di una matrice bidimensionale o di un grafo. Infine, la proiezione è riconducibile alla scelta di mantenere, per ciascun evento, un sottoinsieme di misure, scartando le altre.

2.1 Il modello multidimensionale 15 2.1.2 Aggregazione L aggregazione è un meccanismo di importanza fondamentale nelle basi di dati multidimensionali. Si supponga di voler analizzare le vendite non nel loro dettaglio giornaliero, bensì a livello mensile; continuando la metafora del cubo, ciò significa raggruppare, per ciascun prodotto e negozio, tutte le celle relative ai giorni di uno stesso mese in un unica macro-cella. Nel cubo così aggregato, il numero complessivo di eventi (inteso come il numero di macro-celle risultanti) sarà pari a 50 1000 36, poiché, sulla dimensione tempo, la granularità non è più a livello di giorno ma di mese, e 36 sono i mesi del triennio. Ciascun evento conterrà una sintesi dei dati presenti negli eventi che esso aggrega: nel caso in esame, il numero totale di esemplari venduti nel mese e l incasso complessivo calcolati sommando i valori elementari delle corrispondenti misure (si veda la Tabella 2.1). Data DiTutto DiTutto2 Nonsolopappa 1/1/2000 - - - 2/1/2000 10 15 5 3/1/2000 20-5............ 1/1/2001 - - - 2/1/2001 15 10 20 3/1/2001 20 20 25............ 1/1/2002 - - - 2/1/2002 20 8 25 3/1/2002 20 12 20............ Data DiTutto DiTutto2 Nonsolopappa Gennaio 2000 200 180 150 Febbraio 2000 180 150 120 Marzo 2000 220 180 160............ Gennaio 2001 350 220 200 Febbraio 2001 300 200 250 Marzo 2001 310 180 300............ Gennaio 2002 380 200 220 Febbraio 2002 310 200 250 Marzo 2002 300 160 280............ Data DiTutto DiTutto2 Nonsolopappa 2000 2400 2000 1600 2001 3200 2300 3000 2002 3400 2200 3200 Data DiTutto DiTutto2 Nonsolopappa Totale 9000 6500 7800 Tabella 2.1. Aggregazione sulla gerarchia temporale operata sulle quantità vendute per un dato prodotto in tre negozi Aggregando ulteriormente sul tempo, per ogni combinazione prodotto-negozio, si possono ottenere tre soli eventi, uno per ciascun anno. Al massimo livello di aggregazione sulla dimensione tempo, ciascuna combinazione corrisponde ad un unico evento che riporta il numero totale di esemplari di un prodotto venduti in un negozio nei tre anni e l incasso complessivo. L aggregazione può essere operata contemporaneamente su più dimensioni. Per esempio, come mostrato in Figura 2.4, è possibile aggregare le vendite per mese, tipo di prodotto e città del negozio, nonchè solo per mese e tipo di prodotto. Inoltre, selezione e aggregazione possono essere combinate per permettere un processo di analisi mirato con precisione alle esigenze dell utente.

16 2 Il modello multidimensionale e l OLAP Figura 2.4. Due livelli di aggregazione a partire dai dati elementari 2.2 Tool e tecnologie per il Data Warehousing L ultimo livello comune a tutte le architetture di Data Warehousing è quello dell analisi. Infatti, una volta che i dati sono stati ripuliti, integrati e trasformati, occorre capire come trarre il massimo vantaggio informativo. Esistono, in sostanza, tre approcci differenti (supportati da altrettante categorie di strumenti) all interrogazione di un DW da parte degli utenti finali: reportistica, OLAP e Data Mining. 2.2.1 Reportistica Questo approccio è orientato agli utenti che hanno necessità di accedere, ad intervalli di tempo predefiniti, ad informazioni strutturate in modo pressocchè invariabile. Per esempio, un azienda sanitaria locale deve consegnare agli uffici regionali rapporti mensili riepilogativi sui costi di ricovero sostenuti. Di questi rapporti è nota a priori la forma, che cambia solo a seguito della normativa vigente. Il progettista può, allora, progettare l interrogazione che genera il rapporto nella forma voluta e congelarla all interno di un applicazione perchè possa essere eseguita sui dati correnti quando l utente ne ha l effettiva necessità. Un rapporto è definito da un interrogazione e da una presentazione. L interrogazione comporta, in genere, la selezione e l aggregazione dei dati multidimensionali: per esempio, essa può richiedere gli incassi mensili durante l ultimo trimestre per ciascuna categoria di prodotto. La presentazione può essere in forma tabellare oppure grafica (diagramma, istogramma, torta, ecc.); la Figura 2.5 mostra alcuni esempi di presentazione per l interrogazione precedentemente riportata. Uno strumento di reportistica si valuta non solo in base alla ricchezza nella presentazione dei rapporti, ma anche considerando la flessibilità nei meccanismi per la loro distribuzione. Il rapporto può essere generato su richiesta esplicita dell utente oppure distribuito automaticamente e periodicamente agli utenti registrati, per esempio tramite un servizio di posta elettronica. È opportuno evidenziare che la reportistica non è certamente nata con il Data Warehousing: da quando esistono le basi di dati i rapporti sono sempre stati il mezzo principale su cui la direzione ha potuto basare le attività di valutazione e pianificazione. D altronde, il Data Warehousing ha arrecato alla reportistica due grandi benefici: dal punto di vista dell affidabilità e della correttezza dei risultati, poichè i dati di cui i rapporti offrono la sintesi sono ora consistenti e integrati, e dal punto di vista della tempestività, poichè la separazione architetturale tra l elaborazione delle transazioni e quella analitica migliora significativamente le prestazioni di calcolo. 2.2.2 OLAP L OLAP è, probabilmente, la principale modalità di fruizione delle informazioni contenute in un DW; sicuramente esso rappresenta la modalità più conosciuta e consente ad utenti le cui necessità di analisi

2.2 Tool e tecnologie per il Data Warehousing 17 Figura 2.5. Presentazione di un rapporto: tabelle, diagramma, torta non siano facilmente identificabili a priori di analizzare ed esplorare interattivamente i dati sulla base del modello multidimensionale. Mentre gli utenti degli strumenti di reportistica svolgono un ruolo essenzialmente passivo, gli utenti OLAP sono in grado di costruire attivamente una sessione di analisi complessa in cui ciascun passo effettuato è conseguenza dei risultati ottenuti al passo precedente. Il carattere estemporaneo delle sessioni di lavoro, l approfondita conoscenza dei dati richiesta, la complessità delle interrogazioni formulabili e l orientamento verso utenti tipicamente non esperti di informatica rendono cruciale il ruolo dello strumento utilizzato, la cui interfaccia deve necessariamente presentare ottime caratteristiche di flessibilità, facilità d uso ed efficacia. Una sessione OLAP consiste, in pratica, in un percorso di navigazione che riflette il procedimento di analisi di uno o più fatti di interesse sotto diversi aspetti e a diversi livelli di dettaglio. Questo percorso si concretizza in una sequenza di interrogazioni che spesso non vengono formulate direttamente, ma per differenza rispetto all interrogazione precedente. Il risultato delle interrogazioni è di tipo multidimensionale; poichè le capacità umane di ragionare in più di tre dimensioni sono molto limitate, gli strumenti OLAP rappresentano tipicamente i dati in modo tabellare, evidenziando le diverse dimensioni mediante intestazioni multiple, colori, ecc. Ogni passo della sessione di analisi è scandito dall applicazione di un operatore OLAP che trasforma l ultima interrogazione formulata in una nuova interrogazione. Gli operatori più comuni sono roll-up, drill-down, slice-and-dice, pivoting, drill-across, drillthrough. Nel seguito illustreremo tali operatori mediante un esempio che descrive un grande magazzino virtuale, V-Mall, che effettua vendite da catalogo via telefono e Internet. Le gerarchie di attributi di interesse per il fatto delle vendite nel V-Mall sono rappresentate in Figura 2.6. Year (anno) Quarter (trimestre) Category (categoria) Customer Region (regione cliente) Month (mese) Subcategory (categoria second.) Customer City (città cliente) Time (data) Product (articolo) Customer (cliente) Figura 2.6. Le gerarchie di attributi nel V-Mall; le frecce indicano dipendenze funzionali

18 2 Il modello multidimensionale e l OLAP Roll-up Roll-up significa, letteralmente, arrotolare o alzare, e induce un aumento nell aggregazione dei dati eliminando un livello di dettaglio da una gerarchia. Si supponga, per esempio, che l utente stia visualizzando gli incassi mensili del 97 e 98 per ciascuna regione del cliente; come mostrato in Figura 2.7, effettuare un roll-up può significare eliminare il dettaglio sui singoli mesi per visualizzare gli incassi trimestrali complessivi per ciascuna regione. Figura 2.7. Roll-up sulla gerarchia temporale Il roll-up può anche portare alla diminuzione della dimensionalità del risultato, qualora tutti i dettagli di una gerarchia vengano eliminati; con riferimento alla Figura 2.8, ciò può significare, per esempio, eliminare le informazioni relative ai clienti e visualizzare gli incassi annuali totali per ciascuna categoria di prodotto, passando da una tabella tridimensionale ad una bidimensionale. Figura 2.8. Roll-up con eliminazione della gerarchia cliente

2.2 Tool e tecnologie per il Data Warehousing 19 La Figura 2.9 schematizza l operazione di roll-up, con e senza diminuzione della dimensionalità, attraverso la metafora del cubo. Figura 2.9. Roll-up (a sinistra) e drill-down (a destra) su un cubo Drill-down L operatore di drill-down (letteralmente, trivellare) è duale al roll-up: infatti, come mostrato in Figura 2.9, esso diminuisce l aggregazione dei dati introducendo un ulteriore livello di dettaglio in una gerarchia. La Figura 2.10 mostra un esempio su una tabella bidimensionale, in cui si passa dall aggregazione per regione del cliente a quella, più fine, per città del cliente. Figura 2.10. Drill-down sulla gerarchia del cliente Nel caso della Figura 2.11, il drill-down comporta l aumento della dimensionalità della tabella a seguito dell aggiunta del dettaglio sulle regioni dei clienti. Slice-and-Dice Il termine slice-and-dice (letteralmente, tagliare a fette e cubetti) è uno dei più abusati nella letteratura sul Data Warehousing, anche se viene utilizzato con significati diversi. Alcuni autori lo usano per denotare, genericamente, l intero processo di navigazione OLAP; altri autori lo utilizzano per indicare operazioni di selezione e proiezione sui dati. Noi chiameremo slicing l operazione che riduce la dimensionalità del cubo, fissando un valore per una delle dimensioni, mentre chiameremo selezione o filtraggio l operazione che riduce l insieme dei dati oggetto di analisi attraverso la formulazione di un criterio di selezione (Figura 2.12). Le Figure 2.13 e 2.14 mostrano esempi di slicing e di selezione.

20 2 Il modello multidimensionale e l OLAP Figura 2.11. Drill-down con l aggiunta di una dimensione Figura 2.12. Slicing (sopra) e selezione (sotto) di un cubo Figura 2.13. Slicing sul predicato Year = 1998 Pivoting L operazione di pivoting comporta un cambiamento nella modalità di presentazione con l obiettivo di analizzare le stesse informazioni sotto diversi punti di vista. Seguendo la metafora multidimensionale, effettuare il pivoting significa ruotare il cubo in modo da riorganizzare le celle secondo una nuova prospettiva, ovvero portando in primo piano una diversa combinazione di dimensioni (Figura 2.15). Le Figure 2.16 e 2.17 illustrano esempi di pivoting su tabelle bi- e tri-dimensionali.

2.2 Tool e tecnologie per il Data Warehousing 21 Figura 2.14. Selezione su un predicato complesso Figura 2.15. Pivoting di un cubo Figura 2.16. Pivoting su una tabella bidimensionale Drill-Across Con il termine drill-across si intende la possibilità di stabilire un collegamento tra due o più cubi correlati al fine di compararne i dati, per esempio calcolando espressioni che coinvolgono misure derivate dai due cubi (Figura 2.18). In Figura 2.19 viene riportato un esempio di drill-across tra il cubo delle vendite e il cubo delle promozioni per confrontare gli incassi e gli sconti per ciascun trimestre e per ciascuna categoria di prodotti.

22 2 Il modello multidimensionale e l OLAP Figura 2.17. Pivoting su una tabella tridimensionale Figura 2.18. Drill-across tra due cubi Figura 2.19. Drill-across tra il cubo delle vendite (misura Dollar Sales) e quello delle promozioni (misura Discount) 2.3 ROLAP e MOLAP I termini ROLAP e MOLAP vengono utilizzati per denotare i due principali approcci all implementazione dei DW; essi differiscono per ciò che riguarda il modello logico utilizzato per la rappresentazione dei dati; più specificatamente, ROLAP sta per Relational OLAP, ovvero implementazione

2.3 ROLAP e MOLAP 23 su DBMS relazionale, MOLAP sta per Multidimensional OLAP, ovvero implementazione su DBMS multidimensionale. L idea di adottare tecnologie relazionali per la memorizzazione dei dati nel DW è ben motivata se si considerano l enorme lavoro svolto in letteratura sul modello relazionale, la diffusa esperienza aziendale sull utilizzo e l amministrazione di basi di dati relazionali e l elevato livello di prestazioni e flessibilità raggiunto dai DBMS relazionali. Evidentemente, poichè l espressività del modello relazionale non include i concetti di dimensioni, misura e gerarchia, si rende necessario elaborare tipologie specifiche di schemi che permettano di traslare il modello multidimensionale sui mattoni di base del modello relazionale costituiti da attributi, relazioni e vincoli di integrità. Questo ruolo è svolto principalmente dal celebre star scheme, o schema a stella. Il problema principale delle implementazioni ROLAP è legato alle prestazioni che soffrono della necessità di eseguire costose operazioni di join tra tabelle di elevate dimensioni. Al fine di ridurre il numero di join, una delle parole d ordine del ROLAP è denormalizzazione, ovvero violazione consapevole della terza forma normale orientata alla massimizzazione delle prestazioni. Sempre per ridurre i costi di esecuzione, l altra parola d ordine è ridondanza, che si ottiene materializzando un certo numero di tabelle derivate (viste) che offrono una lettura sintetica dei dati utile per le tipiche interrogazioni OLAP fortemente aggregate. Dal punto di vista architetturale, l adozione della soluzione ROLAP richiede di predisporre un middleware specializzato intermedio tra un server back-end relazionale e il lato front-end, come illustrato in Figura 2.20. Il middleware riceve le interrogazioni OLAP formulate dall utente sullo strumento di front-end e, consultando i metadati, le traduce in istruzioni SQL per il back-end relazionale. Back-end Front-end Server relazionale Middleware Client OLAP Metadati Figura 2.20. Architettura ROLAP Un componente particolarmente importante durante questa fase è il cosiddetto aggregate navigator; questo, in presenza di viste aggregate, si incarica di determinare, tra tutte le viste su cui una data interrogazione può essere risolta, quella che comporta il minimo costo di accesso. In alcune soluzioni commerciali, il middleware è visto come un componente separato che può essere abbinato a un qualsiasi server relazionale per creare un server monoblocco, specializzato nella gestione dei dati multidimensionali. Diversamente dal ROLAP, un modello MOLAP si basa su un modello logico ad hoc sul quale i dati e le operazioni multidimensionali possono essere direttamente rappresentati. Nelle basi di dati multidimensionali, infatti, i dati vengono fisicamente memorizzati in vettori (array) e l accesso è di tipo posizionale. Tra le tecnologie adottate a questo scopo ricordiamo i grid-file, gli R*-tree e gli UB-tree. Il grosso vantaggio dell approccio MOLAP rispetto a quello ROLAP è che le operazioni multidimensionali sono realizzabili in modo semplice e naturale, senza necessità di ricorrere a complesse operazioni di join; le prestazioni di questi sistemi risultano, pertanto, ottime. D altro canto, non esistendo ancora uno standard per il modello logico multidimensionale, le diverse implementazioni MOLAP hanno veramente poco in comune; in genere, l unica cosa in comune è l utilizzo di tecnologie di ottimizzazione specifiche per trattare il problema della sparsità.

24 2 Il modello multidimensionale e l OLAP Concludiamo questa sezione menzionando brevemente l esistenza di un terzo approccio, intermedio tra i precedenti: il cosiddetto HOLAP, o Hybrid OLAP. Un esempio di sistema commerciale HOLAP è Express Server della Oracle che può gestire contemporaneamente dati relazionali e multidimensionali.

3 Modelli logici a supporto del Data Warehousing In questo capitolo prenderemo in considerazione i modelli logici a supporto del Data Warehousing, ovvero quei modelli capaci di tradurre, a livello logico, i concetti di base tipici del modello multidimensionale. Più specificatamente, i modelli che prenderemo in considerazione saranno lo schema a stella e lo schema a fiocco di neve. Nel capitolo discuteremo, anche, del problema della materializzazione delle viste. 3.1 Lo schema a stella La modellazione multidimensionale su sistemi relazionali è basata sul cosiddetto schema a stella (star schema) e sulle sue varianti. Definizione 3.1. Uno schema a stella è composto da: Un insieme di relazioni DT 1,...,DT n, denominate dimension table, ciascuna corrispondente a una dimensione. Ciascuna DT i è caratterizzata da una chiave primaria (tipicamente surrogata) d i e da un insieme di attributi che descrivono le dimensioni di analisi a diversi livelli di aggregazione. Una relazione FT, denominata fact table, che importa le chiavi di tutte le dimension table. La chiave primaria di FT è data dall insieme delle chiavi esterne delle dimension table d 1,...,d n ; FT contiene, inoltre, un attributo per ogni misura. L esempio di Figura 3.1 mostra lo schema a stella per il fatto delle vendite. La chiave della fact table VENDITE è costituita dalla combinazione delle chiavi esterne dalle tre dimension table. È interessante notare che: La visione multidimensionale dei dati si ottiene eseguendo un operazione di join tra la fact table e le diverse dimension table. Per il fatto delle vendite di Figura 3.1 l interrogazione SQL che ricostruisce le celle associando i valori delle misure ai corrispondenti valori degli attributi presenti nelle gerarchie è la seguente: SELECT * FROM Vendite AS FT, Prodotto AS DT1, Negozio AS DT2, Data AS DT3 WHERE FT.chiaveP = DT1.chiaveP AND FT.chiaveN = DT2.chiaveN AND FT.chiaveD = DT3.chiaveD Le chiavi delle dimension table sono surrogate al fine di ridurre lo spazio richiesto per la loro importazione nella fact table. Le dimension table non sono in terza forma normale, poichè la presenza contemporanea di tutti gli attributi di una gerarchia dà luogo a dipendenze funzionali transitive 1. 1 Una relazione si dice in terza forma normale quando nessuno dei suoi attributi non primi (quelli che non fanno parte di chiavi candidate) dipende transitivamente da una chiave. Una dipendenza transitiva ha la forma a b, b c

26 3 Modelli logici a supporto del Data Warehousing DATA chiaved data mese trimestre anno giorno settimana vacanza VENDITE chiaven chiaved chiavep quantità venduta incasso prezzo unitario numero clienti NEGOZIO chiaven negozio città negozio regione negozio stato negozio responsabile distretto PRODOTTO chiavep prodotto tipo categoria reparto gruppo marketing marca città marca Figura 3.1. Schema a stella per le vendite; in corsivo sono rappresentate le chiavi delle relazioni L assenza della terza forma normale introduce una ridondanza (per esempio, la categoria di un tipo di prodotto viene ripetuta per ciascun prodotto di quel tipo) e, quindi, richiede più spazio su disco per la memorizzazione dei dati; tuttavia, al contempo, riduce il numero dei join necessari al reperimento delle informazioni. Si tenga presente che i tradizionali problemi legati alla normalizzazione (le cosiddette anomalie di inserimento, cancellazione e modifica) non destano preoccupazione alcuna, in quanto le gerarchie sono prevalentemente statiche. La sparsità non rappresenta un problema dal momento che nella fact table vengono memorizzate soltanto le combinazioni di chiavi per le quali esiste effettivamente l informazione. Nell esempio di Figura 3.2 è rappresentata una possibile istanza del precedente schema a stella; in tale esempio gli attributi chiave sono sottolineati. La prima tupla della fact table è ralativa alla vendita di Latte Slurp effettuata il 2/9/2001 nel negozio COOP1 di Bologna, mentre la terza tupla è relativa alla vendita di Yogurt Slurp effettuata il 3/10/2001 presso la sede COOP3. Si noti come la denormalizzazione delle dimension table comporti la duplicazione di molti valori: per esempio, per ogni prodotto di tipo latticino, si ripete che la categoria corrispondente è alimentari. La caratteristica più evidente di questa soluzione è, senza dubbio, la denormalizzazione delle dimension table, giustificata dalla riduzione del costo di reperimento dei dati. Si consideri, d altronde, che la cardinalità delle dimension table è, normalmente, molto inferiore rispetto a quella delle fact table e, conseguentemente, l aumento della dimensione totale del database risulta trascurabile. 3.2 Lo schema a fiocco di neve Una delle principali caratteristiche dello schema a stella è la presenza di dipendenze funzionali transitive nelle dimension table che fanno si che queste ultime non siano in terza forma normale (per esempio, la dimension table NEGOZIO di Figura 3.2 contiene la dipendenza funzionale transitiva negozio città negozio, città negozio regione negozio). Sebbene la presenza di questo tipo di dipendenze permetta di eseguire più rapidamente le interrogazioni, può essere utile ridurre il livello di denormalizzazione al fine di ottenere uno schema logico più vicino ai dettami della teoria relazionale. Su questa considerazione si basa lo schema a fiocco di neve (snowflake schema) caratterizzato dalla normalizzazione, in genere parziale, delle dimension table.

3.2 Lo schema a fiocco di neve 27 VENDITE chiaven chiaved chiavep qtà venduta incasso... 1 1 1 170 85... 2 1 2 320 160... 3 2 3 412 412..................... NEGOZIO chiaven negozio città regione... 1 COOP1 Bologna Emilia Romagna... 2 COOP2 Roma Lazio... 3 COOP3 Roma Lazio.................. PRODOTTO chiavep prodotto tipo categoria marca... 1 Latte Slurp latticino alimentari Slurp... 2 Latte Gnam latticino alimentari Gnam... 3 Yogurt Slurp latticino alimentari Slurp..................... DATA chiaved data mese anno... 1 2/9/2001 9/2001 2001... 2 3/10/2001 10/2001 2001... 3 5/10/2001 10/2001 2001.................. Figura 3.2. Una possibile istanza dello schema a stella di Figura 3.1 Definizione 3.2. Uno schema snowflake è ottenibile da uno schema a stella decomponendo una o più dimension table DT i in più dimension table DTi 1,...,DT im in modo da eliminare alcune delle dipendenze funzionali transitive in esse presenti. Ogni dimension table sarà caratterizzata da: una chiave primaria (tipicamente surrogata) d ij ; un sottoinsieme degli attributi di DT i che dipendono funzionalmente da d ij ; zero o più chiavi esterne riferite ad altre DT ij necessarie a garantire la ricostruibilità del contenuto informativo di DT i. Denominiamo primarie le dimension table le cui chiavi vengono importate nella fact table, secondarie le dimension table rimanenti. Uno schema snowflake è ottenuto eliminando progressivamente alcune delle dipendenze funzionali transitive presenti nelle dimension table. Ciascun passo di normalizzazione individua una sotto-gerarchia che verrà memorizzata separatamente. Un esempio di schema snowflake è riportato in Figura 3.3. Tramite l introduzione delle tabelle CITTÀ, TIPO e CATEGORIA si ottiene una parziale normalizzazone dei dati contenuti nelle dimension table; vengono, infatti, spezzate le dipendenze transitive tra negozio e regione, tra prodotto e categoria e tra tipo e reparto. Come conseguenza di quanto detto precedentemente si ha che: Lo spazio richiesto per la memorizzazione dei dati si riduce poichè, per esempio, le corrispondenze tra valori degli attributi città e regione vengono memorizzate una sola volta. Se il numero di negozi per ogni città è elevato, un ulteriore motivo che consente un risparmio di spazio sta nel fatto che a ciascun negozio si abbina il surrogato chiavec (tipicamente 4 byte) invece del campo città (almeno 20 byte).

28 3 Modelli logici a supporto del Data Warehousing DATA chiaved data mese trimestre anno giorno settimana vacanza CATEGORIA chiaveca categoria reparto VENDITE chiaven chiaved chiavep quantità venduta incasso prezzo unitario numero clienti TIPO chiavet tipo chiaveca gruppo marketing NEGOZIO chiaven negozio responsabile distretto chiavec PRODOTTO chiavep prodotto chiavet marca città marca CITTA chiavec città negozio regione negozio stato negozio Figura 3.3. Un possibile schema a fiocco di neve per lo schema a stella presentato in Figura 3.1; in corsivo sono rappresentate le chiavi delle relazioni È necessario inserire nuove chiavi surrogate che permettano di determinare le corrispondenze tra dimension table primarie e secondarie. Per esempio, l importazione di chiavet nella tabella PRODOTTO permette di associare a ciascun prodotto il relativo tipo. L esecuzione di interrogazioni che coinvolgono soltanto gli attributi contenuti nella fact table e nelle dimension table primarie è facilitata poichè le join coinvolgono tabelle di dimensioni inferiori. Il tempo di esecuzione delle interrogazioni che coinvolgono attributi delle dimension table secondarie aumenta poichè è necessario un maggior numero di join. Gli schemi a stella presentano alcune caratteristiche che richiedono particolare cura al fine di ottenere una corretta decomposizione. Oltre a fare attenzione al fatto che la decomposizione non riduca il potere informativo della relazione e non elimini le dipendenze funzionali esistenti nello schema della relazione di partenza, è necessario verificare che nella nuova relazione venga spostato il corretto insieme di attributi. Infatti, gli schemi a stella contengono normalmente più dipendenze funzionali transitive in cascata (per esempio, chiaven negozio, negozio città negozio, città negozio regione negozio, regione negozio stato negozio); pertanto, affinchè la decomposizione sia efficace, è necessario che tutti gli attributi che dipendono, transitivamente e non, dall attributo che ha determinato lo snowflaking siano posti nella nuova relazione. In caso contrario continuerebbero ad esistere altre dipendenze transitive che invaliderebbero la normalizzazione. Per esempio, in Figura 3.4 è mostrata una scorretta normalizzazione della relazione NEGOZIO di Figura 3.1; sebbene la dipendenza transitiva chiaven negozio città negozio sia stata risolta, la presenza dell attributo stato negozio nella relazione NEGOZIO induce una forte ridondanza. Affinchè lo snowflaking sia efficace, tutti gli attributi del sottoalbero dell attributo da cui ha origine la normalizzazione devono essere spostati nella nuova relazione.

3.3 Le viste 29 NEGOZIO chiaven negozio responsabile distretto chiavec stato negozio CITTA chiavec città negozio regione negozio Figura 3.4. Uno schema snowflake scorretto per lo schema a stella presentato in Figura 3.1 3.3 Le viste L enorme quantità dei dati memorizzati nei DW rende difficili le analisi da parte degli utenti che, di conseguenza, tendono a ridurre la porzione da esaminare direttamente tramite operazioni di selezione e aggregazione. Le selezioni permettono di restringere la porzione di dati in esame individuando quelli effettivamente interessanti per la specifica analisi. Con le aggregazioni la riduzione è ottenuta collassando più elementi non aggregati in un unico elemento aggregato (per esempio, calcolando la somma delle quantità vendute in un determinato giorno si analizza un solo dato invece di tanti dati quante sono le vendite giornaliere). Inoltre, tramite l aggregazione, è possibile astrarre da casi specifici ed evidenziare trend generali. Un significativo aumento delle prestazioni può essere ottenuto precalcolando i dati aggregati di uso più comune. Le fact table contenenti dati aggregati sono comunemente dette viste e, dato uno schema di fatto, possono essere individuate dal loro pattern di aggregazione. Nel seguito denoteremo tutte le fact table con il termine viste distinguendo quelle primarie, corrispondenti al pattern primario (il più fine, definito dall insieme delle dimensioni), da quelle secondarie, corrispondenti a pattern secondari (aggregati). Dove ciò non crea ambiguità utilizzeremo il pattern per denotare la vista. Un modo alternativo per individuare le viste secondarie consiste nel verificare se queste possono essere alimentate a partire da altre viste presenti nel DW o se è, invece, necessario ricorrere ai dati operazionali. In Figura 3.5 vengono rappresentate alcune viste ottenibili a partire dallo schema a stella di Figura 3.1. L unica vista primaria è v 1. Una freccia da v i a v j indica che P j P i essendo P i e P j, rispettivamente, i pattern di v i e v j. Conseguentemente, i dati contenuti in v j possono essere calcolati aggregando quelli di v i. Supponendo di adottare lo schema di materializzazione di Figura 3.5, un interrogazione relativa alle vendite che richieda i dati aggregati per tipo di prodotto, data di vendita e città del negozio in cui la vendita è stata effettuata risulterà meno costosa se eseguita sulla vista v 2 piuttosto che sulla vista v 1 poichè essa insisterà su una fact table con un numero ridotto di tuple e non richiederà ulteriori operazioni di aggregazione. Viceversa, un interrogazione che aggreghi le vendite in base a prodotto, data di vendita e città del negozio dovrà essere forzatamente eseguita sulla vista v 1, che è l unica con un pattern di aggregazione sufficientemente fine. Quando si opera con dati aggregati è necessario porre molta attenzione al corretto utilizzo degli operatori di aggregazione. Affinchè dati pre-aggregati possano essere utilizzati per il calcolo di dati ulteriormente aggregati (per esempio, se si vuole calcolare l aggregazione per anno a partire da dati aggregati per quadrimestre), può essere necessario memorizzare ulteriori informazioni. Queste possono essere le misure di supporto o, direttamente, le misure derivate che si intende calcolare.

30 3 Modelli logici a supporto del Data Warehousing v 1={prodotto, data, negozio} v 2={tipo, data, città} v 4={tipo, mese, regione} v 3={categoria, mese, città} v 5={trimestre, regione} Figura 3.5. Alcune viste ottenibili a partire dallo schema a stella presentato in Figura 3.1 Durante la fase di progettazione logica è, pertanto, necessario tenere in considerazione quali operatori dovranno essere utilizzati con le diverse misure aggiungendo, dove necessario, le corrispondenti misure, sia quelle di supporto che quelle derivate. 3.3.1 Schemi relazionali in presenza di dati aggregati In presenza di viste materializzate è possibile adottare diverse varianti del classico schema a stella. La soluzione più semplice consiste nel memorizzare nella stessa fact table sia i dati della vista primaria che quelli delle viste secondarie. Con questa soluzione il livello di aggregazione delle singole tuple della fact table potrà essere identificato solo mediante le corrispondenti tuple nelle dimension table: i record delle dimension table corrispondenti a dati aggregati presenteranno, infatti, dei valori NULL in tutti i campi il cui livello di aggregazione è più fine di quello su cui si sta operando. In Figura 3.6 è rappresentato parte dello schema delle vendite per questa soluzione. VENDITE chiaven chiaved chiavep qtà venduta incasso... 1 1 1 170 85... 2 1 1 300 150... 3 1 1 1700 850..................... NEGOZIO chiaven negozio città regione... 1 COOP1 Bologna Emilia Romagna... 2 - Roma Lazio... 3 - - Lazio.................. Figura 3.6. Memorizzazione di dati aggregati utilizzando una sola fact table Mentre la prima tupla della fact table è relativa a una singola vendita, la seconda memorizza i dati aggregati per tutte le vendite effettuate a Roma; infine, la terza tupla riassume tutte le vendite effettuate nel Lazio. Utilizzando tale soluzione tutte le interrogazioni possono essere risolte sulla stessa fact table. Ciò va a scapito delle prestazioni che si riducono a causa dell enorme dimensione assunta da quest unica tabella. Ad essere penalizzate sono, soprattutto, le interrogazioni che operano su dati aggregati poichè, percentualmente, la porzione di dati che risultano rilevanti per esse è minima. Una seconda soluzione prevede di memorizzare in fact table separate dati relativi a pattern di aggregazione diversi. Le fact table corrispondenti a pattern di aggregazione in cui una o più dimensioni sono completamente aggregate non presenteranno le relative chiavi esterne.

3.3 Le viste 31 La coesistenza di più fact table impone un ulteriore scelta riguardante le dimension table, che possono essere mantenute unificate come nella soluzione precedente (ottenendo il cosiddetto constellation schema, illustrato in Figura 3.7), oppure possono essere replicate per le diverse viste aggregate. DATA chiaved data mese trimestre anno giorno settimana vacanza V 5 chiaved chiaven quantità venduta incasso prezzo unitario numero clienti NEGOZIO chiaven negozio città negozio regione negozio stato negozio responsabile distretto V 1 chiaven chiaved chiavep quantità venduta incasso prezzo unitario numero clienti PRODOTTO chiavep prodotto tipo categoria reparto gruppo marketing marca città marca Figura 3.7. Memorizzazione dei dati aggregati, tramite constellation schema, per lo schema delle vendite Se le dimension table vengono mantenute unificate si ottimizza l accesso alle fact table, ciascuna delle quali conterrà soltanto dati a un particolare livello di aggregazione. Al contrario le dimension table continuano a contenere attributi relativi a livelli diversi delle gerarchie, la loro taglia rimane elevata e continua a essere necessaria l introduzione dei valori NULL nei campi non validi per un particolare livello di aggregazione. La giustificazione per questa soluzione progettuale deriva dalla considerazione che la dimensione delle fact table è notevolmente superiore a quella delle dimension table e conseguentemente la riduzione del costo di esecuzione delle interrogazioni dipende in larga misura dall ottimizzazione delle fact table. Nel caso in cui anche le dimension table vengano replicate, ciascuna di esse conterrà soltanto l insieme di attributi validi per il livello di aggregazione a cui viene utilizzata. In Figura 3.8 vengono rappresentate due diverse viste con le relative dimension table. Si noti come la chiave della fact table secondaria non presenti il campo relativo alla dimensione negozio che è stata completamente aggregata. La soluzione mostrata in Figura 3.8 è quella che promette migliori prestazioni. Infatti, sia l accesso alla fact table che l accesso alle dimension table sono ottimizzati. La massimizzazione delle prestazioni va a scapito dello spazio richiesto per la memorizzazione che cresce non solo a causa del consolidamento dei dati aggregati ma anche a causa delle dimension table ridondanti. Una soluzione intermedia rispetto alle due presentate precedentemente consiste nell applicare lo snowflaking delle dimensioni in corrispondenza dei livelli di aggregazione a cui sono presenti viste aggregate. Questa soluzione consente di usufruire della forte ottimizzazione dovuta alla separazione dei dati aggregati in base al livello di aggregazione senza dover replicare le dimension table, già fortemente ridondanti. In Figura 3.9 il fatto delle vendite viene modellato mediante uno schema snowflake i cui punti di normalizzazione coincidono con gli attributi del pattern della vista aggregata.

32 3 Modelli logici a supporto del Data Warehousing TRIMESTRE chiavet trimestre anno DATA chiaved data mese trimestre anno giorno settimana vacanza V 5 chiavet chiaver quantità venduta incasso prezzo unitario numero clienti V 1 chiaven chiaved chiavep quantità venduta incasso prezzo unitario numero clienti REGIONE chiaver regione negozio stato negozio NEGOZIO chiaven negozio città negozio regione negozio stato negozio responsabile distretto PRODOTTO chiavep prodotto tipo categoria reparto gruppo marketing marca città marca Figura 3.8. Memorizzazione dei dati aggregati, utilizzando più schemi a stella, per lo schema delle vendite TRIMESTRE chiavet trimestre anno DATA chiaved data mese chiavet giorno settimana vacanza V 5 chiavet chiaver quantità venduta incasso prezzo unitario numero clienti V 1 chiaven chiaved chiavep quantità venduta incasso prezzo unitario numero clienti REGIONE chiaver regione negozio stato negozio NEGOZIO chiaven negozio città negozio chiaver responsabile distretto PRODOTTO chiavep prodotto tipo categoria reparto gruppo marketing marca città marca Figura 3.9. Memorizzazione dei dati aggregati, tramite snowflake schema, per lo schema delle vendite

4 Progettazione di un Data Warehouse In questo capitolo illustreremo la metodologia per la progettazione di un Data Warehouse proposta da Kimball, uno dei massimi esperti nel campo dei Data Warehouse. Tale metodologia prevede la progettazione separata dei vari Data Mart che vengono, successivamente, fusi per costruire il Data Warehouse. La progettazione di ciascun Data Mart viene effettuata secondo una sequenza di passi ben definita. 4.1 Metodologia di progettazione di un Data Warehouse In questa sezione descriviamo una metodologia per la progettazione di un Data Warehouse. Essa è stata proposta da Kimball ed è denominata metodologia a nove passi. In realtà, essa specifica i passi richiesti per la progettazione di un Data Mart. Tuttavia, vari Data Mart separati, progettati mediante questa metodologia, possono essere successivamente fusi per ottenere un Data Warehouse complesso coerente. Pertanto, utilizzando questa metodologia, un Data Warehouse consiste nell unione di un insieme di Data Mart separati, implementati in un certo periodo di tempo, eventualmente da team di progetto diversi, ed eventualmente su piattaforme hardware e software differenti. Nel seguito, i vari passi della metodologia in esame verranno descritti uno per ciascuna sezione. Nella loro descrizione si farà riferimento al caso di un agenzia immobiliare. 4.2 Passo 1: Scelta del processo Il termine processo (o funzione ) viene utilizzato per indicare l argomento di un particolare Data Mart. Il primo Data Mart da costruire dovrebbe essere un Data Mart che, molto probabilmente, potrà essere consegnato nei tempi stabiliti, con il budget previsto e che sia capace di rispondere alle esigenze aziendali più importanti dal punto di vista commerciale. Generalmente, come primo Data Mart, viene scelto uno strettamente collegato alle vendite. La corrispondente sorgente dei dati sarà, infatti, accessibile e di alta qualità. Nel selezionare il primo Data Mart dell agenzia immobiliare notiamo che i processi aziendali corrispondenti includono: le vendite degli immobili; gli affitti degli immobili; la visione degli immobili; la pubblicità sugli immobili; la manutenzione degli immobili. I dati necessari per gestire tali processi sono mostrati nel diagramma E/R di Figura 4.1. Si noti che tale diagramma costituisce parte della documentazione di progettazione che descrive i sistemi OLTP necessari a supportare le attività dell agenzia immobiliare. Il processo aziendale selezionato per essere il primo Data Mart è la vendita degli immobili. La parte del diagramma E/R originale che rappresenta i dati coinvolti in questo processo è rappresentata in Figura 4.2.

34 4 Progettazione di un Data Warehouse Lease Recommends Holds Leased by Newspaper Client Renter Requires Property Maintenance Displays Placed in Registers Property for Rent Provides Advert Offers Oversees Attends Branch Has Owner Uses Contacts Staff Describes Client Buyer Sells Manages Takes Property Viewing Promotion Owns Agrees Property for Sale Views Is for Promotes Property Sale Requests Seeks Figura 4.1. Diagramma E/R per la gestione di un agenzia immobiliare 4.3 Passo 2: Scelta della granularità Scegliere la granularità comporta decidere esattamente cosa rappresenta una tupla della Fact Table. Per esempio, l entità PropertySale nella Figura 4.1 rappresenta i fatti su ciascuna vendita di immobili e viene assunta come Fact Table dello schema a stella sulle vendite immobiliari. Pertanto, la granularità della Fact Table PropertySale è rappresentata dalle singole vendite immobiliari.

4.5 Passo 4: Scelta delle misure 35 Branch Has Owner Contacts Staff Sells Promotion Client Buyer Manages Owns Agrees Property Sale Is for Property for Sale Promotes Figura 4.2. Parte del Diagramma E/R di Figura 4.1 che rappresenta i dati coinvolti nel processo di vendita degli immobili di un agenzia immobiliare 4.4 Passo 3: Identificare e rendere conformi le dimensioni Le dimensioni stabiliscono il contesto in base al quale si possono porre le interrogazioni associate alle attività di decision making. Un insieme di dimensioni ben costruito rende il Data Mart comprensibile e facile da utilizzare. Soltanto quando è stata scelta la granularità della Fact Table è possibile identificare le dimensioni. Per esempio, le entità Branch, Staff, Owner, ClientBuyer, PropertyForSale e Promotion nella Figura 4.2 rappresentano dati che, a vario titolo, riguardano le vendite immobiliari; queste entità daranno origine alle Dimension Table dello schema a stella sulle vendite immobiliari. Accanto a tali entità, come Dimension Table, viene inclusa anche la dimensione temporale dal momento che il tempo gioca un ruolo fondamentale in qualunque analisi per il supporto alle decisioni. Le decisioni sulla granularità per la Fact Table influenzano anche le decisioni sulla granularità di ciascuna Dimension Table. Per esempio, se la granularità per la Fact Table PropertySale è una singola vendita immobiliare, allora la granularità della Dimension Table ClientBuyer è data dai dettagli del cliente che ha comprato un particolare immobile. ClientBuyer viene descritto dagli attributi clientid, clientno, clientname, clienttype, city, region e country. Un insieme di dimensioni povero o incompleto ridurrà l utilità di un Data Mart per un organizzazione. 4.5 Passo 4: Scelta delle misure La granularità della Fact Table determina quali misure possono essere utilizzate nel Data Mart. Tutte le misure devono essere espresse al livello implicato dalla granularità. In altre parole, se la granularità della Fact Table è una singola vendita immobiliare, allora tutte le misure numeriche si devono riferire a quella particolare vendita. Lo schema a stella associato alle vendite è illustrato nella Figura 4.3. Le misure dovrebbero essere numeriche e additive. Nella Figura 4.4 viene rappresentato lo schema a stella relativo agli affitti immobiliari per illustrare una Fact Table strutturata male. Questa Fact Table, infatti, non è utilizzabile in quanto vi sono misure non numeriche (promotionname e staffname), una misura non additiva (monthlyrent), e una misura a un diverso livello di granularità rispetto alle altre. La Figura 4.5 mostra come la Fact Table della Figura 4.4 potrebbe essere corretta per ovviare a tali inconvenienti. È possibile aggiungere nuove misure ad una Fact Table in qualunque momento purchè esse siano consistenti con la granularità della tabella.

36 4 Progettazione di un Data Warehouse TIME timeid day week month year BRANCH branchid branchno branchtype city region country PROMOTION promotionid promotionno promotionname promotiontype OWNER ownerid ownerno ownername ownertype city region country PROPERTY SALE timeid propertyid branchid clientid promotionid staffid ownerid offerprice sellingprice salecommission salerevenue PROPERTY FOR SALE propertyid propertyno type street city postcode region country CLIENT BUYER clientid clientno clientname clienttype city region country STAFF staffid staffno staffname position sex city region country Figura 4.3. Schema a stella associato alle vendite 4.6 Passo 5: Memorizzare pre-calcoli nella tabella dei fatti Una volta che le misure sono state selezionate, ciascuna di esse dovrebbe essere riesaminata per determinare se è opportuno usare dei pre-calcoli. Un esempio comune della necessità di memorizzare pre-calcoli si ha quando le misure coinvolgono profitti e perdite. Questa situazione nasce spesso quando la tabella dei fatti è basata su fatture o vendite. La Figura 4.5 mostra la tabella dei fatti con gli attributi rentduration, totalrent, clientallowance, staffcommission e totalrevenue. Questi tipi di misure sono utili perché sono quantità additive dalle quali è possibile derivare informazioni importanti, quali il clientallowance medio, basandosi sull aggregazione di alcuni numeri della tabella dei fatti. Ad esempio, per calcolare il totalrevenue generato per ciascun affitto immobiliare sottraiamo i valori di clientallowance e staffcommission da totalrent. In alcuni casi potrebbe presentarsi la necessità di dover memorizzare un valore anche se questo potrebbe essere derivato da un insieme di attributi. Ciò risulta particolarmente vero per un valore fondamentale per un organizzazione, quale totalrevenue, o quando vi è il rischio che il valore venga calcolato in modo incorretto dall utente. Infatti, il costo causato da un utente che calcola in modo incorretto un valore è maggiore rispetto al piccolo costo necessario per memorizzarlo. 4.7 Passo 6: Completare la tabella delle dimensioni In questo passo ritorniamo alle Dimension Table e aggiungiamo alle dimensioni quante più descrizioni testuali possibili. Le descrizioni testuali dovrebbero essere quanto più possibile intuitive e comprensibili

TIME timeid day week month year BRANCH branchid branchno branchtype city region country PROMOTION promotionid promotionno promotionname promotiontype Fatti non numerici OWNER ownerid ownerno ownername ownertype city region country { 4.9 Passo 8: Tracciare le slowly changing dimension 37 LEASE timeid propertyid branchid clientid promotionname staffname ownerid montlyrent rentduration totalrent clientallowance staffcommission totalrevenue lastyearrevenue Fatti non additivi Fatti numerici con granularità inconsistente rispetto agli altri fatti PROPERTY FOR RENT propertyid propertyno type street city postcode region country CLIENT RENTER clientid clientno clientname clienttype city region country STAFF staffid staffno staffname position sex city region country Figura 4.4. Schema a stella per gli affitti degli immobili; questo è un esempio di una Fact Table strutturata male per gli utenti finali. L utilità di un Data Mart è determinata dallo scopo e dalla natura degli attributi delle tabelle dimensionali. 4.8 Passo 7: Scelta della durata del database La durata misura per quanto tempo nel passato dovrà andare la Fact Table. In molte organizzazioni vi è la necessità di memorizzare le informazioni fino ad uno o due anni rispetto alla data corrente. Per altre organizzazioni, quali le compagnie di assicurazioni, vi possono essere delle richieste legali per mantenere i dati fino a cinque o più anni prima rispetto alla data corrente. Fact Table molto grosse causano almeno due significative problematiche di progettazione. Innanzitutto, è spesso molto difficile risalire a dati vecchi. Più vecchi sono i dati e più probabilmente vi saranno problemi nel leggerli ed interpretarli. In secondo luogo, è necessario che vengano usate le versioni vecchie delle dimensioni in gioco e non le versioni più recenti. Questa problematica è nota come problema della slowly changing dimension e viene descritta più dettagliatamente nel prossimo passo. 4.9 Passo 8: Tracciare le slowly changing dimension Il problema delle slowly changing dimension implica, per esempio, che, per i dati vecchi, è necessario fare riferimento alla vecchia organizzazione e alla vecchia strutturazione dei dati (ovvero

38 4 Progettazione di un Data Warehouse TIME timeid day week month year BRANCH branchid branchno branchtype city region country PROMOTION promotionid promotionno promotionname promotiontype OWNER ownerid ownerno ownername ownertype city region country LEASE timeid propertyid branchid clientid promotionid staffid ownerid rentduration totalrent clientallowance staffcommission totalrevenue PROPERTY FOR RENT propertyid propertyno type street city postcode region country CLIENT RENTER clientid clientno clientname clienttype city region country STAFF staffid staffno staffname position sex city region country Figura 4.5. Schema a stella per gli affitti degli immobili; questo è lo schema della Figura 4.4 con i problemi corretti all organizzazione e alla strutturazione esistenti nel tempo a cui essi si riferiscono). Spesso il Data Warehouse deve assegnare una chiave generalizzata a queste dimensioni per poter costruire più istantanee (relative a periodi di tempo differenti) dei dati coinvolti. Vi sono tre tipi fondamentali di slowly changing dimension ; essi corrispondono alle seguenti situazioni: un attributo di una dimensione viene sovrascritto; un attributo di una dimensione modificata causa la creazione di una nuova tupla in quella dimensione; un attributo di una dimensione modificata fa si che venga creato un attributo alternativo in modo tale che sia il valore vecchio che il valore nuovo dell attributo siano simultaneamente accessibili nella stessa tupla di una Dimension Table. 4.10 Passo 9: Decidere le priorità sulle query e sulle modalità di query In questo passo vengono considerate problematiche di progettazione fisica. Le problematiche di progettazione fisica più critiche che influenzano la percezione che l utente finale ha del Data Mart, sono l ordinamento fisico su disco della Fact Table e la presenza di aggregazioni pre-memorizzate. Al di là di queste problematiche ve ne sono tantissime altre che riguardano l amministrazione, il backup, la performance sull indicizzazione e la sicurezza

4.11 Integrazione dei Data Mart 39 4.11 Integrazione dei Data Mart Al termine dei nove passi della metodologia precedentemente esaminata abbiamo progettato un Data Mart che supporta le richieste di un particolare processo di business e può essere, anche, facilmente integrato con altri Data Mart correlati per formare un Data Warehouse complessivo. Affinchè possa aver luogo il processo di integrazione, se una qualunque dimensione è presente in due Data Mart, le due istanze devono essere identiche oppure una deve essere un sottoinsieme matematico dell altra. Solo in questo modo, infatti, due Data Mart possono condividere una o più dimensioni nella medesima applicazione. Quando una dimensione viene utilizzata in più di un Data Mart, si dice che essa deve essere conforme (conformed). Esempi di dimensioni conformi tra i Data Mart relativi alle vendite e alla pubblicità degli immobili sono le dimensioni Time, PropertyForSale, Branch e Promotion. Se esse non sono sincronizzate nei due Data Mart, il Data Warehouse complessivo sarà, praticamente, inutilizzabile perché i due Data Mart non potranno essere usati insieme. Per esempio, nella Figura 4.6, vengono mostrati gli schemi a stella per i Data Mart relativi alla vendita e alla pubblicità degli immobili; le dimensioni Time, PropertyForSale, Branch e Promotion sono, in questo caso, dimensioni conformi. TIME timeid CLIENT BUYER clientid clientno clientname clienttype city region country STAFF staffid staffno staffname position sex city region country OWNER ownerid ownerno ownername PROPERTY SALE timeid propertyid branchid clientid promotionid staffid ownerid offerprice sellingprice salecommission salerevenue day week month year PROPERTY FOR SALE propertyid propertyno type street city postcode region country BRANCH branchid branchno branchtype city region country ADVERT timeid propertyid branchid newspaperid promotionid advertcost NEWSPAPER newspaperid newspaperno newspapername newspapertype distribution city region country ownertype city region country PROMOTION promotionid promotionno promotionname promotiontype Figura 4.6. Schema a stella per la vendita e la pubblicità degli immobili con le Dimension Table Time, PropertyForSale, Branch e Promotion conformi La Tabella 4.1 mostra le Fact Table e le Dimension Table associate allo schema a stella per ciascun processo aziendale (e, quindi, per ciascun Data Mart) dell agenzia immobiliare in esame.

40 4 Progettazione di un Data Warehouse Gli schemi a stella relativi ai vari Data Mart vengono integrati utilizzando le dimensioni conformi. Per esempio, tutti i Data Mart condividono le dimensioni Time e Branch, come si evince dalla Tabella 4.1; tali dimensioni costituiranno, pertanto, il fulcro del processo di integrazione dei Data Mart volto alla costruzione del Data Warehouse. Processo Aziendale Fact Table Dimension Table Vendite degli immobili PropertySale Time, Branch, Staff, PropertyForSale, Owner, ClientBuyer, Promotion Affitti degli immobili Lease Time, Branch, Staff, PropertyForRent, Owner, ClientRenter, Promotion Visioni degli immobili PropertyViewing Time, Branch, PropertyForSale, PropertyForRent, ClientBuyer, ClientRenter Pubblicità sugli immobili Advert Time, Branch, PropertyForSale, PropertyForRent, Promotion, Newspaper Manutenzione degli immobili PropertyMaintenance Time, Branch, Staff, PropertyForRent Tabella 4.1. Fact Table e Dimension Table per ciascun Data Mart dell agenzia immobiliare in esame Un modello dimensionale dove più Fact Table sono collegate a una o più Dimension Table conformi viene denominato Costellazione dei Fatti. La Costellazione dei Fatti per il Data Warehouse in esame è mostrata nella Figura 4.7. La rappresentazione del modello è stata semplificata in quanto vengono mostrati soltanto i nomi delle Fact Table e delle Dimension Table. Le Fact Table sono evidenziate in grigio mentre le Dimension Table sono mostrate in bianco. Client Buyer PropertySale Promotion PropertyFor Sale Advert Newspaper Branch Property Viewing Time Owner Lease Staff PropertyFor Rent Property Maintenance ClientRenter Figura 4.7. Costellazione dei fatti per il Data Warehouse associato all agenzia immobiliare

5 Data Warehousing e Oracle: Analytical Workspace Manager Questo capitolo ha lo scopo di introdurre Analytic Workspace Manager per Oracle OLAP 10g. Attraverso questo tool di facile utilizzo, è possibile definire, implementare e gestire operazioni di Data Warehousing. 5.1 Analytical Workspace Manager Iniziare con le sorgenti relazionali esistenti Si consideri una immaginaria compagnia mondiale chiamata Global Computing che distribuisce hardware e software. Il punto iniziale per utilizzare il tool Analytical Workspace Manager è considerare gli esistenti schemi a stella, a fiocco di neve o normalizzati. Nella figura in seguito sono illustrate le tabelle che intendiamo analizzare col tool: Progettare un modello dei dati logico Dopo aver esaminato le tabelle relazionali, è possibile identificare le dimensioni, i livelli, le gerarchie e gli attributi dei dati logici. Inoltre, è possibile identificare le relazioni all interno ciascuna dimensione. I dati saranno così utilizzati per progettare l area di lavoro analitica di Analytical Workspace Manager. 1) Identificare le dimensioni Quattro dimensioni saranno utilizzate per organizzare i fatti nel database:

42 5 Data Warehousing e Oracle: Analytical Workspace Manager 1. Channel che mostra come variano i dati secondo ciascun canale di distribuzione. 2. Customer che mostra come variano i dati per diversi clienti o aree geografiche. 3. Product che mostra come variano i dati per prodotti. 4. Time che mostra come variano i dati sul tempo. 2) Identificare i livelli Adesso che abbiamo identificato le dimensioni, possiamo anche identificare i livelli che riassumono i dati all interno di ciascuna dimensione. Le analisi alle tabelle precedenti rilevano che: 1. La dimensione Channel ha tre canali di distribuzione: Sales, Catalog e Internet. Questi tre valori sono al più basso livello di dettaglio nel datawarehouse e saranno raggruppati nel livello Channel. Dal più alto livello di riepilogo al più basso livello di dettaglio, i livelli saranno Total Channel e Channel. 2. La dimensione Customer riflette come Global Computing esegue le analisi geografiche dei clienti. Il più basso livello di dettaglio nel modello dei dati è localizzata in Ship To. a) Shipments, i livelli di riepilogo saranno (dal più alto al più basso): Total Customers, Region, Warehouse e Ship To. b) Market Segmentation, i livelli di riepilogo saranno (dal più alto al più basso): Total Market, Market Segment, Account e Ship To. 1. La dimensione Product avrà quattro livelli (dal più alto al più basso): Total, Class, Family e Item. 2. La dimensione avrà tre livelli (dal più alto al più basso): Year, Quarter e Month. All interno delle dimensioni Channel, Customer e Product, abbiamo aggiunto un livello Totale come il più alto livello di riepilogo. L aggiunta di tale livello fornirà maggiore flessibilità nell analisi dei dati. 3) Identificare le gerarchie Le gerarchie organizzano i livelli all interno di ciascuna dimensione. Per identificare le gerarchie occorre raggruppare i livelli nel corretto ordine di riepilogo. Per le dimensioni Channel, Product, e Time, Global Computing necessita di soltanto una gerarchia per ciascuna dimensione. Per la dimensione Customer, tuttavia, Global Computing necessita di due gerarchie. L analisi all interno della dimensione Customer viene condotta, infatti, attraverso l analisi geografica e attraverso il segmento di vendita. Perciò, i livelli devono essere organizzati in due gerarchie chiamate Shipments e Market Segment. 4) Identificare le misure I fatti che emergono dall analisi del database sono quattro, ovvero: 1. Sales 2. Units 3. Unit Price 4. Unit Cost Altri fatti possono essere ricavati da questi che sono quelli di base. I fatti derivati possono essere calcolati da Analytic Workspace Manager in un secondo momento a richiesta.

5.1 Analytical Workspace Manager 43 Definire l area di lavoro analitica L area di lavoro analitica è una collezione di tipi di dati multidimensionali. La finestra principale fornisce due viste: 1. la Vista Modello che permette di definire un modello dimensionale logico dei dati usando dimensioni, livelli, gerarchie, attributi e misure; 2. la Vista Oggetto che fornisce una interfaccia grafica per OLAP DML. Tramite questa vista è possibile creare, modificare e cancellare oggetti dell area di lavoro analitica. Tale vista è utile per gli utenti esperti che vogliono utilizzare le caratteristiche avanzate di Analytic Workspace Manager. Partire dall utente GLOBAL AW Con questo esercizio creeremo un area di lavoro analitica denominata GLOBAL. Di seguito sono elencati i comandi SQL che definiscono l utente GLOBAL AW con diritti sufficienti per poter utilizzare Analytic Workspace Manager ed accedere alle sorgenti di GLOBAL.. CREATE USER global aw IDENTIFIED BY global aw DEFAULT TABLESPACE global TEMPORARY TABLESPACE global temp QUOTA UNLIMITED ON global QUOTA UNLIMITED ON global temp; GRANT OLAP USER TO global aw; GRANT SELECT ON global.channel dim TO global aw; GRANT SELECT ON global.product dim TO global aw; GRANT SELECT ON global.product child parent TO global aw; GRANT SELECT ON global.product total product member TO global aw; GRANT SELECT ON global.product class member TO global aw; GRANT SELECT ON global.product family member TO global aw; GRANT SELECT ON global.product item member TO global aw; GRANT SELECT ON global.product total product dsc TO global aw; GRANT SELECT ON global.product class dsc TO global aw; GRANT SELECT ON global.product family dsc TO global aw; GRANT SELECT ON global.product item dsc TO global aw; GRANT SELECT ON global.product item buyer TO global aw; GRANT SELECT ON global.product item marketing manager TO global aw; GRANT SELECT ON global.product item package TO global aw; GRANT SELECT ON global.customer dim TO global aw; GRANT SELECT ON global.time dim TO global aw; GRANT SELECT ON global.time year dim TO global aw; GRANT SELECT ON global.time quarter dim TO global aw; GRANT SELECT ON global.time month dim TO global aw; GRANT SELECT ON global.units history fact TO global aw; GRANT SELECT ON global.units update fact TO global aw; GRANT SELECT ON global.price and cost hist fact TO global aw; GRANT SELECT ON global.price and cost upd fact TO global aw; Create l area di lavoro analitica GLOBAL Step 1. Avviare Analytic Workspace Manager. Step 2. Connettersi accedendo attraverso il nome utente global aw e password global aw. Specificare il servizio nella forma host:port:sid (ad esempio, localhost:1521:globaldb).

44 5 Data Warehousing e Oracle: Analytical Workspace Manager La vista di default è la Vista Modello. Attraverso la Vista Modello, è possibile creare oggetti dimensionali logici. Allo stesso tempo, Analytic Workspace Manager istanzia gli oggetti logici come oggetti fisici nell area di lavoro analitica. Step 3. Creare il contenitore dell area di lavoro analitica GLOBAL. Espandere la cartella Schema finché non compaia lo schema GLOBAL AW. Click destro sulla cartella Area di lavoro analitica e seleziona Crea Area di Lavoro Analitica... Step 4. Fornire GLOBAL come nome dell area di lavoro analitica ed accettare la tablespace di default. Cliccare su Crea. Apparirà la nuova area di lavoro GLOBAL nella cartella Aree di lavoro Analitiche.

5.1 Analytical Workspace Manager 45 Definire le dimensioni Nel modello logico, le dimensioni sono i genitori dei livelli, delle gerarchie e degli attributi. Le dimensioni sono una lista di valori univoci che identificano i dati. Essi identificano i lati del cubo logico e quindi le misure (fatti) all interno del cubo. Creare la dimensione Channel Step 1. Click destro sulla cartella Dimensioni, quindi scegliere Dimensioni... Step 2. Nel tab Generale della finestra di dialogo, scrivere CHANNEL come nome ed accettare. Step 3. Cliccare Dettagli di Implementazione e scegliere Utilizza chiavi naturali dell origine dati. Cliccare Crea.

46 5 Data Warehousing e Oracle: Analytical Workspace Manager Nota: Seleziona l opzione Genera chiavi surrogate nell are di lavoro analitica a meno che non si sappia che ciascun membro della dimensione sia unico. Nel caso contrario, se si è sicuri che i membri della dimensione sono unici tra livelli, selezionare Utilizza chiavi naturali dell origine dati, così è possibile utilizzare lo stesso nome nell area di lavoro analitica come nelle sorgenti dati. Ad esempio, su lo schema relazionale utilizza chiavi surrogate numeriche per assicurare l unicità, allora non vi è necessità di creare nuove chiavi surrogate nell area di lavoro analitica. Step 4. La nuova dimensione CHANNEL appare sotto la cartella Dimensioni. Definire i livelli Nelle analisi di mercato, i dati sono tipicamenti riassunti a vari livelli. Ad esempio, un database potrebbe contenere delle istantanee mensili. I mesi sono così il livello base. È tuttavia possibile riassumere questi dati anche in dati trimestrali o annuali. Creare il livello Channel Step 1. Espandere il nodo CHANNEL e cliccare col tasto destro del mouse sulla cartella Livelli, quindi scegliere Crea Livello... Step 2. Nella finestra di dialogo Crea Livello, scrivere TOTAL CHANNEL come nome e cliccare su Crea.

5.1 Analytical Workspace Manager 47 Il nuovo livello TOTAL CHANNEL appare come una nuova voce nella cartella Livelli. Step 3. Ripetere il passo precedente per il livello Channel. Il nuovo livello CHANNEL appare come una nuova voce nella cartella Livelli. Definire le gerarchie Una gerarchia è una struttura logica che utilizza i livelli ordinati per organizzare i dati. Può essere utilizzata per definire aggregazioni di dati; ad esempio, in una dimensione tempo, una gerarchia potrebbe essere usata per aggregare i dati dal livello mensile al livello trimestrale o annuale. Le dimensioni possono avere uno o più di una gerarchia. Se si definiscono gerarchie multiple, assicurarsi di definire una come gerarchia di default. Creare la gerarchia Channel Step 1. Cliccare col tasto destro del mouse sulla cartella Gerarchie, quindi scegliere Crea Gerarchia...

48 5 Data Warehousing e Oracle: Analytical Workspace Manager Step 2. Nella finestra di dialogo Crea Gerarchia, scrivere PRIMARY come nome ed accettare i valori di default. Selezionare i livelli dal livello più allto al livello più basso come illustrato in seguito e cliccare su Crea. La nuova gerarchia PRIMARY appare come una nuova voce nella cartella Gerarchie. Definire gli attributi Gli attributi forniscono le informazioni sui membri di una dimensione. Tutte le dimensioni sono create con due attributi chiamati long e short description. È tuttavia possibile aggiungere altri attributi. La dimensione Time ha, oltre agli attributi long e short description, gli attributi time-span e end-date.

5.1 Analytical Workspace Manager 49 Esaminare gli attributi di Channel Step 1. Espandere la cartella Attributi ed evidenziare LONG DESCRIPTION e SHORT DESCRIPTION. Visionare ed accettare i valori di default. Creare la dimensione Customer Step 1. Creare la dimensione CUSTOMER in modo analogo a quanto già fatto.

50 5 Data Warehousing e Oracle: Analytical Workspace Manager...

5.1 Analytical Workspace Manager 51 I modelli Grazie ai Modelli in Analytic Workspace Manager è possibile salvare la definizione degli oggetti logici in un file XML. Pertanto, utilizzando un modello precedentemente salvato, è possibile ricreare una

52 5 Data Warehousing e Oracle: Analytical Workspace Manager nuova area di lavoro analitica, una nuova dimensione, cubo etc. Occorre ricordarsi che i modelli non includono i dati ma solamente la definizione logica degli oggetti. I Modelli permettono di: 1. Condividere i progetti delle aree di lavoro analitiche con altri utenti. 2. Trasferire le definizioni degli oggetti in altri schemi. 3. Conservare la definizione logica di oggetti anche all esterno del database. 4. Controllare, attraverso il codice XML, la definizione degli oggetti. Creare la dimensione Product Creare la dimensione Product da un modello precedentemente salvato. Step 1. Cliccare col tasto destro del mouse la cartella Dimensioni, quindi scegliere Crea Dimensione da Modello... Step 2. Selezionare il file ProductOther.XML e cliccare su Crea.

La nuova dimensione PRODUCT appare sotto la cartella Dimensioni. 5.1 Analytical Workspace Manager 53 Creare la dimensione Time Step 1. Creare la dimensione TIME basata sul modello TimeSnowflake.XML. La nuova dimensione TIME appare sotto la cartella Dimensioni.

54 5 Data Warehousing e Oracle: Analytical Workspace Manager Adesso, dal momento che tutte le dimensioni sono state create, è possibile creare gli oggetti del cubo. Definire i Cubi I Cubi sono rappresentazioni logiche dei dati multidimensionali. I lati rappresentano i membri delle dimensioni e il corpo contiene i valori dei dati. Ad esempio, i dati delle vendite possono essere organizzati in un cubo, i cui lati contengono i valori delle dimensioni channel, customer, product e time e il cui corpo contiene i dati unit sales e dollar sales. Creare il cubo Units Cube Step 1. Tasto destro sulla cartella Cubi, quindi scegliere Crea Cubo... Step 2. Nel tab Generale della finestra di dialogo Crea Cubo, scrivere UNITS CUBE come nome e selezionare tutte le dimensioni come illustrato nella figura in seguito. NOTA: In alcune figure il cubo UNITS CUBE viene erroneamente visualizzato col nome SALES CUBE!!! Come memorizzare i dati La creazione di un cubo richiede molte decisioni riguardo la memorizzazione dei dati che influiscono sulle performance dell area di lavoro analitica.

5.1 Analytical Workspace Manager 55 Cos è la Sparsità? Con sparsità intendiamo specificare il grado in cui le celle contengono valori NULL invece che dati. Ad esempio, se una variabile è il 25% sparsa, allora il 25% delle celle associate alla variabile contengono valori NULL e il 75% contengono dati. In generale, se una variabile è oltre l 80% sparsa, allora è opportuno gestire la sparsità al fine di garantire buone performance. Analytic Workspace Manager assume, come condizione di default, che i dati siano sparsi e seleziona come sparse tutte le dimensioni, eccetto la dimensione time che è tipicamente densa. Step 3. Cliccare sul tab Dettagli di Implementazione nella finestra di dialogo Create Cube. Accettare i valori di default. Ordinare le dimensioni in un Cubo L ordine in cui le dimensioni sono elencate in un cubo influiscono sulle performance perché esse determinano il modo in cui i dati sono memorizzati sull hard disk. La prima dimensione in un cubo è la dimensione che varia più velocemente, l ultima dimensione è quella che varia più lentamente. Step 4. Nel tab Dettagli di Implementazione, muovere le dimensioni nell ordine come illustrato sotto. Accettare gli altri valori di default. Step 5. Cliccare Crea, il nuovo cubo UNITS CUBE appare sotto la cartella Cubi.

56 5 Data Warehousing e Oracle: Analytical Workspace Manager Creare il Cubo Price and Cost Cube Step 1. Creare il cubo Price and Cost Cube. Includere soltanto le dimensioni TIME e PRODUCT. Step 2. Accettare tutti i default eccetto la sparsità e l operatore di aggregazione. Deselezionare la dimensione PRODUCT come sparsa nel tab Dettagli di Implementazione. Step 3. Selezionare Non Additivo (non riepilogare) per entrambe le dimensioni nel tab Regole.

5.1 Analytical Workspace Manager 57 Nota: Operatore sceglie il tipo di calcolo da effettuare su ciascuna dimensione: 1. Non Additivo - Non aggrega i dati. 2. Somma - Somma di valori. (Default) Step 4. Cliccare Crea. Creare le misure Le misure di base memorizzano i fatti della realtà di interesse. Ciascuna misura appartiene ad un particolare cubo. Creare la misura del cubo UNITS CUBE Step 1. Espandere il nodo UNITS CUBE e cliccare col tasto destro del mouse la cartella Misure, quindi scegliere Crea Misura...

58 5 Data Warehousing e Oracle: Analytical Workspace Manager Step 2. Scrivere SALES come nome nel tab Generale della finestra di dialogo Crea Misure. Accettare i valori di default e cliccare Crea. La nuova misura SALES apparirà all interno della cartella Misure. Step 3. All interno del noto UNITS CUBE cliccare col tasto destro del mouse la cartella Misure e scegliere Crea Misura... Step 4. Nel tab Generale della finestra di dialogo Crea Misure, fornire UNITS come nome. Step 5. Cliccare su Dettagli di Implementazione nella finestra di dialogo Crea Misura. Selezionare INTEGER come tipo di dati e cliccare Crea. La nuova misura UNITS apparirà all interno della cartella Misure.

5.1 Analytical Workspace Manager 59 Creare la misura per il cubo PRICE AND COST CUBE Creare le misure Unit Price e Unit Cost a proprio piacimento. Accettare i valori di default. Mappare le sorgenti relazionali Dopo aver creato gli oggetti logici, è possibile mapparli nelle sorgenti relazionali di Oracle Database. I tal modo è possibile caricare i dati fisici nell area di lavoro analitica. Mappare la dimensione Channel Step 1. Espandere il nodo della dimensione CHANNEL e cliccare su Mapping. La finestra Mapping verrà visualizzata nel pannello di destra. Step 2. Individuare la tabella CHANNEL DIM all interno dello schema GLOBAL. Trascinare CHANNEL DIM nell area mapping.

60 5 Data Warehousing e Oracle: Analytical Workspace Manager Step 3. Cliccare Visualizza Dati per visualizzare la dimension table CHANNEL DIM. Step 4. Cliccare su Annulla per tornare indietro. Step 5. Tracciare delle linee da CHANNEL DIM all oggetto logico CHANNEL. Una volta finito, cliccare Applica.

5.1 Analytical Workspace Manager 61 Mappare la dimensione Customer Mappare la dimensione CUSTOMER DIM nell oggetto logico CUSTOMER a proprio piacimento. Tutte e quattro le dimensioni sono adesso mappate. I modelli Product e Time includono, infatti, i mapping. Mappare il cubo UNITS CUBE Step 1. Espandere il nodo UNITS CUBE e cliccare su Mapping.

62 5 Data Warehousing e Oracle: Analytical Workspace Manager La finestra Mapping apparirà nel pannello di destra. Verrà visualizzato uno schema navigator ed una tabella con delle righe per le misure, dimensioni e livelli. Step 2. Nello schema navigator, individuare la tabella dei fatti UNITS HISTORY FACT con le relative misure nello schema GLOBAL. Trascinarla nell area mapping. Step 3. Cliccare Visualizza Dati per visualizzare la tabella dei fatti UNITS HISTORY FACT:

5.1 Analytical Workspace Manager 63 Step 4. Cliccare Annulla per tornare indietro. Step 5. Tracciare le linee dalla tabella UNITS HISTORY FACT all oggetto logico UNITS CUBE. Una volta finito cliccare Applica. Mappare il cubo PRICE AND COST CUBE Mappare la fact table PRICE COST HIST FACT con l oggetto logico PRICE AND COST CUBE a proprio piacere. Caricare e aggregare i dati in Analytic Workspace In Analytic Workspace Manager è possibile caricare tutti gli oggetti mappati nell area di lavoro analitica. Step 1. Cliccare col tasto destro del mouse sull area di lavoro analitica GLOBAL, quindi scegliere Gestisci area di lavoro analitica GLOBAL.

64 5 Data Warehousing e Oracle: Analytical Workspace Manager Step 2. Selezionare UNITS CUBE e PRICE AND COST CUBE includendo tutte le dimensioni coinvolte. Cliccare Fine. Adesso l area di lavoro analitica GLOBAL contiene i dati come specificato nel progetto logico. È così possibile effettuare delle analisi dimensionali ad-hoc attraverso i tool di Analytic Workspace Manager oppure attraverso altre applicazioni fornite da Oracle Business Intelligence Beans come Discoverer OLAP e Spreadsheet Add-In! Visualizzare i dati con Analytic Workspace Manager Cliccare col tasto destro del mouse la dimensione PRODUCT e scegliere Visualizza dati PRODUCT...

5.1 Analytical Workspace Manager 65 È possibile esplorare e visionare i membri della dimensione Product. Ad esempio, per visualizzare i dati della misura Sales, cliccare col tasto destro del mouse sulla misura SALES del cubo UNITS CUBE e scegliere Visualizza i dati SALES CUBE... Adesso è possibile esplorare e verificare i dati della misura Sales.

66 5 Data Warehousing e Oracle: Analytical Workspace Manager Definire delle misure derivate Le misure derivare sono create effettuando calcoli sulle misure memorizzate nell area di lavoro analitica. Tali fatti derivati non sono fisicamente memorizzati; pertanto essi sono equivalenti a delle viste relazionali. Creare la misura derivata UNIT MARGIN Step 1. Espandere il node del cubo PRICE AND COST CUBE e cliccare col tasto destro del mouse nella cartella Misure Derivate, quindi scegliere Crea Misure Derivate... Step 2. Fornire UNIT MARGIN come nome e selezionare Sottrazione come tipo di calcolo dalla cartella Aritmetica di base. Cliccare continua. Step 3. Come valore del menu Sottrazione scegliere Unit Price e come valore Unit Cost. Cliccare Fine.

5.2 Oracle Spreadsheet Add In 67 La nuova misura derivata UNITS MARGIN apparirà all interno della cartella Misure Derivate. Step 4. Visionare i dati di Unit Margin, cliccare col tasto destro del mouse sulla misura calcolata UNIT MARGIN dal cubo PRICE AND COST CUBE e scegliere Visualizza Dati UNIT MARGIN... Effettuare operazioni di drill down sui livelli per le dimensioni Product e Time. Nota: Si ricordi che è stato selezionato l operatore di aggregazione non additivo nel cubo PRI- CE AND COST CUBE, pertanto i dati verranno visualizzati soltanto la livello base. 5.2 Oracle Spreadsheet Add In Connettersi alle sorgenti dati OLAP di Oracle Una volta installato il tool OracleBI Spreadsheet Add-In, una nuova voce nel menu, denominata OracleBI, viene aggiunta nella barra di menu di Excel. Utilizzare tale menu per accedere alle caratteristiche che interagiscono con Oracle OLAP.

68 5 Data Warehousing e Oracle: Analytical Workspace Manager Seguire i seguenti passi per connettersi alle sorgenti dati OLAP di Oracle: Step 1. Selezionare OracleBI > Nuova Query. Step 2. Inserire un appropriata descrizione di connessione, e specificare l Host Name, Port Number e SID per la connessione OLAP. Cliccare Salva per memorizzare le impostazioni di connessione. Step 3. Cliccare sul tab Connessione a OLAP. Una nuova descrizione di connessione verrà visualizzata. Inserire global aw sia come Nome Utente che come Password, quindi cliccare su Connetti. Il wizard di Oracle OLAP Query vine così lanciato.

5.2 Oracle Spreadsheet Add In 69 Creare una query OLAP Create un report In tale sezione vedremo come creare un report basato sulla misura Sales (vendite) che riporta i migliori 5 prodotti del reparto vendite. Step 1. Nel wizard di creazione query, cliccare su continua. Step 2. Selezionare le misure che si intendono visualizzare. Nota: La lista che appare nella finestra di wizard potrebbe contenere anche cartelle create dall amministratore di database durante la configurazione di Oracle OLAP. Selezionare dalla lista la misura Sales. Cliccare il bottone > per muovere la misura Sales nella lista di destra. Nota: La misura Sales e le dimensioni correlate saranno trascinate nella lista di destra poiché è selezionata la checkbox Aggiungi/Rimuovi automaticamente le dimensioni. Step 3. È possibile rimuovere qualsiasi dimensione che non si è interessati a vedere dalla lista. In ogni caso non rimuovere nessuna dimensione. Step 4. Nel passo Layout del wizard, è possibile cambiare il layout dei dati spostando le dimensioni nella maniera voluta. Muovere Customer, Product, Time e Channel come mostrato nella figura in seguito:

70 5 Data Warehousing e Oracle: Analytical Workspace Manager Cliccare Avanti per continuare. Step 5. Nei prossimi passi del wizard è possibile selezionare i membri delle dimensioni. Selezionare i membri della dimensione Time. Nella lista a sinistra, cliccare sul bottone >> per selezionare tutte i membri della dimensione. Cliccare su Avanti per continuare. Step 6. Selezionare i membri associate alla dimensione Customer. Nella lista di sinistra, selezionare il tab Membri e cliccare sul simbolo ('+') per visualizzare i clienti divisi per regioni. Selezionare le stesse regioni selezionate dalla seguente figura:

5.2 Oracle Spreadsheet Add In 71 Cliccare Avanti per continuare. Step 7. Per ciascuna dimensione Product, è possibile specificare la condizione di classificazione. Cliccare sul tab Condizioni. Appariranno dei modelli di condizioni. Tali modelli possono essere personalizzati per specificare la condizione che si richiede. Espandere la cartella Primi/Ultimi e selezionare il modello in alto 10 in base a Sales. Cliccare sul bottone (>) per muovere la condizione nella lista di condizioni di destra. Step 8. Nella lista di condizioni di destra, scegliere in alto 10 in base a Sales. Cliccare sul primo link e cambiare il 10 in 5. Step 9. Selezionare i membri della dimensione Channel. Nella lista delle condizioni a sinistra, cliccare su All Channel e trascinarla a destra attraverso il bottone (>).

72 5 Data Warehousing e Oracle: Analytical Workspace Manager Cliccare Fine. La query OLAP creata restituirà i dati per i 5 prodotti in base alle vendite in North Americas, All Channel, e anno 1998. Cliccare su 1998 e selezionare 2002 dalla lista. La query è automaticamente ricalcolata e la corrente lista riporta i 5 prodotti in base alle vendite in North Americas, All Channel, e anno 2002. È anche possibile modificare l esistente query OLAP selezionando OracleBI > Modifica Query dal menu di Excel.