Obiettivo della tesi Percorso Sviluppo di una applicazione software per verificare la correttezza di un modello di costo in ambito Data Warehouse si è fatto riferimento al modello di costo pubblicato da Engström et al. la Tesi è stata svolta presso l’Università di Exeter (UK) e l’Università di Skövde (Svezia) Percorso Il problema affrontato Gli elementi più significativi del modello di costo Applicazione software Esempi di risultati sperimentali

Il sistema considerato nel modello di costo Data Warehouse Database Sorgente DB1 Database Sorgente DB2 Database Sorgente DBN .. Data Warehouse Il sistema considerato nel modello di costo Dati Database sorgente Tabella Data Warehouse Vista Delta Query Update Utenti Utenti

Il problema affrontato nel Modello di costo nella Tesi Validazione Sperimentale: corrispondenza tra il comportamento di un sistema reale e le predizioni del modello Sistema reale + Strumenti per eseguire esperimenti Update

Il modello di costo (1) Caratterizzazione delle proprietà della sorgente

Misure tradizionali (esecuzione e comunicazione) Il modello di costo (2) - Nuova metrica (qualitativa e quantitativa) Istante in cui la query è posta Z Risposta basata sullo stato 1 di S1 e 3 di S2 DW t S1 t 1 S2 t 1 2 3 Misura staleness (Z) Database sorgente Tempo di esecuzione Data Warehouse Tempo di esecuzione Tempo di comunicazione Misure tradizionali (esecuzione e comunicazione)

Applicazione software – Criteri guida Per il linguaggio: portabilità, gestione della concorrenza, gestione connessioni a database; Per l’architettura funzionale: chiara separazione tra le classi che modellano il sistema e le classi che si occupano di controllare e misurare lo stesso; Per i benchmark: rilevanza delle grandezze osservate, scalabilità, chiarezza nell’esporre le caratteristiche dell’implementazione e nel presentare i risultati.

Applicazione software - Architettura Saccess Interbase ACCESS Supdater thread Wquerier thread Database sorgente Emulazione del carico Row Table Nuovi tipi di dato Director Configuration Data generator Gui Waccess Wrapper thread Data warehouse Controllo e misurazione Entità del sistema Classi di benchmark

Applicazione software – Implementazione (1) Caratteristiche della sorgente Tabella sorgente Tabella DAW Database Sorgente Trigger Aggiornamenti Update Insert Delete Numero dell’ultimo update inviato al DW Supdater Se non DAW Se DAW Wrapper confronto Wrapper Waccess Numero dell’ultimo update della sorgente che ha subito il commit Le proprietà CHAC e CHAW La proprietà DAW

Applicazione software – Implementazione (2) Emulazione del carico di lavoro Caratterizzazione degli update Basata sull’analisi di Adelberg / Garcia-Molina: Update parziali Frequenza aperiodica Esecuzione immediata Distribuzione di Poisson

Applicazione software – Implementazione (3) Emulazione del carico di lavoro Esplorazione di nuovi algoritmi per produrre il flusso di update Pre- scheduling Pro: flusso di update pronto all’inizio di un esperimento Contro: numero di update comunque limitato Run-time Pro: flusso illimitato Contro: attenzione ai ritardi introdotti Vincente: Algoritmo del Guide Attribute a run-time

Validazione e Verifica garantita dal modello di costo considerato Verifica: svolta mediante controllo dei protocolli e del comportamento sotto carico

Verifica (1) I protocolli Metodo: introduzione di un appropriato output di sistema Utilità: 1) Controllare la corretta sequenza di operazioni nell’eseguire le politiche di manutenzione 2) Verificare la effettiva indipendenza tra i processi concorrenti

Comportamento sotto carico Verifica (2) Comportamento sotto carico Metodo: creazione di applicazioni esterne di supporto per il monitoraggio della dinamica del sistema Utilità: 1) Osservare la evoluzione del sistema nel tempo 2) Controllare le proprietà statistiche degli algoritmi (es: dimensione della tabella sorgente e distribuzione dei valori dei GA)

Ambiente di esecuzione Benchmark Ambiente di esecuzione Piattaforma: Sun Ultra 5, Solaris 8, 128 MB, Interbase 6.0, Java 1.2, Codice bytecode 77 Kb Tuning dei parametri di basso livello del sistema operativo e del Dbms Ispezione della qualità dei risultati: si scartano i risultati ottenuti da esperimenti che non soddisfano i criteri di integrità definiti (es: overlapping update, overlapping query)

P2: Modifica totale (blu) Benchmark Esempi (1) Legenda P1: Modifica Incrementale con DAW (violetto) P2: Modifica totale (blu) Staleness al variare della frequenza di polling in caso di aggiornamenti periodici del data warehouse. Le due politiche offrono prestazioni sempre più simili al diminuire della frequenza di aggiornamento del DW.

Risultati sperimentali Predizioni del modello di costo Benchmark Esempi (2) Risultati sperimentali ( P1 blu, P2 violetto) Predizioni del modello di costo (P1 nero, P2 verde) Costo integrato (esecuzione e comunicazione) al variare della frequenza di polling. L’evidenza sperimentale è in pieno accordo con le predizioni del modello anche in caso di configurazioni dei parametri estreme.

CONCLUSIONI L’applicazione implementa tutti gli aspetti del modello di costo Ha superato tutti i test di verifica Gli esempi di benchmark hanno permesso di: 1) fornire conferma di taluni comportamenti del modello; 2) migliorare la nostra conoscenza sul suo comportamento; 3) evidenziare possibili punti di discussione per affinare il modello;

Sviluppi futuri Caso distribuito (Java RMI) Estensione al caso multisorgente Considerazione di sorgenti non-relazionali (XML)