Tutto il lavoro presentato fino ad ora ´e stato costruito inizialmente come lavoro ”di prova”, accessibile solamente dalla macchina virtuale di cui si ´e parlato nei primi capitoli. Dopo aver terminato la
realizzazione, per rendere il lavoro realmente utilizzabile, ´e stato necessario trasferirlo dalla macchina virtuale al Database ”ufficiale” (pi´u precisamente lo schema SDG del DB ORASTAGE) dal quale sarebbe stato accessibile anche dai membri dello staff FTGM. Per realizzare il trasferimento si ´e pensato di scrivere un’ apposita
procedura in PL/SQL, che non verr´a riportata per intero in quanto ´e costituita da in numero molto elevato di righe di codice.
Sul DB ufficiale le tabelle dell’ SDG sono gi´a presenti ed ´e solo il loro contenuto che deve essere aggiornato, quindi sono state selezionate per il trasferimento solo quelle che avrebbero dovuto effettivamente subire delle modifiche: la T OBJECT che contiene tutti gli oggetti creati o modficati, la T ALBERO LINK poich´e sono stati cambiati i link dei nodi degli alberi, la REL OBJECT PROFILO che associa gli oggetti ai profili degli utenti e la REL MENU FRONTEND nella quale i codici dei pulsanti creati sono associati ai rispettivi men´u padre per costruire la navigazione del sito.
Di seguito un piccolo estratto della procedura dove la query non ´e riportata sempre per motivi di lunghezza:
SET DEFINE OFF; DECLARE
v clob CLOB; BEGIN
v clob:=TO CLOB(’testo della query’);
MERGE INTO SDG.T OBJECT A USING (SELECT
2674 as T OBJECT CODICE,
’P Lab Pisa CUP Massa’ as T OBJECT NOME, ’Lab Pisa con CUP di Massa’ as T OBJECT DESCR, 2 as T TYPE OBJECT CODICE,
#dispatcher/idObject=FC Lab Pisa CUP Massa&idObject=V Lab Pisa CUP Massa& clearParams=S as T OBJECT LINK,
v clob as T OBJECT QUERY, NULL as T OBJECT DB,
NULL as T OBJECT LINK PARAM, 7 as T OBJECT ORDINE,
’coidce Json’ as T OBJECT JSON CONFIG FROM DUAL) B
WHEN NOT MATCHED THEN INSERT (
T OBJECT CODICE, T OBJECT NOME, T OBJECT DESCR, T TYPE OBJECT CODICE, T OBJECT LINK,
T OBJECT QUERY, T OBJECT DB, T OBJECT LINK PARAM, T OBJECT ORDINE, T OBJECT JSON CONFIG)
VALUES (
B.T OBJECT CODICE, B.T OBJECT NOME, B.T OBJECT DESCR,
B.T TYPE OBJECT CODICE, B.T OBJECT LINK, B.T OBJECT QUERY, B.T OBJECT DB,
B.T OBJECT LINK PARAM, B.T OBJECT ORDINE, B.T OBJECT JSON CONFIG)
WHEN MATCHED THEN UPDATE SET
A.T OBJECT NOME = B.T OBJECT NOME, A.T OBJECT DESCR = B.T OBJECT DESCR,
A.T TYPE OBJECT CODICE = B.T TYPE OBJECT CODICE, A.T OBJECT LINK = B.T OBJECT LINK,
A.T OBJECT QUERY = B.T OBJECT QUERY, A.T OBJECT DB = B.T OBJECT DB,
A.T OBJECT LINK PARAM = B.T OBJECT LINK PARAM, A.T OBJECT ORDINE = B.T OBJECT ORDINE,
A.T OBJECT JSON CONFIG = B.T OBJECT JSON CONFIG; .
.
EXCEPTION WHEN OTHERS THEN dbms output.put line(SQLERRM); END;
Il cuore della procedura ´e dato dall’ istruzione MERGE con la quale viene fatto un confronto tra il codice del record che si vuole inserire o modificare e quelli gi´a presenti nella tabella di destinazione: se in questa tabella viene trovato un codice uguale (istruzione WHEN MATCHED) allora il record ´e gi´a presente e viene solo aggiornato (istruzione UPDATE), in caso contrario (WHEN NOT MATCHED) viene aggiunto (istruzione INSERT). La tabella di destinazione viene chiamata A ed appartiene allo schema SDG di ORASTAGE, mentre
quella di partenza viene chiamata B ed ´e ottenuta con una SELECT che preleva, per ciascun record, i valori dei campi da inserire o
modificare. Quindi avremo un’ istruzione MERGE per ogni record ed ´e questo che ha aumentato notevolmente la lunghezza della procedura. E’ possibile ottenere una procedura di questo tipo selezionando una tabella sul Toad e poi scegliendo le opzioni Export Dataset e poi Merge Statement. La sequenza di istruzioni cos´ı ottenuta ´e stata poi leggermente modificata aggiungendo le istruzioni DECLARE, BEGIN, EXCEPTION e END per renderla una vera e propria procedura. La variabile v clob, di tipo CLOB, ´e stata creata per risolvere il problema dell’ inserimento o modifica dei campi i cui valori superavano i 4000 caratteri, ed in particolare questo accadeva per alcune query. Infatti Oracle restituiva un errore quando si andava ad eseguire l’ istruzione SELECT ”testo query” AS T OBJECT QUERY e il testo della query superava il limite imposto. L’ unico modo per aggirare questo problema ´e definire una variabile a cui assegnare il valore del campo e poi effettuare la SELECT sulla variabile invece che direttamente sul valore. Poich´e il numero di record che presentava questo problema era abbastanza esiguo la modifica si ´e potuta fare manualmente andando prima ad individuare i record interessati con la seguente SELECT:
SELECT T OBJECT CODICE FROM T OBJECT WHERE LENGTH(T OBJECT QUERY) > 4000
Nell’ esempio estratto dalla procedura ´e presente solo la tabella T OBJECT, ma analogamente sono state trattate anche le altre tabelle di interesse.
9
Conclusioni
Lo scopo di questo lavoro di tesi ´e stato quello di realizzare, utilizzando la nuova versione del BMF prodotta all’ interno dell’ Unit´a Operativa Sistemi Informativi della FTGM, un Sistema di Governo per Aziende Ospedaliere (in particolare quelle di Pisa e Massa): un applicativo web accessibile dallo staff interessato per la consultazione, inserimento e modifica di dati clinici ed amministrativi con lo scopo primario di effettuare analisi statistiche ed avere uno stumento di supporto alle decisioni aziendali.
La prima fase del progetto ´e stata dedicata alla comprensione delle funzionalit´a, finalit´a e struttura del Sistema di Governo stesso (basandosi sulla versione gi´a esistente), concentrandosi in particolare sul sistema di memorizzazione dei dati che ´e alla base di questo applicativo ed ´e costituito da un Data Warehouse ed alcuni Database. Si ´e potuto cos´ı approfondire la conoscenza di tecnologie che oggi rappresentano un grosso aiuto in ambito clinico e di ricerca. In secondo luogo ´e stato affrontanto il problema della scelta degli strumenti da utilizzare (dal sistema operativo ai software) e la creazione di un ambiente sicuro e predisposto alla costruzione di un applicativo web. Ogni singola operazione svolta ´e stata formativa ed in particolare quelle che sono risultate pi´u problematiche (espansione di una macchina virtuale, gestione delle applicazioni con il Tomcat e l’ import dell’ SDG) hanno sicuramente dato un valore aggiunto alle nozioni che si avevano precedentemente.
Infine nell’ ultima lunga fase si ´e passati alla realizzazione dell’
applicativo vero e proprio, prima studiando gli aspetti teorici e pratici che stanno alla base del nuovo BMF3 (in particolar modo andando a capire i vantaggi introdotti dal formato Json) e successivamente applicandoli all’ SDG con la costruzione dei suoi oggetti e reports. Molto ´e stato appreso o approfondito, ad esempio come gestire tipi di dato complessi messi a disposizione da Oracle, come realizzare delle Sequenze, come leggere un File di Log e ci si ´e scontrati con i problemi che comporta lavorare con una mole di dati immensa (ad esempio come spostarli da un Database all’ altro).
La speranza per il futuro ´e di continuare ad approfondire lo studio di questi strumenti e di poterli applicare, con la consapevolezza che c’ ´e ancora tanto da imparare.
10
Acronimi
BMF- Biomedical Framework DB- Data base
FTGM- Fondazione Toscana Gabriele Monasterio JSON- JavaScript Object Notation
PL/SQL- Procedural Language/ Structured Query Language SDG- Sistema di Governo
11
Bibliografia
Hobbs L., Hillson S., Lawande S., Oracle9iR2 Data Warehousing, Digital Press, 2003
Scalzo B., Oracle DBA Guide to Data Warehousing and Star Schemas, Prentice Hall PTR, 2003
Fondazione Toscana Gabriele Monasterio, sito ufficiale, https://www.ftgm.it/index.php/ftgm
Fondazione Toscana Gabriele Monasterio, Sistema di Governo delle organizzazioni sanitarie,
http://bmf.ftgm.it/doc/2012-FTGM-HMS-SDG-Brochure-ita.pdf Guida Application Server, HTML.it,
http://www.html.it/guide/guida-application-server
Mangione M., Il framework BMF 2.x, Wondermarks Books, 2013 Json, sito ufficiale, http://www.json.org/