Appunti per il Corso di Data Warehousing · • sanita`: analisi di ricoveri e dimissioni,...

Universita 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1 Motivazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 I sistemi di supporto alle decisioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Il Data Warehousing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.4 Architetture per il Data Warehousing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.4.1 Architettura ad un livello . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.4.2 Architettura a due livelli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.4.3 Architettura a tre livelli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.5 I Metadati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.6 Qualita di un Data Warehouse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2 Il modello multidimensionale e l’OLAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.1 Il modello multidimensionale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.1.1 Restrizione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.1.2 Aggregazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2 Tool e tecnologie per il Data Warehousing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.2.1 Reportistica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.2.2 OLAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.3 ROLAP e MOLAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3 Modelli logici a supporto del Data Warehousing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.1 Lo schema a stella . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.2 Lo schema a fiocco di neve . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.3 Le viste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

3.3.1 Schemi relazionali in presenza di dati aggregati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4 Progettazione di un Data Warehouse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.1 Metodologia di progettazione di un Data Warehouse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.2 Passo 1: Scelta del processo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.3 Passo 2: Scelta della granularita . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.4 Passo 3: Identificare e rendere conformi le dimensioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.5 Passo 4: Scelta delle misure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.6 Passo 5: Memorizzare pre-calcoli nella tabella dei fatti . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.7 Passo 6: Completare la tabella delle dimensioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.8 Passo 7: Scelta della durata del database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.9 Passo 8: Tracciare le “slowly changing dimension” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.10 Passo 9: Decidere le priorita sulle query e sulle modalita di query . . . . . . . . . . . . . . . . . . . 384.11 Integrazione dei Data Mart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5 Data Warehousing e Oracle: Analytical Workspace Manager . . . . . . . . . . . . . . . . . . . . 415.1 Analytical Workspace Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415.2 Oracle Spreadsheet Add In . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Elenco delle figure

1.1 Il valore dell’informazione in funzione della quantita . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Architettura ad un livello per un sistema di Data Warehousing . . . . . . . . . . . . . . . . . . . . . . 61.3 Architettura a due livelli per un sistema di Data Warehousing . . . . . . . . . . . . . . . . . . . . . . 71.4 Architettura a due livelli con Data Mart indipendenti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.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 . . . . . . . . . . . . . . . 122.2 Gerarchie di aggregazione sulle dimensioni prodotto e negozio . . . . . . . . . . . . . . . . . . . . . 132.3 Slicing di un cubo tridimensionale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.4 Due livelli di aggregazione a partire dai dati elementari . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.5 Presentazione di un rapporto: tabelle, diagramma, torta . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.6 Le gerarchie di attributi nel V-Mall; le frecce indicano dipendenze funzionali . . . . . . . . . . 172.7 Roll-up sulla gerarchia temporale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.8 Roll-up con eliminazione della gerarchia cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.9 Roll-up (a sinistra) e drill-down (a destra) su un cubo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.10 Drill-down sulla gerarchia del cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.11 Drill-down con l’aggiunta di una dimensione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.12 Slicing (sopra) e selezione (sotto) di un cubo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.13 Slicing sul predicato Year = ‘1998’ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.14 Selezione su un predicato complesso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.15 Pivoting di un cubo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.16 Pivoting su una tabella bidimensionale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.17 Pivoting su una tabella tridimensionale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.18 Drill-across tra due cubi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.19 Drill-across tra il cubo delle vendite (misura Dollar Sales) e quello delle promozioni

(misura Discount) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.20 Architettura ROLAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.1 Schema a stella per le vendite; in corsivo sono rappresentate le chiavi delle relazioni . . . . 263.2 Una possibile istanza dello schema a stella di Figura 3.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.4 Uno schema snowflake scorretto per lo schema a stella presentato in Figura 3.1 . . . . . . . . 293.5 Alcune viste ottenibili a partire dallo schema a stella presentato in Figura 3.1 . . . . . . . . . 303.6 Memorizzazione di dati aggregati utilizzando una sola fact table . . . . . . . . . . . . . . . . . . . . . 303.7 Memorizzazione dei dati aggregati, tramite constellation schema, per lo schema delle

vendite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.8 Memorizzazione dei dati aggregati, utilizzando piu schemi a stella, per lo schema delle

vendite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.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 processodi vendita degli immobili di un’agenzia immobiliare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.3 Schema a stella associato alle vendite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.4 Schema a stella per gli affitti degli immobili; questo e un esempio di una Fact Table

strutturata male . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.5 Schema a stella per gli affitti degli immobili; questo e lo schema della Figura 4.4 con i

problemi corretti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.6 Schema a stella per la vendita e la pubblicita degli immobili con le Dimension Table

Time, PropertyForSale, Branch e Promotion conformi . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 Principali differenze tra database operazionali e Data Warehouse . . . . . . . . . . . . . . . . . . . . 5

2.1 Aggregazione sulla gerarchia temporale operata sulle quantita vendute per un datoprodotto 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 sul-le motivazioni che possono spingere all’utilizzo di tale tecnologia, introdurremo i sistemi di supportoalle decisioni; successivamente descriveremo, in via del tutto generale, il processo di Data Warehou-sing. A questo punto concentreremo la nostra attenzione sulle architetture di Data Warehouse; infine,esamineremo i metadati e chiuderemo con il problema della misurazione della qualita di un DataWarehouse.

1.1 Motivazioni

L’informazione e un bene a valore crescente, necessario per pianificare e controllare le realta aziendalicon efficacia; essa costituisce, di fatto, la materia prima che viene trasformata dai sistemi informativicome i semilavorati vengono trasformati dai sistemi di produzione.

Purtroppo, l’equazione:

dati = informazione

non e sempre corretta: spesso, infatti, la disponibilita 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’ultimodecennio e dalla pressante richiesta di utilizzare attivamente questi dati per scopi che superino quelli,di routine, legati all’elaborazione giornaliera.

Uno scenario tipico e quello di una grande azienda, con numerose filiali, i cui dirigenti desidera-no quantificare e valutare il contributo dato da ciascuna di esse al rendimento commerciale globaledell’impresa.

Essendo i dati elementari sulle attivita svolte disponibili nel database aziendale, un approcciopossibile consiste nel chiedere ai tecnici che lo amministrano di formulare un’interrogazione ad hoc cheeffettui i calcoli necessari sui dati (in genere aggregazioni).

Quando i tecnici saranno riusciti a formulare l’interrogazione voluta (tipicamente in SQL, dopoavere a lungo consultato i cataloghi del database), e una volta terminata la sua elaborazione (il cherichiedera probabilmente alcune ore, dato l’elevato volume dei dati, la complessita dell’interrogazionee la contemporanea incidenza sui dati delle interrogazioni facenti parte del normale carico di lavoro),ai dirigenti verra restituito un rapporto, sotto forma di foglio elettronico, su cui basare le decisionifuture.

Gia da parecchi anni si e capito che questa via e difficilmente percorribile, perche porta ad uninutile 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 routineporta ad inevitabili rallentamenti che rendono insoddisfatti gli utenti di entrambe le categorie.

L’idea alla base del Data Warehousing e, allora, quella di separare l’elaborazione di tipo analitico(OLAP, On-Line Analytical Processing) da quella legata alle transazioni (OLTP, On-Line Transactio-nal Processing), costruendo un nuovo raccoglitore di informazioni che integri i dati elementari prove-nienti da sorgenti di varia natura, li organizzi in una forma appropriata e li renda quindi disponibiliper 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 Warehousingvengono impiegate con successo:

• commercio: analisi delle vendite e dei reclami, controllo di spedizioni e inventari, cura del rapportocon 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;• sanita: analisi di ricoveri e dimissioni, contabilita per centri di costo.

D’altronde, il campo di utilita dei sistemi di Data Warehousing non e ristretto al dominio aziendalee 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 e la necessita di strumenti di archiviazione e interroga-zione che consentono di ottenere facilmente e in tempi ridotti, dall’enorme quantita di dati memorizzatinei database o resi disponibili su Internet, informazioni di sintesi che permettano la valutazione di unfenomeno, la scoperta delle correlazioni significative e, in definitiva, l’acquisizione di conoscenza utilecome supporto alle decisioni.

1.2 I sistemi di supporto alle decisioni

La funzione svolta dalle basi di dati in ambito aziendale e stata fino a qualche anno fa solo quella dimemorizzare dati operazionali, ossia dati generati da operazioni, principalmente di carattere ammini-strativo, svolte all’interno dei processi gestionali (per esempio, gestione degli acquisti, gestione dellevendite, fatturazione).

D’altronde, per ciascuna azienda, e fondamentale poter disporre, in maniera rapida e completa, del-le informazioni necessarie al processo decisionale; le indicazioni strategiche vengono estrapolate princi-palmente dalla mole di dati operazionali contenuti nei database aziendali, attraverso un procedimentodi selezione e sintesi progressiva, schematizzato nella Figura 1.1.

Fonti informative primarie

Informazioni selezionate

Rapporti

Indicazioni strategicheValore

Quantità

Figura 1.1. Il valore dell’informazione in funzione della quantita

Ben presto, l’aumento esponenziale del volume dei dati operazionali ha reso il calcolatore l’unicosupporto adatto al processo decisionale svolto dai dirigenti aziendali.

Proprio a causa di cio il ruolo delle basi di dati, a partire dagli anni ’80, ha subito profondemodifiche 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 attia 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 nellaTabella 1.1.

Nel Passato Nel Futuro

Descrivere il passato Anticipare il futuroDescrivere i problemi Suggerire i cambiamenti da apportareRidurre 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 necessita:

• di gestire grandi moli di dati;• di accedere a diverse fonti di dati, presenti, eventualmente, su piattaforme eterogenee;• di garantire l’accesso a piu 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 cuinegli ultimi anni si e maggiormente focalizzata l’attenzione sia del mondo accademico che di quelloindustriale.

Informalmente, un Data Warehouse puo essere definito come una collezione di metodi, tecnolo-gie e strumenti di ausilio al cosiddetto “lavoratore della conoscenza” (knowledge worker - dirigente,amministratore, gestore, analista) per condurre analisi dei dati finalizzate all’attuazione di processidecisionali e al miglioramento del patrimonio informativo.

Questa definizione, volutamente molto generale, rende un’idea degli scopi del processo ma non neesprime le peculiarita.

Per capire a fondo il ruolo e l’utilita del Data Warehousing occorre allora analizzare le esigenzeche ne hanno decretato la nascita. Alcune lamentele ricorrenti da parte degli utenti finali dei sistemiinformativi tradizionali sono efficacemente riassunte da Kimball:

• Abbiamo montagne di dati ma non possiamo accedervi! Questa frase esprime la frustrazione daparte di chi ha il ruolo e la competenza per decidere del futuro aziendale ma non possiede glistrumenti tecnici per ottenere, nella forma desiderata, i dati necessari.

• Come e possibile che persone che svolgono lo stesso ruolo presentino risultati sostanzialmentediversi? In un contesto aziendale medio-grande sono tipicamente presenti piu basi di dati, ciascunarelativa ad una diversa area del business, spesso memorizzate su piattaforme logico-fisiche differentie non integrate dal punto di vista concettuale. I risultati prodotti all’interno delle diverse areesaranno, allora, molto probabilmente inconsistenti tra loro.

• Vogliamo selezionare, raggruppare e manipolare i dati in ogni modo possibile! Il processo deci-sionale e difficilmente pianificabile a priori. L’utente finale vorrebbe disporre di uno strumentosufficientemente amichevole e flessibile da consentirgli di condurre l’analisi in modo estempora-neo, lasciandosi guidare dalle informazioni via via ottenute per decidere sul momento quali nuovecorrelazioni ricercare.

• Vogliamo mostrare solo cio che e importante! Esaminare i dati al massimo livello di dettaglio enon solo inutile ma, addirittura, controproducente per il processo decisionale perche non consentedi focalizzare l’attenzione sulle informazioni veramente significative.

• Tutti sanno che alcuni dati non sono corretti! Questo e un altro punto dolente. Una percentualenon trascurabile dei dati transazionali e non corretta, o addirittura assente. Evidentemente, basareil procedimento analitico su dati errati e incompleti non permette di raggiungere risultati validi.


Da questo elenco di difficolta e problemi possiamo facilmente estrarre un elenco di parole chiaveche diventano fattori distintivi e requisiti indispensabili del processo di Data Warehousing, ossia delcomplesso di attivita che consentono di trasformare i dati operazionali in conoscenza a supporto delledecisioni:

• accessibilita a utenti con conoscenze limitate di informatica e strutture dati;• integrazione dei dati sulla base di un modello standard dell’impresa;• flessibilita 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) e un contenitore(repository) di dati che diventa garante dei requisiti esposti.

Una definizione corretta e completa di Data Warehouse e tratta dal testo di Inmon:

Un Data Warehouse (DW) e una collezione di dati di supporto per il processo decisionale chepresenta le seguenti caratteristiche:

• e orientata ai soggetti di interesse;• e integrata e consistente;• e rappresentativa dell’evoluzione temporale e non volatile.

Si intende che il DW e orientato ai soggetti perche si incentra sui concetti di interesse dell’azienda,quali i clienti, i prodotti, le vendite, gli ordini. Viceversa, i database operazionali sono organizzatiintorno alle diverse applicazioni del dominio aziendale.

L’accento sugli aspetti di integrazione e consistenza e importante poiche il DW si appoggia a piufonti di dati eterogenee: dati estratti dall’ambiente di produzione, e quindi originariamente archiviatiin basi di dati aziendali o, addirittura, provenienti da sistemi informativi esterni all’azienda. Di tuttiquesti dati il DW si impegna a restituire una visione unificata.

In linea di massima, si puo dire che la costruzione di un sistema di Data Warehousing non comportal’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, poiche la maggiorparte delle transazioni coinvolge i dati piu recenti, il DW deve permettere analisi che spazino sullaprospettiva di alcuni anni. Per tale motivo, il DW e aggiornato ad intervalli regolari, a partire dai datioperazionali, ed e in continua crescita.

Volendo fare un paragone possiamo supporre che, a intervalli regolari, venga scattata una fotografiaistantanea dei dati operazionali. La progressione delle fotografie scattate viene memorizzata nel DWdove 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 Warehousee che gli aggiornamenti sono tipicamente eseguiti “a freddo”, ossia quando il DW e fuori linea, un DWpuo essere fondamentalmente considerato come un database a sola lettura. Tale caratteristica, insiemeall’esigenza degli utenti di contenere i tempi di risposta alle interrogazioni di analisi, ha importanticonseguenze a vari livelli.

Innanzitutto essa incide sulle tecnologie adottate dai DBMS specializzati per il Data Warehousing:non sono, infatti, piu necessarie le tecniche sofisticate di gestione delle transazioni richieste dalleapplicazioni operazionali.

Inoltre, il fatto di operare in sola lettura differenzia profondamente le soluzioni di progettazionelogica per i DW da quelle utilizzate per i database operazionali: l’aspetto forse piu evidente nelleimplementazioni relazionali e che la pratica della normalizzazione delle tabelle viene abbandonata afavore di una parziale denormalizzazione, mirata al miglioramento delle prestazioni.

Ulteriori e fondamentali differenze tra database operazionali e DW sono legate alle tipologie diinterrogazioni. Per i primi, le interrogazioni eseguono transazioni che in genere leggono e scrivono unridotto numero di record da diverse tabelle legate da semplici relazioni: per esempio, si ricercano idati di un cliente per inserire un suo nuovo ordine. Questo tipo di elaborazione viene comunementedetto On-Line Transactional Processing (OLTP). Al contrario, il tipo di elaborazione per cui nasconoi DW viene detto On-Line Analytical Processing (OLAP), ed e caratterizzato da un’analisi dinamica e

1.4 Architetture per il Data Warehousing 5

multidimensionale che richiede la scansione di un’enorme quantita di record per calcolare un insiemedi dati numerici di sintesi che quantifichino le prestazioni dell’azienda.

E importante osservare che, mentre nei sistemi OLTP il nucleo sostanziale del carico di lavoro econgelato all’interno dei programmi applicativi, e solo occasionalmente vengono lanciate interrogazioniestemporanee o di manutenzione straordinaria sui dati, in un DW l’interattivita e una caratteristicairrinunciabile delle sessioni di analisi e fa si che il carico di lavoro effettivo vari continuamente neltempo.

Le peculiarita delle interrogazioni OLAP fanno si che i dati nel DW vengano normalmente rap-presentati in forma multidimensionale. L’idea di base e quella di vedere i dati come punti in unospazio 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 diinteresse per il processo decisionale.

Le principali differenze tra database operazionali e Data Warehouse vengono riassunte nella Tabella1.2.

Caratteristiche Database Operazionali Data Warehouse

Utenti Migliaia CentinaiaCarico di Lavoro Transazioni Predefinite Interrogazioni di analisi ad hocAcceso A centinaia di record, in lettura e scrittura A milioni di record, per lo piu in letturaScopo Dipende dall’applicazione Supporto alle decisioniDati Elementari, sia numerici che alfanumerici Di sintesi, prevalentemente numericiIntegrazione dei dati Per applicazione Per soggettoQualita In termini di integrita In termini di consistenzaCopertura temporale Solo dati correnti Dati correnti e storiciAggiornamenti Continui PeriodiciModello Normalizzato Denormalizzato e multidimensionaleOttimizzazione Per accessi OLTP su una frazione del database Per accessi OLAP su gran parte del databaseSviluppo 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 denotaretutto il sistema di Data Warehousing, anziche il solo contenitore dei dati di sintesi. Laddove riterremoche non si generi confusione, adotteremo anche noi questa comoda abbreviazione.

Le caratteristiche architetturali irrinunciabili per un sistema di Data Warehousing possono esserecosı enunciate:

• Separazione: l’elaborazione analitica e quella transazionale devono essere mantenute il piu possibileseparate.

• Scalabilita: l’architettura hardware e software deve poter essere facilmente ridimensionata a frontedella crescita nel tempo dei volumi di dati da gestire ed elaborare e del numero di utenti dasoddisfare.

• Estendibilita: deve essere possibile accogliere nuove applicazioni e tecnologie senza riprogettareintegralmente il sistema.

• Sicurezza: il controllo sugli accessi e essenziale a causa della natura strategica dei dati memorizzati.• Amministrabilita: la complessita dell’attivita 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, e la minimizzazione deidati memorizzati, ottenuta eliminando le ridondanze.


Datioperazionali

Middleware

Livello delleSorgenti

Livello delWarehouse

Livello diAnalisi

Strumenti direportistica

StrumentiOLAP

Figura 1.2. Architettura ad un livello per un sistema di Data Warehousing

Come mostrato nella Figura 1.2, il Data Warehouse e in questo caso virtuale, nel senso che vie-ne implementato come una vista multidimensionale dei dati operazionali generata da un appositomiddleware, ovvero da uno strato di elaborazione intermedio.

Il primo punto debole di questa architettura e che non rispetta il requisito di separazione tral’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 e possibile (anche se complesso) rispondere ai requisiti diintegrazione e correttezza dei dati, diventa impossibile esprimere un livello di storicizzazione superiorea quello delle sorgenti.

Per questi motivi, l’approccio virtuale al Data Warehousing ha avuto successo soltanto in contestiin cui le esigenze di analisi sono particolarmente limitate e il volume dei dati da esaminare e moltoampio.

1.4.2 Architettura a due livelli

Il requisito di separazione gioca un ruolo fondamentale nel determinare la classica architettura di unsistema di Data Warehousing, rappresentata in Figura 1.3.

Sebbene tradizionalmente denominata architettura a due livelli, per evidenziarne la separazionetra il livello delle sorgenti e quello del DW, essa, in realta, si articola complessivamente su quattrolivelli 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 produzionee, quindi, archiviati originariamente in database aziendali, relazionali o legacy, oppure provenientida sistemi informativi esterni all’azienda.

• Livello dell’alimentazione. I dati memorizzati nelle sorgenti devono essere estratti, ripuliti (pereliminare le inconsistenze e completare eventuali parti mancanti) e integrati (per fondere sorgentieterogenee secondo uno schema comune). I cosiddetti strumenti ETL (Extraction, Transformationand Loading) permettono di integrare schemi eterogenei, nonche di estrarre, trasformare, ripulire,validare, filtrare e caricare i dati dalle sorgenti nel DW. Dal punto di vista tecnologico vengono trat-tate problematiche tipiche dei servizi informativi distribuiti, come la gestione di dati inconsistentie delle strutture dati incompatibili.

• Livello del Warehouse. Le informazioni vengono raccolte in un singolo “contenitore” (il Data Ware-house), centralizzato logicamente. Esso puo essere direttamente consultato, ma anche usato comesorgente per costruire data mart; questi ultimi sono orientati verso specifiche aree dell’impresae, 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, sulleprocedure di pulitura ed alimentazione, sugli utenti, sugli schemi dei data mart, ecc.


Datioperazionali

Strumenti ETL

Datiesterni

Data mart

Data WarehouseMetadati


Livello dialimentazione


Livello diAnalisiStrumenti di

reportistica

StrumentiOLAP

Strumentidi Data Mining

Strumenti perl’analisi what-if

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 stesuradei report nonche per le attivita di analisi e di simulazione.

Dal punto di vista tecnologico sono richieste capacita di gestione dei dati aggregati, ottimizzazionedi interrogazioni complesse, tecniche di indicizzazione avanzate e interfacce visuali amichevoli.

La distinzione tra Data Warehouse e Data Mart, introdotta nell’architettura, merita un approfon-dimento. Il blocco che va sotto il nome di Data Warehouse viene, spesso, denominato anche DataWarehouse primario o Data Warehouse aziendale, e svolge il ruolo di contenitore centrale e globaledei dati di sintesi. I Data Mart possono essere visti come piccoli DW locali che replicano (ed eventual-mente sintetizzano ulteriormente) la porzione di DW primario di interesse per una particolare areaapplicativa.

Con il termine Data Mart si intende un sottoinsieme o un’aggregazione dei dati presenti nel DWprimario, contenente l’insieme delle informazioni rilevanti per una particolare area del business, unaparticolare divisione dell’azienda, oppure una particolare categoria di soggetti.

I Data Mart alimentati dal DW primario sono spesso detti dipendenti. Sebbene, in linea di principionon strettamente necessari, per i sistemi collocati all’interno di realta aziendali medio-grandi essicostituiscono 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’archi-tettura 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 determinauno schema complesso per l’accesso ai dati e ingenera il rischio di inconsistenza tra i Data Mart.


Datisorgente

Datisorgente

Datisorgente

Strumenti ETL

Data mart Data mart

Metadati

Metadati





reportistica

StrumentiOLAP



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 co-munque un DW centrale; in quest’ultimo caso, rispetto all’architettura standard a due livelli, i ruolidei Data Mart e del DW sono, di fatto, invertiti; infatti, il DW, in questo caso, viene alimentato daiData Mart e puo 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 warehousefunge da separatore tra le sorgenti e le applicazioni di analisi, sono cosı riassumibili:

• A livello del DW e continuamente disponibile informazione di buona qualita anche quando, permotivi tecnici oppure organizzativi, e temporaneamente precluso l’accesso alle sorgenti.

• L’interrogazione analitica effettuata sul DW non interferisce con la gestione delle transazioni alivello operazionale, la cui affidabilita e essenziale per il funzionamento dell’azienda.

• L’organizzazione logica del DW e basata sul modello multidimensionale, mentre le sorgenti presen-tano, in genere, modelli relazionali o semi-strutturati.

• C’e una discordanza temporale e di granularita tra sistemi OLTP, che trattano dati correnti e almassimo livello di dettaglio, e sistemi OLAP, che operano su dati storici e di sintesi.

• A livello del DW e possibile utilizzare tecniche specifiche per ottimizzare le prestazioni perapplicazioni di analisi e reportistica.

E 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 DWcome un contenitore di dati integrati e consistenti, ma ancora in forma operazionale, introducendo larappresentazione multidimensionale dei dati solo a livello dei Data Mart. Nella nostra terminologiaquesta visione operazionale del DW corrisponde, sostanzialmente, al livello dei dati riconciliati nellearchitetture a tre livelli, trattate nella prossima sezione.

1.4.3 Architettura a tre livelli

Il terzo livello introdotto in questa architettura e il cosiddetto livello dei dati riconciliati, detto ancheoperational data store, che materializza i dati operazionali ottenuti a valle del processo di integrazione


e ripulitura dei dati sorgente: si ottengono, quindi dati integrati, consistenti, corretti, volatili, correntie dettagliati.

Come illustrato nella Figura 1.5, il DW non viene piu alimentato direttamente dalle sorgenti, bensıdai dati riconciliati.

Il vantaggio principale del livello dei dati riconciliati e che esso crea un modello di dati comune e diriferimento per l’intera azienda, introducendo, al contempo, una separazione netta tra le problematichelegate all’estrazione e integrazione dei dati dalle sorgenti e quelle inerenti l’alimentazione del DW.

Datioperazionali

Strumenti ETL

Datiesterni

Data mart

Data Warehouse

Dati riconciliati

Caricamento

Metadati





reportistica

StrumentiOLAP



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

Va, comunque, detto che, in realta, si puo assumere che anche nelle architetture a due livelli siapresente un livello riconciliato, che non sara, in quel caso, materializzato ma soltanto virtuale, essendodefinito come una vista integrata e consistente dei dati memorizzati nelle sorgenti operazionali.


1.5 I Metadati

Il termine “Metadati” si applica ai dati usati per descrivere altri dati. Nel contesto del Data Ware-housing, in cui giocano un ruolo sostanziale, essi indicano le sorgenti, il valore, l’uso e le funzioni deidati memorizzati nel DW e descrivono come i dati vengono alterati e trasformati durante il passaggioattraverso i diversi livelli dell’architettura.

Come mostrato nelle Figure 1.3, 1.4 e 1.5, il contenitore dei metadati e strettamente collegato alDW vero e proprio; le applicazioni ne fanno un intenso uso sia dal lato dell’alimentazione che da quellodell’analisi.

E possibile distinguere due categorie di metadati, parzialmente sovrapposte, in base ai diversiutilizzi 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, letrasformazioni, 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 qualita, leunita di misura e le aggregazioni significative.

I metadati vengono memorizzati in un apposito contenitore al quale possono accedere tutti gli altricomponenti 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 standarddenominato Common Warehouse Metamodel (CWM), che si poggia su tre standard affermati qualiUML (Unified Modeling Language), XML (eXtensible Markup Language) e XMI (XML MetadataInterchange) ed e 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 BusinessIntelligence, alla gestione della conoscenza e ai portali Web.

1.6 Qualita di un Data Warehouse

La qualita di un processo misura la sua aderenza agli obiettivi degli utenti.Nel caso di sistemi di Data Warehousing, in virtu della loro natura e del loro utilizzo, la qualita

deve essere intesa non solo a livello dei singoli dati ma, soprattutto, con riferimento all’intero sistemaintegrato.

Il problema di definire, misurare e massimizzare la qualita di un sistema di DW e molto complesso.Ci limitiamo, pertanto, a segnalare alcuni tra i fattori che caratterizzano la qualita dei dati:

• Accuratezza: il valore memorizzato e conforme a quello reale.• Attualita: il dato memorizzato non e obsoleto.• Completezza: non mancano informazioni.• Consistenza: la rappresentazione dei dati e uniforme.• Disponibilita: i dati sono facilmente disponibili all’utente.• Tracciabilita: e 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 ilmodello multidimensionale e l’OLAP. Piu specificatamente, la prima parte del capitolo illustra le ca-ratteristiche del modello multidimensionale; successivamente vengono prese in esame le varie tipologiedi strumenti per l’analisi dei dati memorizzati in un Data Warehouse. In particolare, esamineremodapprima la reportistica e, successivamente, l’OLAP. Per quanto riguarda quest’ultima tecnica, esa-mineremo in dettaglio i vari operatori previsti da essa e, successivamente, illustreremo la differenzatra ROLAP e MOLAP.

2.1 Il modello multidimensionale

Negli ultimi anni le basi di dati multidimensionali hanno suscitato un vasto interesse di ricerca e dimercato, 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 rappresentazionedei dati nei DW e, fondamentalmente, legato alla sua semplicita ed intuitivita anche per utenti nonesperti di informatica; tali proprieta sono, a loro volta, dovute alla vasta diffusione di applicazioni ditipo spreadsheet come strumento di produttivita individuale.

Per un approccio efficace al modello multidimensionale, forse, il miglior punto di partenza e unadescrizione 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 comportera una diminuzione della durata media di un ricovero?• Che rapporto c’e tra i profitti realizzati con spedizioni con meno di 10 elementi e quelli realizzati

con spedizioni con piu di 10 elementi?

E chiaro che esprimere interrogazioni di questa natura tramite linguaggi tradizionali come SQLrisulta alquanto complesso ed e altrettanto chiaro che la loro esecuzione su database operazionaliporterebbe a tempi di risposta difficilmente accettabili.

Il modello multidimensionale prende le mosse dalla constatazione che gli oggetti che influenzanoil processo decisionale sono fatti del mondo aziendale, quali, per esempio, le vendite, le spedizioni, iricoveri, gli interventi chirurgici. Le occorrenze di un fatto corrispondono ad eventi accaduti: ciascunavendita o spedizione effettuata e un evento. Per ciascun fatto interessano, in particolare, i valori di uninsieme di misure che descrivono quantitativamente gli eventi: l’incasso di una vendita, la quantitaspedita, il costo di un ricovero, la durata di un intervento chirurgico.

Gli eventi che accadono nell’azienda sono, evidentemente, tantissimi, troppi per poter essere analiz-zati singolarmente. Per poterli selezionare e raggruppare agevolmente si immagina, allora, di collocarliin uno spazio n-dimensionale i cui assi, chiamati, appunto, dimensioni di analisi, definiscono varieprospettive 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 tridi-mensionale le cui dimensioni sono i prodotti, i negozi e le date. Per le spedizioni, le dimensioni possonoessere il prodotto, la data di spedizione, l’ordine, la destinazione e la modalita. I ricoveri possono essereidentificati dalla terna 〈reparto, data, paziente〉, mentre per gli interventi chirurgici occorre aggiungereil tipo di intervento.

E, proprio, il concetto di dimensione che ha dato origine alla diffusissima metafora del cubo perla rappresentazione dei dati multidimensionali. Secondo questa metafora, gli eventi corrispondono acelle di un cubo i cui spigoli rappresentano le dimensioni di analisi (se le dimensioni sono piu di tre,si tratta piu 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 e

la vendita in una catena di negozi. Le dimensioni di analisi sono negozio, prodotto e data; un eventocorrisponde alla vendita di un determinato prodotto in un determinato negozio in un particolaregiorno, ed e descritto da due misure: la quantita 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 e 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 faretramite lo schema relazionale:

VENDITE(negozio, prodotto, data, quantita, incasso)

in cui gli attributi sottolineati sono quelli che costituiscono la chiave primaria e gli eventicorrispondono 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 allastessa terna di valori di negozio, prodotto e data, ma anche che ciascuna terna di valori determinafunzionalmente un unico valore di quantita e un unico valore di incasso. In altre parole, esiste unadipendenza funzionale del tipo:

negozio, prodotto, data → quantita, incasso

La definizione di dipendenza funzionale proviene dalla teoria relazionale. Dato uno schema re-lazionale R e due insiemi di attributi X = a1, . . . , an e Y = b1, . . . , bm, si dice che X determinafunzionalmente Y (scritto X → Y ) se e solo se, per tutte le istanze legali r di R, per ciascuna coppiadi tuple t1 e t2 di r si ha che t1[x] = t2[x] implica t1[y] = t2[y]. Per estensione, nel seguito, diremoche esiste una dipendenza funzionale tra due insiemi di attributi X ed Y quando a ciascun insieme divalori di X corrisponde, necessariamente, nel dominio applicativo, un unico insieme di valori di Y .

Per semplicita di notazione, nell’enumerare gli elementi di ciascun insieme, elimineremo le parentesigraffe.

Per evitare malintesi sul significato del termine “evento”, e importante, a questo punto, precisareche l’insieme delle dimensioni prescelte per rappresentare un fatto identifica univocamente un eventonel modello multidimensionale, ma non necessariamente un evento del dominio applicativo. Per chiarirequesta affermazione apparentemente strana, si consideri ancora il caso delle vendite. Nel dominioapplicativo 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 prodottoin uno specifico negozio.

Come e evidente, la differenza tra le due interpretazioni dipende, da un lato, dal fatto che unoscontrino contiene, in generale, piu prodotti, dall’altro dal fatto che uno stesso prodotto viene, ingenerale, venduto piu volte nello stesso giorno e nello stesso negozio.

Nel seguito, quando non diversamente specificato, useremo il termine “evento”, e di conseguenzail termine “fatto”, con riferimento alla granularita che esso assume nel modello multidimensionale.

Normalmente, ciascuna dimensione e associata ad una gerarchia di livelli di aggregazione (chia-mata, a volte, gerarchia di roll-up) che ne raggruppa i valori in diversi modi. Chiameremo attributidimensionali i livelli che compongono una gerarchia.

La Figura 2.2 propone un piccolo esempio di gerarchie sulle dimensioni prodotto e negozio: i pro-dotti sono raggruppati in tipi, ulteriormente suddivisi in categorie; i negozi si trovano in citta che, aloro volta, fanno parte di regioni. In cima a ciascuna gerarchia si trova un livello fittizio che raggruppatutti i valori relativi a una dimensione.

Prodotto

Negozio

Tipo

Città

Categoria

Regione

BrilloSbiancoLucido

ManipuliteScent

Latte fresco slurpLatte UHT slurpYogurt slurp

BevimiColissima

DiTutto2

Nonsolopappa

DiTutto

DiTutto3

Detersivo

Sapone

Latticino

Bibita

Bologna

Milano

Como

Pulizia casa

Alimentari

EmiliaRomagna

Lombardia

Tutti i prodotti

Tutti i negozi

Figura 2.2. Gerarchie di aggregazione sulle dimensioni prodotto e negozio

Dal punto di vista della teoria relazionale, una gerarchia e esprimibile tramite un insieme didipendenze funzionali tra attributi dimensionali:

prodotto → tipo → categoria

negozio → citta → regione

Riassumendo, un cubo multidimensionale e incentrato su un fatto di interesse per il processodecisionale. Esso rappresenta un insieme di eventi descritti quantitativamente da misure numeriche.Ogni asse del cubo rappresenta una possibile dimensione di analisi; ciascuna dimensione puo esserevista a piu 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, vengonodistinte le singole vendite), sono ancora difficilmente fruibili dall’utente a causa della loro quantita.

Se la catena comprende 50 negozi che vendono complessivamente 1000 prodotti, e il DW copre 3anni di transazioni (circa 1000 giorni), il numero totale di eventi possibili risulta pari a 50 × 1000 ×1000 = 5 × 107. 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 × 106, ancora troppi perpoter essere analizzati da un utente senza far ricorso a strumenti automatici.


Le tecniche per ridurre la quantita dei dati e ottenere, cosı, informazioni utili sono essenzialmentedue: la restrizione e l’aggregazione; per entrambe, come vedremo nei due paragrafi seguenti, la metaforadel 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; cioimplica, nella terminologia dell’Algebra Relazionale, effettuare selezioni e/o proiezioni.

La forma piu semplice di restrizione e il cosiddetto slicing (letteralmente, affettatura) dei dati,illustrato nella Figura 2.3, in cui si riduce la dimensionalita del cubo fissando un valore per una o piudimensioni.

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, peresempio negozio = “DiTutto”, si ottiene come risultato l’insieme degli eventi associati alle venditeeffettuate presso il negozio DiTutto; secondo la metafora si trattera di un piano, ovvero una “fettina”di dati agevolmente visualizzabile all’interno di un foglio elettronico (secondo le ipotesi sui volumi didati introdotte in precedenza, si avranno circa 105 eventi).

Se vengono fissate due dimensioni, per esempio negozio = “DiTutto” e data = “5/4/2001”, ilrisultato sono tutte le vendite di prodotti distinti effettuate presso DiTutto il 5/4/2001 (circa 100eventi); cio e rappresentato, graficamente, dall’intersezione di due piani perpendicolari, ovvero unaretta.

Infine, se tutte le dimensioni vengono fissate, si identifica un unico evento corrispondente ad unpunto nello spazio tridimensionale delle vendite.

La selezione e una generalizzazione dello slicing in cui si riduce la grandezza del cubo esprimendocondizioni sugli attributi dimensionali. Per esempio, si possono selezionare le sole vendite di detersivoBrillo nei negozi di Bologna nei giorni di gennaio 2001.

In questo modo, se i 50 negozi sono uniformemente distribuiti su 10 citta, il numero di eventi daesaminare passa a 5 × 31 = 155, comodamente visionabile all’interno di una matrice bidimensionaleo di un grafo.

Infine, la proiezione e riconducibile alla scelta di mantenere, per ciascun evento, un sottoinsiemedi misure, scartando le altre.

2.1 Il modello multidimensionale 15

2.1.2 Aggregazione

L’aggregazione e 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, cio significa raggruppare, per ciascun prodotto e negozio, tutte lecelle relative ai giorni di uno stesso mese in un’unica macro-cella. Nel cubo cosı aggregato, il numerocomplessivo di eventi (inteso come il numero di macro-celle risultanti) sara pari a 50 × 1000 × 36,poiche, sulla dimensione tempo, la granularita non e piu a livello di giorno ma di mese, e 36 sono imesi del triennio.

Ciascun evento conterra una sintesi dei dati presenti negli eventi che esso aggrega: nel caso inesame, il numero totale di esemplari venduti nel mese e l’incasso complessivo calcolati sommando ivalori elementari delle corrispondenti misure (si veda la Tabella 2.1).

Data DiTutto DiTutto2 Nonsolopappa

1/1/2000 - - -2/1/2000 10 15 53/1/2000 20 - 5. . . . . . . . . . . .

1/1/2001 - - -2/1/2001 15 10 203/1/2001 20 20 25. . . . . . . . . . . .

1/1/2002 - - -2/1/2002 20 8 253/1/2002 20 12 20. . . . . . . . . . . .


Gennaio 2000 200 180 150Febbraio 2000 180 150 120Marzo 2000 220 180 160. . . . . . . . . . . .




2000 2400 2000 16002001 3200 2300 30002002 3400 2200 3200


Totale 9000 6500 7800

Tabella 2.1. Aggregazione sulla gerarchia temporale operata sulle quantita vendute per un dato prodotto intre negozi

Aggregando ulteriormente sul tempo, per ogni combinazione prodotto-negozio, si possono otteneretre soli eventi, uno per ciascun anno.

Al massimo livello di aggregazione sulla dimensione tempo, ciascuna combinazione corrisponde adun unico evento che riporta il numero totale di esemplari di un prodotto venduti in un negozio nei treanni e l’incasso complessivo.

L’aggregazione puo essere operata contemporaneamente su piu dimensioni. Per esempio, come mo-strato in Figura 2.4, e possibile aggregare le vendite per mese, tipo di prodotto e citta del negozio,nonche solo per mese e tipo di prodotto.

Inoltre, selezione e aggregazione possono essere combinate per permettere un processo di analisimirato con precisione alle esigenze dell’utente.


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 e 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 e orientato agli utenti che hanno necessita di accedere, ad intervalli di tempopredefiniti, ad informazioni strutturate in modo pressocche invariabile.

Per esempio, un’azienda sanitaria locale deve consegnare agli uffici regionali rapporti mensili rie-pilogativi sui costi di ricovero sostenuti. Di questi rapporti e nota a priori la forma, che cambia soloa seguito della normativa vigente. Il progettista puo, allora, progettare l’interrogazione che genera ilrapporto nella forma voluta e “congelarla” all’interno di un’applicazione perche possa essere eseguitasui dati correnti quando l’utente ne ha l’effettiva necessita.

Un rapporto e definito da un’interrogazione e da una presentazione. L’interrogazione comporta, ingenere, la selezione e l’aggregazione dei dati multidimensionali: per esempio, essa puo richiedere gliincassi mensili durante l’ultimo trimestre per ciascuna categoria di prodotto. La presentazione puoessere in forma tabellare oppure grafica (diagramma, istogramma, torta, ecc.); la Figura 2.5 mostraalcuni esempi di presentazione per l’interrogazione precedentemente riportata.

Uno strumento di reportistica si valuta non solo in base alla ricchezza nella presentazione deirapporti, ma anche considerando la flessibilita nei meccanismi per la loro distribuzione.

Il rapporto puo essere generato su richiesta esplicita dell’utente oppure distribuito automaticamentee periodicamente agli utenti registrati, per esempio tramite un servizio di posta elettronica.

E opportuno evidenziare che la reportistica non e certamente nata con il Data Warehousing: daquando esistono le basi di dati i rapporti sono sempre stati il mezzo principale su cui la direzione hapotuto basare le attivita di valutazione e pianificazione.

D’altronde, il Data Warehousing ha arrecato alla reportistica due grandi benefici: dal punto di vistadell’affidabilita e della correttezza dei risultati, poiche i dati di cui i rapporti offrono la sintesi sono oraconsistenti e integrati, e dal punto di vista della tempestivita, poiche la separazione architetturale tral’elaborazione delle transazioni e quella analitica migliora significativamente le prestazioni di calcolo.

2.2.2 OLAP

L’OLAP e, probabilmente, la principale modalita di fruizione delle informazioni contenute in un DW;sicuramente esso rappresenta la modalita piu conosciuta e consente ad utenti le cui necessita 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 basedel modello multidimensionale.

Mentre gli utenti degli strumenti di reportistica svolgono un ruolo essenzialmente passivo, gli utentiOLAP sono in grado di costruire attivamente una sessione di analisi complessa in cui ciascun passoeffettuato e conseguenza dei risultati ottenuti al passo precedente.

Il carattere estemporaneo delle sessioni di lavoro, l’approfondita conoscenza dei dati richiesta, lacomplessita delle interrogazioni formulabili e l’orientamento verso utenti tipicamente non esperti diinformatica rendono cruciale il ruolo dello strumento utilizzato, la cui interfaccia deve necessariamentepresentare ottime caratteristiche di flessibilita, facilita d’uso ed efficacia.

Una sessione OLAP consiste, in pratica, in un percorso di navigazione che riflette il procedimentodi analisi di uno o piu 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 formulatedirettamente, ma per differenza rispetto all’interrogazione precedente.

Il risultato delle interrogazioni e di tipo multidimensionale; poiche le capacita umane di ragionarein piu di tre dimensioni sono molto limitate, gli strumenti OLAP rappresentano tipicamente i dati inmodo tabellare, evidenziando le diverse dimensioni mediante intestazioni multiple, colori, ecc.

Ogni passo della sessione di analisi e scandito dall’applicazione di un operatore OLAP che trasformal’ultima interrogazione formulata in una nuova interrogazione.

Gli operatori piu comuni sono roll-up, drill-down, slice-and-dice, pivoting, drill-across, drill-through.

Nel seguito illustreremo tali operatori mediante un esempio che descrive un grande magazzinovirtuale, 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 inFigura 2.6.

Year (anno)

Category(categoria)

Customer Region(regione cliente)

Customer City(città cliente)

Customer(cliente)

Subcategory(categoria second.)

Product (articolo)

Quarter (trimestre)

Month (mese)

Time (data)

Figura 2.6. Le gerarchie di attributi nel V-Mall; le frecce indicano dipendenze funzionali


Roll-up

Roll-up significa, letteralmente, arrotolare o alzare, e induce un aumento nell’aggregazione dei datieliminando un livello di dettaglio da una gerarchia.

Si supponga, per esempio, che l’utente stia visualizzando gli incassi mensili del ’97 e ’98 per ciascunaregione del cliente; come mostrato in Figura 2.7, effettuare un roll-up puo significare eliminare ildettaglio sui singoli mesi per visualizzare gli incassi trimestrali complessivi per ciascuna regione.

Figura 2.7. Roll-up sulla gerarchia temporale

Il roll-up puo anche portare alla diminuzione della dimensionalita del risultato, qualora tutti idettagli di una gerarchia vengano eliminati; con riferimento alla Figura 2.8, cio puo significare, peresempio, eliminare le informazioni relative ai clienti e visualizzare gli incassi annuali totali per ciascunacategoria di prodotto, passando da una tabella tridimensionale ad una bidimensionale.

Figura 2.8. Roll-up con eliminazione della gerarchia cliente


La Figura 2.9 schematizza l’operazione di roll-up, con e senza diminuzione della dimensionalita,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) e duale al roll-up: infatti, come mostrato in Fi-gura 2.9, esso diminuisce l’aggregazione dei dati introducendo un ulteriore livello di dettaglio in unagerarchia.

La Figura 2.10 mostra un esempio su una tabella bidimensionale, in cui si passa dall’aggregazioneper regione del cliente a quella, piu fine, per citta del cliente.

Figura 2.10. Drill-down sulla gerarchia del cliente

Nel caso della Figura 2.11, il drill-down comporta l’aumento della dimensionalita della tabella aseguito dell’aggiunta del dettaglio sulle regioni dei clienti.

Slice-and-Dice

Il termine slice-and-dice (letteralmente, tagliare a fette e cubetti) e uno dei piu abusati nella letteraturasul Data Warehousing, anche se viene utilizzato con significati diversi. Alcuni autori lo usano perdenotare, genericamente, l’intero processo di navigazione OLAP; altri autori lo utilizzano per indicareoperazioni di selezione e proiezione sui dati.

Noi chiameremo “slicing” l’operazione che riduce la dimensionalita del cubo, fissando un valore peruna delle dimensioni, mentre chiameremo “selezione” o “filtraggio” l’operazione che riduce l’insiemedei 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.


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 modalita di presentazione con l’obiettivo dianalizzare le stesse informazioni sotto diversi punti di vista.

Seguendo la metafora multidimensionale, effettuare il pivoting significa ruotare il cubo in mododa riorganizzare le celle secondo una nuova prospettiva, ovvero portando in primo piano una diversacombinazione di dimensioni (Figura 2.15).

Le Figure 2.16 e 2.17 illustrano esempi di pivoting su tabelle bi- e tri-dimensionali.


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 possibilita di stabilire un collegamento tra due o piu cubi cor-relati al fine di compararne i dati, per esempio calcolando espressioni che coinvolgono misure derivatedai due cubi (Figura 2.18).

In Figura 2.19 viene riportato un esempio di drill-across tra il cubo delle vendite e il cubo dellepromozioni per confrontare gli incassi e gli sconti per ciascun trimestre e per ciascuna categoria diprodotti.


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 (misuraDiscount)

2.3 ROLAP e MOLAP

I termini “ROLAP” e “MOLAP” vengono utilizzati per denotare i due principali approcci all’imple-mentazione dei DW; essi differiscono per cio che riguarda il modello logico utilizzato per la rappre-sentazione dei dati; piu 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 DBMSmultidimensionale.

L’idea di adottare tecnologie relazionali per la memorizzazione dei dati nel DW e ben motivatase si considerano l’enorme lavoro svolto in letteratura sul modello relazionale, la diffusa esperienzaaziendale sull’utilizzo e l’amministrazione di basi di dati relazionali e l’elevato livello di prestazioni eflessibilita raggiunto dai DBMS relazionali.

Evidentemente, poiche l’espressivita del modello relazionale non include i concetti di dimensioni,misura e gerarchia, si rende necessario elaborare tipologie specifiche di schemi che permettano ditraslare il modello multidimensionale sui mattoni di base del modello relazionale costituiti da attributi,relazioni e vincoli di integrita. Questo ruolo e svolto principalmente dal celebre star scheme, o schemaa stella.

Il problema principale delle implementazioni ROLAP e legato alle prestazioni che soffrono dellanecessita 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 e “denormalizzazio-ne”, ovvero violazione consapevole della terza forma normale orientata alla massimizzazione delleprestazioni.

Sempre per ridurre i costi di esecuzione, l’altra parola d’ordine e “ridondanza”, che si ottienematerializzando un certo numero di tabelle derivate (viste) che offrono una lettura sintetica dei datiutile per le tipiche interrogazioni OLAP fortemente aggregate.

Dal punto di vista architetturale, l’adozione della soluzione ROLAP richiede di predisporre unmiddleware specializzato intermedio tra un server back-end relazionale e il lato front-end, come illustra-to in Figura 2.20. Il middleware riceve le interrogazioni OLAP formulate dall’utente sullo strumentodi front-end e, consultando i metadati, le traduce in istruzioni SQL per il back-end relazionale.

Server relazionale

Back-end Front-end

Middleware

Metadati

Client OLAP

Figura 2.20. Architettura ROLAP

Un componente particolarmente importante durante questa fase e il cosiddetto aggregate navigator;questo, in presenza di viste aggregate, si incarica di determinare, tra tutte le viste su cui una datainterrogazione puo essere risolta, quella che comporta il minimo costo di accesso.

In alcune soluzioni commerciali, il middleware e visto come un componente separato che puoessere abbinato a un qualsiasi server relazionale per creare un server “monoblocco”, specializzatonella gestione dei dati multidimensionali.

Diversamente dal ROLAP, un modello MOLAP si basa su un modello logico ad hoc sul quale i datie le operazioni multidimensionali possono essere direttamente rappresentati.

Nelle basi di dati multidimensionali, infatti, i dati vengono fisicamente memorizzati in vettori(array) e l’accesso e 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 e che le operazioni multi-dimensionali sono realizzabili in modo semplice e naturale, senza necessita di ricorrere a complesseoperazioni di join; le prestazioni di questi sistemi risultano, pertanto, ottime.

D’altro canto, non esistendo ancora uno standard per il modello logico multidimensionale, le diverseimplementazioni MOLAP hanno veramente poco in comune; in genere, l’unica cosa in comune el’utilizzo di tecnologie di ottimizzazione specifiche per trattare il problema della sparsita.


Concludiamo questa sezione menzionando brevemente l’esistenza di un terzo approccio, intermediotra i precedenti: il cosiddetto HOLAP, o Hybrid OLAP. Un esempio di sistema commerciale HOLAP eExpress Server della Oracle che puo 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 multidimen-sionale. Piu specificatamente, i modelli che prenderemo in considerazione saranno lo schema a stellae lo schema a fiocco di neve. Nel capitolo discuteremo, anche, del problema della materializzazionedelle viste.

3.1 Lo schema a stella

La modellazione multidimensionale su sistemi relazionali e basata sul cosiddetto schema a stella (starschema) e sulle sue varianti.

Definizione 3.1. Uno schema a stella e composto da:

• Un insieme di relazioni DT1, . . . ,DTn, denominate dimension table, ciascuna corrispondente a unadimensione. Ciascuna DTi e caratterizzata da una chiave primaria (tipicamente surrogata) di e daun 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. Lachiave primaria di FT e data dall’insieme delle chiavi esterne delle dimension table d1, . . . , dn; FT

contiene, inoltre, un attributo per ogni misura.

2

L’esempio di Figura 3.1 mostra lo schema a stella per il fatto delle vendite. La chiave della facttable VENDITE e costituita dalla combinazione delle chiavi esterne dalle tre dimension table.

E interessante notare che:

• La visione multidimensionale dei dati si ottiene eseguendo un’operazione di join tra la fact tablee le diverse dimension table. Per il fatto delle vendite di Figura 3.1 l’interrogazione SQL chericostruisce le celle associando i valori delle misure ai corrispondenti valori degli attributi presentinelle gerarchie e 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 loroimportazione nella fact table.

• Le dimension table non sono in terza forma normale, poiche la presenza contemporanea di tuttigli attributi di una gerarchia da luogo a dipendenze funzionali transitive1.

1 Una relazione si dice in terza forma normale quando nessuno dei suoi attributi non primi (quelli che nonfanno parte di chiavi candidate) dipende transitivamente da una chiave. Una dipendenza transitiva ha laforma a → b, b → c

26 3 Modelli logici a supporto del Data Warehousing

DATA

PRODOTTO

NEGOZIO

VENDITE

chiaveD

chiaveP

chiaveN

chiaveN

data

prodotto

negozio

chiaveD

mese

tipo

città negozio

chiaveP

trimestre

categoria

regione negozio

quantità venduta

anno

reparto

stato negozio

incasso

giorno

gruppo marketing

responsabile

prezzo unitario

settimana

marca

distretto

numero clienti

vacanza

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 untipo di prodotto viene ripetuta per ciascun prodotto di quel tipo) e, quindi, richiede piu spazio sudisco per la memorizzazione dei dati; tuttavia, al contempo, riduce il numero dei join necessari alreperimento delle informazioni.Si tenga presente che i tradizionali problemi legati alla normalizzazione (le cosiddette anomalie diinserimento, cancellazione e modifica) non destano preoccupazione alcuna, in quanto le gerarchiesono prevalentemente statiche.

• La sparsita non rappresenta un problema dal momento che nella fact table vengono memorizzatesoltanto le combinazioni di chiavi per le quali esiste effettivamente l’informazione.

Nell’esempio di Figura 3.2 e rappresentata una possibile istanza del precedente schema a stella;in tale esempio gli attributi chiave sono sottolineati. La prima tupla della fact table e ralativa allavendita di Latte Slurp effettuata il 2/9/2001 nel negozio COOP1 di Bologna, mentre la terza tuplae relativa alla vendita di Yogurt Slurp effettuata il 3/10/2001 presso la sede COOP3. Si noti comela denormalizzazione delle dimension table comporti la duplicazione di molti valori: per esempio, perogni prodotto di tipo “latticino”, si ripete che la categoria corrispondente e “alimentari”.

La caratteristica piu evidente di questa soluzione e, senza dubbio, la denormalizzazione delle di-mension table, giustificata dalla riduzione del costo di reperimento dei dati. Si consideri, d’altronde,che la cardinalita delle dimension table e, normalmente, molto inferiore rispetto a quella delle facttable 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 e la presenza di dipendenze funzionali transi-tive nelle dimension table che fanno si che queste ultime non siano in terza forma normale (per esem-pio, la dimension table NEGOZIO di Figura 3.2 contiene la dipendenza funzionale transitiva negozio

→ citta negozio, citta negozio → regione negozio).Sebbene la presenza di questo tipo di dipendenze permetta di eseguire piu rapidamente le inter-

rogazioni, puo essere utile ridurre il livello di denormalizzazione al fine di ottenere uno schema logicopiu vicino ai dettami della teoria relazionale.

Su questa considerazione si basa lo schema a fiocco di neve (snowflake schema) caratterizzato dallanormalizzazione, in genere parziale, delle dimension table.

3.2 Lo schema a fiocco di neve 27

VENDITE

chiaveN chiaveD chiaveP qta venduta incasso ...

1 1 1 170 85 . . .

2 1 2 320 160 . . .

3 2 3 412 412 . . .

. . . . . . . . . . . . . . . . . .

NEGOZIO

chiaveN negozio citta 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 e ottenibile da uno schema a stella decomponendo una opiu dimension table DTi in piu dimension table DTi1, . . . ,DTim

in modo da eliminare alcune delledipendenze funzionali transitive in esse presenti.

Ogni dimension table sara caratterizzata da:

• una chiave primaria (tipicamente surrogata) dij ;• un sottoinsieme degli attributi di DTi che dipendono funzionalmente da dij ;• zero o piu chiavi esterne riferite ad altre DTij necessarie a garantire la ricostruibilita del contenuto

informativo di DTi.

2

Denominiamo “primarie” le dimension table le cui chiavi vengono importate nella fact table,“secondarie” le dimension table rimanenti.

Uno schema snowflake e ottenuto eliminando progressivamente alcune delle dipendenze funzionalitransitive presenti nelle dimension table.

Ciascun passo di normalizzazione individua una sotto-gerarchia che verra memorizzata separata-mente.

Un esempio di schema snowflake e riportato in Figura 3.3. Tramite l’introduzione delle tabelleCITTA, TIPO e CATEGORIA si ottiene una parziale normalizzazone dei dati contenuti nelle dimensiontable; vengono, infatti, spezzate le dipendenze transitive tra negozio e regione, tra prodotto e categoriae tra tipo e reparto.

Come conseguenza di quanto detto precedentemente si ha che:

• Lo spazio richiesto per la memorizzazione dei dati si riduce poiche, per esempio, le corrispondenzetra valori degli attributi citta e regione vengono memorizzate una sola volta. Se il numero dinegozi per ogni citta e elevato, un ulteriore motivo che consente un risparmio di spazio sta nelfatto che a ciascun negozio si abbina il surrogato chiaveC (tipicamente 4 byte) invece del campocitta (almeno 20 byte).


DATA

PRODOTTO

TIPOCATEGORIA

NEGOZIO

CITTA’

VENDITE

chiaveD

chiaveP

chiaveT

chiaveCA

chiaveN

chiaveC

chiaveN

data

prodotto

tipo

categoria

negozio

città negozio

chiaveD

mese

chiaveT

chiaveCA

reparto

responsabile

regione negozio

chiaveP

trimestre

marca

gruppo marketing

distretto

stato negozio

quantità venduta

anno

città marca

chiaveC

incasso

giorno

prezzo unitario

settimana

numero clienti

vacanza

Figura 3.3. Un possibile schema a fiocco di neve per lo schema a stella presentato in Figura 3.1; in corsivosono rappresentate le chiavi delle relazioni

• E necessario inserire nuove chiavi surrogate che permettano di determinare le corrispondenzetra dimension table primarie e secondarie. Per esempio, l’importazione di chiaveT nella tabellaPRODOTTO permette di associare a ciascun prodotto il relativo tipo.

• L’esecuzione di interrogazioni che coinvolgono soltanto gli attributi contenuti nella fact table e nelledimension table primarie e facilitata poiche le join coinvolgono tabelle di dimensioni inferiori.

• Il tempo di esecuzione delle interrogazioni che coinvolgono attributi delle dimension table seconda-rie aumenta poiche e necessario un maggior numero di join.

Gli schemi a stella presentano alcune caratteristiche che richiedono particolare cura al fine diottenere una corretta decomposizione.

Oltre a fare attenzione al fatto che la decomposizione non riduca il potere informativo della relazionee non elimini le dipendenze funzionali esistenti nello schema della relazione di partenza, e necessarioverificare che nella nuova relazione venga spostato il corretto insieme di attributi.

Infatti, gli schemi a stella contengono normalmente piu dipendenze funzionali transitive in ca-scata (per esempio, chiaveN → negozio, negozio → citta negozio, citta negozio → regione

negozio, regione negozio → stato negozio); pertanto, affinche la decomposizione sia efficace, enecessario che tutti gli attributi che dipendono, transitivamente e non, dall’attributo che ha determi-nato lo snowflaking siano posti nella nuova relazione. In caso contrario continuerebbero ad esisterealtre dipendenze transitive che invaliderebbero la normalizzazione.

Per esempio, in Figura 3.4 e mostrata una scorretta normalizzazione della relazione NEGOZIO diFigura 3.1; sebbene la dipendenza transitiva chiaveN → negozio → citta negozio sia stata risolta,la presenza dell’attributo stato negozio nella relazione NEGOZIO induce una forte ridondanza.

Affinche lo snowflaking sia efficace, tutti gli attributi del sottoalbero dell’attributo da cui ha originela normalizzazione devono essere spostati nella nuova relazione.

3.3 Le viste 29

NEGOZIO

CITTA’

chiaveN

chiaveC

negozio

città negozio

responsabile

regione negozio

distretto

stato negozio

chiaveC

Figura 3.4. Uno schema snowflake scorretto per lo schema a stella presentato in Figura 3.1

3.3 Le viste

L’enorme quantita dei dati memorizzati nei DW rende difficili le analisi da parte degli utenti che, diconseguenza, tendono a ridurre la porzione da esaminare direttamente tramite operazioni di selezionee aggregazione.

Le selezioni permettono di restringere la porzione di dati in esame individuando quelli effettiva-mente interessanti per la specifica analisi.

Con le aggregazioni la riduzione e ottenuta collassando piu elementi non aggregati in un unicoelemento aggregato (per esempio, calcolando la somma delle quantita vendute in un determinatogiorno si analizza un solo dato invece di tanti dati quante sono le vendite giornaliere). Inoltre, tramitel’aggregazione, e possibile astrarre da casi specifici ed evidenziare trend generali.

Un significativo aumento delle prestazioni puo essere ottenuto precalcolando i dati aggregati di usopiu 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, corri-spondenti al pattern primario (il piu fine, definito dall’insieme delle dimensioni), da quelle secondarie,corrispondenti a pattern secondari (aggregati).

Dove cio non crea ambiguita utilizzeremo il pattern per denotare la vista. Un modo alternativoper individuare le viste secondarie consiste nel verificare se queste possono essere alimentate a partireda altre viste presenti nel DW o se e, invece, necessario ricorrere ai dati operazionali.

In Figura 3.5 vengono rappresentate alcune viste ottenibili a partire dallo schema a stella di Fi-gura 3.1. L’unica vista primaria e v1. Una freccia da vi a vj indica che Pj ≤ Pi essendo Pi e Pj ,rispettivamente, i pattern di vi e vj . Conseguentemente, i dati contenuti in vj possono essere calcolatiaggregando quelli di vi.

Supponendo di adottare lo schema di materializzazione di Figura 3.5, un’interrogazione relativaalle vendite che richieda i dati aggregati per tipo di prodotto, data di vendita e citta del negozio in cuila vendita e stata effettuata risultera meno costosa se eseguita sulla vista v2 piuttosto che sulla vistav1 poiche essa insistera su una fact table con un numero ridotto di tuple e non richiedera ulteriorioperazioni di aggregazione.

Viceversa, un’interrogazione che aggreghi le vendite in base a prodotto, data di vendita e citta delnegozio dovra essere forzatamente eseguita sulla vista v1, che e l’unica con un pattern di aggregazionesufficientemente fine.

Quando si opera con dati aggregati e necessario porre molta attenzione al corretto utilizzo deglioperatori di aggregazione.

Affinche dati pre-aggregati possano essere utilizzati per il calcolo di dati ulteriormente aggregati (peresempio, se si vuole calcolare l’aggregazione per anno a partire da dati aggregati per quadrimestre),puo essere necessario memorizzare ulteriori informazioni. Queste possono essere le misure di supportoo, direttamente, le misure derivate che si intende calcolare.


v ={prodotto, data, negozio}1

v ={tipo, data, città}2

v ={categoria, mese, città}3

v ={tipo, mese, regione}4

v ={trimestre, regione}5

Figura 3.5. Alcune viste ottenibili a partire dallo schema a stella presentato in Figura 3.1

Durante la fase di progettazione logica e, pertanto, necessario tenere in considerazione quali ope-ratori dovranno essere utilizzati con le diverse misure aggiungendo, dove necessario, le corrispondentimisure, sia quelle di supporto che quelle derivate.

3.3.1 Schemi relazionali in presenza di dati aggregati

In presenza di viste materializzate e possibile adottare diverse varianti del classico schema a stella.La soluzione piu 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 potra essere iden-

tificato solo mediante le corrispondenti tuple nelle dimension table: i record delle dimension tablecorrispondenti a dati aggregati presenteranno, infatti, dei valori NULL in tutti i campi il cui livello diaggregazione e piu fine di quello su cui si sta operando.

In Figura 3.6 e rappresentato parte dello schema delle vendite per questa soluzione.

VENDITE

chiaveN chiaveD chiaveP qta venduta incasso ...

1 1 1 170 85 . . .

2 1 1 300 150 . . .

3 1 1 1700 850 . . .

. . . . . . . . . . . . . . . . . .

NEGOZIO

chiaveN negozio citta 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 e relativa a una singola vendita, la seconda memorizza idati aggregati per tutte le vendite effettuate a Roma; infine, la terza tupla riassume tutte le venditeeffettuate nel Lazio.

Utilizzando tale soluzione tutte le interrogazioni possono essere risolte sulla stessa fact table. Ciova a scapito delle prestazioni che si riducono a causa dell’enorme dimensione assunta da quest’unicatabella. Ad essere penalizzate sono, soprattutto, le interrogazioni che operano su dati aggregati poiche,percentualmente, la porzione di dati che risultano rilevanti per esse e minima.

Una seconda soluzione prevede di memorizzare in fact table separate dati relativi a pattern diaggregazione diversi. Le fact table corrispondenti a pattern di aggregazione in cui una o piu dimensionisono completamente aggregate non presenteranno le relative chiavi esterne.

3.3 Le viste 31

La coesistenza di piu fact table impone un’ulteriore scelta riguardante le dimension table, che pos-sono essere mantenute unificate come nella soluzione precedente (ottenendo il cosiddetto constellationschema, illustrato in Figura 3.7), oppure possono essere replicate per le diverse viste aggregate.

DATA

PRODOTTO

NEGOZIO

V1

V5

chiaveD

chiaveP

chiaveN

chiaveN

chiaveD

data

prodotto

negozio

chiaveD

chiaveN

mese

tipo

città negozio

chiaveP

trimestre

categoria

regione negozio

quantità venduta

quantità venduta

anno

reparto

stato negozio

incasso

incasso

giorno

gruppo marketing

responsabile

prezzo unitario

prezzo unitario

settimana

marca

distretto

numero clienti

numero clienti

vacanza

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, ciascunadelle quali conterra soltanto dati a un particolare livello di aggregazione. Al contrario le dimension tablecontinuano a contenere attributi relativi a livelli diversi delle gerarchie, la loro taglia rimane elevatae continua a essere necessaria l’introduzione dei valori NULL nei campi non validi per un particolarelivello di aggregazione.

La giustificazione per questa soluzione progettuale deriva dalla considerazione che la dimensionedelle fact table e notevolmente superiore a quella delle dimension table e conseguentemente la riduzionedel 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 conterra soltantol’insieme di attributi validi per il livello di aggregazione a cui viene utilizzata. In Figura 3.8 vengonorappresentate due diverse viste con le relative dimension table. Si noti come la chiave della facttable secondaria non presenti il campo relativo alla dimensione negozio che e stata completamenteaggregata.

La soluzione mostrata in Figura 3.8 e quella che promette migliori prestazioni. Infatti, sia l’accessoalla fact table che l’accesso alle dimension table sono ottimizzati. La massimizzazione delle prestazioniva a scapito dello spazio richiesto per la memorizzazione che cresce non solo a causa del consolidamentodei dati aggregati ma anche a causa delle dimension table ridondanti.

Una soluzione intermedia rispetto alle due presentate precedentemente consiste nell’applicare losnowflaking delle dimensioni in corrispondenza dei livelli di aggregazione a cui sono presenti visteaggregate. Questa soluzione consente di usufruire della forte ottimizzazione dovuta alla separazionedei dati aggregati in base al livello di aggregazione senza dover replicare le dimension table, giafortemente ridondanti.

In Figura 3.9 il fatto delle vendite viene modellato mediante uno schema snowflake i cui punti dinormalizzazione coincidono con gli attributi del pattern della vista aggregata.


TRIMESTRE

DATA

PRODOTTO

NEGOZIO

REGIONE

V1

V5

chiaveT

chiaveD

chiaveP

chiaveN

chiaveR

chiaveN

chiaveT

trimestre

data

prodotto

negozio

regione negozio

chiaveD

chiaveR

anno

mese

tipo

città negozio

stato negozio

chiavePtrimestre

categoria

regione negozio

quantità venduta

quantità venduta

anno

reparto

stato negozio

incasso

incasso

giorno

gruppo marketing

responsabile

prezzo unitario

prezzo unitario

settimana

marca

distretto

numero clienti

numero clienti

vacanza

città marca

Figura 3.8. Memorizzazione dei dati aggregati, utilizzando piu schemi a stella, per lo schema delle vendite

TRIMESTRE

DATA

PRODOTTO

NEGOZIO

REGIONE

V1

V5

chiaveT

chiaveD

chiaveP

chiaveN

chiaveR

chiaveN

chiaveT

trimestre

data

prodotto

negozio

regione negozio

chiaveD

chiaveR

anno

mese

tipo

città negozio

stato negozio

chiavePchiaveT

categoria

chiaveR

quantità venduta

quantità venduta

giorno

reparto

responsabile

incasso

incasso

settimana

gruppo marketing

distretto

prezzo unitario

prezzo unitario

vacanza

marca

numero clienti

numero clienti

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 propostada Kimball, uno dei massimi esperti nel campo dei Data Warehouse. Tale metodologia prevede laprogettazione separata dei vari Data Mart che vengono, successivamente, fusi per costruire il DataWarehouse. La progettazione di ciascun Data Mart viene effettuata secondo una sequenza di passi bendefinita.

4.1 Metodologia di progettazione di un Data Warehouse

In questa sezione descriviamo una metodologia per la progettazione di un Data Warehouse. Essa estata proposta da Kimball ed e denominata “metodologia a nove passi”.

In realta, essa specifica i passi richiesti per la progettazione di un Data Mart. Tuttavia, variData Mart separati, progettati mediante questa metodologia, possono essere successivamente fusi perottenere un Data Warehouse complesso coerente.

Pertanto, utilizzando questa metodologia, un Data Warehouse consiste nell’unione di un insiemedi Data Mart separati, implementati in un certo periodo di tempo, eventualmente da team di progettodiversi, 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 fara 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 DataMart.

Il primo Data Mart da costruire dovrebbe essere un Data Mart che, molto probabilmente, potraessere consegnato nei tempi stabiliti, con il budget previsto e che sia capace di rispondere alle esigenzeaziendali piu importanti dal punto di vista commerciale.

Generalmente, come primo Data Mart, viene scelto uno strettamente collegato alle vendite. Lacorrispondente sorgente dei dati sara, infatti, accessibile e di alta qualita.

Nel selezionare il primo Data Mart dell’agenzia immobiliare notiamo che i processi aziendalicorrispondenti includono:

• le vendite degli immobili;• gli affitti degli immobili;• la visione degli immobili;• la pubblicita 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 attivita dell’agenzia immobiliare.Il processo aziendale selezionato per essere il primo Data Mart e la vendita degli immobili. La parte

del diagramma E/R originale che rappresenta i dati coinvolti in questo processo e rappresentata inFigura 4.2.

34 4 Progettazione di un Data Warehouse

Lease

ClientRenter

ClientBuyer

Propertyfor Rent

Requires

Recommends

Staff

Propertyfor Sale

PropertyMaintenance

Owner

Owns

Views

PropertyViewing

Newspaper

Advert

Promotion

PropertySale

Branch

Holds

Offers

Has

Attends

Placed in

Displays

Uses

Promotes

Provides

Oversees

Sells

Seeks

Manages

Takes

Describes

Is for

Requests

Leased by

Registers

Contacts

Agrees

Figura 4.1. Diagramma E/R per la gestione di un’agenzia immobiliare

4.3 Passo 2: Scelta della granularita

Scegliere la granularita comporta decidere esattamente cosa rappresenta una tupla della Fact Table. Peresempio, l’entita PropertySale nella Figura 4.1 rappresenta i fatti su ciascuna vendita di immobili eviene assunta come Fact Table dello schema a stella sulle vendite immobiliari. Pertanto, la granularitadella Fact Table PropertySale e rappresentata dalle singole vendite immobiliari.

4.5 Passo 4: Scelta delle misure 35

ClientBuyer

Staff

Propertyfor Sale

Owner

Owns

Promotion

PropertySale

BranchHas

Promotes

Sells

Manages

Is for

Contacts

Agrees

Figura 4.2. Parte del Diagramma E/R di Figura 4.1 che rappresenta i dati coinvolti nel processo di venditadegli 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 alleattivita di decision making. Un insieme di dimensioni ben costruito rende il Data Mart comprensibilee facile da utilizzare.

Soltanto quando e stata scelta la granularita della Fact Table e possibile identificare le dimensioni.Per esempio, le entita Branch, Staff, Owner, ClientBuyer, PropertyForSale e Promotion nellaFigura 4.2 rappresentano dati che, a vario titolo, riguardano le vendite immobiliari; queste entitadaranno origine alle Dimension Table dello schema a stella sulle vendite immobiliari.

Accanto a tali entita, come Dimension Table, viene inclusa anche la dimensione temporale dalmomento che il tempo gioca un ruolo fondamentale in qualunque analisi per il supporto alle decisioni.

Le decisioni sulla granularita per la Fact Table influenzano anche le decisioni sulla granularita diciascuna Dimension Table. Per esempio, se la granularita per la Fact Table PropertySale e una singolavendita immobiliare, allora la granularita della Dimension Table ClientBuyer e data dai dettaglidel cliente che ha comprato un particolare immobile. ClientBuyer viene descritto dagli attributiclientID, clientNo, clientName, clientType, city, region e country.

Un insieme di dimensioni povero o incompleto ridurra l’utilita di un Data Mart per un’organizza-zione.

4.5 Passo 4: Scelta delle misure

La granularita della Fact Table determina quali misure possono essere utilizzate nel Data Mart.Tutte le misure devono essere espresse al livello implicato dalla granularita. In altre parole, se la

granularita della Fact Table e una singola vendita immobiliare, allora tutte le misure numeriche sidevono riferire a quella particolare vendita.

Lo schema a stella associato alle vendite e 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 e utilizzabile in quanto vi sono misure non numeriche (promotionName e staffName), unamisura non additiva (monthlyRent), e una misura a un diverso livello di granularita rispetto alle altre.

La Figura 4.5 mostra come la Fact Table della Figura 4.4 potrebbe essere corretta per ovviare atali inconvenienti.

E possibile aggiungere nuove misure ad una Fact Table in qualunque momento purche esse sianoconsistenti con la granularita della tabella.


BRANCH

PROMOTION

TIME

STAFF

CLIENT BUYER

OWNER

PROPERTY SALE

PROPERTY FOR SALE

branchID

promotionID

timeID

staffID

clientID

ownerID

timeID

propertyID

branchNo

promotionNo

day

staffNo

clientNo

ownerNo

propertyID

propertyNo

branchType

promotionName

week

staffName

clientName

ownerName

city

promotionType

month

position

clientType

ownerType

branchID

type

region

year

sex

city

city

clientID

street

country

city

region

region

promotionID

city

region

country

country

staffID

postCode

ownerID

region

offerPrice

country

sellingPrice

saleCommission

saleRevenue

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 perdeterminare se e opportuno usare dei pre-calcoli.

Un esempio comune della necessita di memorizzare pre-calcoli si ha quando le misure coinvolgonoprofitti e perdite. Questa situazione nasce spesso quando la tabella dei fatti e basata su fatture ovendite.

La Figura 4.5 mostra la tabella dei fatti con gli attributi rentDuration, totalRent, clientAllowan-ce, staffCommission e totalRevenue. Questi tipi di misure sono utili perche sono quantita additivedalle quali e possibile derivare informazioni importanti, quali il clientAllowance medio, basandosisull’aggregazione di alcuni numeri della tabella dei fatti. Ad esempio, per calcolare il totalRevenuegenerato per ciascun affitto immobiliare sottraiamo i valori di clientAllowance e staffCommission

da totalRent.In alcuni casi potrebbe presentarsi la necessita di dover memorizzare un valore anche se questo

potrebbe essere derivato da un insieme di attributi. Cio risulta particolarmente vero per un valorefondamentale per un’organizzazione, quale totalRevenue, o quando vi e il rischio che il valore vengacalcolato in modo incorretto dall’utente. Infatti, il costo causato da un utente che calcola in modoincorretto un valore e 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 piu descrizionitestuali possibili. Le descrizioni testuali dovrebbero essere quanto piu possibile intuitive e comprensibili

4.9 Passo 8: Tracciare le “slowly changing dimension” 37

BRANCH

PROMOTION

TIME

STAFF

CLIENT RENTER

OWNER

LEASE

PROPERTY FOR RENT

branchID

promotionID

timeID

staffID

clientID

ownerID

timeID

propertyID

branchNo

promotionNo

day

staffNo

clientNo

ownerNo

propertyID

propertyNo

branchType

promotionName

week

staffName

clientName

ownerName

city

promotionType

month

position

clientType

ownerType

Fatti numerici congranularità inconsistenterispetto agli altri fatti

Fatti non numerici

Fatti nonadditivi

branchID

type

region

year

sex

city

city

clientID

street

country

city

region

region

promotionName

city

region

country

country

staffName

postCode

ownerID

region

montlyRent

country

rentDuration

totalRent

clientAllowance

staffCommission

totalRevenue

lastYearRevenue

country

{

Figura 4.4. Schema a stella per gli affitti degli immobili; questo e un esempio di una Fact Table strutturatamale

per gli utenti finali. L’utilita di un Data Mart e determinata dallo scopo e dalla natura degli attributidelle tabelle dimensionali.

4.8 Passo 7: Scelta della durata del database

La durata misura per quanto tempo nel passato dovra andare la Fact Table.In molte organizzazioni vi e la necessita di memorizzare le informazioni fino ad uno o due anni

rispetto alla data corrente. Per altre organizzazioni, quali le compagnie di assicurazioni, vi possonoessere delle richieste legali per mantenere i dati fino a cinque o piu anni prima rispetto alla datacorrente.

Fact Table molto grosse causano almeno due significative problematiche di progettazione.Innanzitutto, e spesso molto difficile risalire a dati vecchi. Piu vecchi sono i dati e piu probabilmente

vi saranno problemi nel leggerli ed interpretarli.In secondo luogo, e necessario che vengano usate le versioni vecchie delle dimensioni in gioco e non

le versioni piu recenti. Questa problematica e nota come problema della “slowly changing dimension”e viene descritta piu 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, e ne-cessario fare riferimento alla vecchia organizzazione e alla vecchia strutturazione dei dati (ovvero


BRANCH

PROMOTION

TIME

STAFF

CLIENT RENTER

OWNER

LEASE

PROPERTY FOR RENT

branchID

promotionID

timeID

staffID

clientID

ownerID

timeID

propertyID

branchNo

promotionNo

day

staffNo

clientNo

ownerNo

propertyID

propertyNo

branchType

promotionName

week

staffName

clientName

ownerName

city

promotionType

month

position

clientType

ownerType

branchID

type

region

year

sex

city

city

clientID

street

country

city

region

region

promotionID

city

region

country

country

staffID

postCode

ownerID

region

rentDuration

country

totalRent

clientAllowance

staffCommission

totalRevenue

country

Figura 4.5. Schema a stella per gli affitti degli immobili; questo e lo schema della Figura 4.4 con i problemicorretti

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 piu 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 accessibilinella stessa tupla di una Dimension Table.

4.10 Passo 9: Decidere le priorita sulle query e sulle modalita di query

In questo passo vengono considerate problematiche di progettazione fisica. Le problematiche di pro-gettazione fisica piu critiche che influenzano la percezione che l’utente finale ha del Data Mart, sonol’ordinamento fisico su disco della Fact Table e la presenza di aggregazioni pre-memorizzate.

Al di la di queste problematiche ve ne sono tantissime altre che riguardano l’amministrazione, ilbackup, 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 DataMart che supporta le richieste di un particolare processo di business e puo essere, anche, facilmenteintegrato con altri Data Mart correlati per formare un Data Warehouse complessivo.

Affinche possa aver luogo il processo di integrazione, se una qualunque dimensione e presente in dueData Mart, le due istanze devono essere identiche oppure una deve essere un sottoinsieme matematicodell’altra. Solo in questo modo, infatti, due Data Mart possono condividere una o piu dimensioni nellamedesima applicazione.

Quando una dimensione viene utilizzata in piu di un Data Mart, si dice che essa deve essereconforme (conformed). Esempi di dimensioni conformi tra i Data Mart relativi alle vendite e allapubblicita degli immobili sono le dimensioni Time, PropertyForSale, Branch e Promotion. Se esse nonsono sincronizzate nei due Data Mart, il Data Warehouse complessivo sara, praticamente, inutilizzabileperche 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 allavendita e alla pubblicita degli immobili; le dimensioni Time, PropertyForSale, Branch e Promotion

sono, in questo caso, dimensioni conformi.

CLIENT BUYER

clientID

clientNo

clientName

clientType

city

region

country

STAFF

staffID

staffNo

staffName

position

sex

city

region

country

BRANCH

PROMOTION

TIME

OWNER

branchID

promotionID

timeID

ownerID

branchNo

promotionNo

day

ownerNo

branchType

promotionName

week

ownerName

city

promotionType

month

ownerType

region

year

city

country

region

country

PROPERTY FOR SALE

ADVERT

NEWSPAPER

propertyID

timeID

newspaperID

propertyNo

propertyID

newspaperNo

type

branchID

newspaperName

street

newspaperID

newspaperType

city

promotionID

distribution

postCode

advertCost

city

region

region

country

country

PROPERTY SALE

timeID

propertyID

branchID

clientID

promotionID

staffID

ownerID

offerPrice

sellingPrice

saleCommission

saleRevenue

Figura 4.6. Schema a stella per la vendita e la pubblicita 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 ciascunprocesso aziendale (e, quindi, per ciascun Data Mart) dell’agenzia immobiliare in esame.


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 Tabella4.1; tali dimensioni costituiranno, pertanto, il fulcro del processo di integrazione dei Data Mart voltoalla costruzione del Data Warehouse.

Processo Aziendale Fact Table Dimension Table

Vendite degli immobili PropertySale Time, Branch, Staff, PropertyForSale, Owner, ClientBuyer, PromotionAffitti degli immobili Lease Time, Branch, Staff, PropertyForRent, Owner, ClientRenter, PromotionVisioni degli immobili PropertyViewing Time, Branch, PropertyForSale, PropertyForRent, ClientBuyer, ClientRenterPubblicita sugli immobili Advert Time, Branch, PropertyForSale, PropertyForRent, Promotion, NewspaperManutenzione 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 piu Fact Table sono collegate a una o piu Dimension Table conformiviene denominato “Costellazione dei Fatti”.

La Costellazione dei Fatti per il Data Warehouse in esame e mostrata nella Figura 4.7. La rap-presentazione del modello e stata semplificata in quanto vengono mostrati soltanto i nomi delle FactTable e delle Dimension Table. Le Fact Table sono evidenziate in grigio mentre le Dimension Tablesono mostrate in bianco.

ClientBuyer

PropertySale Promotion

Newspaper

Time

Staff

ClientRenter

Advert

PropertyViewing

Lease

PropertyMaintenance

PropertyForSale

Branch

Owner

PropertyForRent

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. At-traverso questo tool di facile utilizzo, e possibile definire, implementare e gestire operazioni di DataWarehousing.

5.1 Analytical Workspace Manager

Iniziare con le sorgenti relazionali esistenti

Si consideri una immaginaria compagnia mondiale chiamata Global Computing che distribuiscehardware e software.

Il punto iniziale per utilizzare il tool Analytical Workspace Manager e considerare gli esistentischemi a stella, a fiocco di neve o normalizzati. Nella figura in seguito sono illustrate le tabelle cheintendiamo analizzare col tool:

Progettare un modello dei dati logico

Dopo aver esaminato le tabelle relazionali, e possibile identificare le dimensioni, i livelli, le gerarchie egli attributi dei dati logici. Inoltre, e possibile identificare le relazioni all’interno ciascuna dimensione. Idati saranno cosı utilizzati per progettare l’area di lavoro analitica di Analytical Workspace Manager.

1) Identificare le dimensioniQuattro 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 livelliAdesso 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 valorisono al piu basso livello di dettaglio nel datawarehouse e saranno raggruppati nel livello Channel.Dal piu alto livello di riepilogo al piu basso livello di dettaglio, i livelli saranno Total Channel eChannel.

2. La dimensione Customer riflette come Global Computing esegue le analisi geografiche dei clienti.Il piu basso livello di dettaglio nel modello dei dati e localizzata in Ship To.

a) Shipments, i livelli di riepilogo saranno (dal piu alto al piu basso): Total Customers, Region,Warehouse e Ship To.

b) Market Segmentation, i livelli di riepilogo saranno (dal piu alto al piu basso): Total Market,Market Segment, Account e Ship To.

1. La dimensione Product avra quattro livelli (dal piu alto al piu basso): Total, Class, Family e Item.2. La dimensione avra tre livelli (dal piu alto al piu basso): Year, Quarter e Month.

All’interno delle dimensioni Channel, Customer e Product, abbiamo aggiunto un livello Totalecome il piu alto livello di riepilogo. L’aggiunta di tale livello fornira maggiore flessibilita nell’analisidei dati.

3) Identificare le gerarchieLe 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 gerarchiaper ciascuna dimensione.

Per la dimensione Customer, tuttavia, Global Computing necessita di due gerarchie. L’analisi al-l’interno della dimensione Customer viene condotta, infatti, attraverso l’analisi geografica e attraversoil segmento di vendita. Percio, i livelli devono essere organizzati in due gerarchie chiamate Shipmentse Market Segment.

4) Identificare le misureI fatti che emergono dall’analisi del database sono quattro, ovvero:

1. Sales2. Units3. Unit Price4. Unit Cost

Altri fatti possono essere ricavati da questi che sono quelli di base. I fatti derivati possono esserecalcolati 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 e una collezione di tipi di dati multidimensionali. La finestra principalefornisce due viste:

1. la Vista Modello che permette di definire un modello dimensionale logico dei dati usandodimensioni, livelli, gerarchie, attributi e misure;

2. la Vista Oggetto che fornisce una interfaccia grafica per OLAP DML. Tramite questa vista epossibile creare, modificare e cancellare oggetti dell’area di lavoro analitica. Tale vista e utileper gli utenti esperti che vogliono utilizzare le caratteristiche avanzate di Analytic WorkspaceManager.

Partire dall’utente GLOBAL AW

Con questo esercizio creeremo un’area di lavoro analitica denominata GLOBAL. Di seguito sonoelencati i comandi SQL che definiscono l’utente GLOBAL AW con diritti sufficienti per poter utilizzareAnalytic 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. Specificareil servizio nella forma host:port:sid (ad esempio, localhost:1521:GlobalDB).


La vista di default e la Vista Modello. Attraverso la Vista Modello, e possibile creare oggettidimensionali logici. Allo stesso tempo, Analytic Workspace Manager istanzia gli oggetti logici comeoggetti fisici nell’area di lavoro analitica.

Step 3. Creare il contenitore dell’area di lavoro analitica GLOBAL. Espandere la cartella Schemafinche non compaia lo schema GLOBAL AW. Click destro sulla cartella Area di lavoro analitica eseleziona Crea Area di Lavoro Analitica. . .

Step 4. Fornire GLOBAL come nome dell’area di lavoro analitica ed accettare la tablespace didefault. Cliccare su Crea.

Apparira la nuova area di lavoro GLOBAL nella cartella Aree di lavoro Analitiche.


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


Nota: Seleziona l’opzione “Genera chiavi surrogate nell’are di lavoro analitica” a meno che non sisappia che ciascun membro della dimensione sia unico. Nel caso contrario, se si e sicuri che i membridella dimensione sono unici tra livelli, selezionare “Utilizza chiavi naturali dell’origine dati”, cosı epossibile 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’unicita,allora non vi e necessita 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 potreb-be contenere delle istantanee mensili. I mesi sono cosı il livello base. E tuttavia possibile riassumerequesti 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, quindiscegliere Crea Livello. . .

Step 2. Nella finestra di dialogo Crea Livello, scrivere TOTAL CHANNEL come nome e cliccaresu Crea.


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 e una struttura logica che utilizza i livelli ordinati per organizzare i dati. Puo essereutilizzata per definire aggregazioni di dati; ad esempio, in una dimensione tempo, una gerarchiapotrebbe essere usata per aggregare i dati dal livello mensile al livello trimestrale o annuale.

Le dimensioni possono avere uno o piu 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. . .


Step 2. Nella finestra di dialogo Crea Gerarchia, scrivere PRIMARY come nome ed accettare ivalori di default. Selezionare i livelli dal livello piu allto al livello piu basso come illustrato in seguitoe 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. E tuttaviapossibile aggiungere altri attributi. La dimensione Time ha, oltre agli attributi long e short description,gli attributi time-span e end-date.


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 gia fatto.


. . .


I modelli

Grazie ai Modelli in Analytic Workspace Manager e possibile salvare la definizione degli oggetti logiciin un file XML. Pertanto, utilizzando un modello precedentemente salvato, e possibile ricreare una


nuova area di lavoro analitica, una nuova dimensione, cubo etc. Occorre ricordarsi che i modelli nonincludono 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 Dimensioneda Modello. . .

Step 2. Selezionare il file ProductOther.XML e cliccare su Crea.


La nuova dimensione PRODUCT appare sotto la cartella Dimensioni.

Creare la dimensione Time

Step 1. Creare la dimensione TIME basata sul modello TimeSnowflake.XML.

La nuova dimensione TIME appare sotto la cartella Dimensioni.


Adesso, dal momento che tutte le dimensioni sono state create, e possibile creare gli oggetti delcubo.

Definire i Cubi

I Cubi sono rappresentazioni logiche dei dati multidimensionali. I lati rappresentano i membri delledimensioni e il corpo contiene i valori dei dati. Ad esempio, i dati delle vendite possono essere orga-nizzati in un cubo, i cui lati contengono i valori delle dimensioni channel, customer, product e time eil 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 nomee 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 influisconosulle performance dell’area di lavoro analitica.


Cos’e la Sparsita?

Con sparsita intendiamo specificare il grado in cui le celle contengono valori NULL invece che dati. Adesempio, se una variabile e il 25% sparsa, allora il 25% delle celle associate alla variabile contengonovalori NULL e il 75% contengono dati. In generale, se una variabile e oltre l’80% sparsa, allora eopportuno gestire la sparsita al fine di garantire buone performance.

Analytic Workspace Manager assume, come condizione di default, che i dati siano sparsi e selezionacome sparse tutte le dimensioni, eccetto la dimensione time che e 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 perche esse de-terminano il modo in cui i dati sono memorizzati sull’hard disk. La prima dimensione in un cubo e ladimensione che varia piu velocemente, l’ultima dimensione e quella che varia piu lentamente.

Step 4. Nel tab Dettagli di Implementazione, muovere le dimensioni nell’ordine come illustratosotto. Accettare gli altri valori di default.

Step 5. Cliccare Crea, il nuovo cubo UNITS CUBE appare sotto la cartella Cubi.


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 sparsita e l’operatore di aggregazione. Deselezionare ladimensione PRODUCT come sparsa nel tab Dettagli di Implementazione.

Step 3. Selezionare Non Additivo (non riepilogare) per entrambe le dimensioni nel tab Regole.


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 realta di interesse. Ciascuna misura appartiene ad unparticolare 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, quindiscegliere Crea Misura. . .


Step 2. Scrivere SALES come nome nel tab Generale della finestra di dialogo Crea Misure. Accettarei valori di default e cliccare Crea. La nuova misura SALES apparira all’interno della cartella Misure.

Step 3. All’interno del noto UNITS CUBE cliccare col tasto destro del mouse la cartella Misure escegliere 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. SelezionareINTEGER come tipo di dati e cliccare Crea.

La nuova misura UNITS apparira all’interno della cartella Misure.


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, e possibile mapparli nelle sorgenti relazionali di Oracle Database.I tal modo e 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 verra visualizzata nel pannello di destra.

Step 2. Individuare la tabella CHANNEL DIM all’interno dello schema GLOBAL. TrascinareCHANNEL DIM nell’area mapping.


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.


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.


La finestra Mapping apparira nel pannello di destra. Verra visualizzato uno schema navigator eduna tabella con delle righe per le misure, dimensioni e livelli.

Step 2. Nello schema navigator, individuare la tabella dei fatti UNITS HISTORY FACT con lerelative misure nello schema GLOBAL. Trascinarla nell’area mapping.

Step 3. Cliccare Visualizza Dati per visualizzare la tabella dei fatti UNITS HISTORY FACT:


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 CUBEa proprio piacere.

Caricare e aggregare i dati in Analytic Workspace

In Analytic Workspace Manager e possibile caricare tutti gli oggetti mappati nell’area di lavoroanalitica.

Step 1. Cliccare col tasto destro del mouse sull’area di lavoro analitica GLOBAL, quindi scegliereGestisci area di lavoro analitica GLOBAL.


Step 2. Selezionare UNITS CUBE e PRICE AND COST CUBE includendo tutte le dimensionicoinvolte. Cliccare Fine.

Adesso l’area di lavoro analitica GLOBAL contiene i dati come specificato nel progetto logico. E cosıpossibile effettuare delle analisi dimensionali ad-hoc attraverso i tool di Analytic Workspace Manageroppure attraverso altre applicazioni fornite da Oracle Business Intelligence Beans come DiscovererOLAP 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. . .


E possibile esplorare e visionare i membri della dimensione Product.

Ad esempio, per visualizzare i dati della misura Sales, cliccare col tasto destro del mouse sullamisura SALES del cubo UNITS CUBE e scegliere Visualizza i dati SALES CUBE. . .

Adesso e possibile esplorare e verificare i dati della misura Sales.


Definire delle misure derivate

Le misure derivare sono create effettuando calcoli sulle misure memorizzate nell’area di lavoro anali-tica. Tali fatti derivati non sono fisicamente memorizzati; pertanto essi sono equivalenti a delle visterelazionali.

Creare la misura derivata UNIT MARGIN

Step 1. Espandere il node del cubo PRICE AND COST CUBE e cliccare col tasto destro del mousenella cartella Misure Derivate, quindi scegliere Crea Misure Derivate. . .

Step 2. Fornire UNIT MARGIN come nome e selezionare Sottrazione come tipo di calcolo dallacartella Aritmetica di base. Cliccare continua.

Step 3. Come valore del menu Sottrazione scegliere Unit Price e come valore Unit Cost. CliccareFine.

5.2 Oracle Spreadsheet Add In 67

La nuova misura derivata UNITS MARGIN apparira all’interno della cartella Misure Derivate.

Step 4. Visionare i dati di Unit Margin, cliccare col tasto destro del mouse sulla misura calcolataUNIT 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 e 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 Ora-cleBI, viene aggiunta nella barra di menu di Excel. Utilizzare tale menu per accedere alle caratteristicheche interagiscono con Oracle OLAP.


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 Numbere 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 verravisualizzata. Inserire “global aw” sia come Nome Utente che come Password, quindi cliccare suConnetti.

Il wizard di Oracle OLAP Query vine cosı lanciato.


Creare una query OLAP

Create un report

In tale sezione vedremo come creare un report basato sulla misura Sales (vendite) che riporta i migliori5 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 listadi destra.

Nota: La misura Sales e le dimensioni correlate saranno trascinate nella lista di destra poiche eselezionata la checkbox Aggiungi/Rimuovi automaticamente le dimensioni.

Step 3. E possibile rimuovere qualsiasi dimensione che non si e interessati a vedere dalla lista.

In ogni caso non rimuovere nessuna dimensione.

Step 4. Nel passo Layout del wizard, e possibile cambiare il layout dei dati spostando le dimensioninella maniera voluta.

Muovere Customer, Product, Time e Channel come mostrato nella figura in seguito:


Cliccare Avanti per continuare.

Step 5. Nei prossimi passi del wizard e possibile selezionare i membri delle dimensioni.

Selezionare i membri della dimensione Time. Nella lista a sinistra, cliccare sul bottone >> perselezionare 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 clientidivisi per regioni. Selezionare le stesse regioni selezionate dalla seguente figura:


Cliccare Avanti per continuare.

Step 7. Per ciascuna dimensione Product, e possibile specificare la condizione di classificazio-ne. Cliccare sul tab Condizioni. Appariranno dei modelli di condizioni. Tali modelli possono esserepersonalizzati 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 primolink 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 (>).


Cliccare Fine.La query OLAP creata restituira 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 e automaticamente ricalcolata e la correntelista riporta i 5 prodotti in base alle vendite in North Americas, All Channel, e anno 2002.

E anche possibile modificare l’esistente query OLAP selezionando OracleBI > Modifica Query dalmenu di Excel.

Appunti per il Corso di Data Warehousing · • sanita`: analisi di ricoveri e dimissioni,...

Documents

Transcript of Appunti per il Corso di Data Warehousing · • sanita`: analisi di ricoveri e dimissioni,...