Sviluppo di una applicazione software per verificare la correttezza

2. Obiettivo della tesi 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

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

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

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

6. 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 0 1 S2 t 0 1 2 3 Misura staleness (Z) Database sorgente Tempo di esecuzione Data Warehouse Tempo di esecuzione Tempo di comunicazione Misure tradizionali (esecuzione e comunicazione)

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

8. 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 Controllo e misurazione Data warehouse Classi di benchmark Entità del sistema

9. 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 DAW Se non DAW Wrapper confronto Wrapper Waccess Numero dell’ultimo update della sorgente che ha subito il commit Le proprietà CHAC e CHAW La proprietà DAW

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

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

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

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

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

15. 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)

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

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

18. 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;

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