QuOnto: Driver per SQLite e
Derby e test su database di
dimensione crescente
A cura di:
Francesco Menniti
Obiettivi Tesina

Realizzare driver di QuOnto (“Querying
Ontologies” ):



Realizzare guide all’uso dei DBMS usati:



Driver per Derby
Driver per SQLite
Guida all’uso di Derby
Guida all’uso di SQLite
Testare i driver

Confronti tra i risultati
07/07/2008
2
Descrizione Derby e SQLite


Derby è un motore Open Source
Database Technology parte dell’ Apache
DB Project
SQLite è una libreria C che implementa
un DBMS SQL incorporabile all'interno di
applicazioni.
07/07/2008
3
Derby: obiettivi, caratteristiche,
compatibilità e note

I principali obiettivi di Derby sono:



Scritto interamente in Java e Open-Source



Conformità agli standard SQL!
Portabilità (JAVA) !
Fornisce supporto JDBC (Java Batabase
Connectivity)
Può funzionare come DB embedded
Deadlock detection, crash recovery, backup
and restore ability, Multi-user, transactions
API
07/07/2008
4
SQLite: obiettivi, caratteristiche,
compatibilità e note

Gli obiettivi di SQLite sono:



Semplicità e leggerezza !
Efficienza su piccoli DB
Portabilità (ANSI-C)





Supporto mediante binding e wrapper
E’ una libreria scritta in C ed è Open-Source
Fornisce supporto JDBC (Java Batabase Connectivity)
Può funzionare come DB embedded
Non completa conformità allo standard SQL


View di sola lettura, non si possono fare insert, delete,
update
Le FOREIGN KEYS sono riconosciute ma non implementate
07/07/2008
5
Strumenti ed interfacce


Sia per Derby che per SQLite esistono
interfacce che permettono di usare tali DB
Derby: (ad es.)



SQuirreLSQL Client
Aqua Data Studio
SQLite: (ad es.)



SharpPlus Sqlite Developer
Liteman
SQLite3 (interfaccia a riga di camando)
07/07/2008
6
Valutazioni finali

Derby:



Completa compatibilità con lo standard SQL
Possibilità di creare un driver per QuOnto
SQLite


Incompleta compatibilità con SQL
Possibilità di creare un driver per QuOnto
07/07/2008
7
Implementazione

Esempi di alcune differenze implementative
tra Derby e SQLite:

Derby:



comando per rimuovere una vista è "DROP VIEW + nomeVista“
Nella UNION il DISTINCT è di default
SQLite:


07/07/2008
il comando per rimuovere una vista è "DROP VIEW IF EXIST +
nomeVista“
Nella UNION il DISTINCT non è di default
8
Implementazione …continua

Esempi di alcune somiglianze implementative
tra Derby e SQLite:

Sia in Derby sia in SQLite l’operatore di
concatenazione è “||”


(String createFunctorConcatStatment(String,String[]))
Sia in Derby sia in SQLite il comando per creare
una vista è "CREATE VIEW " + name + " AS " +
body
07/07/2008
9
Come avviene il test


Stesso computer nelle stesse condizioni per i test
Aboxes di dimensioni differenti (sia per SQLite che
per Derby): 1, 5, 10, 30 università


Realizzate off-line da un tool scritto in Java a partire dalle
Aboxes della LUBM
Output del test





EXPANSION TIME
EVALUATION TIME
TOTAL TIME (tempi rappresentati nei grafici)
NUMERO DI CQs DENTRO LA UCQ ESPANSA
Numero di answers delle query
07/07/2008
10
Query usate nei test

Per descrivere le query sono stati utilizzati i seguenti
fattori:
 Grandezza input: misura la porzione delle istanze delle classi




coinvolte nella query sul totale delle istanze delle classi
(grande se input > 5%)
Selettività: misura come la porzione stimata delle istanze
delle classi coinvolte nella query soddisfano i criteri di
selezione della query (alta se la porzione < 10%)
Complessità: il numero di classi e di proprietà coinvolte nella
query determina la complessità della stessa
Assunzione di gerarchia: considera se informazioni
provenienti da una gerarchia di classi o da una gerarchia di
proprietà sono richieste per raggiungere la risposta completa
(ampia se la profondità della gerarchia > 3)
Assunzione di inferenza logica: considera se l’inferenza
logica è richiesta per raggiungere la completezza della
risposta
07/07/2008
11
Query usate nei test (cont.)
1. {x | GraduateStudent(x) AND takesCourse(x,”Dep0.Univ0/GraduateCourse0”)}
(query con grande input, alta selettività, tale query riguarda una classe e una
proprietà, non assume nessuna informazione gerarchica)
2. {x,y,z | GraduateStudent(x) AND University(y) AND Department(z) AND
subOrganizationOf(z,y) AND memberOf(x,z) AND undergraduateDegreeFrom(x,y)}
(query con pattern triangolare, riguarda 3 classi e tre proprietà, quindi molti join)
5. {x | Person(x) AND memberOf(x,”Dep0.Univ0”)}
(Person e memberOf hanno una gerarchia molto ampia)
6. {x | Student(x)}
(query con grande quantità in input, e una discreta gerarchia determinata da
Student, tale query è relativa ad una sola classe; assume sia la SubClassOf esplicita
della relazioni tra UndergraduateStudent e Student e quella implicita tra
GraduateStudent e Student )
07/07/2008
12
Query usate nei test (cont.)
7. {x,y | Student(x) AND Course(y) AND takesCourse(x,y) AND
teacherOf(“Dep0.Univ0/AssociateProfessor0”,y)}
(query simile alla precedente ma con selettività più alta, infatti è relativa a 2
classi e ad una proprietà)
8. {x,y,z | Student(x) AND Department(y) AND memberOf(x,y) AND
subOrganizationOf(y,”Univ0”) AND emailAddress(x,z)}
(query ancora più complessa della 7 con aggiunta di un’altra proprietà)
13. {x | Person(x) AND hasAlumnus(“Univ0”,x)}
(query di verifica per relazioni inverse)
14. {x | UndergraduateStudent(x)}
(è la query più semplice: grande quantità in input, bassa selettività, assenza
di gerarchia, assenza di inferenza)
07/07/2008
13
Test SQLite
(millisecondi)
Tempo di calcolo della Query
Test SQLitequery
query leggere
TestSQLite
pesanti
450000
7000
400000
6000
350000
5000
300000
Tempo di calcolo 4000
250000
(millisecondi) 3000
200000
150000
2000
100000
1000
50000
0
0
0
0
5
5
10
15
20
25
30
10
15 dati (numero
20 di università)
25
Dimensione
35
30
35
Dimensione dati (numero di università)
Query 1
07/07/2008 Query 11
Query 12
Query 3
Query 4
Query 5
Query 14Query 2
Query 6Query 7Query 8
Query 10
Query 13
Query 9
14
Test Derby
TestDerby
Derby
query
leggere
Test
Derby
query
molto
pesanti
Test
query
pesanti
6000
120000000
250000
5000
100000000
200000
4000
Tempo di calcolo80000000
3000
Tempo
di
Tempo(millisecondi)
di calcolo
calcolo 150000
60000000
2000
(millisecondi)
(millisecondi) 100000
40000000
1000
0
50000
20000000
0
0 0
0 0
5
10
15
20
25
30
(numero
di20
università)
15
20
25
5 5 Dimensione
1010 dati 15
25
Query 1
Query 3
Dimensionedati
dati(numero
(numerodidiuniversità)
università)
Dimensione
Query 4
Query 5
Query 7
Query 10
Query 11
Query 12
Query 13
14 8 QueryQuery
6 9
Query 2 Query Query
07/07/2008
35
30
30
35
35
15
Esempio 1: query 4
{x,y1,y2,y3 | Professor(x) AND worksFor(x,”Dep0.Univ0”) AND name(x,y1) AND
emailAddress(x,y2) AND telephone(x,y3)}
(query con 3 attributi di concetto che interroga su proprietà multiple di una
singola classe, ampia gerarchia per Professor, piccolo input e alta selettività)
Confronto Derby SQLite query 4
6000
5000
4000
Tempo di calcolo
(millisecondi)
Query SQLite
3000
Query Derby
2000
1000
0
07/07/2008
1
5
10
30
Query SQLite
172
469
500
750
Query Derby
4532
5125
5313
5562
Dimensione dati (numero di università)
16
Esempio 2: query 7
{x,y | Student(x) AND Course(y) AND takesCourse(x,y) AND
teacherOf(“Dep0.Univ0/AssociateProfessor0”,y)}
(query con selettività alta, infatti è relativa a 2 classi e ad una proprietà)
Confronto Derby SQLite query 7
8000
6000
Tempo di calcolo
(millisecondi)
Query SQLite
4000
Query Derby
2000
0
07/07/2008
1
5
10
30
Query SQLite
46
78
109
5860
Query Derby
31
438
2594
5029
Dimensione dati (numero di università)
17
Esempio 3: query 12
{x,y | Chair(x) AND Department(y) AND worksFor(x,y) AND
subOrganizationOf(y,”Univ0”)}
(tale query richiede di inferire che professore è una istanza della classe Chair
perché lui o lei sono a capo del dipartimento; query con piccolo input)
Confronto Derby SQLite query 12
8000
6000
Tempo di calcolo
(millisecondi)
Query SQLite
4000
Query Derby
2000
0
07/07/2008
1
5
10
30
Query SQLite
5593
3375
3625
7422
Query Derby
878
625
984
1344
Dimensione dati (numero di università)
18
Esempio 4: query 14
{x | UndergraduateStudent(x)}
(è la query più semplice: grande quantità in input, bassa
selettività, assenza di gerarchia, assenza di inferenza)
Confronto Derby SQLite query 14
30000000
25000000
20000000
Tempo di calcolo
(millisecondi)
Query SQLite
15000000
Query Derby
10000000
5000000
0
07/07/2008
1
5
10
30
Query SQLite
0
0
0
312
Query Derby
14875
262860
1181765
28509265
Dimensione dati (numero di università)
19
Conclusioni

Derby:





Si comporta molto meglio di SQLite per Aboxes di grandi dimensioni
In via generale all’aumentare della dimensione della Abox i tempi di
answering aumentano in modo pressoché lineare o quasi
Estrema lentezza nel fare answering sulle query con grandi quantità di
dati in ingresso e dove ci sono molti elementi da restituire
Più veloce in query dove bisogna effettuare inferenza logica
SQLite:




07/07/2008

si comporta meglio di Derby per Aboxes di dimensioni ridotte
In via generale all’aumentare della dimensione della Abox i tempi di
answering aumentano in modo pressoché lineare o quasi
Limite: massimo numero di termini che possono essere messi in
UNION, UNION ALL, EXCEPT, oppure INTERSECT è determinato da un
parametro fisso e tale parametro di default è settato a 500
Su query con più di qualche attributo di concetto SQLite risulta più
veloce rispetto a Derby indipendentemente dalla dimensione della Abox
considerata
Su query dove bisogna fare inferenza logica SQLite risulta più lento,
20
perché non adotta ottimizzazioni particolari