Ministarstvo Prosvjete

Elektronski Informacioni sistem nauno istraivake djelatnosti

eNID

Prijedlog relacione eme i softverskog rjeenja u domenu: 1) 2) 3) 4) 5) 6) Evidentiranja nauno-istraivakih ustanova Evidentiranja istraivaa Evidentiranje projekata Praenje projekata Dostupnost radova Mogunost brze pretrage dokumenata

Relaciona ema (slika 1) uraena je u Boyce-Codd normalnoj formi*, primjenom grafikog alata MySQL WorkBench. Iako se u veini relacionih ema danas koristi MyISAM** kao mehanizam za skladitenje podataka autor je odabrao InnoDB*** iz razloga referencijalnih veza i strogog integriteta eme relacije.
* Relacija R(A1 , . . . , An ) je u Boyce-Codd-ovoj normalnoj formi (u oznaci BCNF) ako FZ X Y , gde je X, Y {A1 , . . . An } i X Y = , povlai FZ X Ai , za svako i = 1, 2, . . . , n **http://dev.mysql.com/doc/refman/5.0/en/myisam-storage-engine.html ***http://dev.mysql.com/doc/refman/5.0/en/innodb-storage-engine.html

Slika 1 - Entity Relationship Diagram

Indexirane tabele: keyword_table

Radi ubrzanja pretage dokumenata pomou jedne ili vie rijei, entitet rijei (keyword_table_*) podijeljen je u 64 podentiteta numerisanih redom od 0 do 63, odnosno keyword_table_0 do keyword_table_63. Relacija koja spaja rijei i dokumenta (keyword_document_table_*) podijeljena je u 64 podentiteta numerisana redom od 0 do 63, odnosno keyword_document_table_0 do keyword_document_table_63, gdje atribut fk_keyword ukazuje na rije a fk_document na dokument (ili dokumenta) kojem rije pripada.

Brojni sistem osnove 64.

Vrijednost 0 base64: A

1 B 17 R 33 h 49 x

2 C 18 S 34 i 50 y

3 D 19 T 35 j 51 z

4 E 20 U 36 k 52 0

5 F 21 V 37 l 53 1

6 G 22 W 38 m 54 2

7 H 23 X 39 n 55 3

8 I 24 Y 40 o 56 4

9 J 25 Z 41 p 57 5

10 K 26 a 42 q 58 6

11 L 27 b 43 r 59 7

12 M 28 c 44 s 60 8

13 N 29 d 45 t 61 9

14 O 30 e 46 u 62 +

15 P 31 f 47 v 63 /

Vrijednost 16 base64: Q

Vrijednost 32 base64: g

Vrijednost 48 base64: w

Koristimo gusti primarni index, odnosno onaj koji indexira sortiranu kolonu. Gusti index je onaj index za koji vai da za svaku vrijednost atributa u fajlu postoji odgovarajui index.

Proces unoenja
Registrovani istraivai uploaduju dokumenta na server. Podrani formati su *.pdf, *.doc, *.docx i *.ppt. Dokumenta se uvaju u unaprijed odreenom direktorijumu na serveru. Kada se dokument sauva u direktorijumu vri se obrada istog prije unosa podataka u relacionu emu Vri se izvlaenje rijei iz dokumenta pomou jednog od 4 programa za obradu texta zavisno od tipa dokumenta:
http://www.winfield.demon.nl/

1)

antiword za dokumenta tipa *.doc

2) 3) 4)

http://sourceforge.net/projects/docx2txt/

docx2txt za dokumenta tipa *.docx pdfbox za dokumenta tipa *.pdf catdoc za dokumenta tipa *.ppt

http://pdfbox.apache.org/

http://gleyhaser-two.times.lv/boston-ca8/74.html

Proces izvlaenje texta vri se na nain to se sve bjeline (spaces) promijene unaprijed odreenim karakterom (na primjer #) da bi se dobio niz rijei razdvojenih karakterom # gdje se svaka rije pojavljuje najvie jedan put:
$words = array_unique( explode( '#', $processed_document ) );

Unosi se dokument. Pored ostalih atributa dokumenta u tabeli document_table postoji atribut fulltxt_document tipa LONGTEXT gdje se uva dokument koji se sastoji samo od rijei ( $words ). Originalni dokument sa slikama i ostalim vidovima razliitih formatiranja uva se u direktorijumu, kao to je ve navedeno. Posljednja verzija dokumenta je puni naziv dokumenta, dok su ranije verzije, pored punog imena dokumenta numerisane rednim brojem verzije. Zatim se vri unos svake pojedinane rijei akko su zadovoljena oba sljedea uslova: 1) 2) rije mora biti dua od 3 karaktera rije ne smije ve postojati u tabeli keyword_table

Da bi se ispunio drugi uslov potrebno je izvriti upit nad tabelom gdje se uvaju rijei, i tako za svaku rije iz datog dokumenta. Da bi se smanjilo vrijeme procesa provjere 64 puta, indexirana je tabela keyword_table na sljedei nain: Nad datom rijeju odradi se funkcija base64_encode koja vraa datu rije u brojnom sistemu osnove 64. Prvo slovo date rijei se prevodi u dekadni brojni sistem tako da dobijemo broj tabele u kojoj se moe (a i ne mora) nalaziti traena rije. Time smo smanjili pretragu 64 puta, to je u realnom sistemu sa 100 miliona rijei reda veliine milion i po rijei, odnosno veliko smanjenje vremena pretrage.
$base64Chars[ ] = {A, B, C, ..., 9, +, /}; $hash = base64_encode( $keyword ); $table_number = $base64Chars[ $hash[ 0 ] ];

Kao to vidimo proces je veoma jednostavan i to je najvanije izvrava se u operativnoj memoriji raunara bez potrebe dovlaenja podataka sa diska to umnogome ubrzava proces, jer podsjetimo se da operativna memorija radi na nivou nanosekundi (reda 2 do 3 nanosekunde), a vrsti diskovi na nivou milisekundi (reda 20 milisekundi).

Za svaku uneenu rije u tabelu keyword_table_BROJTABELE postoji torka u tabeli keyword_document_table_BROJTABELE koja ukazuje na dokument kojem rije pripada.

Proces pretrage

Kao to smo vidjeli proces unoenja dokumenata je dosta skup. Potrebno je preeljati veliki 1 broj rijei (priblino 64 ukupnog broja svih rijei) svaki put kada se unosi nova rije. Ovakav pristup odabran je iz razloga to se eliminie mogunost pojavljivanja iste rijei vie puta a samim tim se pretraga ubrzava mnogostruko.
U primjeru koji je testirao autor - knjiga Modern Operating Systems 3e (2007) by Andrew Tanenbaum postojalo je 470492 rijei od kojih je ostalo 13482 jedinstvene.

Uvedimo sljedee oznake da bi izraunali cijenu pretrage po odreenoj rijei: (, ) (, ) broj torki veliina jedne torke broj blokova faktor blokiranja, odnosno broj torki koje mogu da stanu u jedan blok broj razliitih atributa u relaciji . broj torki za koje vai (, ) = (,) onosno prosjean broj

pojavljivanja svakog elementa posebno.

Uzmimo sljedei primjer: Neka imamo 100 dokumenata, u prosjeku po 500 strana, gdje strana u prosjeku ima 1000 rijei. Traimo sva dokumenta u kojima se pojavljuje rije test, na sljedei nain: test istestirati testovi protest base64_encode( test ) = dGVzdA 64 = 2910

select * from document_table where id_document in ( select fk_document from keyword_document_table_29 where fk_keyword in ( select id_keyword from keyword_table_29 where word_keyword like '%test%' ) );

= 4 B (veliina tipa int odnosno kljua koji ukazuje na rije - id_keyword) = Cijena upita rauna se kao 2 ( + 1 ) zato to su ispunjeni sljedei uslovi: 1) 2) atribut torke nad kojim se vri pretraga je klju, postoji index.

= 50 000 000
4096 4

= 1024 (podrazumijevana veliina bloka je 4096B odnosno 4KB)

Prvi korak: Umjesto da pretragu vrimo pretragu nad 50000000 rijei, radimo je nad 781250 rijei. slijedi: base64_encode( test ) = dGVzdA 64 = 2910 = 50 000 000 / 64 781250 = = 4096 = 1024 4 781250 = 763 1024

select id_keyword from keyword_table_29 where word_keyword like '%test%'

Imamo = 2 ( + 1 ) = 2 ( 763 + 1 ) = 9.57 = 10, odnosno 10 I/O operacija je potrebno da se izvri upit. Znajui vrijeme rada savremenih vrstih diskova (reda 20 milisekundi) dobijamo vrijeme 200 milisekundi.

Slino se dobija i za:

select fk_document from keyword_document_table_29 where fk_keyword in ( <lista id-jeva vraena za 0.2s> )

s tim to e navedeni upit vratiti vjerovatno vie id-jeva jer je u pitanje tabela vie u vie, pa za jednu vrijednost kljua postoji jedna ili vie referenci ka dokumentima, ali je pravu vrijednost nemogue tano ustanoviti. Pretpostavimo da se traena rije nalazi u 10% dokumenata. Dobijamo:

select * from document_table where id_document in ( <lista id-jeva vraena za 0.26s> );

= 2 ( + 1 ) = 2 ( 7630 + 1 ) = 12.89 = 13 0.26 + 0.2 = 0.46

Dakle Execution Time je reda 0.46s dok je Fetching Time teko ustanoviti zbog veliine konkretnog dokumenta, odnosno atributa fulltxt_document. Navedeni primjer oslikava vrijeme pretrage. Meutim ako uzmemo u obzir da je u knjizi Modern Operating Systems 3rd Edition (2007) od Andrewa Tanenbauma postojalo 470492 rijei od kojih su 13482 bile jedinstvene, dobijamo vrijeme izvravanja 0.013s umjesto 0.46s, odnosno 35 puta manje.