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

Presentazione sul tema: "1 Biglietti: schema E/R. 2 Biglietti: albero degli attributi."— Transcript della presentazione:

1 1 Biglietti: schema E/R

2 2 Biglietti: albero degli attributi

3 3

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

5 5 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 dellalbero degli attributi (aggiunta di una dipendenza funzionale). Oppure può essere rilevata durante lanalisi del carico di lavoro, ad esempio, analizzando la possibilità di fare una interrogazione del tipo per ogni stato, confrontare gli incassi delle sue città.

6 6 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 :

7 7 Alimentazione del Data Mart Si considera il seguente schema relazionale del DB operazionale DB_BIGLIETTI Si considera solo lestrazione statica che viene effettuata quando il DM deve essere popolato per la prima volta e consiste concettualmente in una fotografia dei dati operazionali. lalimentazione a partire da zero

8 8 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 lintroduzione di chiavi surrogate (infatti le chiavi surrogate devono essere create e gestite durante lalimentazione), 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.

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

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

11 11 Alimentazione del Data Mart Si deve considerare se è sufficiente fare lINNER JOIN oppure si deve fare un OUTER JOIN … Tra BIGLIETTO e CLIENTE è sufficiente lINNER JOIN in quanto tutti i biglietti hanno un cliente (questo si vede dallE/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 …

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

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

14 14 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 lattributo 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 lalto, dove CHECK_IN è lattributo 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])

15 15 Alimentazione del Data Mart Avendo a disposizione lattributo CHECK_IN, lalimentazione 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

16 16 1. Si svuota il contenuto del DM: è utile per testare le procedure di estrazione statica 2. Si copiano le dimensional table: lunico vincolo da rispettare è quello dellintegrità 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 Alimentazione del Data Mart: creazione di pacchetti DTS 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 nellordine stabilito

17 17 Analysis Services: definizione del CUBO Biglietti 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 Nel seguito viene utilizzato Analysis Services per analizzare i dati del DM dei Biglietti, discutendo alcuni punti caratteristici

18 18 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 dellattributo A : è come se venissero considerati solo i voli che partono ed arrivano allo stesso aeroporto (la figura piccola riporta la visualizzazione)!

19 19 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 http://dbgroup.unimo.it/SIA/EsempioTelefonate/Telefonate.html 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

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

21 21 Normalmente un cubo virtuale è definito come combinazione di due o più cubi che condividono alcune dimensioni. Daltra 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 CUBI VIRTUALI

22 22 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 leditor delle Dimensioni CUBI VIRTUALI : Esempio

23 23 Definire uno schema di fatto per analizzare i ritardi; in particolare lanalisi deve considerare laeroporto di partenza, mentre per quello darrivo basta considerare solo la citta e lo stato 1. Si costruisce lalbero degli attributi basato sullentità VOLOGIORN 2. Si modifica lalbero aggiungendo la dipendenza CITTA STATO 3. Si modifica lalbero eliminando A-SIGLA Ritardi: Progettazione dello schema di Fatto

24 24 Progettazione Schema di Fatto 4. Si modifica lalbero 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 Ritardi: Progettazione dello Schema di Fatto Si considera CITTA, STATO come gerarchia condivisa : per semplicità non viene indicata sul disegno

25 25 Se è già stato realizzato lo Schema logico di pag. 8, si possono riusare le dimension table già introdotte, cioè VOLO e AEROPORTO Ritardi: Progettazione logica Daltra 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

26 26 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. 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 Salvo ed edito la view aggiungendogli il raggruppamento e calcolando RITARDO:

27 27 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 lattributo 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

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

29 29 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 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 allinterno del cubo, accertarsi che questa dimensione non sia usata da un cubo virtuale; in caso positivo, cancellare prima il cubo virtuale Se nel cubo virtuale si sceglie DATA di BIGLIETTI: non si visualizza Ritardo!

30 30 Proprietà dei membri e dimensioni virtuali Gli attributi descrittivi collegati ad attributi dimensionali si possono modellare usando Proprietà membro Nellesempio, un possibile attributo descrittivo è il nome inglese dellinsegnamento. 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