D2I Modena, 27 Aprile 2001 Progettazione e interrogazione di Data Warehouse (Tema 2) Unità Responsabile: Cosenza Unità Coinvolte: Cosenza - Bologna.

Presentazione sul tema: "D2I Modena, 27 Aprile 2001 Progettazione e interrogazione di Data Warehouse (Tema 2) Unità Responsabile: Cosenza Unità Coinvolte: Cosenza - Bologna."— Transcript della presentazione:

1 D2I Modena, 27 Aprile 2001 Progettazione e interrogazione di Data Warehouse (Tema 2) Unità Responsabile: Cosenza Unità Coinvolte: Cosenza - Bologna

2 Rapporti previsti D2.R1: Documento sui risultati dell'analisi dello stato dell'arte sulle architetture di data warehouse (CS,BO) D2.R2: Documento sull'analisi dello stato dell'arte sulle tematiche di progettazione logico-fisica del livello dei dati derivati (BO) D2.R3: Documento sull'analisi dello stato dell'arte sulle tematiche di interrogazione di sistemi di grandi dimensioni (CS) I rapporti sono stati completati o sono in “dirittura d’arrivo”.

3 Rapporto D2.R1 Il rapporto, prodotto in collaborazione dalle unità di Cosenza (Pasquale Rullo) e Bologna (Stefano Rizzi) presenta un’analisi delle architetture di data warehouses note in letteratura. Vengono analizzate le architetture ad uno, a due, a tre livelli con livello riconciliato “piatto” ed a tre livelli con livello riconciliato gerarchico. Viene mostrato come sia, in genere, da preferirsi l’adozione di architetture a tre livelli rispetto ad architetture ad uno o a due livelli.

4 Rapporto D2.R1 Viene messo in evidenza il ruolo centrale che rivestono, da una parte, i metadati e, dall’altra, l’architettura del livello riconciliato. Quest’ultimo rappresenta il punto di raccordo tra le tematiche trattate all’interno del tema 2 e quanto sviluppato, in particolare, nell’ambito del tema 1. Viceversa, le funzionalità fornite per il livello dei dati derivati costituiscono punto di raccordo con le tematiche proprie del tema 3. Fermo restando l’adozione di una struttura che comprenda almeno tre livelli, è necessario procedere con una definizione di architettura per il progetto D2I che permetta un buon grado di sinergia con gli altri temi del progetto.

5 Il rapporto, scritto da Golfarelli e Rizzi, presenta una rassegna di tecniche di ottimizzazione sviluppate negli ultimi anni per ridurre i tempi di risposta alle interrogazioni su data warehouses. Altri dettagli, a cura di Stefano, tra breve. Rapporto D2.R2

6 “Answering Queries:Tractable Cases and Optimizations” Answering a query is computationally very expensive: NP- hard even for conjunctive queries Different query plans may lead to execution time having very different execution times (many orders of magnitude) However, finding the best query plan is NP-hard Rapporto D2.R3

7 Different approaches: Quantitative methods: –finding an optimal query plan, if the query is rather small, or –finding a “good” query plan by using some heuristics, if the query is large, as usual in data warehouses Structural methods: –answering an acyclic query is (output) polynomial –many queries are “very close” to acyclic queries Rapporto D2.R3

8 Quantitative Methods: Exhaustive search (dynamic programming) Heuristics (greedy algorithms) Randomized algorithms Iterative Dynamic Programming Rapporto D2.R3

9 Structural Methods : Acyclic queries can be efficiently answered Checking query containment for acyclic queries is feasible in polynomial time (a key issue for answering queries using views) The good properties of acyclic queries also hold for queries having a bounded degree of cyclicity: –Bounded tree-width queries –Bounded hinge-width queries –Biconnected components queries –Bounded hypertree-width queries Rapporto D2.R3

10 Future work on these issues: Quantitative and structural approaches are completely separated worlds Most commercial DBMS only use quantitative methods for optimizing queries Many meaningful queries are acyclic or close to acyclic queries Integrate ideas from both approaches for answering queries in the data warehouse framework Rapporto D2.R3

11 Problematiche generali da affrontare Necessità di raccordo tra sviluppi all’interno del tema 2 e quanto portato avanti negli altri temi (  struttura del metadata repository) In particolare, la definizione dell’architettura dovrà tenere conto delle esigenze degli altri temi La definizione delle funzionalità da offrire al livello dell’utente è un altro problema su cui riflettere con attenzione per il proseguio del progetto.