Biglietti: schema E/R. Biglietti: albero degli attributi

Transcript

1 Biglietti: schema E/R 1 Biglietti: albero degli attributi 2

2 Biglietti: albero degli attributi 3 Dimensioni, Misure e Schema! Dimensioni = {CodVolo, Data, Check-in,AnnoNascitaCliente}! Tra le dimensioni non ho tutti gli attributi chiave di BIGLIETTO GLOSSARIO delle MISURE NUM. BIGLIETTI = COUNT(*) INCASSO = SUM(BIGLIETTO.tariffa) NUM. COLLI = SUM(BIGLIETTO.NumeroColli) 4

3 Modifica dello schema di fatto! Si aggiunge allo schema di fatto la dipendenza CITTA! STATO! Tale dipendenza non era inizialmente espressa nello schema E/R e si può rilevare ed aggiungere allo schema E/R durante la fase di ricognizione dei dati.! Oppure può essere rilevata ed aggiunta dal progettista durante la costruzione dell albero degli attributi (aggiunta di una dipendenza funzionale).! Oppure può essere rilevata durante l analisi del carico di lavoro, ad esempio, analizzando la possibilità di fare una interrogazione del tipo per ogni stato, confrontare gli incassi delle sue città. 5 Progettazione logica! Riportando le dimensioni degeneri nella fact table e traducendo la gerarchia condivisa in una sola dimension table, si ottiene questo star schema :! Se per la gerarchia condivisa si effettua uno snowflake sul primo attributo condiviso (la SIGLA) si ottiene questo schema : 6

4 Alimentazione del Data Mart! Si considera il seguente schema relazionale del DB operazionale DB_BIGLIETTI! Si considera solo l estrazione statica che viene effettuata quando il DM deve essere popolato per la prima volta e consiste concettualmente in una fotografia dei dati operazionali. l alimentazione a partire da zero 7 Alimentazione del Data Mart! Per semplificare il processo di alimentazione, consideriamo dapprima come schema del Data Mart DM_BIGLIETTI il secondo schema di pagina 6, ma senza l introduzione di chiavi surrogate (infatti le chiavi surrogate devono essere create e gestite durante l alimentazione), ovvero si utilizzano le chiavi del DB operazionale DB_BIGLIETTI:! Nel seguito vengono dapprima individuate le espressioni SQL utili ad alimentare il DM, poi tali espressioni verranno utilizzate per creare un pacchetto DTS! La generazione delle dimension table VOLO e AEROPORTO è semplice, in quanto corrisponde a copiare le istanze delle rispettive relazioni nel DB_BIGLIETTI. Siccome VOLO si riferisce tramite FK ad AEROPORTO occorre copiare prima AEROPORTO. 8

5 Alimentazione del Data Mart! Essendo la fact table BIGLIETTI con granularità temporale, le sue istanze (gli eventi primari) verranno determinate tramite un raggruppamento sulle dimensioni! Per alimentare la fact table occorre effettuare delle interrogazioni sul DB operazionale (DB_BIGLIETTI) e riportarne il risultato nel DM (DM_BIGLIETTI). Normalmente una query SQL può essere riferita solo ad un DataBase, allora procediamo in questo modo 1. Nel DB operazionale si crea la query che calcola le istanze della fact table e si memorizza tale query in una vista (VIEW_BIGLIETTI) 2. Si copia il contenuto della vista VIEW_BIGLIETTI nella table fact BIGLIETTI del DM! Per semplicità, effettuiamo prima il calcolo senza la dimensione CHECK_IN, che ricordiamo essere una dimensione con valore boolean (1 = biglietto con check_in, 0 = bigletto senza check_in). 9 Alimentazione del Data Mart! La view VIEW_BIGLIETTI deve contenere il join tra BIGLIETTI, CHECK_IN (per prendere NUMCOLLI) e CLIENTE (per prendere ANNONASC) ed il raggruppamento su DATA, CODVOLO, ANNONASC! Conviene fare il join graficamente (vedi figura) quindi salvare la view, riaprirla e scrivere a mano il raggruppamento 10

6 Alimentazione del Data Mart! Si deve considerare se è sufficiente fare l INNER JOIN oppure si deve fare un OUTER JOIN " Tra BIGLIETTO e CLIENTE è sufficiente l INNER JOIN in quanto tutti i biglietti hanno un cliente (questo si vede dall E/R ma si deve verificare in pratica sul relazionale, controllando che il campo CLIENTE in BIGLIETTI sia not null ) " Tra BIGLIETTO e CHECK_IN è necessario fare un outer join per includere anche i biglietti che non hanno corrispondente in CHECK_IN 11 Alimentazione del Data Mart! Aprendo la view, aggiungo il GROUP BY e le misure:! La somma di un insieme di valori con almeno un NULL è teoricamente NULL: per avere 0 invece che NULL mettiamo allora SUM(ISNULL(NUMCOLLI,0)). In SQL SERVER il NULL nella somma è considerato per default 0, quindi si può non inserire ISNULL. 12

7 Alimentazione del Data Mart! Cosa avviene se un valore di un attributo di ragruppamento è NULL?! Supponiamo che ANNONASC possa essere NULL, sia a causa di BIGLIETTI senza un CLIENTE specificato, sia perchè il cliente ha un ANNONASC nullo.! In questi casi conviene codificare il valore NULL con un opportuno valore, ad esempio 0; In questo modo tale valore non crea problemi quando utilizzato come valore di chiave. Nella view si sostituisce dbo.cliente.annonasc con ISNULL(dbo.CLIENTE.ANNONASC, 0) AS ANNONASC.! A questo punto la creazione della view (VIEW1) per alimentare la fact table senza la dimensione CHECK_IN è terminata. Nel seguito discuteremo come introdurre tale dimensione 13 Alimentazione del Data Mart! La dimensione CHECK_IN è particolare in quanto non corrisponde ad un attributo dello schema del DB operazionale, ma deve essere calcolato: 1 = biglietto con check_in, 0 = bigletto senza check_in.! In base alla discussione già fatta sul left join, possiamo calcolare tale valore effettuando il left join; questo calcolo, riportato nelle slide seguenti, risulta essere complesso, in quanto richiede la definizione di più viste.! Una soluzione più semplice è quella di aggiungere l attributo alla tabella BIGLIETTO e di calcolarlo tramite UPDATE sulla tabella. In pratica tale soluzione corrisponde alla traduzione del subset CHECK_IN con il collasso verso l alto, dove CHECK_IN è l attributo selettore UPDATE BIGLIETTO SET CHECK_IN = 0 WHERE NUMBIGLIETTO NOT IN (SELECT NUMBIGLIETTO FROM [CHECK-IN]) UPDATE BIGLIETTO SET CHECK_IN = 1 WHERE NUMBIGLIETTO IN (SELECT NUMBIGLIETTO FROM [CHECK-IN]) 14

8 Alimentazione del Data Mart! Avendo a disposizione l attributo CHECK_IN, l alimentazione della fact table con tale dimensione è molto semplice, basta aggiungerlo agli attributi di raggruppamento! La vista (VIEW_BIGLIETTI) per alimentare la fact table è quindi:! Ora il contenuto della vista può essere copiato nella table fact BIGLIETTI del DM.! Conclusioni " Normalmente, il calcolo è un raggruppamento sulle dimensioni " Considerazioni sui join tra tabelle: LEFT JOIN " Considerazioni sui valori nulli: ISNULL 15 Alimentazione del Data Mart: creazione di pacchetti DTS 1. Si svuota il contenuto del DM: è utile per testare le procedure di estrazione statica 2. Si copiano le dimensional table: l unico vincolo da rispettare è quello dell integrità referenziale: quando si copia la tabella A, devono essere già state copiate tutte le tabelle alle quali A si riferisce tramite una FK " Si definisce un pacchetto DTS per ogni passo. Siccome in ogni passo si devono semplicemente copiare delle tabelle è conveniente (è più semplice) creare tale pacchetto tramite Importa Dati " In uno star schema si possono copiare tutte le dimension table in un solo passo 3. Si copia il contenuto della vista nella fact table! Ai passi generali riportati si possono aggiungere altre operazioni che dipendono dal contesto; ad esempio le istruzioni di update di pagina 14.! Dopo aver creato e provato i pacchetti (package) per i singoli passi, si puo creare un unico package che li include tutti, eseguendoli nell ordine stabilito 16

9 Analysis Services: definizione del CUBO Biglietti! Nel seguito viene utilizzato Analysis Services per analizzare i dati del DM dei Biglietti, discutendo alcuni punti caratteristici! Dimensione ParteDa : quando viene salvato il cubo, vengono contati i membri di ciascun livello; se il numero di CodVolo risulta inferiore a quello del livello padre Sigla (messaggio in basso) occorre rifare il conteggio in modo da contare le sigle effettivamente presenti 17 CUBO : gerarchia condivisa! Dimensione ArrivaA : non si può usare (come in figura) la stessa tabella AEROPORTO definendo un altro join tra VOLO e AEROPORTO sulla base dell attributo A : è come se venissero considerati solo i voli che partono ed arrivano allo stesso aeroporto (la figura piccola riporta la visualizzazione)! 18

10 CUBO : gerarchia condivisa! Dimensione ArrivaA : si deve inserire una nuova copia di AEROPORTO " AEROPORTO usato in ParteDA si rinomina in AeroportoDa (cambia alias) " Si inserisce ancora la tabella AEROPORTO " Si procede con la definizione di ArrivaA # Un altro esempio di cubo con gerarchia condivisa è in Completare il cubo definendo le altre dimensioni e le misure. Introdurre la misura CostoMedioBiglietto (CMB), calcolata come INCASSO/NUM_BIG. Implementazione in Analysis Services 1. Si definisce la misura derivata CMB_Base 2. Si definisce la misura di supporto Conteggio, aggregata con COUNT 3. Si definisce CMB calcolata come CMB_Base/Conteggio 19 CUBI VIRTUALI! Un cubo virtuale è una combinazione di più cubi all'interno di un cubo logico e può essere paragonato a una vista di un database relazionale! Un cubo virtuale consente di visualizzare contemporaneamente i dati di cubi diversi rendendo disponibili funzionalità di analisi più avanzate! Come per una vista, un cubo virtuale non è materializzato (memorizzato) quindi non richiede ulteriore spazio di archiviazione fisico! Un cubo virtuale può anche essere basato su un singolo cubo per esporre solo subset selezionati delle misure e delle dimensioni! Un cubo virtuale offre un'utile funzione di protezione grazie alla possibilità di limitare l'accesso di alcuni utenti durante la visualizzazione dei cubi sottostanti! Un cubo può essere riferito ad una sola fact table: il cubo virtuale è quindi indispensabile per confrontare i dati relativi a due o più fact table 20

11 CUBI VIRTUALI! Normalmente un cubo virtuale è definito come combinazione di due o più cubi che condividono alcune dimensioni.! D altra parte non c è alcuna limitazione nella definizione di un cubo virtuale: si può definire un cubo virtuale come combinazione di due cubi con insiemi di dimensioni differenti o, al limite, che non condividono alcuna dimensione: In corrispondenza di membri di dimensioni differenti, non esisterà alcun evento nel cubo virtuale. Più precisamente " Sia CV un cubo virtuale ottenuto come unione di C1 e C2 " Sia D1 (D2) una dimensione di C1 (C2) non presente in C2 (C1) " Allora le celle non vuote (ovvero gli eventi esistenti) sono solo in corrispondenza di (D1.All, D2.x), con x membro di D2 (D1.y, D2.All), con y membro di D1 21 CUBI VIRTUALI : Esempio! Definiamo un Cubo Virtuale come composizione di " Cubo dei Biglietti (CB) - cubo definito in precedenza " Cubo dei Ritardi (CR) - nuovo cubo per analizzare I ritardi! Dimensioni Condivise " È una dimensione che viene definita indipendntemente dal cubo e che può essere condivisa (cioè usata) in più cubi " Facilita la definizione dei cubi e risparmia spazio (si memorizza solo una volta) " È un concetto analogo a quello di gerarchia condivisa! Nel nostro esempio definiamo le seguenti dimensioni condivise relative a CB " ArrivaA, ParteDa, OraDiPartenza, Compagnia " Le altre dimensioni (es. ANNONASCITA) sono degeneri: non serve che siano condivise! Problema della gerarchia condivisa nel Cubo dei Biglietti: " Quando si usano le due dimensioni ParteDa e ArrivaA esiste lo stesso problema già discusso in precedenza " La soluzione al problema è la stessa: si modifica il nome (cambia alias) della tabella AEROPORTO; essendo una dimensione condivisa, si deve usare l editor delle Dimensioni 22

12 Ritardi: Progettazione dello schema di Fatto! Definire uno schema di fatto per analizzare i ritardi; in particolare l analisi deve considerare l aeroporto di partenza, mentre per quello d arrivo basta considerare solo la citta e lo stato 1. Si costruisce l albero degli attributi basato sull entità VOLOGIORN 2. Si modifica l albero aggiungendo la dipendenza CITTA! STATO 3. Si modifica l albero eliminando A-SIGLA 23 Ritardi: Progettazione dello Schema di Fatto! Progettazione Schema di Fatto 4. Si modifica l albero eliminando CODVOLO per CITTA_ARRIVO, 5. Si definisce lo Schema di Fatto selezionando come misura RITARDO (ovviamente definita come media ed aggregata tramite media) e come dimensioni: DATA CODVOLO e CITTA_ARRIVO! Si considera CITTA, STATO come gerarchia condivisa : per semplicità non viene indicata sul disegno 24

13 Ritardi: Progettazione logica! Se è già stato realizzato lo Schema logico di pag. 8, si possono riusare le dimension table già introdotte, cioè VOLO e AEROPORTO! D altra parte se si progetta lo schema logico da zero, per entrambi gli schemi di fatto, è possibile usare in AEROPORTO il riferimento a CITTA:! Nel seguito useremo il primo schema + lo schema di pagina 8 (altrimenti dobbiamo variare gli oggetti (cubi) realizzati finora 25 Ritardi: Alimentazione del Data Mart - Fact Table! Alimentazione della fact table: raggruppo su DATA,CODVOLO e CITTA_ARRIVO; definiamo una view (nel DB dei Biglietti) che contiene questi attributi (si noti che per CITTA_ARRIVO devo fare un join con AEROPORTO). Considero dei join interni.! Salvo ed edito la view aggiungendogli il raggruppamento e calcolando RITARDO: CREATE VIEW dbo.vistaritardi AS SELECT dbo.vologior.data, dbo.vologior.codvolo, dbo.aeroporto.citta AS CITTA_ARRIVO, AVG(RITARDO) AS RITARDO FROM dbo.vologior INNER JOIN dbo.volo ON dbo.vologior.codvolo = dbo.volo.codvolo INNER JOIN dbo.aeroporto ON dbo.volo.a = dbo.aeroporto.sigla GROUP BY dbo.vologior.data, dbo.vologior.codvolo, dbo.aeroporto.citta 26

14 Ritardi: Alimentazione del Data Mart - Dimension Table CITTA! Se nel DM ho AEROPORTO " Prendo i dati direttamente da tale tabella e li inserisco in citta: insert into CITTA select distinct CITTA,STATO from AEROPORTO " Si noti il distinct: in CITTA l attributo CITTA è chiave! Se nel DM non ho AEROPORTO " Prendo i dati dal DB Biglietti e precisamente dalla tabella AEROPORTO. " Quindi si effettua un importa dati basato sulla query select distinct CITTA,STATO from AEROPORTO! Dopo aver alimentato CITTA si può alimentare RITARDI con un semplice importa dati per prendere la view Ritardi nel DB Biglietti ed inserirlo nella tabella RITARDI del DM 27 Cubo dei Ritardi! Definizione delle dimensioni " Data: come dimensione temporale " ParteDA: si riutilizza la dimensione condivisa già definita in precedenza " Compagnia: si riutilizza la dimensione condivisa già definita in precedenza " CittaArrivo: nuova dimensione basata sulla tabella CITTA! Definizione della misura RITARDO aggregata tramite AVG 1. Si definisce RITARDOBASE basata su Ritardo ed aggregata tramite SUM 2. Si definisce la misura di supporto Conteggio, aggregata con COUNT 3. Si definisce Ritardo calcolato come RITARDOBASE /Conteggio 28

15 Cubo Virtuale! Quando si definisce un Cubo Virtuale si possono combinare solo le misure non i membri calcolati; quindi RITARDO deve essere ricalcolato nel cubo virtuale e pertanto le misure RitardoBase e Conteggio devono essere riportate nel cubo virtuale! Se nel cubo virtuale si sceglie DATA di BIGLIETTI: non si visualizza Ritardo!! Allora definiamo DATA come Dimensione Condivisa; dovendo selezionare la tabella dalla quale prenderla, si sceglie RITARDI: infatti in RITARDI ho tutti i voli giornalieri e quindi tutte le date che mi interessano! Prima di modificare una dimensione all interno del cubo, accertarsi che questa dimensione non sia usata da un cubo virtuale; in caso positivo, cancellare prima il cubo virtuale 29 Proprietà dei membri e dimensioni virtuali! Gli attributi descrittivi collegati ad attributi dimensionali si possono modellare usando Proprietà membro " Nell esempio, un possibile attributo descrittivo è il nome inglese dell insegnamento.! Una dimensione virtuale è una dimensione rispetto alla quale non vengono calcolati e materializzati dati aggregati " Logicamente, non c è nessuna differenza tra dimensioni ordinarie e dimensioni virtuali! Una dimensione virtuale viene definita rispetto ad una proprietà di un membro di una dimensione ordinaria 30