Esempio di progettazione di un DW La sorgente dati è costituita da un unico DataBase SQL-Server con informazioni sui Manifesti degli Studi e gli orari delle lezioni. Viene considerato il progetto di un DataMart per l analisi dei crediti (CFU) e degli orari delle lezioni Sommario 1. Analisi degli schemi e dei dati per definire lo schema riconciliato Si discute quindi dove e come realizzare tale schema riconciliato con riferimento alle architetture a due e a tre livelli 2. Realizzazione del DB riconciliato : architetture a 3 e a 2 livelli 3. Punti caratteristici della costruzione dello schema di fatto relativo agli orari 4. Progetto logico e alimentazione 5. Esempi di cubi in Analysis Services 6. Esempi di interrogazioni in MDX 7. Esempi di Data Transformation Service (DTS) di SQL-SERVER Questi esempi sono riferiti al caso dell alimentazione del Dbriconciliato con i dati del DB originale (vedi architettura a 3 livelli). Ovviamente i concetti introdotti si applicano anche ad altre situazioni (come ad esempio l alimentazione del DataWarehouse tramite il Dbriconciliato) 8. Note sulla Realizzazione del DW con architettura ad 1 livello 1
Schema sorgente : ORARI 2
Schema sorgente : CREDITI 3
Documentazione dello schema Se un insegnamento ha un unico SSD (Settore Scientifico Disciplinare) allora Il numero di crediti relativi viene specificato in Insegnamenti C è una sola tupla nella tabella Insegnamenti_Corsi_SSD Altrimenti I crediti vengono specificati in Insegnamenti_Corsi_SSD, con la possibilità di suddividerli in base alla tipologia (CFU_base, CFU_Affini, CFU_Carat,CFU_Sede e CFU_Altre); chiameremo tali crediti, crediti dettagliati In questo caso il numero di Crediti in Insegnamenti è nullo (in quanto equivale alla somma dei vari crediti specifici) L associazione tra insegnamenti e attività è molti a molti, con partecipazione opzionale di Insegnamenti: ovvero ci sono alcuni insegnamenti con nessuna attività associata 4
Analisi dei dati Nel seguito faremo un analisi dei dati, tramite alcuni esempi, allo scopo di individuare eventuali problemi di inconsistenza dei dati del DataBase reale rispetto alle specifiche riportate nella documentazione Inoltre, in base a tale analisi, verrà definito il DB riconciliato L analisi dei dati è un attività da condurre in collaborazione con l amministratore del DB, sia perchè può richiedere una conoscenza approfondita dello schema dei dati sia perche in alcuni casi può richiedere l esecuzione di query SQL non banali 5
Analisi dei dati / Crediti Esempio: Allo scopo di verificare se la regola sui crediti è rispettata effettuiamo un interrogazione per vedere se ci sono insegnamenti con il campo CREDITI non nullo (CREDITI IS NOT NULL) ma con più di un SSD associato SELECT IdInsegnamento,COUNT(*) FROM TBL_INSEGNAMENTI_CORSI_SSD WHERE IdInsegnamento IN( SELECT TBL_INSEGNAMENTI.ID FROM TBL_INSEGNAMENTI WHERE CREDITI IS NOT NULL) GROUP BY IdInsegnamento HAVING COUNT(*) >1 Risultato (ci sono 9 tuple su 4272). Ad esempio, l insegnamento 519 non rispetta la regola: ha CREDITI non nullo e due SSD associati 6
Analisi dei dati / Crediti Quanti sono gli insegnamenti con Crediti nullo? 347 SELECT COUNT(*) FROM TBL_INSEGNAMENTI WHERE CREDITI IS NULL Quanti sono gli insegnamenti con almeno un Credito specifico riportato in TBL_INSEGNAMENTI_CORSI_SSD? 1067 (Questa interrogazione è fatta tramite una vista in modo da poterla riutilizzare nel seguito, in altre interrogazioni) CREATE VIEW VIEW_CREDITI_SPECIFICI_NON_NULL AS SELECT * FROM TBL_INSEGNAMENTI_CORSI_SSD WHERE (CFU_Sede IS NOT NULL) OR (CFU_Altre IS NOT NULL) OR (CFU_Base IS NOT NULL) OR (CFU_Caratt IS NOT NULL) OR (CFU_Affini IS NOT NULL) SELECT COUNT(*) FROM VIEW_CREDITI_SPECIFICI_NON_NULL 7
Analisi dei dati / Crediti Quali sono gli insegnamenti con un valore di Crediti non NULLO e diverso dalla somma dei crediti dettagliati riportati in TBL_INSEGNAMENTI_CORSI_SSD? NESSUNO! SELECT * FROM TBL_INSEGNAMENTI WHERE (Crediti IS NOT NULL) AND (Crediti <> (SELECT SUM(isnull(CFU_Sede, 0) + isnull(cfu_altre, 0) + isnull(cfu_base, 0) + isnull(cfu_caratt, 0) + isnull(cfu_affini, 0)) FROM WHERE VIEW_CREDITI_SPECIFICI_NON_NULL IdInsegnamento = TBL_INSEGNAMENTI.ID GROUP BY IdInsegnamento)) 8
Analisi dei dati / Crediti Se un insegnamento ha crediti null in TBL_INSEGNAMENTI, posso ricavarlo facendo la somma dei crediti dettagliati? NO, perchè Quali sono gli insegnamenti con un valore di CREDITI null in TBL_INSEGNAMENTI e con la somma diversa da zero dei crediti specifici riportati in TBL_INSEGNAMENTI_CORSI_SSD? NESSUNO! SELECT * FROM WHERE TBL_INSEGNAMENTI (Crediti IS NOT NULL) AND (0 <> (SELECT SUM(isnull(CFU_Sede, 0) + isnull(cfu_altre, 0) + isnull(cfu_base, 0) + isnull(cfu_caratt, 0) + isnull(cfu_affini, 0)) FROM WHERE VIEW_CREDITI_SPECIFICI_NON_NULL IdInsegnamento = TBL_INSEGNAMENTI.ID GROUP BY IdInsegnamento)) 9
Analisi dei dati / Crediti : conclusioni La tabella TBL_INSEGNAMENTI_CORSI_SSD non aggiunge informazione sul numero dei crediti complessivi di un insegnamento, quindi è inutile fare la somma dei crediti in essa riportata per assegnarla come Crediti in TBL_INSEGNAMENTI Decisione: Non si considerano i crediti dettagliati. Decisione: nel livello riconciliato dei dati si considera un associazione unoa-molti tra Insegnamenti e SSD In TBL_INSEGNAMENTI viene aggiunto un campo IdSSD Nel caso di insegnamenti con più SSD si considera un solo SSD a caso, ottenibile, ad esempio, come SSD con massimo valore di ID, cioè tra tutti gli SSD associati all insegnamento prendo quello il cui ID ha valore massimo. Usiamo questa tecnica perchè facilmente implementabile in SQL tramite la funzione MAX; naturalmente si potrebbe definire una funzione più complessa. 10
Analisi dei dati / Attività Con un procedimento analogo al precedente si analizza l associazione tra gli insegnamenti e le attività, verificando che non ci sono insegnamenti con più di una attività associata SELECT IdInsegnamento FROM TBL_INSEGNAMENTI_ATTIVITA group by IdInsegnamento having count(*) > 1 Risultato vuoto: non ci sono insegnamenti con più di una attività associata Decisione: nel livello riconciliato dei dati si considera un associazione uno-a-molti tra Insegnamenti e Attività: In TBL_INSEGNAMENTI verrà considerato il campo IdAttività in cui viene riportato l ID dell unica attività associata Conviene calcolare tale ID come valore max tra tutti gli ID delle attività associate all insegnamento: in questo modo se verranno inseriti degli insegnamenti con più attività, nello schema riconciliato si riesce comunque ad individuare una sola attività 11
Livello riconciliato: Crediti e Attività 12
Analisi dei dati / Orari Un aspetto evidente dello schema degli orari è l assenza di una chiave in TBL_INS_ORARIO. Questo significa che non sono dichiarati i classici vincoli non sovrapposizione: non ci sono due insegnamenti nello stesso ora nella stessa aula. Si può verificare che non è vero, in quanto la seguente query restituisce un risultato non vuoto: SELECT Id_Anno, Id_Periodo, Id_Giorno, Id_Ora, Id_Aula FROM TBL_INS_ORARIO GROUP BY Id_Anno, Id_Periodo, Id_Giorno, Id_Ora, Id_Aula HAVING (COUNT(DISTINCT Id_Ins) > 1) non sdoppiamento: in un certo orario, un insegnamento è in una sola aula. Si può verificare che non è vero, in quanto la seguente query restituisce un risultato non vuoto: SELECT Id_Ins, Id_Anno, Id_Periodo, Id_Giorno, Id_Ora FROM TBL_INS_ORARIO GROUP BY Id_CDS, Id_Ins, Id_Anno, Id_Periodo, Id_Giorno, Id_Ora HAVING (COUNT(DISTINCT Id_Aula) > 1) 13
Analisi dei dati / Orari Un altro aspetto è la denormalizzazione della tabella INS_ORARIO: ci sono alcuni campi che, intuitivamente, dipendono da altri campi. Dipendenza Id_periodo Id_Anno Per verificare questa dipendenza funzionale ricavo i valori di Id_periodo che hanno differenti Id_anno associati: SELECT Id_periodo FROM TBL_INS_ORARIO group by Id_Periodo having count(distinct Id_Anno) > 1 Il risultato è vuoto, quindi, sull istanza corrente, la dipendenza è verificata. Verifichiamo che Id_Anno in INS_ORARIO sia lo stesso IdAA indicato in TBL_PERIODI: SELECT count(*) FROM TBL_INS_ORARIO JOIN TBL_PERIODI ON TBL_INS_ORARIO.Id_Periodo = TBL_PERIODI.Id where TBL_INS_ORARIO.Id_Anno <> TBL_PERIODI.IdAA Decisione: Id_Anno si può eliminare dalla tabella INS_ORARIO. 14
Analisi dei dati / Orari Come altro esempio di potenziale dip. funz., consideriamo se in INS_ORARIO l insegnamento (Id_Ins) determina il Corso di Studio (Id_cds) Dipendenza Id_Ins Id_Cds Per verificare questa dip. Funz. ricavo i valori di Id_Ins che hanno differenti Id_Cds associati: SELECT Id_Ins FROM TBL_INS_ORARIO group by Id_Ins having count(distinct Id_CDS) > 1 Il risultato della query non è vuoto: Cosa significa questo? Perche in INS_ORARIO non ho solo il CDS di Id_Ins (quello specificato in TBL_INSEGNAMENTI come Id_CorsoStudioRegolamento)? Analizzando alcune tuple, ma soprattutto chiedendo all amministratore del DB, si scopre che viene seguita la seguente regola: sia X un insegnamento con del Corso di studi CDSX che mutua da un insegnamento Y del Corso di studi CDSY; allora tutte le ore di X in INS_ORARIO vengono messe con Id_Ins=Y e Id_Cds=CDSX Decisione: Id_Cds resta nella tabella INS_ORARIO. 15
Analisi dei dati / Orari - Mutuazioni Esempio: consideriamo due insegnamenti (SI, SI&BD) con i relativi Corsi di Studio indicati nella tabella INSEGNAMENTI TBL_INSEGNAMENTI ID IDCORSODISTUDIOREGOLAMENTO SI E-BUS SI&BD GEST_IND Orario (A.A. 2003/2004, periodo=3) Lunedi, ore 9-11, SI e SI&BD, aula F Martedì!, ore 9-10, SI, aula G Mercoled!ì, ore 10-10, SI&BD, aula H In base alla precedente regola, in INS_ORARIO si ha: TBL_INS_ORARIO ID_CDS ID_ANNO ID_PERIODO ID_INS ID_GIORNO ID_ORA ID_AULA E-BUS 2003/2004 3 SI&BD 1 2 F E-BUS 2003/2004 3 SI&BD 1 3 F GEST_IND 2003/2004 3 SI&BD 1 2 F GEST_IND 2003/2004 3 SI&BD 1 3 F E-BUS 2003/2004 3 SI&BD 2 2 G GEST_IND 2003/2004 3 SI&BD 3 3 H Se non si considerano le mutuazioni, tutte le ore vengono assegnate a SI&BD ma questo può essere non significativo per alcune tipologie di analisi (ad esempio, se l insegnamento ha un docente, e chiedo qual è l impegno - ovvero il numero di ore - del docente dovrei considerare le mutuazioni). 16
Livello riconciliato : schema complessivo 17
Dove si realizza lo schema riconciliato? 1. Architettura a 3 livelli si realizza un nuovo DB (DBRiconciliato) con lo schema riconciliato: Dati operazionali Dati esterni Livello delle sorgenti Strumenti ETL DBRiconciliato Caricamento Dati riconciliati Meta-dati Livello di alimentazione Data Warehouse Livello del warehouse Il nuovo DBRiconciliato deve essere alimentato con i dati originali: si può usare il DTS di SQL Server (vedi ultima parte) 18
Alimentazione del DBRiconciliato Esempio: Tabella TBL_INSEGNAMENTI 1. Si crea la tabella TBL_INSEGNAMENTI dello schema riconciliato 2. Tramite DTS si copiano i campi di TBL_INSEGNAMENTI i cui valori restano inalterati nel DBRiconciliato 3. Si determinano gli altri campi della tabella ; in questo caso occorre calcolare IdSSD come valore massimo dei valori presenti in TBL_INSEGNAMENTI_CORSI_SSD, allora 1. Si effettua una copia temporanea in DBRiconciliato di TBL_INSEGNAMENTI_CORSI_SSD) 2. Si esegue la seguente istruzione UPDATE TBL_INSEGNAMENTI SET IdSSD = (SELECT max(idssd) FROM TBL_INSEGNAMENTI_CORSI_SSD_TEMP WHERE TBL_INSEGNAMENTI.Id = idinsegnamento) Alternative (più difficili da implementare) IdSSS viene calcolato tramite una query nel DTS IdSSS viene calcolato tramite una vista nel DB originale 19
Dove si realizza lo schema riconciliato? 2. Architettura a 2 livelli Non si realizza un nuovo DB riconciliato Livello delle sorgenti Dati operazionali Dati esterni Strumenti ETL Livello di alimentazione Data Warehouse Livello del warehouse La riconciliazione viene effettuata direttamente nel DB originale, tramite l aggiunta di opportune tabelle e/o viste, cioè lo schema riconciliato di pag. 17 viene realizzato nel DB originale. Uso di tabelle: Lo schema riconciliato viene realizzato nel DB originale introducendo solo le tabelle variate (es. TBL_INSEGNAMENTI) ed eventualmente nuove tabelle; le altre tabelle (es. TBL_ATTIVITA) la cui struttura non è stata modificata restano invariate 20
Architettura a 2 livelli : uso di tabelle Le tabelle variate (es. TBL_INSEGNAMENTI) ed eventualmente le nuove tabelle si costruiscono tramite tabelle (il cui nome è seguito da _RIC per ricordare che sono dello schema riconciliato) Esempio: Tabella TBL_INSEGNAMENTI_RIC 1. Si crea la tabella TBL_INSEGNAMENTI_RIC dello schema riconciliato 2. Si copiano i campi di TBL_INSEGNAMENTI i cui valori restano inalterati nello schema riconciliato INSERT INTO TBL_INSEGNAMENTI_RIC(Id, IdCorsoStudioRegolamento, Denominazione, Crediti, IdAmbito, IdAttivita, AnnoCorso, Asterisco) SELECT Id, IdCorsoStudioRegolamento, Denominazione, Crediti, IdAmbito, IdAttivita, AnnoCorso, Asterisco FROM TBL_INSEGNAMENTI 3. Si determinano gli altri campi della tabella; nell esempio IdSSD: UPDATE TBL_INSEGNAMENTI_RIC SET IdSSD = (SELECT max(idssd) FROM TBL_INSEGNAMENTI_CORSI_SSD WHERE TBL_INSEGNAMENTI_RIC.Id = idinsegnamento) Le istruzioni 2 e 3 possono essere eseguite in un pacchetto DTS, (precedute da uno svuotamento dell tabella TBL_INSEGNAMENTI_RIC) Si consiglia di utilizzare questa modalità nella tesina 21
Architettura a 2 livelli: uso di viste Lo schema riconciliato (vedi p. 17) si realizza nel DB originale definendo le tabelle variate e le eventuali nuove tabelle come viste La definizione delle viste può risultare difficile, in quanto occorre considerare, in genere, sia campi invariati sia campi calcolati! Esempio: TBL_INSEGNAMENTI_RIC definita come vista 1. Si definisce la vista V1 che riporta i campi di TBL_INSEGNAMENTI i cui valori restano inalterati nello schema riconciliato CREATE VIEW V1 AS SELECT Id, IdCorsoStudioRegolamento, Denominazione, Crediti, IdAmbito, IdAttivita, AnnoCorso, Asterisco FROM TBL_INSEGNAMENTI 2. Per ogni campo calcolato (es. IdSSD) si definisce una vista avente come attributi la chiave di TBL_INSEGNAMENTI e il campo calcolato; CREATE VIEW V2(ID,IdSSD) as SELECT idinsegnamento,max(idssd) FROM TBL_INSEGNAMENTI_CORSI_SSD GROUP BY idinsegnamento 3. La vista TBL_INSEGNAMENTI_RIC è il join di V1 e V2 : CREATE VIEW TBL_INSEGNAMENTI_RIC( tutti gli attributi ) AS SELECT V1.*, IdSSD FROM V1, V2 WHERE V1.ID=V2.ID 22
Schema di Fatto - Orari Punti caratteristici: La tabella INS_ORARIO non ha una chiave e l insieme di attributi non è chiave: Nel corrispondente schema E/R considero un codice fittizio (nota: in base alle specifiche so già che sarà uno schema a grana temporale, nel quale questo codice scomparirà) Convergenza? L AnnoAccademico indicato in Periodi è lo stesso di quello riportato in CorsoDiStudiRegolamento? Si, ad eccezione di 25 tuple su circa 10.000! Possiamo indicare la convergenza (eventualmente si possono pulire le tuple sporche). La convergenza non influenza il nostro progetto logico Granularità a livello di ora: Non si vuole considerare la singola ora, ma solo differenziare tra 'mattina' e pomeriggio : si definisce una dimensione MATPOM derivata da ID_ORA. Per semplicità (come nel caso dell attributo CHECK_IN nell esempio dei biglietti) si aggiunge alla tabella INS_ORARIO un attributo MATPOM con valori mat e pom calcolato direttamente sul DB transazionale: update TBL_INS_ORARIO set MATPOM= mat where ID_ora >=0 and ID_ora<=5 update TBL_INS_ORARIO set MATPOM= pom where ID_ora >=6 Senza considerare le mutuazioni si definisce solo la misura NUM_ORE = count(*) 23
Schema di Fatto - Orari - Mutuazioni Per tenere conto delle mutuazioni : non ho informazioni sulle mutuazioni nello schema NUM_ORE_EFFETTIVE (cioè ore non mutuate da altri CDS) : Si deve innanzitutto definire cosa significa non mutuata considerando la regola precedente, e quindi si può procedere al calcolo. Nel lucido che segue verrà presentato tale calcolo; per semplicità nel calcolo (della espressioni SQL) si aggiunge alla tabellla INS_ORARIO un campo MUTUATA che riporta appunto l esito di tale calcolo Esempio: Orario (A.A. 2003/2004, periodo=3) Lunedi, ore 9-11, SI e SI&BD, aula F Martedì!, ore 9-10, SI, aula G Mercoled!ì, ore 10-10, SI&BD, aula H TBL_INSEGNAMENTI ID IDCORSODISTUDIOREGOLAMENTO SI E-BUS SI&BD GEST_IND In base alla regola, in INS_ORARIO si ha: TBL_INS_ORARIO ID_CDS ID_ANNO ID_PERIODO ID_INS ID_GIORNO ID_ORA ID_AULA MUTUATA E-BUS 2003/2004 3 SI&BD 1 2 F SI E-BUS 2003/2004 3 SI&BD 1 3 F SI GEST_IND 2003/2004 3 SI&BD 1 2 F NO GEST_IND 2003/2004 3 SI&BD 1 3 F NO E-BUS 2003/2004 3 SI&BD 2 2 G NO GEST_IND 2003/2004 3 SI&BD 3 3 H NO 24
Schema di Fatto - Orari - Mutuazioni Calcolo dell attributo MUTUATA 1. Per default, un ora è non mutuata : update TBL_INS_ORARIO set MUTUATA='NO' 2. Un ora è mutuata se (a) ID_CDS è diverso da IDCORSODISTUDIOREGOLAMENTO nella tabella INSEGNAMENTI e (b) c è una corrispondente ora (stessa ora, stesso giorno, stessa aula,stesso anno e periodo) con differente ID_CDS update TBL_INS_ORARIO set MUTUATA='SI' where ID_CdS <> (select idcorsostudioregolamento from TBL_INSEGNAMENTI where TBL_INS_ORARIO.ID_ins = TBL_INSEGNAMENTI.Id) and exists (select * from TBL_INS_ORARIO as O1 where TBL_INS_ORARIO.ID_Anno=O1.Id_anno and TBL_INS_ORARIO.Id_periodo=O1.Id_periodo and TBL_INS_ORARIO.Id_giorno=O1.Id_giorno and O.Id_ora=O1.Id_ora and TBL_INS_ORARIO.Id_aula=O1.Id_aula and O.ID_CDS<>O1.Id_CDS) 25
Progetto Logico 26
Alimentazione del DM L alimentazione delle Dimension Table è semplice: la loro struttura corrisponde a quelle del DB transazionale; utilizzare importa dati rispettando l ordine imposto dalle FK (vedi esempi DTS) Per l alimentazione della Fact Table si definisce una vista nel DB originale, contenente tutte le misure In questo caso NUM_ORE si calcola su tutte le tuple di INS_ORARIO mentre NUM_ORE_EFF solo su quelle con Mutuata = No : conviene definire due viste e poi fare il join Vista per il Calcolo di NUM_ CREATE VIEW ConteggioOre(Id_CDS, Id_Periodo, Id_Ins, Id_Giorno,Id_Aula, MatPom,NUM_ORE) AS SELECT Id_CDS, Id_Periodo, Id_Ins, Id_Giorno, Id_Aula, MatPom, count(*) FROM TBL_INS_ORARIO group by Id_CDS, Id_Periodo, Id_Ins, Id_Giorno, Id_Aula, MatPom Vista per il Calcolo di NUM_ CREATE VIEW ConteggioOreEffettive (Id_CDS, Id_Periodo, Id_Ins, Id_Giorno,Id_Aula, MatPom,NUM_ORE_EFF) AS SELECT Id_CDS, Id_Periodo, Id_Ins, Id_Giorno, Id_Aula, MatPom, count(*) FROM TBL_INS_ORARIO where Mutuata = No' group by Id_CDS, Id_Periodo, Id_Ins, Id_Giorno, Id_Aula, MatPom Nota: si potrebbero usare queste due viste per alimentare la Fact Table, però l alimentazione in DTS risulta più complessa: si preferisce creare una sola vista. 27
Vista per il calcolo delle misure Vista con entrambi i valori calcolati : è ottenuta (usare l interfaccia grafica) come join delle due precedenti viste Siccome ConteggioOre ha un sovrainsieme delle tupe di ConteggioOreEffettive, usare ConteggioOre Left Join ConteggioOreEffettive Usare isnull(num_ore_eff,0) : in questo modo per una tupla che è in ConteggioOre ma non in ConteggioOreEffettive (cioè è mutuata) ho 0 come valore di NUM_ORE_EFF AS CREATE VIEW dbo.conteggioentrambe SELECT dbo.conteggioore.id_cds, dbo.conteggioore.id_periodo, dbo.conteggioore.id_ins, dbo.conteggioore.id_giorno, FROM dbo.conteggioore.id_aula, dbo.conteggioore.matpom, dbo.conteggioore.num_ore, isnull(dbo.conteggiooreeffettive.num_ore_eff,0) as NUM_ORE_EFF dbo.conteggioore LEFT OUTER JOIN dbo.conteggiooreeffettive ON dbo.conteggioore.matpom = dbo.conteggiooreeffettive.matpom AND dbo.conteggioore.id_aula = dbo.conteggiooreeffettive.id_aula AND dbo.conteggioore.id_giorno = dbo.conteggiooreeffettive.id_giorno AND dbo.conteggioore.id_ins = dbo.conteggiooreeffettive.id_ins AND dbo.conteggioore.id_periodo = dbo.conteggiooreeffettive.id_periodo AND dbo.conteggioore.id_cds = dbo.conteggiooreeffettive.id_cds 28
Realizzazione Cubi in Analysis Services Consideriamo la Dimensione Periodo con la relativa gerarchia TipoPeriodo è la denominazione del periodo. In Analysis Services possiamo definire due dimensioni: Nota: nella dimensione TipoPeriodo si decide di non considerare il livello IdPeriodo; è una modifica rispetto al progetto concettuale iniziale 29
Alcuni esempi di query MDX Nel seguito vengono riportati alcuni esempi di query MDX sul cubo ORARI Esempio: Ore mutuate (definite come differenza tra le ore e quelle effettive): COLUMNS: i primi 7 CDS che hanno un maggior numero di ore mutuate ROWS: I periodi del 2004/2005gli Anni Accademici Si mostrano le ore mutuate WITH MEMBER [MEASURES].[NUM_ORE_MUTUATE] AS '[Measures].[Num Ore]- [Measures].[Num Ore Eff]' SELECT TOPCOUNT([CDS].[Denominazione].MEMBERS, 7, [NUM_ORE_MUTUATE]) ON COLUMNS, [Periodo].[2004/2005].CHILDREN ON ROWS FROM ORARI WHERE [NUM_ORE_MUTUATE] Problema: in questo modo il TopCount ordina rispetto a [NUM_ORE_MUTUATE] complessive, non quelle del 2004/2005. Per ordinare rispetto a quelle del 2004/2005 : ([Periodo].[2004/2005],[NUM_ORE_MUTUATE]) WITH MEMBER [MEASURES].[NUM_ORE_MUTUATE] AS '[Measures].[Num Ore]- [Measures].[Num Ore Eff]' SELECT TOPCOUNT([CDS].[Denominazione].MEMBERS, 7, ([Periodo].[2004/2005],[NUM_ORE_MUTUATE]))ON COLUMNS, [Periodo].[2004/2005].CHILDREN ON ROWS FROM ORARI WHERE [NUM_ORE_MUTUATE] 30
Alcuni esempi di query MDX Esempio: Ore per AnnoAccademico/Periodo e AnnoDiCorso/CorsodiStudi COLUMNS: (X,Y), dove X è un Anno Accademico e Y un TipoPeriodo NONEMPTYCROSSJOIN( [Periodo].[AnnoAccademico].MEMBERS, [TipoPeriodo].[TipoPeriodo].MEMBERS ) ON COLUMNS ROWS : (X,Y), dove X è un Anno di Corso e Y è un Corso di Studi, limitato a Informatica ed Elettronica: NONEMPTYCROSSJOIN( [Anno Corso].[Anno Corso].MEMBERS, {[CDS].[Ingegneria Elettronica], [CDS].[Ingegneria Informatica] }) ON ROWS Se invece di Informatica ed Elettronica voglio i primi tre Cds per numero di ore: NONEMPTYCROSSJOIN( [Anno Corso].[Anno Corso].MEMBERS, TOPCOUNT([CDS].[Denominazione].MEMBERS,3,[Measures].[Num Ore])}) ON ROWS 31
Architetture a 1 livello Si discute brevemente questo tipo di soluzione nell esempio. Alla fine della progettazione logica, si ha lo schema logico (pag. 26) su carta. Il livello del warehouse è costituito da un insieme di viste nel DB operazionale: si può definire una vista corrispondente alla fact table FT_ORARI partendo dalla vista ConteggioEntrambe (pag. 28); per le dimension table si usano direttamente le table operazionale. Dati operazionali Middleware Strumenti OLAP Livello delle sorgenti Livello del warehouse Livello di analisi Il livello di analisi (i cubi) verranno definiti usando come sorgente dati il DB operazionale; un cubo può essere definito a partire da una vista. Prescindendo dai noti problemi di efficienza, elenchiamo alcuni pro e contro: Pro: Alcuni analisi (cubi) si realizzano in modo immediato; ad esempio, possiamo analizzare il numero di ore rispetto al giorno e al cds anche senza realizzare alcuna vista ma riferendoci direttamente alla tabella INS_ORARIO Contro: Per analisi più complete/complesse, che coinvolgono particolari dimensioni (es. MatPom) e/o misure (es. Num_Ore_Eff) occorre definire delle viste non banali oppure effettuare complessi calcoli (misure, dimensioni) usando lo specifico strumento OLAP (Analysis Services nel nostro caso). 32
Alcuni esempi di DTS Nel seguito vengono riportati alcuni screenshots relativi all uso del Data Transformation Service (DTS) di SQL-SERVER Questi esempi sono riferiti al caso dell alimentazione del Dbriconciliato con i dati del DB originale (vedi architettura a 3 livelli). Ovviamente i concetti introdotti si applicano anche ad altre situazioni (come ad esempio l alimentazione del DataWarehouse tramite il Dbriconciliato) Tabelle invariate: si intendono le tabelle che vengono copiate da una tabella origine, senza modificare le istanze (eliminando, eventualmente, alcuni campi) 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 Allora è possibile seguire questa procedura (valida in assenza di cicli) Passo 1: copio tutte le tabelle che non si riferiscono ad altre tabelle Passo 2: copio tutte le tabelle che si riferiscono alle tabelle copiate al passo 1 Si definisce un pacchetto DTS per ogni passo. Siccome in ogni passo si devono copiare delle tabelle è più semplice creare tale pacchetto tramite Importa Dati In caso di cicli si devono eliminare, una o pìù, FK Manualmente sul diagramma Tramite opportune istruzioni SQL (ALTER TABLE) nei vari passi 33
DTS: copia delle tabelle invariate Importazione guidata dei dati 34
DTS: copia delle tabelle invariate Selezione dell origine dati 35
DTS: copia delle tabelle invariate Selezione della destinazione dati 36
DTS: copia delle tabelle invariate Selezione tabelle di origine e destinazione 37
DTS: copia delle tabelle invariate Selezione dei mapping e trasformazioni tra le colonne 38
DTS: copia delle tabelle invariate Creazione delle tabelle di destinazione 39
DTS: copia delle tabelle invariate Esecuzione del pacchetto 40
DTS: copia delle tabelle invariate Salvataggio del pacchetto 41
DTS: copia delle tabelle invariate Proprietà del pacchetto 42
DTS: copia delle tabelle invariate Riepilogo dell importazione dati 43
DTS: trasformazione dei dati Creazione di un nuovo pacchetto 44
DTS: trasformazione dei dati Proprietà del pacchetto 45
DTS: trasformazione dei dati Creazione di un pacchetto per la trasformazione dei dati 46
DTS: trasformazione dei dati Inserimento di una connessione: è il primo DB da usare 47
DTS: trasformazione dei dati Inserimento di una connessione dal menù: diversi tipi di connessione 48
DTS: trasformazione dei dati Proprietà della connessione 49
DTS: trasformazione dei dati Inserimento di un altra connessione: è il secondo DB da usare 50
DTS: trasformazione dei dati Inserimento del task per la trasformazione dei dati 51
DTS: trasformazione dei dati Inserimento del task da menù: diversi tipi di attività (task) 52
DTS: trasformazione dei dati Selezione della sorgente e della destinazione per il task 53
DTS: trasformazione dei dati Proprietà del task: selezione della tabella di origine 54
DTS: trasformazione dei dati Proprietà del task: selezione della tabella di destinazione 55
DTS: trasformazione dei dati Proprietà del task: proprietà della tabella di destinazione 56
DTS: trasformazione dei dati Corrispondenza tra i campi delle tabelle origine e destinazione del primo task 57
DTS: trasformazione dei dati Corrispondenza tra i campi delle tabelle origine e destinazione del secodno task: copia degli insegnamenti 58
DTS: trasformazione dei dati Corrispondenza tra i campi delle tabelle origine e destinazione del terzo task 59
DTS: trasformazione dei dati I tre tasks possono essere eseguiti in parallelo 60
DTS: trasformazione dei dati Inserimento di attività Esegui SQL 61
DTS: trasformazione dei dati La prima attività esegue le seguenti istruzioni SQL 62
DTS: trasformazione dei dati La seconda attività esegue le seguenti istruzioni SQL 63
DTS: trasformazione dei dati Definizione del flusso di lavoro: le attività Esegui SQL sono effettuate al completamento (in caso di esito positivo) dei task precedenti. 64
DTS: trasformazione dei dati Definizione delle regole per la prima precedenza 65
DTS: trasformazione dei dati Definizione delle regole per la seconda precedenza 66
DTS: trasformazione dei dati Creazione di un package per la tabella TBL_INS_ORARIO 67
DTS: Pacchetto generale Definizione del package generale che stabilisce l ordine di esecuzione degli altri pacchetti 68
DTS: Pacchetto generale Inserimento di un attività per l esecuazione di un pacchetto 69
DTS: Pacchetto generale Definizione delle precedenze per l esecuzione dei pacchetti 70