• Non ci sono risultati.

6.3 Sviluppo della Staging Area

6.3.1 Sviluppo della fact table Tirocini Approvati

Dopo aver estratto tutti i dati dalle sorgenti alla Staging Area, si è passati alla realizzazione del cubo dei Tirocini Approvati (SF_TIR_TIROCINI_APPROVATI). L’iter di sviluppo di questa fact table è stato suddiviso in 6 step con la conseguente realizzazione di cinque tabelle temporanee TT_ e due tabelle di fine elaborazione S_(tutti i flussi di popolamento di queste tabelle sono stati realizzati tramite il costrutto di interfaccia spiegato nel capitolo 3). Le motivazioni alla base di questa logica sono due: La prima è dovuta a un limite strutturale riscontrato nel tool ODI o un probabile bug presente nella versione utilizzata che consiste nell’impossibilita di poter eseguire delle join con condizioni che coinvolgono più di due tabelle per volta, la seconda motivazione è dovuta ad una formattazione errata dei dati estratti dalla tabella sorgente nell’estrattore T_PERIODI_TIROCINI, questi, sono stati perciò "puliti" e rielaborati e inseriti in una nuova tabella temporanea. Quest’ultimo punto sarà approfondito dettagliatamente nel paragrafo sulla pulizia del dato.

Sulla base di queste motivazioni, la logica di creazione della fact table Tirocini Approvati ha subito numerosi cambiamenti nel corso dello sviluppo del progetto.

Primo step

Il primo step è stato quello di reperire informazioni inerenti gli esami e i CFU (Crediti Formativi Universitari) dei tirocini di tipo curriculare (tipo 1). Per fare

questo:

• E’ stata creata inizialmente la tabella TT_TIR_CFU_TIROCINI_P00 per ap- plicare un filtro sui campi NUMERO_CARRIERA e PROGRESSIVO_ESAME per considerare soltanto i dati valorizzati.

• In seguito è stata creata la tabella temporanea TT_TIR_CFU_TIROCINI_P01 a partire dalla tabella TT_TIR_CFU_TIROCINI_P00. Un altro filtro è stato invece applicato sulla tabella T_OFFERTE_TIROCINI per considerare soltanto quelli di tipo 1, cioè, solo quelli formativi. Grazie a questa prima tabel-

6.3 Sviluppo della Staging Area

la si è quindi riusciti ad ottenere un identificativo univoco dei tirocini (ID_TIROCINIO) indispensabile per la fact table finale.

Sempre questa prima tabella temporanea unita in left join con la tabella T_ESAME1 ha permesso di selezionare i campi come il numero dei crediti e debiti per ogni tirocinio, il voto e altri campi utili per gli step successivi. L’unica logica applicata in questo caso ha riguardato l’anno accademico di svolgimento dei tirocini curricolari che iniziano alla fine di un anno accademico e terminano nel secondo. Infatti in questo caso è stato considerato il mese dell’esame: se compreso negli ultimi tre mesi dell’anno allora vorrà dire che il tirocinio farà riferimento all’anno accademico attuale, altrimenti si considererà l’anno accademico precedente.

Secondo step

Il secondo step ha previsto l’anticipazione di una vista al flusso descritto allo step precedente. Nello specifico, in fase di sviluppo è emersa la presenza, nella tabella T_PERIODI_TIROCINI di date che pur essendo ben formate, erano concettualmente errate (tirocini iniziati nell’anno 0016 per esempio). E’ stato quindi contattato immediatamente il gestore dell’applicativo tirocini per la modifica delle date e per la gestione di vincoli e di controlli direttamente lato applicativo, onde evitare l’ingresso a sistema di date sbagliate, tuttavia per consentire in questa fase una corretta analisi del dato è stata applicata una logica di pulizia dei valori di tipo data confluente nella vista V_T_PERIODI_TIROCINI. La logica che ha portato alla risoluzione di questa problematica sarà affrontata nel paragrafo della pulizia del dato.

Dopo aver creato la vista, sono stati mappati i campi riguardanti le ore svolte del tirocinio, le date di inizio effettivo e previsto e di fine prevista ed effettiva dei tirocini e l’ID del tirocinio. Le logiche applicate a questi campi e visibili in Figura 6.5 hanno permesso di selezionare il minimo tra tutte le date di inizio dei

1Si ricorda che tutti gli estrattori (le tabelle con il prefisso T) caricati in in staging area

sono identici alle tabelle sorgenti sia come meta dati che come numerosità, l’unico cambiamento effettuato è stato sul nome

Figura 6.5: Interfaccia di popolamento della tabella periodi tirocini (secondo step) tirocini previsti ed effettivi così come il massimo tra la data di fine, questo per essere sicuri di riferirsi sempre alle corrette date.

Terzo step

Nel terzo step è stata costruita la tabella TT_TIR_TIROCINI_APPROVATI_01 in cui sono stati selezionati 38 campi attraverso 9 left join tra le tabelle di estrazione (le T_) e le tabelle delle anagrafiche costruite nei primi due step. Tra questi 38 campi troviamo gli ID del tirocinio, dell’offerta del tirocinio, dell’accordo con l’ente esterno e dell’anno accademico, del tutor esterno e della località dove il tirocinio è stato svolto (sia estera che italiana). Altri campi utili sono stati quelli dei flag per la borsa di studio, per la tesi all’estero ma anche lo stato del tirocinio. Infine è stato applicato un filtro sulla tabella T_OFFERTE_TIROCINI per selezionare sia i tirocini di tipo curricolare che quelli formativi, in quanto entrambi saranno oggetto di analisi della fact table finale.

Quarto step

Nel quarto step è stata costruita la tabella TT_TIR_TIROCINI_APPROVATI_02 a partire dalla tabella target del terzo step in left join con le tabelle dell’anagrafica da cui è stata selezionata la matricola dello studente e due viste che hanno permesso di ottenere informazioni inerenti l’ID della sede dove è stato svolto il tirocinio (rispettivamente ID_COMUNE_ITA per la sede italiana, ID_COMUNE_EST per la sede

6.3 Sviluppo della Staging Area

Figura 6.6: Interfaccia di popolamento della tabella temporanea (terzo step)

Figura 6.7: Interfaccia di popolamento della tabella temporanea (quarto step) Quinto step

Nel quinto step sono state create due: S_TIR_TIPO e S_TIR_ARTICOLAZIONE che provenivano rispettivamente dalle tabelle di estrazione T_TIPI_TIROCINIO e T_CONTESTI. Queste due tabelle hanno permesso di ridurre notevolmente il numero di campi di interesse al solo ID, nome e descrizione della tabella in cui erano presenti tutti i contesti (es: i diversi uffici, dipartimenti, commissioni ecc.). Inoltre alla tabella T_TIPI_TIROCINIO è stato applicato un filtro per considerare solo i tirocini di tipo 1 e 2. Per gestire i casi in cui potevano arrivare dalle sorgenti nuovi dati non presenti, state create due procedure (per ognuna delle due tabelle) che aggiungono un fittizio per i 3 campi delle tabelle finali.

Sesto step

In quest’ultimo step, si è infine giunti alla SF_TIR_TIROCINI_APPROVATI (Fi- gura 6.8), costruita con le seguenti operazioni di left join che partivano tutte dai campi della tabella di output (la tabella di sinistra) del quinto step:

• 5 left join verso ognuna di queste dimensioni conformi: L_UOR_STRUTTURA, L_DOC_DOCENTE, L_DID_INDIRIZZO, L_STU_CARRIERA, S_AZI_MAPPING2 • 2 left join verso S_TIR_TIPO ed S_TIR_ARTICOLAZIONE , queste hanno con-

sentito di recuperare l’ID del tipo tirocinio e l’ID dell’articolazione dei tirocini. Si ricorda infatti che i tirocini utili ai fini dell’analisi su questa fact table sono solo quelli di tipo curricolare e formativo.

Figura 6.8: Interfaccia di popolamento della fact table Tirocini Approvati Le logiche applicate in questa fase e in parte visibili in Figura 6.10 sono state:

• Inserimento del fittizio ’-1’ per tutte le chiave esterne (dove è presente il prefisso ID), questo controllo di chiave esterna è stato fatto per impedire la presenza di valori NULL nella fact table

• Conversione dei campi INIZIO_PREVISTO, INIZIO_EFFETTIVO, FINE_PREVISTA, FINE_EFFETTIVA dal formato data al formato numerico ’YYYYMMDD’ e aggiunta del fittizio ’998888’ in caso di presenza del valore NULL

2Si noti la presenza del prefisso L usato nella naming convention per riferisi alle lookup del

data mart, questo fa capire come queste dimensioni siano già state consolidate in precedenza, mentre la tabella con prefisso S è un’eccezione in quanto è una dimensione conforme non presente sul data mart ma su staging area.

6.3 Sviluppo della Staging Area

• Per ottenere l’ID_COMUNE della sede del tirocinio è stata effettuata una verifica su più step, a seconda se si tratta di un comune italiano o straniero. Nel primo caso, se il comune preso a partire dal campo ID_NAZIONE_SEDE_TIRO è nullo allora verrà preso il campo ID_NAZIONE e se questo è uguale a 1 allora vorrà dire che è un comune italiano e l’ID del comune è preso dal campo ID_COMUNE_ITA, se anche quest’ultimo risulta nullo allora viene aggiunto il fittizio ’99999’. Nel caso in cui il comune è straniero (diverso da 1) allora si prende il campo ID_COMUNE_EST, se è nullo allora è aggiunto il fittizio ’0’ • La misura NUM_ORE è calcolata per i tirocini di tipo 2 (curriculare) e se il

valore è 0 o mancante, il valore sarà ottenuto dal campo ORE_TOTALI • La misura CFU_DA_AUTORIZZARE è valorizzata nel caso in cui il campo

ID_TIPO=2 (siamo nel caso di tirocini di tipo curriculare), questa misura è pari al numero dei crediti formativi universitari (CFU) del tirocinio in quanto non ancora autorizzato

• CFU_ACQUISIBILI misura valorizzata nel caso di tirocini curriculari, se il campo CREDITI risulta non presente (siamo nel caso in cui lo studente non ha ancora sostenuto il tirocinio) allora dal campo CFU saranno restituiti i CFU che lo studente deve ancora acquisire

• CFU_ACQUISTI è un’altra misura valorizzata per i tirocini di tipo curriculare. Se il voto dell’esame è superiore o uguale 18, oppure il giudizio non è tra non idoneo, non ammesso respinto, ritirato allora i CFU acquisiti saranno pari alla differenza tra il numero dei crediti totali (campo CREDITI) e quelli di DEBITO. Ad esempio nel caso in cui uno studente ha sostenuto e superato un tirocinio di 2 crediti ma deve acquisirne ancora 6 (su un totale di 8) allora si farà la differenza tra i crediti totali (8) e quelli da acquisire (6). Il risultato sarà il valore di questo campi, vale a dire i crediti acquisiti.

Documenti correlati