• Non ci sono risultati.

Esecuzione in memoria centrale

2.2 Hypertree Decomposition

3.1.1 Esecuzione in memoria centrale

L’esecuzione in memoria centrale di DLVDB utilizza il modulo di istanziazione standard di DLV, ma consente di importare i fatti di input tramite viste (anche complesse) su database; inoltre consente di esportare l’output del programma (o solo parti di esso) in tabelle di database esterni.

Questa tipologia di esecuzione supporta pienamente il linguaggio di DLV e tutte le sue estensioni ed ottimizzazioni (ad esempio, vincoli forti e deboli, funzioni esterne, magic-set, ecc.); ci`o `e reso possibile dalla scelta progettuale di non modificare affatto la strategia di valutazione standard implementata in DLV, ma di introdurre semplicemente moduli per l’importazione/esportazione dei dati nel sistema.

L’input e l’output dei dati `e consentito attraverso due comandi built-in nella sintassi di DLV, specificatamente i comandi #import ed #export.

Il comando #import. Legge le tuple da una specificata tabella di un database relazionale e le memorizza come fatti (programma EDB) con un nome di predi- cato p specificato dall’utente. Il nome degli atomi importati `e impostato a p, e definisce una parte del programma EDB. Ulteriori predicati EDB possono essere aggiunti attraverso un file di testo. Dal momento che DLV supporta soltanto numeri interi senza segno e costanti il comando #import prevede un parametro che specifica una conversione di tipo per ogni colonna della tabella. La sintassi del comando #import `e la seguente:

#import(databasename,username,password,query, predname, typeConv). dove:

databasename `e il nome dell’origine dati ODBC per il database di interesse; username identifica l’utente che si connette al database (la stringa deve essere racchiusa da virgolette);

password `e la stringa che specifica la password da utilizzare per l’accesso a da- tabasename (la stringa deve essere racchiusa da virgolette);

query `e una stringa che rappresenta lo statement SQL da eseguire per reperire i dati;

predname indica il nome del predicato nel programma in cui caricare i dati; typeConv specifica le regole di conversione dei dati necessarie per convertire i tipi del database nei tipi di DLV.

La sintassi del parametro typeConv `e la seguente: type : Conv [, Conv]., dove type `e una stringa costante e Conv rappresenta uno tra i seguenti tipi di conversione:

U INT : la colonna `e convertita in un intero senza segno; UT INT: la colonna `e troncata ad un intero senza segno; UR INT: la colonna `e arrotondata ad un intero senza segno;

3.1. DLVDB 43 CONST: la colonna `e convertita in una stringa senza virgolette;

Q CONST: la colonna `e convertita in una stringa con le virgolette.

Il numero di conversioni specificate deve essere identico al numero di colonne della tabella selezionata. Le stringhe convertite in CONST devono essere delle costanti valide di DLV (ad esempio non possono contenere spazi).

Un comando #import carica i dati dalla tabella una riga per volta, tramite la query SQL specificata dall’utente, e crea un atomo per ciascuna tupla sele- zionata. Il nome di ciascun atomo `e impostato a predname ed `e considerato come fatto, cio`e parte del programma EDB. Altri predicati EDB possono esse- re aggiunti attraverso file di testo da inviare a DLV insieme al programma logico. Il comando #export. Permette di esportare l’estensione di un predicato in un an- swer set su un database. Ogni atomo (per quel predicato) che `e vero nell’answer set comporter`a l’inserimento di una corrispondente tupla nel database.

Il comando #export ha due varianti. La prima ha la seguente sintassi: #export(databasename, username, password, predname, tablename). La seconda variante aggiunge un ulteriore parametro “REPLACE where SQL-Condition”, che consente di sostituire le tuple nella tabella in base alla condizione “SQL-Condition”. Ci`o consente di aggiungere le tuple alla tabella senza creare conflitti nel caso in cui tali tuple violerebbero alcuni vincoli di integrit`a del database (ad esempio, duplicare valori per un attributo chiave).

In questo caso:

databasename `e il nome dell’origine dati ODBC per il database di interesse; username identifica l’utente che si connette al database (la stringa deve essere racchiusa da virgolette);

password `e la stringa che specifica la password da utilizzare per l’accesso a da- tabasename (la stringa deve essere racchiusa da virgolette);

predname identifica il nome del predicato da esportare nel database;

tablename indica la tabella in cui i dati devono essere copiati; essa deve essere gi`a presente nel database, con il numero corretto di attributi;

“REPLACE where SQL-Condition” contiene le parole chiave REPLACE e whe- re seguite da una SQL-Condition che indica le tuple che devono essere eliminate prima che avvenga l’esportazione; ci`o pu`o essere utile per eliminare quelle tuple che corrispondono a vincoli di integrit`a violati.

Esempio. Si assuma che un’agenzia di viaggi debba richiedere l’elenco di tutte le destinazioni raggiungibili da una certa compagnia aerea sia con i propri vettori, sia utilizzando accordi di code-share con altre compagnie.

Si supponga inoltre che i voli diretti di ciascuna compagnia siano memo- rizzati in una relazione flight rel(Id, From, To, Company) del database dbAir- ports, mentre gli accordi di code-share siano memorizzati nella relazione codesha- re rel(Company1, Company2, FlightId) di un database esterno dbCommercial; se vi `e un accordo di code-share tra la compagnia c1 e la compagnia c2 per il volo FlightId, vuol dire che FlightId `e effettivamente realizzato tramite vettori di c1, ma pu`o essere considerato anche realizzato da c2.

Infine, si assuma che, per ragioni di sicurezza, non `e consentito alle agenzie di viaggio di accedere ai database dbAirports e dbCommercial e, pertanto, `e

necessario memorizzare il risultato della computazione in una tabella composed CompanyRoutes di un terzo database dbTravelAgency predisposto appositamen- te per le agenzie di viaggio. Il programma datalog che pu`o calcolare tutte le connessioni desiderate `e il seguente:

destinations(From, To, Comp) :- flight(Id, From, To, Comp).

destinations(From, To, Comp) :- flight(Id, From, To, Comp), codeshare(C2, Comp, Id).

destinations(From, To, Comp) :- destinations(From, T2, Comp), destinations (T2, To, Comp).

Per poter utilizzare i dati residenti nei vari database introdotti precedente- mente, `e necessario far corrispondere il predicato flight con la relazione flight rel di dbAirports ed il predicato codeshare con la relazione codeshare rel di dbCom- mercial. Infine, `e necessario far corrispondere il predicato destinations con la relazione composedCompanyRoutes di dbTravelAgency.

Pertanto, i comandi che `e necessario aggiungere al precedente programma datalog sono:

#import(dbAirports,airportUser,airportPasswd , “SELECT FROM flight rel”, flight, “type : U INT, Q CONST, Q CONST, Q CONST” ).

#import(dbCommercial,commUser,commPasswd , “SELECT FROM codesha- re rel”, codeshare, “type : Q CONST, Q CONST, U INT”).

#export(dbTravelAgency, agencyName, agencyPasswd, destinations, composed CompanyRoutes).

Di seguito illustriamo la tipologia di esecuzione direttamente in memoria di massa, con opportuno esempio.