QuOnto: Driver per SQLite e Derby e test su database di dimensione crescente

1. QuOnto: Driver per SQLite e Derby e test su database di dimensione crescente A cura di: Francesco Menniti

2. Obiettivi Tesina • Realizzare driver di QuOnto (“Querying Ontologies” ): • Driver per Derby • Driver per SQLite • Realizzare guide all’uso dei DBMS usati: • Guida all’uso di Derby • Guida all’uso di SQLite • Testare i driver • Confronti tra i risultati

3. 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.

4. Derby: obiettivi, caratteristiche, compatibilità e note • I principali obiettivi di Derby sono: • Conformità agli standard SQL! • Portabilità (JAVA) ! • Scritto interamente in Java e Open-Source • Fornisce supporto JDBC (Java Batabase Connectivity) • Può funzionare come DB embedded • Deadlock detection, crash recovery, backup and restore ability, Multi-user, transactions API

5. 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

6. 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)

7. 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

8. 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: • il comando per rimuovere una vista è "DROP VIEW IF EXIST + nomeVista“ • Nella UNION il DISTINCT non è di default

9. 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

10. 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

11. 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

12. 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 )

13. 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)

14. Test SQLite

15. Test Derby

16. 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à)

17. 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à)

18. 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)

19. Esempio 4: query 14 {x | UndergraduateStudent(x)} (è la query più semplice: grande quantità in input, bassa selettività, assenza di gerarchia, assenza di inferenza)

20. 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: • 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, perché non adotta ottimizzazioni particolari