Metodologia d’importazione dei dati 19 

Le operazioni d’importazione dati richiedono l’esecuzione dei seguenti processi standard e in particolare richiedono la registrazione della fonte dati nel file di definizione data_source.xml.

I componenti principali interessati dalle operazioni d’importazione sono quattro:

• ImportManager; 

• Importer; 

• Parser;  

• Loader.  

L’ImportManager è unico per tutta la fase d’importazione, il suo obiettivo è istanziare, configurare ed eseguire gli Importer dichiarati nel file di configurazione data_sources.xml. Un altro compito dell’ImportManager è creare gli indici sul database alla fine della fase d’importazione.

Per ciascuna fonte dati considerata viene definito un Importer, il cui obiettivo è quello di gestire ed eseguire i Parser e i Loader per tale origine dati.

L'Importer riceve dall’ImportManager l'elenco dei file dati da importare, quindi configura, istanzia e gestisce i Loader. Per ogni file sorgente viene istanziato un Loader che estende il Parser adeguato per ciascun formato di file specifico. Il Loader riceve dal Parser i dati estratti dal file e li memorizza nelle tabelle del database.

I Parser sono classi che si occupano di estrarre i dati dal file; sono presenti vari Parser specifici per ogni tipo di formato di file:

• TabularFileParser: utilizzato per gestire i file di tipo tabellare con separatore di campo singolo;

• TabularFileWithHeaderParser: utilizzato per gestire i file tabellare con separatore di campo singolo aventi header;

• TabularFileParserMultipleSeparator: utilizzato per gestire i file di tipo tabellare con separatori di campo multipli;

• TabularFileWithHeaderParserMultipleSeparator: utilizzato per gestire i file di tipo tabellare con separatori di campo multipli aventi header.

Il Loader estende un Parser in quanto deve implementarne il metodo astratto onNextLine( ) che si occupa di processare la singola riga estratta dal file tabellare. Spesso la distinzione tra Parser e Loader non è ben definita, perché il Loader esegue alcune operazioni di analisi, o viceversa.

Se il Parser per il file dati da importare è già presente all’interno delle classi del framework, esso viene utilizzato, in caso contrario è necessario creare un nuovo Parser. È inoltre necessario implementare l'Importer specifico per ogni sorgente, mentre l’ImportManager non viene modificato.

In figura 9 sono schematizzate le operazioni necessarie a completare il processo di importazione e le interazioni tra i componenti precedentemente descritti.

Operazioni importer

Operazioni loader

Import Manager Importer Loader parser

Configurazione

Escuzione

Esecuzione Per ogni record

del file

Esito parsing file

Inserimento dati in DB

Figura 9 – Scenario di una tipica fase d’importazione 

Inoltre eventuali modifiche strutturali del framework richiederebbero la ridefinizione di tutte le classi implementate in precedenza. Ho, quindi, proceduto con un’analisi approfondita delle procedure presenti all’interno del progetto, con lo scopo di definire un formalismo comune che consentisse di astrarle ulteriormente. Questi aspetti saranno maggiormente approfonditi nel capitolo successivo.

L'importazione è stata progettata per essere molto flessibile e consentire l'aggiunta di nuove fonti in modo semplice e procedurale. Per raggiungere quest’obiettivo, il processo è guidato da un file di configurazione XML, data_sources.xml nel quale è necessario definire l'elenco e tutte le caratteristiche di alto livello delle sorgenti dati da importare e le relazioni che intercorrono tra di esse.

Inoltre, quando viene importata una nuova feature è necessario definirne le caratteristiche all’interno di un altro file XML, feature_definition.xml, andando a specificare se si tratta di entità biomolecolare o di feature biomedica, se è ontologica, se presenta dati di similarità o di history e con quale altre features viene associata.

Ovviamente, la riprogettazione delle procedure automatiche d’importazione, descritta in precedenza, ha richiesto in maniera congiunta una ristrutturazione dei file di configurazione XML, all’interno dei quali deve essere definito tutto quanto risulta essere specifico per la singola sorgente.

Ogni sorgente identifica i propri record attraverso un identificativo; prima di importare i dati all’interno del data warehouse, è necessario verificare che tale ID sia conforme con l’espressione regolare definita all’interno del file di configurazione data_sources.xml. Il componente che si occupa di eseguire il match è definito all’interno della classe RelationshipMatcher.java, in realtà creata per importare le informazioni di associazione tra coppie di features. È stato quindi necessario implementare una nuova classe dedita a validare gli ID importati con le espressioni regolari, mentre la classe RelationshipMatcher.java dovrà occuparsi solamente del popolamento delle tabelle di associazione. Quest’aspetto sarà maggiormente approfondito in seguito nel quinto capitolo.

L’applicazione assegna a ogni “data record” importato un OID univoco rispetto tutte le entries del data warehouse. Per assicurare la correttezza dei dati importati, è stato definito un insieme di regole che consentono al componente ID Matcher di identificare il tipo di dato associato a ciascun ID, in modo da inserire le informazioni nelle tabelle appropriate del data warehouse. Durante questo processo, ogni tupla viene associata con i metadata relativi la propria sorgente dati, in modo da tenere traccia della sua provenienza.

Il processo d’importazione è in grado di completare autonomamente il lavoro nonostante siano presenti nel file anomalie, quali la presenza o la mancanza di colonne rispetto a quanto definito nel file XML, di rilevare (e ricordare) le modifiche e segnalare la presenza di tali anomalie.

Al termine dell’importazione dei dati sono abilitate le chiavi primarie o esterne, i vincoli di unicità e gli indici, in modo da rilevare possibili duplicazioni e incongruenze, e migliorare i tempi di acceso.

L’applicazione prevede che sia abilitato un indice univoco sui campi source_name e source_id delle tabelle importate, in modo da identificare ogni singola tupla fornita da una sorgente. L’importazione della banca dati OMIM è risultata conflittuale con tale definizione. A differenza delle sorgenti finora importate, le quali fornivano per ogni loro identificativo un solo data record, OMIM fornisce diversi file di sorgente all’interno dei quali sono memorizzate tuple riferite allo stesso ID. È stato, quindi, necessario non solo tenere traccia della sorgente che ha fornito l’ID ma anche del file dal quale quest’ultimo è stato estratto, tramite l’aggiunta di un nuovo campo reference_file. Inoltre vi era la necessità di eliminare eventuali tuple duplicate e di aggregare informazioni riguardanti una stessa feature memorizzate in record diversi tra loro. Ciò ha portato alla realizzazione di un nuovo modulo dedito all’eliminazione/merge delle tuple duplicate, le cui scelte procedurali e implementative saranno descritte con maggiore dettaglio nel sesto capitolo.