Data warehousing con SQL Server

Data warehousing con SQL Server SQL Server è un RDBMS (Relational DataBase Management System) Analysis Services è un componente di SQL Server che offre un insieme di funzionalità di supporto al data warehousing Componenti per il data warehousing OLAP Server: è il server analitico dei dati rappresenta i dati analitici del DW in forma multidimensionale, usando i concetti di cubo, dimensione e misura OLAP Manager : strumento di amministrazione dei dati analitici 1 Analysis Services (AS) Punto di partenza : DW relazionale organizzato secondo uno schema dimensionale (star schema, snowflake schema) Il DW relazionale non deve essere necessariamente un DB gestito con SQL Server Obiettivo : I dati del DW relazionale vengono rappresentati ed analizzati in forma multidimensionale usando la nozione di cubo (data cube) I cubi sono contenuti in un OLAP database gestiti dall OLAP Server Un cubo recupera i dati dal DW relazionale che è definito come sorgente dati (data source) all interno dell OLAP Database Un OLAP database può avere varie data source Un cubo può recuperare dati da una singola data source Diversi cubi (di uno stesso OLAP database) possono recuperare dati da data source differenti 2

Strumenti OLAP nell architettura di un DW Architettura a 2 livelli (il discorso vale anche per quella a 3 livelli ) Livello delle sorgenti Dati operazionali Dati esterni Strumenti ETL Livello di alimentazione i Data Warehouse Livello del warehouse Strumenti OLAP Livello di analisi i CUBO Schema Multidimensionale Lo strumento OLAP 1. analizza i dati del DW, ovvero dati che hanno già una struttura multidimensionale (schema a stella/snowflake) 2. Ha una connessione dati con il DW 3. Non ha nessuna connessione con i Dati Operazionali 3 Cubi nelle architetture a 2 e 3 livelli Dato uno schema di fatto ed il corrispondente schema logico (stella/snowflake) si costruisce il cubo corrispondente, che è praticamente t definito it in modo univoco essendo le scelte di progettazione già state realizzate Nel cubo 1. Si aggiungono eventuali misure derivate e calcolate. In particolare, per uno schema di fatto vuoto si introduce la misura di conteggio degli eventi 2. Si definiscono gli operatori di aggregazione g 3. Si definiscono alcuni aspetti specifici, quali il membro ALL per le dimensioni Dal punto di vista concettuale la definizione del cubo non richiede altro; tuttavia nel costruire un cubo si possono gestire una serie di altri concetti, in particolare quelli legati all efficienza del sistema 4

Architetture ad 1 livello Caratterizzata t dal fatto che al DW non corrisponde un nuovo DB, ma lo schema logico del DW è implementato attraverso delle viste nel DB Operazionale: il livello del warehouse funge quindi da middleware tra i dati operazionali e lo strumento OLAP Per la Fact Table serve una vista in quanto occorre definire gli eventi primari e le misure Per le Dimension Table 1. si può definire una vista 2. si può usare una table del DB Operazionale con struttura simile 3. Si può definire e costruire direttamente nello strumento OLAP Dati operazionali Middleware Strumenti OLAP Livello delle sorgenti Livello del warehouse Livello di analisi Lo strumento OLAP ha una connessione con il DB Operazionale 5 Architetture ad 1 livello Problemi di efficienza È ora evidente che le operazioni sul DB operazionali (OLTP, On-Line Transactional Processing) siano mischiate con quelle di tipo analitico OLAP (OLAP, On-Line Analytical Processing) Se si prescinde da questi aspetti di efficienza, i un architettura tt ad un livello può essere utile per effettuare analisi semplici in modo immediato, senza passare attraverso la realizzazione di un nuovo DB. Ad esempio, uno schema di fatto transazionale contenente solo una dimensione data ed una o più dimensioni degenere può essere implementato in modo immediato e semplice 6

Analysis Services : Editor del Cubo Il sistema OLAP di Analysis Services, così come un qualsiasi altro sistema OLAP, ha concetti e strumenti propri per definire uno schema multidimensionale (un cubo), concetti e strumenti più o meno sofisticati e spesso proprietari (cioè propri del particolare sistema OLAP e differenti da sistema a sistema) Ad esempio in Analysis Services lo strumento (automatico) per definire le dimensioni consente di scegliere se usare uno schema a stella oppure a fiocco di neve o altro, quale attributo o espressione usare come nome di un livello e così via. Vedere esempio DimensioneDistretto In un architettura a 2 o 3 livelli, dove è già stato progettato lo schema di fatto e lo schema logico, di Analysis Services sono sufficienti solo quei concetti/strumenti che ci consentono di 1. Definire gli operatori di aggregazione per le misure 2. Definire Misure Derivate e Calcolate 3. Visualizzare i dati del fatto in modo multidimensionale, effettuando operazioni di roll-up e drill-down 7 Schemi multi-dimensionali in AS Dimensioni e attributi dimensionali si chiamano livelli I valori delle dimensioni e degli attributi dimensionali si dicono membri livelli dimensione STORE (ALL) membri STORE CITY STATE COUNTRY (ALL) Ditutto RE EmiliaR Italia ALL NonSoloX RE EmiliaR Italia ALL NonSoloY MO EmiliaR Italia ALL NonSoloZ RM Lazio Italia ALL............ ALL 8

Schemi multi-dimensionali in AS Membri e Livelli: le dimensioni contengono solitamente il livello speciale (ALL) che contiene il solo membro All che denota tutti tti i membri della dimensione Organizzazione in Livelli: In Analysis Services i livelli formano una successione lineare (un nodo può avere al massimo un figlio) L organizzazione in livelli corrisponde alla definizione di una relazione padre-figlio tra i membri di livelli successivi (ogni membro di un livello si raggruppa nel membro padre) il membro All è padre dei membri Italia, Francia,... il membro Italia è padre dei membri EmiliaR, Lazio,.. Misure : Le misure sono considerate come membri di una dimensione speciale chiamata Measures (presente in tutti i cubi) 9 Dimensioni: livello (ALL) e membro ALL Dimensione CITTA_ARRIVO ARRIVO con due livelli : Citta Statto CITTA STATO (ALL) MARSIGLIA FRANCIA ALL PARIGI FRANCIA ALL LONDRA INGHIL ALL...... livelli membri Nella visualizzazione della dimensione, il livello ll (ALL) è chiamato (Totale) ed dil membro ALL è totale CITTA_ARRIVO Nelle proprietà della dimensione si può eliminare il livello (ALL) (All level = No) e cambiare il nome del membro ALL: 10

Dimensioni: livello (ALL) e membro ALL Per definizione, i i il membro ALL (e di conseguenza il livello ll (ALL) che lo contiene) deve essere presente in ogni dimensione in quanto consente di avere i totali per quella dimensione, ovvero di visualizzare are pattern senza la dimensione in questione Non introdurre il membro ALL per una dimensione può comportare dei vantaggi dal punto di vista dell efficienza: intuitivamente, si evita di pre-calcolare i valori corrispondenti ad ALL Se non si introduce il membro ALL, i totali per quella dimensioni possono essere comunque calcolati attraverso espressioni MDX. Nelle nostre dimensioni definiremo sempre il membro ALL! Una curiosità: il membro ALL è presente anche in SQL, nel group by with ROLLUP Vendite SELECT isnull(libro,'totale') as Libro, sum(numero) as numero, sum(incasso) as incasso FROM Vendite group by Libro with ROLLUP 11 Dalle Gerarchie del DFM ai Livelli di AS Le dimensioni/livelli del cubo sono univocamente definite dalle dimensioni/gerarchie dello schema di fatto Data una gerarchia, per ogni cammino dalla dimensione (radice) alle foglie si deve definire un dimensione nel cubo con un numero di livelli pari alla lunghezza del cammino Se la gerarchia è un albero puro (no condivisioni/convergenze, no attributi cross-dimensionali, no attributi multipli) nel cubo ci saranno un numero di dimensioni pari al numero di foglie dell albero Dimensione ORA_DI_PARTENZA Con livelli VOLO ORA_DI_PARTENZA 12

Dalle Gerarchie del DFM ai Livelli di AS Per costruire una dimensione/livelli di AS 1. Si considera lo schema logico 2. Si seleziona la Dimension table corrispodente ; nel caso di snowflake schema si selezionano le dimension table corrispondenti e si verifica che siano correttamente legate tramite join 3. Si definiscono i livelli (cominciando dall ultimo, cioè dalla foglia) 4. Si decide se tenere o meno il membro ALL 5. Si definiscono gli eventuali operatori di aggregazione particolari per questa dimensione (formule personalizzate di roll-up) Oltre alla struttura della dimensione si devono decidere altri aspetti, in particolare se la dimensione può essere condivisa da più dimensioni 13 Esempio : DimensioneDistretto L esempio vuole evidenziare come l uso di AS su un DM già progettato (come nelle architetture a 2 e 3 livelli) è molto semplice ed evita di dover utilizzare strumenti propri di AS Consideriamo un caso frequente, ovvero quello di un attributo dimensionale derivante dalla composizione di più attributi Esempio: Nella Tabella Negozio (esempio Vendite), il distretto di vendita è STATO_DISTRETTO+NDISTRETTO I valori di tale attributo dimensionale vengono ricavati tramite una vista e quindi riportati in una Dimension_Table del DM con struttura DT_NEGOZIO(NOME, NOMEDISTRETTO, STATO_DISTRETTO) 14

Esempio : DimensioneDistretto La implementazione in AS, partendo dalla DT_NEGOZIO è immediata: 1) si seleziona DT_NEGOZIO 2) si definiscono i tre livelli iniziando da StatoDistretto (2.a) 1) 2.a) 2.b) 2.c) Visualizzazione della dimensione ottenuta: 15 Esempio : DimensioneDistretto L implementazione in AS, senza usare DT_NEGOZIO ma direttamente su NEGOZIO non è immediata: occorre effettuare in AS quelle manipolazioni (ricavare il valore di NomeDistretto) effettuate primma in fase di alimentazione In definitiva, molti strumenti propri di AS non sono indispensabili quando si parte da un DM già progettato ed implementato in un DB relazionale! 16

Operatore di aggregazione AVG in AS CostoMedioBiglietto (CMB) aggregato tramite AVG CodVolo DATA INCASSO NUM_BIG CMB ALIT1 GEN1 20 2 10 ALIT1 GEN2 40 4 10 ALIT2 GEN2 30 6 5 SUM SUM AVG Compagnia DATA INCASSO NUM_BIG CMB ALITALIA GEN1 20 2 10 ALITALIA GEN2 70 10 7,5 Compagnia Mese INCASSO NUM_BIG CMB ALITALIA GEN 90 12 8,33 In Analysis Services una misura con operatore di aggregazione algebrico deve essere definito tramite una misura calcolata Nel caso della media, essendo AVG(CMB)=SUM(CMB)/count(*): 1. Si definisce la misura CMB_Base con oper. di aggregazione SUM 2. Si definisce la misura di supporto Conteggio, aggregata con COUNT 3. Si definisce CMB calcolata come CMB_Base/Conteggio CMB_Base e Conteggio possono non essere visualizzate 17 Esempio di cubo: Ritardi_NEW Schema di Fatto Ritardi_New Schema Logico snowflake: FACT TABLE RITARDINEW(CODVOLO:VOLO, ANNO,INIZIOMESE, CITTAARRIVO:CITTA, RITARDO,NUMRITARDI) DIMENSION TABLE VOLO(CODVOLO,COMPAGNIA, AEROP_PART:AEROPORTO) AEROPORTO(SIGLA, CITTA_PART:CITTA) CITTA (CITTA,STATO) In AS si definiscono 3 Dimensioni condivise (ad una gerarchia corrispondono più dimensioni in AS, quindi spesso il nome contiene il nome della foglia che si raggiunge) 1) STATO_PARTENZA 2) STATO_ARRIVO oppure CITTA_ARRIVO (infatti c è solo un cammino e quindi non c è cè ambiguita ) 3) COMPAGNIA 18

Database OLAP Si crea un nuovo DB OLAP che conterrà tutti gli oggetti multidimensionali (cubo, dimensioni condivise) 1) Si definisce l origine dei dati, ovvero il collegamento al DM 2) Si seleziona la voce relativa a SQL Server e quindi - dall elenco dei DB disponibili - si seleziona il DM Se si apportano modifiche al DM, per renderle visibili anche nel DB OLAP può essere necessario aggiornare l origine dati 19 Dimensione: STATO_PARTENZA 1) Si seleziona la tabella contenente la radice della dimensione 2) Si aggiungono g le altre tabelle che contengono gli attributi dimensionale, controllando le relazioni di join 20

Cubo: Ritardi_NEW Dopo aver generato tutte le dimensioni condivise, si passa alla generazione del cubo 1) Si userà l editor (la procedura guidata infatti è basata su concetti propri di AS ) 2) Si seleziona la fact table; un cubo è basato su una ed una sola fact table 3) Se la Fact Table è vuota si ha un warning del tipo: 21 Cubo: Ritardi_NEW - dimensioni Vengono introdotte le dimensioni condivise già definite, mentre le altre vengono definite direttamente nel cubo. 4) Si definiscono le dimensioni degeneri ANNO e INIZIOMESE 5) Si inseriscono le dimensioni condivise definite in precedenza, una alla volta. 6) Inserimento CITTA_ARRIVO: il join con la fact table viene automaticamente definito considerando il nome, quindi essendo nomi diversi non viene automaticamente generato In ogni caso, meglio generare manualmente i Join! 22

Cubo: Ritardi_NEW - dimensioni 7) Si genera il join. A questo punto la dimensione CITTA_ARRIVO ARRIVO per il cubo è definita. 8) Inserimento STATO_PARTENZA. Il sistema introduce tutte le tabelle che servono per definire la dimensione. PROBLEMA: la tabella CITTA viene usata due volte, in due dimensioni. Questo non è corretto, è come se si stesse definendo una convergenza. Il sistema non consente questo ciclo: 23 Cubo: Ritardi_NEW - dimensioni Per evitare il problema precedente, ogni qualvolta c è cè una tabella che viene usata in più dimensioni tramite condivisione, si assegna un alias a ciascuna occorrenza 9) Inserimento dimensione COMPAGNIA: in questo caso COMPAGNIA è nella stessa tabella VOLO, quindi non è necessario introdurre un alias per volo Tutte le dimensioni sono state inserite: si noti il differente simbolo per quelle condivise 24

Cubo: Ritardi_NEW - misure Misura addittiva NUMRITARDI, la definizione è immediata Per la misura Misura RITARDO, aggregata tramite AVG, si deve usare una misura calcolata come spiegato a pagina 17: 1. Si seleziona Ritardo e si definisce RitardoBase (con SUM) Si noti che RitardoBase è una misura derivata, ovvero non presente nel fatto iniziale ma definita a partire da altre misure 2. Si seleziona Ritardo e si definisce la misura derivata Conteggio (con count) 3. Si definisce la misura calcolata: in AS una misura calcolata è chiamata membro calcolato; c è una interfaccia grafica Il procedimento è mostrato nella slide che segue. 25 Ritardi NEW: Misura Ritardo con AVG 26

Cubo: Ritardi_NEW - visualizzazione Consideriamo il pattern STATO_PARTENZA.CITTA, CITTA_ARRIVO.STATO e visualizziamo limitandoci a CITTA_ARRIVO.STATO = ITALIA ) 27 Cubo: Ritardi_NEW - verifica E bene verificare i risultati ottenuti con il cubo, calcolando alcune misure direttamente sugli eventi primari ovvero effettuando il calcolo in SQL sul DM: 28

Calcolo delle misure: ottimizzazione Un significativo aumento delle prestazioni può essere ottenuto precalcolando i dati aggregati di uso più comune L ottimizzazione usa il concetto di vista materializzata: Ogni pattern secondario corrisponde ad una vista sul pattern primario Vengono materializzate le viste (ovvero pre-calcolate e memorizzate in tabelle) corrispondenti ad alcuni pattern secondari La scelta delle viste da materializzare è basata sul compromesso tra diversi vincoli, i principali dei quali sono Tempo di costruzione ed aggiornamento delle viste materializzate Spazio a disposizione Nella progettazione fatta finora 1. Progettazione logica con il modello ROLAP 2. Non abbiamo considerato le viste materializzate Varie tecniche di ottimizzazione sono generalmente già implementate nei sistemi i OLAP e l utente t può configurare alcuni parametri, quali lo spazio a disposizione per memorizzare i dati aggregati Nel seguito vedremo velocemente come ciò avviene in AS, dove il concetto di vista materializzata viene utilizzato in fase di archiviazione del cubo. 29 Archiviazione del cubo Consente di decidere come memorizzare i dati relativi ad un cubo, alle sue dimensioni e I dati aggregati: Noi abbiamo già scelto come modello di progettazione logica il modello ROLAP, infatti stiamo considerando un DM implementato in un DB relazionale Selezionando ROLAP anche come metodo di memorizzazione del cubo, i dati del cubo e delle dimensionii i restano nello (cioè sono quelli del) star/snowflake schema e anche le aggregazioni verranno messe in tabelle.. 30

Archiviazione del cubo Viene fissata la memoria a disposizione per memorizzare i dati aggregati Si determina quindi quante aggregazioni è possibile memorizzare Durante l elaborazione trascurare eventuali warning dovuti spesso alla creazione di indici 31 Archiviazione del cubo Le aggregazioni vengono salvate in tabelle nel DM Analizzando una di queste tabelle, si vedono i dati aggregati ed i valori calcolati per tutte le misure del cubo (non per quelle calcolate in quanto vengono determinate sui dati già aggregati) Per ulteriori dettagli sul ROLAP (e MOLAP) di AS vedere il manuale. Alcuni altri aspetti specifici verranno visti durante le esercitazioni 32