1 / 20

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

QuOnto: Driver per SQLite e Derby e test su database di dimensione crescente. A cura di: Francesco Menniti. Obiettivi Tesina. Realizzare driver di QuOnto (“ Qu erying Onto logies” ): Driver per Derby Driver per SQLite Realizzare guide all’uso dei DBMS usati: Guida all’uso di Derby

ivy
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related