Biglietti: schema E/R

Biglietti: albero degli attributi

Biglietti: albero degli attributi

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)

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

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 :

Alimentazione del Data Mart Si considera il seguente schema relazionale del DB operazionale DB_BIGLIETTI Si considera solo l’alimentazione a partire da zero

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.

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 Nel DB operazionale si crea la query che calcola le istanze della fact table e si memorizza tale query in una vista (VIEW_BIGLIETTI) 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).

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

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 …

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.

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

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]) SET CHECK_IN = 1 WHERE NUMBIGLIETTO IN (SELECT NUMBIGLIETTO FROM [CHECK-IN])

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

Alimentazione del Data Mart Calcolo dell’attributo CHECK_IN utilizzando le viste In base alla discussione già fatta sul left join, possiamo calcolare tale valore effettuando il left join :

Alimentazione del Data Mart L’attributo CHECK_IN si ricava da [CHECK-IN].NUMBIGLIETTO con un semplice if (usiamo il case di SQL-SERVER): CASE WHEN (dbo.[CHECK-IN].NUMBIGLIETTO IS NULL) THEN 0 ELSE 1 END AS CHECK_IN SQL-SERVER non consente di raggruppare su un attributo calcolato tramite CASE Si crea una prima vista con l’attributo calcolato tramite il case Si raggruppa su tale vista