2.2 Hypertree Decomposition
3.1.2 Esecuzione in memoria di massa
Il sistema DLVDB consente la valutazione di programmi logici normali stratifi- cati direttamente in memoria secondaria, con i dati di input (fatti) memorizzati in database eventualmente distribuiti. Il sistema supporta sia la “true negation” che la “negation as failure” e tutti i predicati built-in attualmente previsti in DLV; infine, un aspetto molto importante riguarda il supporto di programmi contenenti funzioni di aggregazione (peraltro gi`a introdotte anche in DLV) ol- tre che l’identificazione di eventuali violazioni di vincoli. Naturalmente, come accade in DLV, ciascun programma deve soddisfare specifiche regole di “safety” al fine di poterne garantire una valutazione corretta. DLVDB`e stato progettato per fornire tre peculiarit`a fondamentali:
• la capacit`a di valutare i programmi logici direttamente in memoria di massa, utilizzando una minima quantit`a di memoria centrale;
• la capacit`a di far corrispondere i predicati presenti nei programmi a viste, anche complesse, su tabelle di basi di dati;
• la possibilit`a di specificare in modo semplice ed intuitivo quali dati devono essere considerati l’input del programma e quali l’output.
3.1. DLVDB 45
Figura 3.1: DLVDB Grammatica per le direttive ausiliarie
Direttive ausiliarie. Come precedentemente evidenziato,DLVDB`e stato proget- tato principalmente per quelle applicazioni che operano su grandi quantit`a di dati memorizzati in database anche distribuiti. Pertanto, esso deve consentire all’utente di specificare una serie di direttive per gestire al meglio l’interazione del sistema con tali database.
Le direttive ausialirie devono essere scritte in un file separato con estensione “typ”. Esse sono suddivise in tre sezioni. La “Init Section” consente di defi- nire il working database, cio`e il database in cui verr`a fatta la valutazione del programma. La “Table Definition Section” consente di specificare i mapping tra i predicati del programma logico e le tabelle del database. Infine, la “Final Section” definisce le direttive per la memorizzazione di alcuni (o tutti) i risultati dell’esecuzione del programma.
La grammatica con cui l’utente pu`o specificare tali direttive `e mostrata in Figura 3.1.
Il comando USEDB (1.) consente di definire la connessione con il working database. Una possibile definizione di tale direttiva, quando il nome del data- base `e MyDatabase (ad esempio su Postgres) e l’accesso `e consentito all’utente scott con password tiger `e il seguente:
USEDB MyDatabase:scott:tiger LIKE POSTGRES. La direttiva USEDB `e l’unica direttiva non opzionale.
La direttiva LIKE `e opzionale ma fortemente raccomandata. Essa con- sente di selezionare lo specifico dialetto SQL ed ottimizzare l’interazione con il working database. Se non `e specificata la direttiva LIKE, vengo utilizzati l’SQL e le funzionalit`a ODBC standard (la compatibilit`a totale `e garantita con POSTGRES).
Attualmente i DBMS totalmente compatibili come working database sono: • POSTGRESQL 8.0 e superiore
• MySQL 5.0 • ORACLE 10g • SQL Server 2005 • DB2 UDB Versione 8.2
La direttiva USE va utilizzata per specificare un mapping tra una tabella che esiste nel database ed il predicato del programma. Si noti che la tabella pu`o essere memorizzata in un database diverso da quello di lavoro (specifi- cando l’opzione [FROM DatabaseName]). Quando viene specificata la clausola [AS (“SQL-Statement”)] la tabella `e aggiornata dal risultato dell’esecuzione di “SQL-Statement’. Nel caso in cui sia necessario aggiungere ad una tabella esistente nuove tuple derivate durante la computazione, `e necessario specifi- care esplicitamente l’operazione di “append” attraverso la direttiva U SE . . . ALLOW AP P EN D.
Con la direttiva CREATE, il sistema crea una tabella e definisce il mapping con il predicato. La tabella verr`a creata nel working database. La direttiva alla riga 8., se presente, stabilisce che la tabella non venga eliminata alla fine della valutazione.
In entrambi i casi `e necessario utilizzare l’opzione MAPTO per collegare la tabella al predicato corrispondente. Il numero di attributi della tabella deve chiaramente essere lo stesso dell’arit`a del predicato a cui essa viene associata. Nella definizione delle tabelle, viene richiesto di specificare i tipi di dato solo per consentire una corretta valutazione dei predicati built-in e delle funzioni di aggregazione.
L’opzione “Query” pu`o essere utilizzata per specificare la tabella che dovr`a memorizzare i risultati dell’eventuale query contenuta nel programma.
Nella “Final Section” la direttiva DBOUTPUT consente di specificare il working database in cui il programma memorizza la computazione. Se `e ne- cessario memorizzare soltanto uno specifico predicato, `e necessario utilizzare la direttiva 11. L’utente pu`o scegliere se appendere i dati (tramite l’opzione AP- PEND) a quelli eventualmente gi`a presenti, o se sovrascriverli (tramite l’opzione OVERWRITE).
E’ importante sottolineare che tali direttive consentono di ottenere un’eleva- ta flessibilit`a nel reperimento dei dati di input e nella memorizzazione dell’out- put.
Esempio. Si consideri lo scenario introdotto nell’esempio precedente dell’esecu- zione in memoria centrale e si supponga che, a causa dell’enorme dimensione dei dati di input, si voglia eseguire il calcolo delle destinazioni raggiungibili di- rettamente in memoria di massa (cio`e direttamente sul database). Per fare ci`o,
3.1. DLVDB 47
Figura 3.2: DLVDB Esempio di direttive ausiliarie `
e necessario utilizzare al posto dei comandi #import ed #export le direttive au- siliarie mostrate in Figura 3.2. Esse consentono di specificare i mapping tra i predicati del programma e le tabelle introdotte precedentemente. E’ importan- te mettere in evidenza il fatto che il sistema potr`a derivare automaticamente dei mapping di default ogniqualvolta ci`o sia possibile (ad esempio quando una relazione ed un predicato hanno lo stesso nome) in modo da semplificare il pi`u possibile la loro definizione.