PRIMJENA NOSQL BAZA PODATAKA NA SUSTAV ZA UPRAVLJANJE DOKUMENTIMA

Transcription

1 SVEUČILIŠTE U ZAGREBU FAKULTET ORGANIZACIJE I INFORMATIKE V A R A Ţ D I N Mario Peroković PRIMJENA NOSQL BAZA PODATAKA NA SUSTAV ZA UPRAVLJANJE DOKUMENTIMA DIPLOMSKI RAD Varaţdin, 2014.

2 SVEUČILIŠTE U ZAGREBU FAKULTET ORGANIZACIJE I INFORMATIKE V A R A Ţ D I N Mario Peroković Matični broj: 41754/12 R Studij: Baze podataka i baze znanja PRIMJENA NOSQL BAZA PODATAKA NA SUSTAV ZA UPRAVLJANJE DOKUMENTIMA DIPLOMSKI RAD Mentor: Doc.dr.sc. Markus Schatten Varaţdin, srpanj 2014.

3 Sadrţaj 1. Uvod Polustrukturirani model podataka Formalne definicije iz teorije grafova Općenito o polustrukturiranom modelu podataka Prikaz podataka iz drugih vrsta izvora Relacijske baze podataka Objektno orijentirane baze podataka JSON format Tipovi podataka u JSON formatu Primjer podataka u JSON formatu Korištenje JSON Scheme Primjer JSON Scheme Korištenje JSON formata NoSQL sustavi za upravljanje bazama podataka Model podataka Document Model Graph model Key-value model Model upita Document model Graph model Key-value model Konzistentnost Konzistentni sustavi Gotovo konzistentni sustavi Korištenje API-ja Slojevi više razine Komercijalna podrška i snaga zajednice Prikaz korištenja sustava MongoDB Način pohrane podataka Čitanje podataka Modeliranje podataka Struktura dokumenta Povezivanje dokumenata Agregacija podataka Agregirajući cjevovod Map-reduce Agregirajuće funkcije jednostavne svrhe Migracija podataka u MongoDB I

4 5. Usporedba NoSQL i relacijskih baza podataka Razlike u modelu podataka Agregacija podataka Integracija s aplikacijama Sustavi za upravljanje dokumentima Postojeća rješenja na trţištu INoffice EDR Senso Osnovni zahtjevi sustava za upravljanje dokumentima Ostale funkcionalnosti sustava za upravljanje dokumentima Radni proces dokumenta Raspodjela poslova na zaposlenike Praćenje stanja dokumenta u sustavu Autorizacija i sigurnost Ţivotni ciklus dokumenta Praktični rad Osnovni zahtjevi sustava Korisničke priče Ulaz novog dokumenta u sustav OdreĎivanje tipa dokumenta Obrada ulaznih/izlaznih računa Odobravanje ulaznih računa Plaćanje računa Detaljan opis sustava Dijagram slučajeva korištenja Mogući tipovi dokumenata Grupe korisnika Radni procesi OdreĎivanje jedinstvenog identifikatora i tipa dokumenta Ulazni račun Izlazni račun Unos podataka o plaćanju Implementacija sustava Arhitektura sustava Baza podataka Server-side aplikacija Client-side aplikacija Korištenje sustava Instalacija Preduvjeti II

5 Postavljanje baze podataka Postavljanje sustava Prijava u sustav Pregled svih dokumenata Upload novog dokumenta OdreĎivanje jedinstvenog identifikatora dokumenta OdreĎivanje tipa dokumenta Popunjavanje podataka za dokument Odobravanje dokumenta Unos plaćanja za dokument Budući rad i mogući napredak sustava Zaključak Literatura III

6 1. Uvod Tradicionalni način uredskog poslovanja, odnosno upravaljanja dokumentima u poduzećima, se vodio na "ručni" način. Bilo je potrebno ručno evidentirati svaki dokument koji prolazi kroz organizaciju. U taj proces je, izmeďu ostalog, uključeno klasificiranje dokumenata te sastavljanje potrebnih oznaka, kao što su urudţbeni broj i klasifikacijske oznake, na dokumente, a one bi jednoznačno odreďivale taj dokument. S druge strane postoje različiti stupnjevi povjerljivosti, odnosno, različitim tipovima dokumenata su imale pristup različite grupe ljudi. U današnje vrijeme se ovakav pristup uredskom poslovanju čini podosta zastario, jer se korištenjem informacijsko-komunikacijske tehnologije uredsko poslovanje moţe puno lakše obavljati, i to pomoću sustava za upravljanje dokumentima. Sustavi za upravljanje dokumentima uvelike olakšavaju evidenciju i pristup svim dokumentima koji prolaze kroz organizacije. Svaki dokument koji uďe u sustav ima definiran svoj radni proces (eng. workflow), a za svaki zadatak u radnom procesu je zaduţena grupa ljudi ili odreďena osoba. Ovime se postiţe i dozvola pristupa pojedinim dokumentima, jer jedna grupa ljudi moţe imati pristup samo nekoj vrsti dokumenta. Takav sustav bi na jednom mjestu trebao omogućiti klasifikaciju dokumenata, odreďivanje vrste dokumenta te zapravo svaki potreban zadatak koji dokument ima u svojem zadanom radnom procesu. Sustavima za upravljanje dokumentima najbolje odgovaraju NoSQL 1 baze podataka jer upravo one omogućuju pohranjivanje cijelih dokumenata, najčešće u JSON 2 formatu. Prednost takvih baza podataka jest u tome što one nemaju definiranu shemu, za razliku od SQL 3 baza podataka koje imaju shemu i podaci koji se pohranjuju u njih moraju odgovarati definiranoj shemi. U današnje vrijeme relacijske baze podataka sve teţe drţe korak s modernim NoSQL bazama podataka koje omogućuju pohranu ne samo strukturiranih, već i polustrukturiranih i nestrukturiranih podataka. Upravo u tome se moţe primjetiti glavni razlog primjene NoSQL baza podataka na sustave za upravljanje dokumentima, jer se dokumenti u takvim sustavima mogu opisati pomoću polustrukturiranih podataka. 1 NoSQL - Not Only SQL 2 JSON - JavaScript Object Notation 3 SQL - Structured Query Language - upitni jezik u relacijskim bazama podataka 1

7 U nastavku rada, u drugom poglavlju, je dan opis polustrukturiranog modela podataka, u trećem poglavlju JSON format koji se koristi za pohranu dokumenata. U četvrtom poglavlju su prikazani NoSQL sustavi za upravljanje bazama podataka, dok se u petom prikazuje usporedba NoSQL baza podataka i relacijskih baza podataka. U šestom poglavlju je opisano što su to sustavi za upravljanje dokumentima, dok je u sedmom poglavlju prikazan praktični rad. Za izradu praktičnog rada je korištena MongoDB 4 NoSQL baza podataka, sustav za upravljanje bazama podataka otvorenog koda 5 te je meďu vodećim NoSQL bazama podataka. Uz MongoDB sustav za upravljanje bazama podataka je korištena Node.js platforma za izgradnju serverske strane praktičnog rada, dok je prikazana aplikacija izraďena kao singlepage 6 aplikacija korištenjem HTML/CSS/JavaScript skupa tehnologija. U osmom poglavlju je dan zaključak i kritički osvrt autora na tematiku obraďenu radom, a u desetom poglavlju je prikazana korištena literatura. 4 MongoDB (from humongous) - vodeći sustav za upravljanje dokumentima 5 otvoreni kod (eng. open source) - računalni program čiji je izvorni kod dostupan javnosti na uvid, korištenje i izmjenu 6 single-page aplikacija - web aplikacija koja je dohvaćena jednim učitavanjem stranice, dok se pojedini resursi dinamički učitavaju tijekom korištenja aplikacije 2

8 2. Polustrukturirani model podataka Tradicionalne relacijske baze podataka se temelje na starom modelu, relacijskom modelu podataka. Relacijski model podataka je star 40-tak godina i svojevremeno je predstavljao revoluciju u pohrani podataka. U njemu su podaci organizirani u tablice, a one mogu biti povezane. Podaci su zapravo bili čvsto strukturirani. No, u novije vrijeme, odnosno porastom korisnika Interneta, samim time i elektroničkog poslovanja, javlja se potreba za razmjenom sve više podataka preko mreţe, a izvori podataka na internetu su dostupni u velikom broju formata, slijedom čega podaci nisu strukturirani čime se javila potreba za polustrukturiranim modelom podataka. Prema [15], str Formalne definicije iz teorije grafova S obzirom na to da se polustrukturirani model podataka prikazuje u obliku grafova, u nastavku je dano nekoliko formalnih definicija iz područja teorije grafova. Izvor: [15], str 1-2. Definicija 1. - Usmjereni graf Neka V bude skup vrhova, a B V Vskup bridova. Usmjereni graf je G jest par (V, B). Za svaki brid b = (v i, v j ) kažemo da je v i početak, a v j završetak brida. Definicija 2. - Ciklus Ciklus u usmjerenom grafu je svaki put od jednog vrha u taj isti vrh. Graf bez ciklusa se naziva acikličnim grafom. Definicija 3. - Stablo Usmjereni graf (V, B) je stablo ako postoji jedinstveni put od v k do v i za svaki v i V, i k. Svako stablo je ujedno i aciklički graf te ima jedinstven korijen stabla. Definicija 4. - Podatkovni graf Podatkovni graf je usmjereni graf (V, B) čiji su bridovi imenovani, a vrhovi su podatkovni objekti te mogu biti: atomski (listovi) složeni (imaju bridove prema drugim vrhovima) Svaki složeni vrh ima svoj identitet koji je jedinstven u danom podatkovnom grafu. 3

9 2.2. Općenito o polustrukturiranom modelu podataka Polustrukturirani model podataka nema shemu, poput relacijskog, a često ga se opisuje korištenjem termina self-describing 7, što znači da dovoljno govori sam za sebe i shema mu nije potrebna, a isto tako nije potrebno opisivati strukturu podatka. Prema [16], str. 11. Podaci se prikazuju pomoću Object Exchange Model-a (OEM), koji je model za polustrukturirani model podatka temeljen na grafovima. Podaci su u njemu su opisani kao skup objekata, gdje svaki objekt moţe biti jednostavan ili kompleksan - sastoji se od podobjekata. U globalu, podaci su prikazani grafom u kojem su čvorovi objekti, bridovi su imena atributa, a vrijednosti se nalaze u listovima grafa. Prema [17], str. 2. Takav model podataka se moţe prikazati na sljedeći način: { } ime: "Ivan", tel: " ", "ivan@foi.hr" Prikaz koda 1. Primjer polustrukturiranog tipa podatka Moţe se primjetiti da nije bilo potrebno definirati tip podatka za bilo koju vrijednost, kao i to da su podaci vrlo slični formatu JSON, koji je detaljnije opisan u poglavlju 3. Ovo se moţe shvatiti kao lista, tip podataka u mnogim programskim jezicima, koja se sastoji od niza elemenata u obliku ključ: vrijednost. Sasvim je uobičajeno vidjeti i sloţenu vrijednost, kao u prikazu koda 2, gdje je atribut ime sloţen, a sastoji se od još dva atributa. { } ime: { first: "Ivan", last: "Ivić" }, tel: " ", "ivan@foi.hr" Prikaz koda 2. Sloţeniji polustrukturirani tip podatka Kada su podaci organizirani u ovom obliku, moţe ih se prikazati grafički korištenjem teorije grafova, gdje korijen predstavlja objekt, a vrijednosti se nalaze u listovima stabla. Tako se objekt iz prikaza koda 2 moţe grafički prikazati kao na slici 1 na sljedećoj stranici. 7 self-describing - samo opisujući 4

10 Slika 1. Prikaz polustrukturiranog podatka pomoću stabla U ovom obliku moţemo kreirati i niz objekata, kao na prikazu koda 3. { } osoba: { ime: "Ivan", tel: " ", "ivan@foi.hr" }, osoba: { ime: "Franjo", tel: " ", "franjo@foi.hr" } Prikaz koda 3. Niz objekata u polustrukturiranom modelu podataka No, glavna prednost polustrukturiranog tipa podatka je u tome što objekti ne moraju imati iste atribute, niti atributi moraju biti isti tip podatka, što se moţe vidjeti u prikazu koda 4. { } osoba: { ime: "Ivan", tel: " ", "ivan@foi.hr" }, osoba: { ime: { first: "Franjo", last: "Franjić" }, tel: " ", "franjo@foi.hr" } Prikaz koda 4. Razlike u objektima kod polustrukturiranog modela podataka 5

11 2.3. Prikaz podataka iz drugih vrsta izvora Kroz polustrukturirani model podataka moţemo prikazati i strukturirane podatke, stoga će u ovom dijelu rada biti obraďen način na koji moţemo podatke iz relacijskih i objektno orijentiranih baza podataka prikazati kao polustrukturirani model podataka Relacijske baze podataka Shema je u relacijskim bazama podataka opisana kao r1(a, B, C), r2(c, D), gdje su r1 i r2 imena relacija, a A, B, C i C, D nazivi stupaca u te dvije relacije. Uz ovo, trebalo bi definirati i domenu svih stupaca. Primjer (Izvor: [16], str. 14) Dana je struktura i vrijednosti u relacijama kao na slici 2. r1 A B C r2 C D a1 b1 c1 c2 d2 a2 b2 c2 c3 d3 Slika 2. Prikaz relacija i njihovih vrijednosti c4 d4 Podaci iz relacija se mogu prikazati kao polustrukturirani tip podatka, kao u prikazu koda 5. { r1: { } }, r2: { } redak: { { a: a1, b: b1, c: c1 } }, redak: { { a: a2, b: b2, c: c2 } } redak: { { c: c2, d: d2 } }, redak: { { c: c3, d: d3 } }, redak: { { c: c4, d: d4 } } Prikaz koda 5. Prikaz podataka iz relacija u polustrukturiranom obliku Moţe se primjetiti da su vrijednosti redova iz relacija r1 i r2 prikazane kao niz podataka unutar objekata za pojedinu relaciju. 6

12 Isto tako, podaci se mogu prikazati i grafički pomoću stabla, kao na slici 3. Slika 3. Prikaz podataka iz relacija u obliku grafa Objektno orijentirane baze podataka U novije vrijeme se javila potreba za razvijanjem drukčijih baza podataka u odnosu na relacijske, ali da budu takve da se postigne što veći stupanj sličnosti izmeďu same baze podataka i aplikacijske domene. Korištenjem tradicionalnih relacijskih baza podataka se javlja gubljenje semantike od poslovnog procesa do same aplikacije, a ono ima za posljedicu teško prihvaćanje aplikacija od strane korisnika, jer je realizacija aplikacije drugačija od načina na koji se posao odvijao ručno. Izvor: [18], str Primjer Primjer se sastoji od dvije osobe, koje su povezane na način da je osoba imena Franjo roditelj osobi imena Ivan. Podaci su prikazani podatkovnim grafom na slici 4. Slika 4. Podaci iz objektne baze podataka za prikaz u polustrukturiranom obliku 7

13 Veze dijete-od i roditelj-od izmeďu dva objekta su prikazane pomoću operatora "&", koji označava referencu na objekt. Dakle, osoba o1 je dijete od osobe o2. Isti ti podaci se mogu prikazati kao polustrukturirani tip podataka, što je vidljivo u prikazu koda 6. { } osoba: &o1 { ime: "Ivan", dijete-od: &o2 }, osoba: &o2 { ime: "Franjo", prezime: "Franjić", roditelj-od: &o1 } Prikaz koda 6. Podaci iz objektne baze podataka kao polustrukturirani podatak Ovim kratkim pregledom je pojašnjena mogućnost prikazivanja i strukturiranih podataka u obliku polustrukturiranog modela podataka, što se najčešće radi da bi se iskoristile prednosti polustrukturiranog modela podataka. 8

14 3. JSON format JSON (JavaScript Object Notation) je format za razmjenu podataka. Prednost mu je što je čitljiv ljudima, a takoďer je jednostavan računalima za parsiranje i generiranje. JSON je zapravo tekstualni format koji ne ovisi o niti jednom programskom jeziku, no koristi konvencije programskih jezika C obitelji Tipovi podataka u JSON formatu U JSON formatu su dopušteni sljedeći tipovi podataka: Broj - JSON podrţava i cijele i decimalne brojeve, s time da decimalni moraju biti odvojeni točkom String - Niz znakova Boolean - true ili false vrijednosti Niz - sortirani niz čiji elementi mogu biti bilo koji podrţani tip podataka u JSON formatu. Slika 5. Grafički prikaz niza u JSON formatu (Izvor: Objekt - nesortirani niz oblika "name/value" parova. Dijele se vitičastim zagradama, a dvotočka dijeli naziv od vrijednosti svojstva objekta. Slika 6. Grafički prikaz objekta u JSON formatu (Izvor: null - prazna vrijednost, korištenjem ključne riječi null 9

15 3.2. Primjer podataka u JSON formatu U nastavku je dan primjer podataka u JSON formatu. { } "firstname": "Ivan", "lastname": "Ivić", "isalive": true, "age": 25, "height_cm": , "address": { "streetaddress": "Zagrebačka 57", "city": "Varaždin", "postalcode": "42000" }, "phonenumbers": [ { "type": "kucni", "number": " " }, { "type": "mobilni", "number": " " } ] Prikaz koda 7. Primjer podataka u JSON formatu U prikazu podataka je prikazana osoba imena Ivan, prezimena Ivić koja ima 25 godina i visoka je cm. Prikazani su svi mogući tipovi podataka u JSON formatu. Primjer niza je dan u svojstvu phonenumbers, a niz se sastoji od dva objekta od kojih svaki predstavlja jedan broj telefona Korištenje JSON Scheme Kada se koristi JSON format, postoji mogućnost i korištenja JSON Scheme, koja definira strukturu podataka, no to nije obavezno. JSON Schema moţe sluţiti za validaciju podataka te za dokumentaciju oblika podataka. Temelji se na XML Schemi, no za koristi se za JSON format podataka Primjer JSON Scheme U nastavku je dan primjer JSON Scheme. { "$schema": " "name": "Osoba", "type": "object", "properties": { "OIB": { "type": "string", "description": "Identifikator osobe", "required": true, "minlength": 11, "maxlength": 11 }, 10

16 } } "firstname": { "type": "string", "description": "Ime osobe", "required": true }, "lastname": { "type": "string", "description": "Prezime osobe", "required": true }, "godine": { "type": "int", "description": "Starost osobe u godinama", "required": true } Prikaz koda 8. Primjer korištenja JSON Scheme Za podataka OIB korištena su svojstva minlength i maxlength za ograničenje duljine podatka na 11 znakova. Svi podaci su označeni kao obavezni za unos pomoću required svojstva. Za prikazanu JSON Schemu odgovarajući podaci u JSON formatu bi izgledali na sljedeći način: { } "OIB": " ", "firstname": "Ivan", "lastname": "Ivić", "godine": Korištenje JSON formata Prikaz koda 9. Podaci za prikazanu JSON Schemu Korištenje JSON formata se povećalo sve većim korištenjem AJAX (Asynchronous JavaScript and XML) tehnika kod izrade web aplikacija, a u tim aplikacijama se vrlo brzo i efikasno moralo dohvaćati podatke asinkrono. Povećanjem popularnost društvenih mreţa, mnogo se web stranica oslanja na sadrţaj koji je objavljen na raznim društvenim mreţama, stoga se na vrlo lagan način korištenjem jquery biblioteke za JavaScript programski jezik mogu dohvaćati različiti podaci s različitih dostupnih servisa, a ti servisi najčešće podatke vraćaju upravo u JSON formatu. Primjerice, ukoliko se pozove javno dostupan Graph API na Facebook društvenoj mreţi i pretraţuje se tekst "foi.varazdin" API vraća podatke kao u prikazu koda 10 na sljedećoj stranici. 11

17 { "id": " ", "about": "Fakultet organizacije i informatike jedna je od sastavnica Sveučilišta u Zagrebu. Nalazi se u sjevernoj Hrvatskoj, u samome centru prekrasnog baroknog grada Varaždina. ", "category": "Education", "category_list": [ { "id": " ", "name": "Educational Organization" }, { "id": " ", "name": "College & University" } ], "checkins": 1578, "description": "Fakultet organizacije i informatike jedna je od 33 sastavnice Sveučilišta u Zagrebu. Nalazi se u sjevernoj Hrvatskoj, u samome centru prekrasnog baroknog grada Varaždina godine je proslavio 50 godina postojanja. Prvih 12 godina djelovao je kao Visoka ekonomska škola, a od godine djeluje kao fakultet i jedini je koji obrazovnim i znanstvenoistraživačkim programom isključivo pokriva područje informacijskih znanosti, odnosno informatike. U tu svrhu izučavaju se sadržaji iz informacijskih znanosti (informatike) i informacijskih tehnologija i sadržaji iz ekonomije, organizacije, komunikologije i drugih srodnih područja.", "founded": "1962", "hours": { "mon_1_open": "06:00", "mon_1_close": "21:00", "tue_1_open": "06:00", "tue_1_close": "21:00", "wed_1_open": "06:00", "wed_1_close": "21:00", "thu_1_open": "06:00", "thu_1_close": "21:00", "fri_1_open": "06:00", "fri_1_close": "21:00", "sat_1_open": "06:00", "sat_1_close": "21:00" }, "likes": 21985, "link": " "location": { "city": "Varazdin", "country": "Croatia", "latitude": , "longitude": , "street": "Pavlinska 2", "zip": "42000" }, "name": "Faculty of Organization and Informatics", "phone": " ", "talking_about_count": 848, "username": "foi.varazdin", "website": " } Prikaz koda 10. Primjer odgovora javno dostupnog Facebook Graph API-a u JSON formatu 12

18 4. NoSQL sustavi za upravljanje bazama podataka Tradicionalne relacijske baze podataka imaju dugotrajnu poziciju u većini organizacija i to iz dobrih razloga. One podupiru aplikacije koje imaju trenutne poslovne potrebe, a isto tako postoji veliki izbor poduzeća koja izgraďuju i odrţavaju takve sustave. No, u posljednje vrijeme, kao što je u uvodu rečeno, organizacije su u potrazi za alternativama tradicionalnoj relacijskoj infrastrukturi. Postoji nekoliko razloga radi čega je to tako. Prvo, potrebno je izvršavati zadatke koji su iznad postojećih aplikacija i infrastruktura, drugo, organizacije ţele pronaći dovoljno dobre alternative koje će zamijeniti skupi vlasnički softver. I treće, radi se o agilnim metodama razvoja, gdje organizacije traţe brz i agilan razvoj svojih aplikacija. Prema [1]. Tako se grade online aplikacije s novim pristupom u rukovanju podacima nazvanim NoSQL. Nekoliko je razloga zbog kojih je relacijski model podatka nedovoljno dobar za potrebe modernih sustava. Prema [1]: Programeri rade s novim tipovima podataka (strukturirani, polustrukturirani, nestrukturirani, polimorfni...), i to s velikim količinama takvih podataka. Dugotrajni vodopadni model razvoja programskih proizvoda je prošlost. Sve više se koriste agilni pristupi razvoju, što znači da manji timovi rade u kratkotrajnim agilnim sprintevima, gdje se programski proizvod kro praktički svaki tjedan nadograďuje. Objektno orijentirano programiranje je u današnje vrijeme norma, stoga je programerima potreban model podataka koji odgovara upravo tom pristupu. NoSQL sustavi sadrţe nekoliko prednosti, no najčešće je spominjano to da su skalabilniji 8 i pruţaju bolje performanse od relacijskih sustava za upravljanje bazama podataka. NoSQL sustavi bi se mogli podijeliti na 3 osnovne vrste: Document model Graph model Key-value model U nastavku rada će biti opisano 5 bitnih stavki NoSQL sustava za upravljanje bazama podataka, gdje će svaka stavka biti opisana kroz tri vrste takvih sustava. 8 skalabilnost (eng. scalability) - mogućnost sustava da nastavi funkcionirati jednako dobro prilikom promjene opterećenja 13

19 4.1. Model podataka Model podataka je zapravo glavna stvar po kojoj se NoSQL sustavi za upravljanje bazama podataka razlikuju od relacijskih sustava. Postoji više vrsta, no model podataka kod NoSQL baza podataka se moţe podijeliti na tri kategorije: document model, graph model, key-value model. U radu će najviše paţnje biti posvećeno prvo navedenoj vrsti modela podataka, modelu dokumenta, jer je takav model podataka odlično odgovara sustavima za upravljanje dokumentima, jer se u takve sustave pohranjuju cjeli dokumenti Document Model Takozvane baze podataka za pohranu dokumenata (eng. document databases) pohranjuju podatke u obliku dokumenata, za razliku od relacijskih baza podataka koje podatke pohranjuju u redove i stupce unutar tablica. Dokumenti koji se pohranjuju u baze podataka su najčešće strukturirani pomoću JSON formata, vrlo popularnog u posljednje vrijeme, a koji je opisan u prethodnom poglavlju. Takav oblik podataka je podosta intuitivan i prirodan način za modeliranje podataka, a takoďer se moţe preslikati u objektno orijentirano programiranje, gdje bi svaki dokument bio jedan objekt. Svaki dokument se moţe sastojati od jednog ili više atributa, čije vrijednosti mogu biti broj, string, boolean ili niz, kao što je opisano u prethodnom poglavlju. Ono najvaţnije, svi podaci koji su vezani na dokument najčešće se pohranjuju upravo na taj dokument, čime se uvelike smanjuje vrijeme pristupa podacima i gotovo u potpunosti izbacuje potreba za kompleksnim spajanjem tablica. Naravno, ovdje se javlja pitanje aţuriranja podataka, no najčešće se entiteti koji su podloţni promjenama ipak ne spremaju direktno na dokument, već su pohranjeni na posebnom mjestu, a dokument ima spremljenu asocijaciju na takav entitet. Što se sheme tiče, moţe se reći da u ovakvim bazama podataka sheme zapravo i nema, jer svaki dokument moţe sadrţavati različite atribute, čime se postiţe fleksibilnost, a olakšava se modeliranje polustrukturiranih ili polimorfnih tipova podataka. TakoĎer, ovime se uvelike olakšava buduće editiranje aplikacije tijekom razdoblja, jer je vrlo lako dodati neki atribut dokumentu. 14

20 Pohranjivanje podataka u ovakvom obliku ima nekoliko prednosti: [2] Dokumenti su nezavisne jedinice, a omogućuju bolje performanse i distribuciju podataka na više servera, a čuvajući ih i lokalno. Aplikacijska logika je jednostavnija za programiranje. Ne moraju se raditi promjene izmeďu objekata iz baze podataka i upita, već se objekt pretvara direktno u dokument. Nestrukturirani podaci se vrlo lako pohranjuju. S obzirom da dokument moţe sadrţavati sve što aplikacijska logika dopušta, a nema strogo definirane sheme, nestrukturirane dokumente je vrlo lako pohraniti. Pretraţivanje je takoďer vrlo jednostavno kod ovakvih baza podataka, najčešće se podaci mogu pretraţivati prema bilo kojem atributu unutar dokumenta. Kao što je već i rečeno, ovakve baze podataka su vrlo pogodne upravo za sustave za upravljanje dokumentima, gdje se cijeli dokumenti trebaju pohranjivati unutar baze podataka. TakoĎer, moguće ih je primjeniti za širok spektar aplikacija zbog fleksibilnosti modela podataka kao i mogućnosti pretraţivanja dokumenata po bilo kojem atributu. MongoDB sustav za upravljanje bazama podataka pohranjuje dokumente u formatu koji je vrlo sličan JSON-u, a to je BSON 9, što omogućuje laku pohranu podataka. TakoĎer, sustav odgovara modernim objektno orijentiranim metodologijama, a uz to je i lagan (eng. lightweight) i brz. Isto tako, MongoDB podrţava indeksiranje kao i kompleksne upitne mehanizme, a za razliku od drugih sustava koji ne podrţavaju ili je potrebno koristiti dodatne module za uključivanje kompleksnog pretraţivanja. Zbog tih prednosti, upravo je MongoDB sustav za upravljanje dokumentima koji će biti korišten prilikom izrade praktičnog dijela ovog rada Graph model Ovakve baze podataka koriste teoriju grafova i zapravo se koristi struktura grafa za pohranjivanje podataka. Struktura s čvorovima, listovima i svojstvima daje reprezentaciju podataka. Praktički, podaci se modeliraju kao mreţa veza izmeďu elemenata. 9 BSON (Binary JSON), binarna serijalizacija dokumenata u JSON formatu. Izvor: [3]. 15

21 Iako bi ovakav pristup mogao biti malo teţi za shvaćanje zbog svoje kompleksnosti i neintuitivnosti, moţe se primjeniti na veliki broj aplikacija. Upravo zbog svoje strukture mreţe, sustavi društvenih mreţa su vrlo dobar primjer korištenja ovakvih baza podataka Key-value model Iz perspektive modela podataka, ovakav način pohrane podataka je praktički najjednostavnija vrsta NoSQL baza podataka. Svaka stavka unutar baze podataka je pohranjena u obliku ključ:vrijednost. No, glavni nedostatak ovoga je to što se podaci mogu pretraţivati samo preko ključa, ali moţe biti koristan za reprezentaciju polimorfnih i nestrukturiranih podataka. Ovakve baze podataka se mogu primjeniti na manji broj aplikacija, i to na one kod kojih se podaci pretraţuju samo po jednoj vrijednosti ključa Model upita S obzirom na različitost aplikacija, svaka od njih ima neke svoje zahtjeve što se tiče pretraţivanja podataka. Ponekad je dovoljno da se koristi osnovni model upita, iz razloga što će se podaci dohvaćati isključivo prema primarnom ključu. No, kod većine aplikacija je potrebna mogućnost pretraţivanja podataka prema nekoliko vrijednosti u zapisu. Primjerice, ukoliko se u bazu podataka pohranjuju informacije o studentima na fakultetu, jasno je da će se pretraţivati najćešće studenti, no isto tako će se vrlo vjerojatno podaci agregirati 10 prema upisanim kolegijima ili smjerovima Document model Već je ranije spomenuto da baze podataka za pohranu dokumenata omogućuju pretraţivanje prema bilo kojem atributu na dokumentu. MongoDB sustav, primjerice, pruţa niz opcija indeksiranja za optimizaciju upita na bazu podataka, a uključuje unique, tekst, geoprostorne i druge vrste indeksa. Uz to, sustavi najčešće pruţaju neku vrstu okvira za agregaciju podataka i to za analize u realnom vremenu, kao i naprednu MapReduce 11 implementaciju za sofisticirane analize. Detaljniji prikaz upitnih mehanizama u sustavima za pohranu dokumenata će biti prikazan nešto kasnije, kada će se opisivati korištenje MongoDB sustava. 10 agregacija (eng. aggregation) - proces u kojem su informacije grupirane prema odreďenoj vrijednosti ili prikazane u formi za pregled, a u svrhu statističke prezenacije podataka 11 Map-reduce - paradigma za procesiranje podataka u korisne agregirane rezultate.izvor: [4]. Detaljnije u poglavlju

22 Graph model Kod ovakvih sustava veze izmeďu podataka mogu biti korištene za donošenje jednostavnih i sloţenih zaključaka o podacima, a usto je analiza povezanosti podataka vrlo efikasna zbog same strukture podataka. No, ostale vrste analiza i nisu efikasne zbog istog razloga, načina na koji su podaci povezani Key-value model Kao što je već spomenuto, kod ključ: vrijednost načina pohrane podataka se podaci dohvaćaju pretraţivanjem samo po primarnom ključu. Za pretraţivanje ostalih podataka, korisnici bi zapravo trebali sami voditi računa o sekundarnim indeksima koji bi olakšali i ubrzali takvo pretraţivanje. Što se aţuriranja tiče, ovdje su potrebna dva koraka. Prvo je potrebno pronaći odreďeni zapis prema primarnom ključu, a nakon toga ga aţurirati. Aţuriranje je najčešće izvedeno kao kompletno prepisivanje vrijednosti, bez obzira na to što su promijenjeni samo mali dijelovi iste Konzistentnost NoSQL sustavi za upravljanje bazama podataka najčešće sadrţe nekoliko kopija podataka i to zbog dostupnosti istih kao i skalabilnosti cijelog sustava. Zbog toga što najčešće imaju nekoliko kopija podataka NoSQL sustavi se mogu podijeliti u dvije skupine, i to: konzistentni, i gotovo konzistentni (eng. eventually consistent). Konzistentni sustavi bi bili takvi da nakon što se podaci zapišu u bazu podataka, odmah su vidljivi u danim upitima, dok kod gotovo konzistentnih takve promjene nisu vidljive istoga trenutka, ali eventualno će prikazati točne podatke Konzistentni sustavi Različite aplikacije imaju različite zahtjeve što se tiče konzistentnosti podataka, no najčešće su zahtjevi aplikacije takvi da podaci moraju biti konzistentni kroz svo vrijeme korištenja iste. Nekako se ovakav pristup nameće kao prirodan i logičan. Većina NoSQL sustava za upravljanje bazama podataka je konzistentna, sve aktivnosti nad podacima obavlja nad glavnom kopijom podataka. Eventualno, moguće je kod izvršavanja upita naznačiti da se podaci ţele dohvatiti iz neke druge kopije podataka, čime sustav zapravo postaje gotovo konzistentan. 17

23 Gotovo konzistentni sustavi Kod gotovo konzistentnih sustava postoji vremenski period kada podaci izmeďu različitih kopija podataka nisu u potpunosti sinkronizirani, što u velikoj većini slučajeva i nije baš prihvatljivo, radi čega su ovakvi sustavi prihvatljivi za aplikacije čiji se podaci ne mijenjaju često (ili tzv. read-only aplikacije) ili povijesne arhive. S druge strane, moţe biti pogodno i za aplikacije koje imaju veliku količinu pisanja podataka, a podaci će se čitati kasnije u odreďenom trenutku vremena (najčešće su to sustavi za biljeţenje aktivnosti, eng. logs). Ono što je vrlo bitno je to da ovakvi sustavi moraju imati način na koji će riješiti eventualne konflikte izmeďu različitih kopija podataka. To je najviše izraţeno kod sustava u kojima se podaci zapisuju na različite kopije podataka, pa se zapravo ne zna koji podatak je istinit. Neki sustavi, kao CouchDB, koriste korisnika da pomogne u rješavanju ovakvih situacija Korištenje API-ja Kao što nam je poznato, API 12 se koristi za komuniciranje sa nekim sustavom. Najčešće je potrebno API-ju proslijediti odreďene parametre, a API nam vraća rezultat svoje obrade. U poglavlju o JSON formatu je bilo prikazano kako se koristi Facebookov Graph API. Kod NoSQL baza podataka ne postoji standard za dizajniranje sučelja. Svaki sustav je graďen pomoću različitih tehnologija i sve one omogućuju komuniciranje s NoSQL bazom podataka Slojevi više razine Za veliku većinu NoSQL sustava su napravljeni pristupni slojevi više razine, pomoću kojih je olakšan pristup do podataka u bazi. Takve slojeve izraďuju ljudi koji su eksperti u odreďenim programskim jezicima i koji znaju kako ostali programeri koriste taj isti programski jezik. Programeri najčešće koriste ovakve slojeve zbog toga što im je puno lakše naučiti korištenje istih, jer su već upoznati s sintaksom i funkcioniranjem programskog jezika. Korištenje istih uvelike smanjuje vrijeme koje je potrebno za izgradnju programskih sustava. 12 API - aplikacijsko programsko sučelje (eng. application programming interface) - sučelje koje odreďuje kako bi komponente računalnih sustava trebale djelovati jedne izmeďu drugih 18

24 4.5. Komercijalna podrška i snaga zajednice Prilikom izrade aplikacija, odabir sustava za upravljanje bazama podataka je moţda čak i najvaţnija stavka. Jednom kad se aplikacija izgradi nad nekim sustavom za upravljanje bazama podataka, preskupo je i podosta izazovno migrirati podatke na drugi sustav za upravljanje bazama podataka. NoSQL sustavi su relativno novi i trenutno ima poveći broj opcija, no najvjerojatnije će se kroz vrijeme isprofilirati nekoliko najvećih sustava. Zbog velikog broja prednosti, oko NoSQL pristupa u pohrani podataka se okupila velika zajednica, što je dobar znak. Kada sustav za upravljanje bazama podataka ima jaku zajednicu, korisnicima je lakše pronaći programere koji su dobro upoznati s tehnologijom. Isto tako, zbog veličine zajednice, puno toga se dijeli izmeďu ljudi, primjerice dokumentacija, informacije i primjeri implementacija specifičnih problema Prikaz korištenja sustava MongoDB Dosad su bile prikazane osnovne stavke NoSQL sustava, a u nastavku će biti opisan sustav MongoDB, koji je korišten i za izradu praktičnog dijela ovog rada. MongoDB je sustav za pohranu dokumenata otvorenog koda i vodeći NoSQL sustav za upravljanje bazama podataka koji je dizajniran upravo na način na koji se aplikacije izgraďuju i odrţavaju u današnje vrijeme, čime pomaţe organizacijama i njihovim računalnim sustavima da budu agilniji i skalabilniji Način pohrane podataka Podaci se u MongoDB sustavu pohranjuju u obliku dokumenata u BSON formatu, kao što je već ranije navedeno. Dokumenti u takvom obliku su analogni strukturama objekata u objektno orijentiranim programskim jezicima. { } "OIB": " ", "firstname": "Ivan", "lastname": "Ivić", "hobiji": [ "tenis", "vinogradarstvo" ] Prikaz koda 11. Dokument u MongoDB sustavu 19

25 Svi dokumenti u sustavu se pohranjuju unutar collectiona 13. Collection je grupa dokumenta koji imaju neka svojstva zajednička. Collection zapravo moţe odgovarati tablicama u relacijskim bazama podataka. Grafički prikaz collectiona je dan na slici 7. Slika 7. Grafički prikaz collection-a (Izvor: Čitanje podataka Upiti nam sluţe da bi dohvatili jedan ili više podataka iz baze, prema odreďenim kriterijima. Upit u MongoDB sustavu za izvor moţe imati jedan collection dokumenata. Upit moţe sadrţavati detaljne uvjete, i dokumenti koji te uvjete zadovoljavaju se vraćaju korisniku. TakoĎer, upiti mogu sadrţavati limite te sortiranja. Za upite se u MongoDB sustavu koristi db.collection.find() funkcija. Ta funkcija kao parametar prima u uvjet i projekcije 14. U nastavku je na slici 8 prikazan jednostavan upit koji pretraţuje "users" collection. Slika 8. Jednostavan upit u MongoDB sustavu (Izvor: Upit zahtijeva samo 5 zapisa pomoću metode limit(5). Analogno tome, isti upit bi u relacijskim bazama podataka izgledao kao na slici 9. Slika 9. Upit sa slike 4 u relacijskim bazama podataka (Izvor: 13 Zbog nepraktičnosti hrvatskog prijevoda riječi collection, u radu će se koristiti izvorna riječ na engleskom jeziku. 14 projekcije (eng. projections) - označavanje atributa za koje ţelimo da nam se vrate iz baze podataka 20

26 Na slici 10 se nalazi grafički prikaz upita nad kojim je primjenjeno sortiranje. Slika 10. Grafički prikaz upita u MongoDB sustavu s primjenom sortiranja (Izvor: Sa slike je vidljivo da je kao izvor podataka dan "users" collection. Pomoću operatora $gt 15 se ţele dohvatiti samo korisnici koji imaju više od 18 godina. Nadalje, primjenjena je funkcija sortiranja, a pridjeljen joj je parametar "1" koji označava uzlazno sortiranje Modeliranje podataka Podaci se kod NoSQL baza podataka modeliraju nešto drugačije nego što je to kod relacijskih baza podataka. U NoSQL bazama podataka nema sheme, odnosno collection ne zahtijeva točnu strukturu dokumenta koji se u nju pohranjuje. Naravno, dokumenti koji se pohranjuju unutar istog collection-a, imaju sličnu strukturu, jer predstavljaju slične entitete. Najveći izazov kod modeliranja podataka je balansiranje potreba aplikacije, performansi i karakteristika sustava za upravljanje bazama podataka koji se koristi, kao i načine dohvaćanja podataka Struktura dokumenta Najveća odluka kod dizajniranja modela podataka je u načinu na koji će dokumenti biti povezani jedni s drugima. Postoje dva načina povezivanja, i to su reference i ugrađeni dokumenti. Prema [4]. Reference Kod ovog načina povezivanja dokumenata, veze izmeďu podataka se ostvaruju uključivanje poveznica ili referenci iz jednog dokumenta u drugi. Ovo je tzv. normalizirani model 15 $gt - operator "veće od" (eng. greater than) 21

27 podataka, što je na neki način slično vanjskom ključu u relacijskim bazama podataka. Primjer ovakvog povezivanja podataka se nalazi na slici 11. Slika 11. Korištenje reference za povezivanje dokumenata (Izvor: Sa slike je vidljivo da contact dokument i access dokument imaju referencu prema user dokumentu. Normalizirani modeli podataka bi se u pravilu trebali koristiti: Prema [4]. kada bi ugraďivanje dokumenata rezultirali dupliciranjem podataka, a ne bi dalo znatne razlike u performansama kod čitanja podataka, kada se ţele prikazati sloţenije više-više veze, kada se modeliraju veliki hijerarhijski skupovi podataka. Korištenjem referenci se postiţe veća fleksibilnost nego korištenje ugraďivanja dokumenata, ali aplikacije tada moraju izvršavati više upita prema bazi podataka da bi dohvatile sve podatke. Ugrađeni dokumenti UgraĎivanjem dokumenata se veze izmeďu podataka spremaju unutar jednog dokumenta. U pravilu, to izgleda kao "pod-dokument" unutar dokumenta. Takav model podataka se naziva denormalizirani model podataka. On dozvoljava aplikacijama da dohvate i manipuliraju podacima kroz korištenje samo jednog poziva prema bazi podataka. Na slici 12 na sljedećoj stranici je prikazan primjer ovakvog povezivanja podataka. 22

28 Slika 12. UgraĎivanje dokumenata (Izvor: Sa slike je vidljivo da su contact i access dokumenti ugraďeni unutar user dokumenta, umjesto da sadrţavaju referencu prema istom. Rezultat ovakvog povezivanja je manji broj upita koji se moraju uputiti prema bazi podataka da bi se izvršile odreďene radnje. UgraĎivanje dokumenata bi se trebalo koristiti: Prema[4]. kada postoji veza sadržavanja 16 kod veza jedan-više. Entiteti koji su na strani više se ubacuju unutar entiteta na strani jedan, najčešće u obliku niza UgraĎivanje dokumenata ima prednost kod čitanja podataka iz baze, jer se svi podaci dohvate kroz samo jedan upit prema bazi podataka. TakoĎer, aţuriranje podataka koji su povezani na taj dokument se takoďer moţe obaviti kroz jednu operaciju. No, postoje i loše strane korištenja ovog pristupa. U onim situacijama u kojima dokumenti rastu nakon kreiranja, odnosno podloţni su promjenama, mogu utjecati na performanse kod zapisivanja podataka i dovesti do fragmentacije podataka. Zbog toga bi se u pravilu trebalo izbjegavati veliko aţuriranje dokumenata. 16 veza sadrţavanja (eng. contains) - javlja se kod veza jedan - jedan, što praktički znači da jedan entitet sadrţava drugi entitet. 23

29 Povezivanje dokumenata Veza jedan-jedan uz ugrađivanje dokumenata Primjer će izgledati ovako: Osoba ima adresu na kojoj ţivi. S obzirom na to da kada god dohvaćamo podatke o osobi iz baze podataka, najčešće će nam trebati i njegova adresa. Radi toga, korištenje referenci kod veze jedan-jedan nije najprihvatljivija opcije jer za dohvaćanje podataka nam trebaju dva upita prema bazi. Radi toga koristimo ugraďivanje dokumenata i dokument osoba izgleda kao u prikazu koda 12. { } _id: "ivan", OIB: " ", firstname: "Ivan", lastname: "Ivić", address: { street: "Zagrebačka 57", city: "Varaždin", zip: "42000", country: "Hrvatska" } Prikaz koda 12. Primjer veze jedan-jedan Korištenjem ugraďenih informacija o adresi za osobu, sve podatke moţemo dohvatiti kroz jedan upit prema bazi podataka. Veza jedan-više uz ugrađivanje dokumenata Iskoristit će se isti primjer uz sitnu promjenu. Recimo da osoba ima još jednu adresu, jedna odgovara prebivalištu, ali iz nekog razloga osoba trenutno ima boravište na drugoj adresi. U takvom slučaju, uz korištenje ugraďivanja dokumenata, dokument osoba izgleda kao u prikazu koda 13. { } _id: "ivan", OIB: " ", firstname: "Ivan", lastname: "Ivić", addresses: [{ street: "Zagrebačka 57", city: "Varaždin", zip: "42000" }, { street: "Varaždinska 75", city: "Zagreb", zip: "10000" }] Prikaz koda 13. Primjer veze jedan-više uz ugraďivanje dokumenata 24

30 I ovdje je prednost ta da ukoliko dohvaćamo sve informacije o osobi, to ćemo moći napraviti korištenjem samo jednog upita prema bazi podataka. Veza jedan-više uz korištenje referenci Koristit će se sljedeći primjer. Prate se podaci u knjiţnici, i za svaku knjigu se biljeţi i izdavač. Radi pojednostavljenja, prikazati će se dvije knjige, kao na prikazu koda 14. { }, { } title: "Uvod u SQL", author: "Rabuzin, Kornelije", pages: 216, year: 2011, language: "hr", publisher: { name: "Fakultet organizacije i informatike", city: "Varaždin" } title: "SQL - napredne teme", author: "Rabuzin, Kornelije", pages: 216, year: 2014, language: "hr", publisher: { name: "Fakultet organizacije i informatike", city: "Varaždin" } Prikaz koda 14. Zapis knjiga pomoću ugraďivanja dokumenata Ovdje je očito da se podaci o izdavaču ponavljaju, što bi u budućnosti mogla biti znatna količina ponovljenih podataka. Rješenje bi se moglo napraviti na sljedeći način. Izdavača izdvojiti u poseban dokument, a na dokumente knjiga zapisati samo identifikator izdavača, kao na prikazu koda 15. { }, { } title: "Uvod u SQL", author: "Rabuzin, Kornelije", pages: 216, year: 2011, language: "hr", publisher_id: "foi" title: "SQL - napredne teme", author: "Rabuzin, Kornelije", pages: 216, year: 2014, language: "hr", publisher_id: "foi" Prikaz koda 15. Primjer veze jedan-više korištenjem referenci { _id: "foi", name: "Fakultet organizacije i informatike", city: "Varaždin" } 25

31 Agregacija podataka Operacije agregiranja procesiraju zapise podataka i vraćaju izračunate rezultate. Dakle, moţe se reći da takve funkcije obraďuju podatke i prikazuju rezultat u potrebnom obliku, što znači da se koriste za izradu izvještaja i statističkih prikaza podataka. Agregirajuće operacije koriste collection-e i dokumente kao ulaz i izlaz, poput upita. MongoDB pruţa tri načina za izvršavanje agregacije podataka: Prema [4]. agregirajući cjevovod (eng. aggregation pipeline) map-reduce agregirajuće funkcije jednostavne svrhe Agregirajući cjevovod Agregirajući cjevodod je okvir za agregaciju podataka kod kojeg dokumenti ulaze u transformacije koje sadrţe više koraka. Agregirajući cjevovod je zapravo alternativa mapreduce funkciji, i moţe biti jednostavniji za korištenje. Na slici 13 je prikazan primjer korištenja agregirajućeg cjevovoda. Slika 13. Korištenje agregirajućeg cjevovoda (Izvor: Ovakva operacija ima dva koraka, $match i $group. Vidljivo je da se u $match koraku pretraţuju svi zapisi koji imaju status "A", dok se u $group koraku dobiveni rezultati iz 26

32 prethodnog koraka grupiraju prema "cust_id" zapisu, i izračunava se zbroj vrijednosti "amount" atributa grupiranih zapisa te se sprema u atribut "total". Ovakav pristup se moţe usporediti s korištenjem cjevovoda u UNIX-like operacijskim sustavima (korištenje " "), za korištenje više operacija, gdje rezultat jedne operacije postaje ulazni podatak u drugu operaciju. $match i $group su samo neki od operatora koji se mogu koristiti kod agregirajućeg cjevovoda, preostali su: 17 $project - preoblikuje stream dokumenta $redact - ograničava sadrţaj vraćenog dokumenta na razinu atributa $limit - ograničava broj dokumenata u agregirajućem cjevovodu $skip - prekače specificiran broj dokumenata i vraća ostale $unwind - uzima niz dokumenata i vraća ih kao stream dokumenata $sort - uzima sve dokumente i vraća ih sortirane prema odreďenom atributu $geonear - vraća sortiran niz dokumenata prema udaljenosti od geoprostorne točke $out - zapisuje dokumente iz cjevovoda u collection. Ako se koristi, $out mora biti zadnji operator u cjevovodu Map-reduce Map-reduce je paradigma za procesiranje podataka u korisne agregirane rezultate. Na slici 14 na sljedećoj stranici je prikazano korištenje map-reduce operacije u MongoDB sustavu za upravljanje bazama podataka. 17 Operatori agregirajućeg cjevovoda (Izvor: 27

33 Slika 14. Korištenje map-reduce operacije (Izvor: U ovom primjeru je vidljivo da sustav primjenjuje map funkciju na svaki dokument koji zadovoljava upit (upit vraća sve dokumente koji imaju status "A"). Map funkcija vraća key: value parove. Za one ključeve koji imaju više vrijednosti, sustav primjenjuje i reduce funkciju, koja u ovom primjeru daje zbroj svih vrijednosti. Reduce funkcija prikuplja i saţima i agregira podatke dobivene kroz map funkciju. Na kraju, sustav sprema rezultate u "order_totals" collection. Opcionalno je korištenje i finalize funkcije, koja rezultate reduce funkcije dodatno moţe saţeti. Generalno, map-reduce funkcije u MongoDB sustavu mogu kao ulaz primati dokumente iz jednog collectiona i napraviti bilo kakva sortiranja ili limite prije započimanja map funkcije. Map-reduce moţe vratiti rezultat kao dokument, ili moţe zapisati rezultat u collection, kao u primjeru. 28

34 Agregirajuće funkcije jednostavne svrhe MongoDB sustav pruţa niz agregirajućih funkcija koje izvršavaju jednostavne operacije nad podacima. Ovakve operacije su u usporedbi s agregirajućim cjevovodom i map-reduce funkcijom limitirane, no ponekad su nam baš potrebne jednostavne operacije nad skupom podataka. Count Korištenjem count funkcije, sustav vraća broj dokumenata koji odgovaraju zadanom upitu. U prikazu koda 16 je dan primjer korištenja count funkcije. { a: 1, b: 0 }, { a: 1, b: 1 }, { a: 1, b: 4 }, { a: 2, b: 2 } db.zapisi.count() // vraća 4 db.zapisi.count( { a: 1 } ) // vraća 3 Prikaz koda 16. Korištenje count funkcije Recimo da imamo collection naziva zapisi koji se sastoji od samo 4 zapisa. U prvom korištenju count funkcije, kada joj nije proslijeďen nikakav upit, ona vraća ukupan broj zapisa u collection-u nad kojim je pozvana. U drugom slučaju, kao upit je upisano "{ a: 1}", funkcija vraća broj 3, što je broj zapisa koji kao vrijednost atributa "a" imaju "1". Distinct Distinct operacija uzima u obzir dokumenate koji odgovaraju proslijeďenom upitu, i vraća sve jedinstvene vrijednosti za atribut proslijeďen u upitu. Primjer se nalazi u prikazu koda 17. { a: 1, b: 0 }, { a: 1, b: 1 }, { a: 1, b: 1 }, { a: 1, b: 4 }, { a: 2, b: 2 }, { a: 2, b: 2 } db.zapisi.distinct( "b" ) // [ 0, 1, 4, 2 ] Prikaz koda 17. Korištenje distinct funkcije U collection zapisi su upisana tri zapisa, i nakon toga je pozvana distinct funkcija i kao parametar joj je proslijeďen "b" atribut. Rezultat funkcije je niz jedinstvenih vrijednosti tog atributa unutar collection-a. 29

35 Group Operacija group uzima broj dokumenata koji zadovoljavaju proslijeďeni upit, i nakon toga grupira dokumente prema vrijednosti atributa proslijeďenog u upitu, te ih vraća u obliku niza. Primjer je dan u prikazu koda 18. { a: 1, b: 4 }, { a: 1, b: 2 }, { a: 1, b: 4 }, { a: 2, b: 3 }, { a: 2, b: 1 }, { a: 1, b: 5 }, { a: 4, b: 4 } db.zapisi.group({ key: { a: 1 }, cond: { a: { $lt: 3 } }, reduce: function( cur, result ) { result.count += cur.b }, initial: { count: 0 } }) // rezultat [ { a: 1, count: 15 }, { a: 2, count: 4 } ] Prikaz koda 18. Korištenje group funkcije U početku su prikazani zapisi koji se nalaze u zapisi collection-u. Nakon toga je nad njime pozvana group funkcija, kojoj su proslijeďeni neki parametri iz razloga što su obavezni. key - atribut prema kojem će se grupirati, cond - uvjet koji dokument mora zadovoljiti da bi ušao u group funkciju. (U primjeru su to svi dokumenti čiji je atribut "a" manji od 3 - operator $lt 18 ), reduce - funkcija koja izvršava odreďene operacije prilikom grupiranja. (U primjeru zbraja vrijednosti atributa "b" u rezultantni atribut "count"), initial - postavljanje inicijalnih vrijednosti koje se koriste u reduce funkciji. Ovime je završen pregled sustava MongoDB, jer zbog same teme rada, nije potrebno u detalje opisivati i objašnjavati kako radi MongoDB sustav. 18 $lt - operator "manje-od" (eng. lower than) 30

36 Migracija podataka u MongoDB U posljednje vrijeme se javlja pitanje automatske migracije podataka iz relacijskih baza podataka u MongoDB bazu podataka. Već postoje alati koji omogućuju migraciju podataka, no programeri često kreiraju vlastite skripte koje transformiraju podatke iz relacijske baze podataka u hijerarhijsku JSON strukturu koja moţe biti uvezena u MongoDB korištenjem mongoimport alata. TakoĎer, mnogi Extract Transform Tool (ETL) 19 alati (Pentaho, Talend, Informatica) su implementirali veze prema MongoDB bazama podataka, i omogućili radni proces u kojem su podaci izvaďeni iz izvorne relacijske baze podataka, transformirani i učitani u zadanu MongoDB bazu podataka. Način na koji se rade migracije je taj da su relacijski sustav i MongoDB pokrenuti paralelno, a podaci se premještaju inkrementalno: Prema[5], str. 12 Kako se zapisi dohvaćaju iz relacijske baze podataka, aplikacija ih zapisuje u MongoDB Postoje provjere konzistentosti, primjerice, korištenjem MD5 sume Svi novokreirani ili aţurirani podaci su zapisani samo na MongoDB Na taj način je Shutterfly 20 migrirao metapodatke šest milijardi fotografija i 20TB podataka iz Oracle baze podataka u MongoDB bazu podataka. Nakon migracije, performanse sustava su se povećale devet puta, troškovi smanjili za 80%. 19 ETL - niz funkcija (operacija) koje preoblikuju podatke iz izvora u korisne informacije pohranjene u skladištu podataka. Izvor [7]. 20 Shutterfly - sustav za dijeljenje fotografija, dostupan na 31

37 5. Usporedba NoSQL i relacijskih baza podataka Relacijske baze podataka su bile osnova kod izrade aplikacija dugi niz godina. No, današnjim potrebama i načinom izrade samih aplikacija, javila se potreba za modernijim pristupom pohrani podataka. U tablici 1 se nalaze razlike u nazivima pojedinih entiteta kod relacijskih baza podataka i NoSQL baza podataka. Relacijske baze podataka Baza podataka Tablica Redak Indeks NoSQL baze podataka Baza podataka Collection Dokument Indeks JOIN 21 UgraĎeni dokument ili referenca Tablica 1. Razlike u nazivima entiteta kod relacijskih i NoSQL baza podataka (Prema [5]) 5.1. Razlike u modelu podataka Najveće promjene se očituju kroz model podataka, stoga je model podataka prvi opisan. NoSQL sustav ne zahtijeva strogu shemu prije umetanja podataka, niti zahtjeva promjenu sheme kada različiti podaci moraju biti procesirani. Prema [6], str 5. Način na koji su podaci pohranjeni kod NoSQL baza podataka se moţe preslikati na korištenje objekata kod objektno-orijentiranih programskih jezika, za razliku od relacijskih baza podataka, gdje se korištenjem Object Relational Mappers-a (ORM) 22 povećava kompleksnost i reducira fleksibilnost shema. Još jedna stvar koja najčešće brine ljude koji dolaze iz svijeta relacijskih baza podataka u NoSQL je to što nema spajanja tablica kod upita. A rješenje je zapravo vrlo jednostavno, dokumenti se mogu ugraďivati jedni u druge čime se izbjegava potreba za spajanjem tablica kod izvršavanja upita. 21 JOIN - "klauzula koja se koristi za spajanje tablica, a koja je standardizirana u standardu SQL-92". Izvor [8], str Object Relational Mapper - tehnika za pretvaranje podataka iz nekompatibilnih (najčeše iz relacijskih baza) u objekte u objektno-orijentiranim programskim jezicima. 32

38 Na slici 16 na sljedećoj stranici se nalazi prikaz relacijske sheme, odnosno modela podatka. Moţe se zaključiti da se atribut "Pers_ID" iz tablice "Car" koristi da bi se dobila informacija o tome koja osoba je vlasnik kojeg auta. Slika 15. Primjer relacijske sheme (Izvor:[5], str. 3) Korištenjem NoSQL baza podataka i ugraďivanjem dokumenata jednih unutar drugih, odnosno spremanjem normaliziranih redaka i stupaca u jedan dokument, se izbjegava potreba za korištenje spajanja tablica jer je dovoljan jedan upit prema bazi podataka da se dohvate svi potrebni podaci. Prethodni primjer sa slike 15 tako moţemo modelirati u MongoDB sustavu kao na prikazu koda 19. { firstname: "Paul", surname: "Miller", city: "London", location: [45.123, ], cars: [ { model: "Bentley", year: 1973, value: ,... }, { model: "Rolls Royce", year: 1965, value: ,... } ] } Prikaz koda 19. Strukturirani JSON dokument(prema: RDBMS to MongoDB Migration Guide, str. 4) 33

39 U jednostavnom primjeru s vlasnikom automobila, relacijski model se sastoji od samo dvije tablice, no u realnim aplikacijama je to puno veći broj. No, to ne znači ništa za način pohrane podataka u NoSQL bazama podataka, kod njih su podaci prikazani u prirodnijem i intuitivnijem načinu. Dakle, vidljivo je da korištenje NoSQL baza podataka i pohrane dokumenata ima svoje prednosti: Prema [5], str. 4. Dokument s ugraďenim ostalim dokumentima je dohvaćen sa samo jednim pozivom prema bazi podataka, u odnosu na relacijske baze podataka, gdje se tablice moraju spajati. U NoSQL sustavu je dokument fizički pohranjen kao jedan dokument i zahtjeva samo jedno čitanje iz memorije. S druge strane, relacijsko spajanje tablica zahtijeva više čitanja s više fizičkih lokacija na disku. S obzirom na način pohrane dokumenata (cijeli dokument je na jednoj fizičkoj lokaciji na disku), ukoliko se koristi distribuirana pohrana podataka 23, jednostavno je dohvaćanje dokumenata. Administrator baze podataka se ne mora brinuti za performanse kod izvršavanja spanjanja tablica koje su na fizički odvojenim serverima. Već su ranije spomenuti načini na koji se implementiraju različite veze izmeďu dokumenata u NoSQL sustavima. Za razliku od relacijskih baza podataka gdje se koriste vanjski ključevi, u NoSQL bazama podataka postoji ugraďivanje dokumenata ili korištenje referenci Agregacija podataka Već je ranije spomenuto da je agregacija podataka vrlo bitna jer nam daje grupirane i statističke informacije. Neki NoSQL sustavi nemaju agregirajuće sposobnosti, no MongoDB koji je korišten u ovom radu ima. U takvim situacijama, programeri koriste razne zaobilazna rješenja za agregaciju, kao što su: izrada agregirajućih funkcionalnosti unutar aplikacija, čime se povećava kompleksonst i smanjuju performanse aplikacije Izvoz podataka u vanjske servise koji rade map-reduce funkciju nad podacima. Ovo takoďer povećava kompleksnost jer ne dopušta analizu podataka u realnom vremenu. Ako NoSQL sustav podrţava, napisati map-reduce funkciju u tom sustavu. 23 distribuirana pohrana podataka - U NoSQL svijetu se još naziva i sharding. 34

40 MongoDB sustav ima Agregacijski okvir koji ima funkcionalnost sličnu GROUP BY 24 i povezanim SQL izrazima. Korištenjem agregacijskog okvira, dokumenti prolaze kroz agregacijski cjevovod, gdje su podaci procesirani kroz različite operatore. Operatori koji se koriste u agregacijskom okviru su već ranije navedeni u radu Integracija s aplikacijama Bitna razlika izmeďu relacijskih sustava i NoSQL sustava je ta što je kod NoSQL sustava sučelje implementirano u obliku metoda unutar API-ja u specifičnom programskom jeziku, a nema zaseban jezik implementacije, kao što relacijske baze podataka imaju SQL. Uz to, dokumenti koji su pohranjeni u NoSQL bazu podataka odgovaraju modelu i strukturi podataka u objektno orijentiranim programskim jezicima, što omogućuje vrlo jednostavnu integraciju sa bazom podataka. 24 GROUP BY - klauzula pomoću koje se kreiraju grupe podataka u SQL-u. Izvor [8], str

41 6. Sustavi za upravljanje dokumentima Kao što je u uvodu već rečeno, tradicionalni način uredskog poslovanja je u današnje vrijeme zastario i zahtijeva puno vremena. Korištenjem sustava za upravljanje dokumentima uvelike se smanjuje vrijeme i količina posla potrebnog da bi se svi dokumenti evidentirali. Takvi sustavi, primjer čega će biti izraďen kao praktični dio ovog rada, povezuju sve potrebne korake za evidentiranje svih dokumenata koji se mogu naći u organizaciji. Takav sustav poboljšava produktivnost jer omogućuje jednostavnije, kvalitetnije i brţe obavljanje potrebnog posla Postojeća rješenja na trţištu S obzirom na to da se već neko vrijeme uredsko poslovanje seli u sustave za upravljanje dokumentima, u ovom dijelu rada će biti dan kratak pregled postojećih rješenja na trţištu, gdje će naglasak biti na rješenjima domaćih tvrtki INoffice2 INoffice2 je sustav tvrtke IN2 25 koji pruţa podršku rada uredskom poslovanju i prati tijek dokumenata unutar organizacije. Ideja sustava je da se svi podaci koji opisuju neki dokument unose na jednom mjestu, a unosi ih zaduţena osoba. Osnovni moduli sustava: Izvor [12] Upis i klasifikacija dokumenata, uz mogućnost skeniranja Praćenje kretanja dokumenata unutar kuće, dodjela dokumenata u rad Evidencija rada i promjena statusa dokumenata Evidencija otpreme dokumenata i ostalog materijala Arhiviranje dokumenata Izvješćivanje Što se tehnologija tiče, INoffice2 je razvijen u troslojnoj arhitekturi i dostupan je u Oracle i Microsoft verziji. 25 IN2 grupa - grupacija za razvoj softvera, projektiranje i izvedbu sloţenih IT sustava temeljenih na naprednim tenhnologijama. Izvor: 36

42 EDR Sustav za upravljanje dokumentima tvrtke Utilis d.o.o. 26 koji se integrira u Intranet okolinu organizacije, ili mu se momţe pristupiti putem Interneta korištenjem sigurne veze. Omogućuje pohranu različitih vrsta dokumenata, grupiranje dokumenata prema vrsti, omogućavanje prava pristupa. Slika 16. Prikaz.EDR sustava za upravljanje dokumentima (Izvor: Uz navedene funkcionalnosti ima korisničko sučelje za pretraţivanje, dohvat i uvid u dokumente koje je standardizirano i poznato korisnicima koji se sluţe Internetom. Sustav je implementiram korištenjem Microsoftovih tehnologija. TakoĎer je jednostavan za administraciju te pruţa mogućnost centraliziranog odrţavanja i primjene sigurnosnih postupaka, dok se svaki pristup dokumentu biljeţi u sustasvu. 26 Utilis d.o.o. - poduzeće za pruţanje usluga na području korištenja informacijsko-komunikacijskih tehnologija. Izvor: 37

43 Senso Senso sustav za upravljanje dokumenata tvrtke Senso profi d.o.o. 27 je sustav koji koristi Alfresco 28. Sami sustav za upravljanje dokumentima je integriran u cjelokupno rješenje koje tvrtka nudi i dostupno je kao snaţni web bazirani posluţitelj. Sustav je integriran u sinkronizaciju kalendara, zadataka i upravljanje radnim procesima. Senso sustav ima sljedeće ciljeve: Izvor [14] Povećanje dostupnosti i brzine pristupa dokumentima - bitno je što brţe upotrijebiti informacije u poslovnom kontekstu Povećanje produktivnosti - automatizacija poslovnih procesa unutar organizacija na bazi dokumenata Povećanje efikasnosti - stvaranje baza znanja o projektima i poslovnim procesima Povećanje sigurnosti i upravljanja - centralizacija sigurnosti i upravljanja uz poštivanje poslovnih i tehničkih zahtjeva korisnika Uz sve ovo, Senso omogućuje promjene na dokumentu, kao i upravljanju prava pristupa pojedinom dokumentu, dok je sve to obuhvaćeno kroz upravljanje ţivotnim ciklusom dokumenta Osnovni zahtjevi sustava za upravljanje dokumentima Svaki sustav za upravljanje dokumentima bi trebao sadrţavati skup osnovnih elemenata koji su potrebni za evidentiranje svih dokumenata. Minimalni elementi koje bi sustav za upravljanje dokumentima trebao imati su: Prema [10], str Dolazak dokumenata u sustav - najčešće skeniranjem. Dobar sustav za upravljanje dokumentima ima ugraďenu podršku da dokumenti automatski dolaze u sustav nakon što su skenirani. 2. Arhitektura i skalabilnost - sustav bi trebao biti neovisan o platformi i podrţavati različite operacijske sustave na klijentskoj strani. 27 Senso profi d.o.o. - tvrtka koja se bavi implementacijom informatičkih poslovnih rješenja za male, srednje i velike korisnike. Izvor: 28 Alfresco - vodeći sustav za upravljanje dokumentima otvorenog koda. Izvor: 38

44 3. Pohrana i arhiviranje dokumenata - na centralnom repozitoriju organizacije bi se trebali pohranjivati svi dokumenti koji uďu u sustav. Najbolje je kada su dokumenti organizirani u mape/podmape, obično je to prema vrsti dokumenta. 4. Administracija sustava - sustav bi trebao pruţiti web bazirani modul za administriranje, gdje je, izmeďu ostalih stvari za administriranje, najbitnije da se mogu postavljati različite razine pristupa, odnosno privilegije. 5. Dohvaćanje dokumenata - dokumenti se moraju moći dohvatiti brzo i lako. Nekako je najlakše ako su dokumenti pohranjeni u pdf formatu, da su neovisni o platformi i mogu se na različitim mjestima otvoriti. Ovdje je vrlo bitno i pretraţivanje dokumenata, preciznije, da se dokumenti mogu pretraţivati prema većini podataka na njima. 6. Pregled dokumenata i izvještavanje - povezano s prethodnom točkom, no dobar sustav za upravljanje dokumentima bi trebao imati jednostavan pregled dokumenata, kao i izvještaja o dokumentima. Izvještaji su posebno bitni ako se radi o financijskim dokumentima. 7. Spremanje dnevničkog zapisa - sustav bi trebao pohranjivati sve aktivnosti koje su pojedini korisnici izvršavali na dokumentima, tako da se kasnije moţe provjeriti tko je što radio i na kojem dokumentu. Osim navedenih 7 elemenata, sustavi mogu imati i odreďene druge funkcionalnosti koje su opisane u sljedećem dijelu rada Ostale funkcionalnosti sustava za upravljanje dokumentima Radni proces dokumenta Najbitnija stavka, a koja nije navedena u prethodnom popisu elemenata sustava za upravljanje dokumenata, jest radni proces dokumenta. Svaki dokument koji uďe u organizaciju, a samim time i u sustav, ima odreďen svoj radni proces. Ponekad je to samo jednostavno arhiviranje dokumenta, a ponekad radni proces moţe biti vrlo kompleksan i u njemu mora sudjelovati velik broj sudionika Raspodjela poslova na zaposlenike "Sustav treba omogućiti raspodjelu poslova po djelatnicima, tj. zaduţivanje djelatnika s rokovima dovršetka posla." Izvor [9], str

45 Iz prikazanog citata se moţe zaključiti da se svaki proces unutar cjelovitog radnog procesa nad nekim dokumentom mora raspodijeliti po zaposlenicima, gdje su djelatnici najčešće zaduţeni za istu vrstu poslova, ili više njih Praćenje stanja dokumenta u sustavu Uz prethodno opisane funkcionalnosti, potrebno je pratiti i stanja dokumenta u sustavu. Najčešće je to povezano s radnim procesom, gdje u svakom procesu dokument ima odreďen status, no moţe biti situacija i kada to nije jednoznačno povezano Autorizacija i sigurnost Različite vrste dokumenata imaju različitu razinu povjerljivosti podataka. Radi toga, sustav ne bi smio dopustiti zaposlenicima da imaju pristup dokumentima za čiji pregled ili ureďivanje nemaju ovlasti Ţivotni ciklus dokumenta Ţivotni ciklus dokumenta kreće njegovim ulazom u sustav za upravljanje dokumentima. On u sustav moţe ući na različite načine. Moţe ga kreirati bilo koji zaposlenik unutar organizacije, ili moţe biti dostavljen od strane pošte. No, svaki dokument, bez obzira tko ga je unio u sustav, ima svoj radni proces koji kreće jednom kada je dokument u sustavu. Samim time se na neki način moţe poistovjetiti ţivotni ciklus dokumenta i njegov radni proces, ali s iznimkom da kada radni proces dokumenta završi, on je arhiviran, ali je još uvijek dostupan za pregled, što zapravo znači da ţivotni ciklus nije završio. Nakon ulaska dokumenta u sustav, potrebno je popuniti neke podatke o dokumentu. Zanimljivo je da se ti podaci tijekom radnog procesa dokumenta mogu mijenjati zbog različitih razloga. Prema [11], str. 4, ţivotni ciklus dokumenta sadrţi sljedeće korake: ulaz dokumenta - dokument moţe nastati unutar organizacije ili moţe biti zaprimljen od neke vanjske organizacije. TakoĎer, dokument moţe pristići u bilo kojem obliku, elektroničkom, papirnatom i dr. upravljanje dokumentom - jednom kada je dokument kreiran, moţe postati zapis koji je klasificiran i upravljan prema svojem radnom procesu. pohrana dokumenta - jednom kada dokument postane zapis, odnosno kada krene njegov radni proces, bitno je da bude pohranjen u bazu podataka. 40

46 dostupnost dokumenta - kada je dokument sigurno pohranjen, on mora biti dostupan zaposlenicima za pregled i ureďivanje. uništavanje dokumenta - ponekad se javlja potreba da nakon odreďenog vremenskog perioda, primjerice tri godine, dokumenti budu uništeni. No, ovo najčešće nije praksa, već su dokumenti, nakon što im završi radni proces, arhivirani i dostupni za pregled. Ovime je završen kratki pregled osnovnih funkcionalnosti koje bi sustav za upravljanje dokumenata trebao imati i u nastavku rada je prikaza jedan takav sustav koji je izraďen za potrebe ovog rada. 41

47 7. Praktični rad Dosad prikazani koncepti su spojeni u implementaciju sustava za upravljanje dokumentima. Klijent koji će koristiti sustav je mala tvrtka koja se bavi prodajom računalne opreme Osnovni zahtjevi sustava Osnovni zahtjevi koje će izgraďeni sustav za upravljanje dokumentima imati su sljedeći: Ulazak dokumenata u sustav - svaki korisnik moţe uploadati dokument u definiranom formatu (radi jednostavnosti implementacije, dokumenti mogu biti slike, najčešće.jpg) Pohrana dokumenata - sustav pohranjuje dokumente na, za to, ranije odreďenu lokaciju na disku. OdreĎivanje tipa dokumenta - korisnik koji je za to zaduţen, mora odrediti tip dokumenta koji je ušao u sustav. Sustav nakon toga, ovisno o tipu dokumenta, pokreće radni proces koji je predviďen za taj tip dokumenta. Pregled svih dokumenata - sustav treba omogućiti korisniku pregled svih dokumenata u sustavu. Unos podataka o plaćanju za ulazne i izlazne račune - sustav omogućuje praćenje ulaznih i izlaznih računa. Samim time je potrebno omogućiti i praćenje plaćanja na takvoj vrsti dokumenta Korisničke priče U nastavku je prikazano nekoliko korisničkih priča na temelju kojih će biti kreiran dijagram slučajeva korištenja 29 i implementirane funkcionalnosti aplikacija Ulaz novog dokumenta u sustav Nakon uspješne prijave u sustav, korisnik ţeli uploadati novi dokument. Pripremio je dva dokumenta za upload. Jedan od njih je račun za struju koji je pokupio u poštanskom sandučiću, a drugi je izlazni račun koji je tvrtka izdala klijentu za prodani monitor. Korisnik otvori formu za upload dokumenta, odabere skenirani dokument i pritisne gumb "Snimi", čime dokument ulazi u sustav. Istu radnju korisnik ponovi i za izlazni račun. 29 Dijagram slučajeva korištenja (eng. Use Case) - dijagram koji prikazuje odnose izmeďu korisnika sustava i slučaja korištenja, odnosno funkcionalnosti sustava. 42

48 OdreĎivanje tipa dokumenta Korisnik najprije mora odabrati jedinstveni identifikator dokumenta u sustavu. Sustav korisniku daje prijedlog, pa korisnik zapravo mora samo potvrditi prijedlog koji mu je dao sustav. Nakon toga, korisnik koji je zaduţen za odreďivanje tipa dokumenata, vidi u sustavu da su pristigla dva nova dokumenta. Otvori prvi dokument (račun za struju) te njemu odredi da je to ulazni račun - URA. Za drugi dokument (račun klijentu za prodani monitor) odredi da je izlazni račun - IRA. Ovim postupkom, sustav pokreće radne procese za ova dva dokumenta Obrada ulaznih/izlaznih računa Korisnik koji ima prava ureďivanja podataka dokumenta moţe popuniti potrebne podatke za dokumente koji su ušli u sustav. Korisnik upisuje sljedeće podatke za tip dokumenta URA: datum partner ukupan iznos iznos PDV-a datum dospijeća poziv na broj broj računa primatelja Za dokument IRA popunjuje sljedeće podatke: datum klijent ukupan iznos iznos PDV-a Kada je korisnik završio s unosom podataka za dokumente, mora na dokumentu označiti da su podaci upisani čime dokument postaje spreman za sljedeći korak u svom radnom procesu. 43

49 Odobravanje ulaznih računa Korisnik s dozvolom odobravanja ulaznih računa moţe odobriti, ukoliko se slaţe s unesenim podacima, ulazni račun, čime dokument postaje spreman za plaćanje. Račun postaje odobren klikom na gumb "Odobri" kada se otvori traţeni dokument Plaćanje računa Korisnik ţeli unijeti da je račun plaćen. U dijelu sustava "Plaćanja" korisnik moţe odabrati ulazne ili izlazne račune. Za svaki dokument koji je tamo prikazan moţe unijeti podatak o plaćanju. Korisnik pronaďe ţeljeni dokument, pritisne gumb "Unesi plaćanje" te popuni informacije vezane uz plaćanje Detaljan opis sustava Dijagram slučajeva korištenja Na temelju osnovnih zahtjeva i korisničkih priča napravljen je dijagram slučajeva korištenja, koji prikazuje odnose izmeďu korisnika sustava i funkcionalnosti izgraďenog sustava. Dijagram je prikazan na slici 17 na sljedećoj stranici. Iz dijagram slučajeva korištenja se moţe vidjeti da će implementirani sustav sadrţavati sljedeće funkcionalnosti: Prijava korisnika Upload novog dokumenta u sustav OdreĎivanje jedinstvenog identifikatora i tipa dokumenta Obrada ulaznih/izlaznih računa Odobravanje ulaznih računa Unos plaćanja za račune 44

50 Slika 17. Dijagram slučajeva korištenja za sustav za upravljanje dokumentima Mogući tipovi dokumenata Iz popisa funkcionalnosti se moţe zaključiti da će se sustav prvenstveno bazirati na račune, ulazne i izlazne. Naravno da to nije jedina vrsta dokumenata koji mogu doći u neku organizaciju, no radi jednostavnosti implementacije i prikaza sustava za upravljanje dokumentima, u ovom sustavu će se pratiti samo ulazni i izlazni računi. Dakle, moguće vrste dokumenata u sustavu su: Ulazni račun - URA Izlazni račun - IRA Grupe korisnika Ovisno o grupi korisnika se postiţe odreďena razina sigurnosti, a moţe se postići i odreďena razina povjerljivosti. U ovom sustavu neće biti previše značaja dano povjerljivosti, s obzirom da se radi o maloj tvrtki za prodaju računalne opreme. 45

51 Grupe korisnika u sustavu: Klasifikatori - grupa korisnika koja je zaduţena za odreďivanje tipa dokumenata kao i dodjeljivanje jedinstvenog identifikatora dokumentu. Uređivači - grupa korisnika koja je zaduţena za obradu ulaznih/izlaznih računa, kao i za unos plaćanja za pojedini račun Odobravatelji - grupa korisnika koja je zaduţena za odobravanje ulaznih računa Za upload novog dokumenta u sustav korisnik ne mora biti član niti jedne grupe, što znači da svi korisnici u sustavu mogu kreirati novi dokument Radni procesi Radni procesi se razlikuju ovisno o tipu dokumenta. S obzirom na to da u ovom sustavu postoje dvije vrste dokumenata, radni procesi za svaki od njih su dani u nastavku. No, prvi radni proces je jednak za oba tipa dokumenta. Zapravo, nego što sustav zna tip dokumenta potrebno mu je dodijeliti jedinstveni identifikator OdreĎivanje jedinstvenog identifikatora i tipa dokumenta OdreĎivanje jedinstvenog identifikatora je prvi radni proces i zajednički je svim dokumentima koji uďu u sustav. Korisnik iz grupe Klasifikatori najprije mora odrediti jedinstveni identifikator dokumenta. Sustav korisniku daje prijedlog jedinstvenog identifikatora na način da zna koliko ima dokumenata dosad u sustavu, a jednoznačno su odreďeni oblikom "Godina.RedniBroj", što primjerice moţe biti " ", a to znači da je ovo 111-ti dokument u 2014 godini. Nakon što se odredi jedinstveni identifikator, isti korisnik, ili neki drugi iz grupe Klasifikatori moţe odrediti tip dokumenta. Kada korisnik odredi tip dokumenta, pokreće se radni proces vezan za odabrani tip dokumenta. Grafički prikaz radnog procesa odreďivanja jedinstvenog identifikatora i tipa dokumenta se nalazi na slici 18 na sljedećoj stranici. 46

52 Slika 18. OdreĎivanje jedinstvenog identifikatora i tipa dokumenta Ulazni račun Kada se u sustavu pojavi novi ulazni račun, prvi zadatak u njegovom radnom procesu je vezan uz grupu Uređivači. Korisnici iz te grupe moraju popuniti potrebne podatke na dokumentu da bi započeo sljedeći korak radnog procesa. Nakon što Uređivači završe obradu ulaznih računa, zadatak imaju Odobravatelji. Oni moraju odobriti dokument tako da moţe ići na plaćanje. U slučaju da Odobravatelji odbiju dokument, on se vraća na prethodni zadatak i Uređivači moraju aţurirati podatke o dokumentu. Grafički prikaz radnog procesa za ulazne račune se nalazi na slici 19. Slika 19. Radni proces za ulazne račune 47

53 Izlazni račun Radni proces za izlazne račune je podosta sličan radnom procesu za ulazne račune. TakoĎer Uređivači najprije moraju popuniti podatke za izlazni račun. Nakon popunjavanja podataka na red dolazi odobravanje izlaznog računa, za što je zaduţena grupa Odobravatelji. Kao i u slučaju ulaznih računa, Odobravatelji mogu odobriti ili odbiti izlazni račun. Na slici 20 je grafički prikaz radnog procesa za izlazne račune. Slika 20. Radni proces za izlazne račune Unos podataka o plaćanju Jednom kada su računi (ulazni i izlazni) odobreni, korisnička grupa Uređivači mogu unositi podatke o plaćanju istih. U slučaju ulaznih računa, organizacija moţe račun platiti u više navrata, i jednom kada je račun plaćen u potpunosti, njegov radni proces završava. U slučaju izlaznih računa se takoďer mogu unijeti podaci o plaćanju u više navrata, i kada je iznos podmiren u cijelosti, radni proces završava. Radni proces je prikazan na slici 21. Slika 21. Radni proces unosa podataka o plaćanju 48

54 7.4. Implementacija sustava Praktični dio ovog rada, sustav za upravljanje dokumentima, je implementiran kao singlepage web aplikacija, korištenjem modernih tehnologija. Tako se na klijentskoj strani koriste tehnologije poput HTML-a, CSS-a i JavaScripta, dok je na serverskoj strani korišten NodeJS, platforma za izradu modernih i skalabilnih mreţnih aplikacija. Kao baza podataka je odabran MongoDB sustav za upravljanje bazama podataka Arhitektura sustava Sustav je graďen kroz tri sloja. Arhitektura sustava je prikazana na slici 22. Slika 22. Arhitektura sustava za upravljanje bazama podataka 49

55 Baza podataka Osnovni sloj nad kojim leţe preostala dva sloja je sloj baze podataka. Kao što je već rečeno, korištena je MongoDB baza podataka za pohranu dokumenata. Model baze podataka Baza podatka se sastoji od sljedećih 5 collection-a: Documents - dokumenti Payments - plaćanja Usergroups - korisničke grupe Users - korisnici Workflows - radni procesi Najbitniji collection je svakako Documents, s obzirom da se u njega pohranjuju dokumenti iz sustava za upravljanje dokumentima. No, uz ovih 5 collection-a, postoje još 2 entiteta, a to su Comments (komentari) i Tasks (zadaci). No, oni se ugraďuju unutar dokumenata. Komentari se ugraďuju u Documents entitet, a zadaci se ugraďuju u Workflows entitet. Prikaz ER modela se nalazi na slici 23. Dodatna 2 entiteta koja se ne nalaze u bazi podataka kao zasebni collection-i su označena ukošenim slovima. Slika 23. ER (Entity Relationship) model Sa slike se moţe vidjeti da korisnici mogu biti članovi više korisničkih grupa, kao i da korisničke grupe mogu sadrţavati više korisnika. Nadalje, korisnička grupa moţe biti zaduţena za više zadataka, dok za taj zadatak moţe biti zaduţena samo jedna grupa korisnika. 50

56 Na pojedinom radnom procesu se moţe nalaziti više zadataka, no taj zadatak moţe biti samo na jednom radnom procesu. Na svakom dokumentu u trenutku vremena moţe biti vezan samo jedan radni proces, dok taj isti radni proces moţe biti vezan na više dokumenata. Nadalje, svaki dokument moţe imati više komentara, dok se komentar odnosi samo na jedan dokument. I na kraju, na dokument moţe biti vezano više plaćanja, a pojedino plaćanje se odnosi samo na jedan dokument Server-side aplikacija Na serverskoj strani (eng. backend) je implementirana zasebna aplikacija, koja nema svoje grafičko sučelje već pruţa niz API-ja pomoću kojih klijentska aplikacija koristi podatke iz baze podataka. Serverska strana je implementirana korištenjem NodeJS platforme. Autorizacija pristupa Kod zaprimanja zahtjeva na bilo koji API, prvo se radi provjera korisnika. Provjera korisnika je implementirana na način da korisnik nakon prijave dobije svoj token koji traje 7 dana. U tih narednih 7 dana korisnik ne mora ponavljati postupak prijave, već uvijek kod zahtjeva na API šalje svoj token. Ukoliko je token istekao, klijent dobije obavijest da se mora ponovno logirati. Pristup bazi podataka Za pristup MongoDB bazi podataka je korišten mongojs 30 dodatak za NodeJS, a predstavlja sloj više razine za komunikaciju s MongoDB bazama podataka. Spremanje dokumenata Aplikacija sprema dokumente u za to predviďenu datoteku na disku. Uz spremanje originala, sprema se i slika dokumenta koja je manje rezolucije i kvalitete i sluţi samo za pregled. Popis API-ja Na serverskoj strani su dostupni API-ji prikazani u tablici 2 na sljedećoj stranici. Za pristup svim API-jima osim za prijavu i registraciju je potrebno slati sljedeće parametre: userid - mongo ObjectId identifikator korisnika - adresa korisnika token - pristupni token koji korisnik dobije nakon prijave u aplikaciju 30 mongojs - sloj više razine za pristup MongoDB bazi podataka iz NodeJS platforme. Izvor: 51

57 Metoda URL pristupa Potrebni parametri Svrha Korisnik POST /user method o o login password createuser password firstname lastname Korištenjem ovog API-ja korisnik se moţe registrirati ili prijaviti u aplikaciju. Dokumenti GET /documents - Dohvaćanje svih dokumenata, nije potrebno slanje nikakvih dodatnih parametara. GET /document documentid Dohvaćanje specifičnog dokumenta pomoću mongo ObjectId-a. POST /document file name Kreiranje novog dokumenta. Potrebno poslati sliku i naziv dokumenta. PUT /document documentid podaci za aţuriranje Aţuriranje dokumenta s točno odreďenim mongo ObjectId-om i ostalim podacima koji se spremaju. GET /files/document/:id/:type id type o o fullsize preview Dohvaćanje slike za pregled dokumenta, potrebni mongo ObjectId dokumenta i vrsta slike POST /comments documentid comment author Spremanje novog komentara na dokument. Potrebno poslati tekst komentara, i mongo ObjectId-ove dokumenta i autora 52

58 Radni procesi PUT /workflows documentid task Zavšavanje zadatka na dokumentu. Potrebno poslati mongo ObjectId dokumenta i zadatak koji se završava. Plaćanja GET /payments direction o incoming o outgoing Dohvaćanje svih ulaznih ili izlaznih plaćanja, ovisno o parametru. POST /payments documentid amount paymentdate Spremanje plaćanja na dokument. Potrebno proslijediti mongo ObjectId dokumenta, iznos i datum plaćanja Tablica 2. Popis API-ja na serverskoj strani Client-side aplikacija Aplikacija na klijentskoj strani je ono što korisnici vide. Ovaj sloj aplikacije sluţi za komunikaciju izmeďu korisnika i serverske strane. Tehnologije Klijentska strana je realizirana kao single-page web aplikacija korištenjem modernih tehnologija poput: HTML JavaScript - jquery biblioteka. LESS - napredniji jezik od običnog CSS-a, ima mogućnost korištenja varijabli i funkcija. Handlebars.js - JavaScript biblioteka koja omogućuje korištenje HTML predloţaka i dinamičko popunjavanje istih. 53

59 Implementacija Cjelokupna aplikacija na klijentskoj strani je implementirana korištenjem JavaScript programskog jezika, i to ponajviše Module Pattern 31 uzorka dizajna. Tako je svaki veći dio aplikacije odvojen u zaseban modul unutar kojeg je implementirana njegova funkcionalnost. S obzirom na to da je aplikacija implementirana kao single-page javila se potreba za korištenjem biblioteke koja će omogućavati korištenje ruta u address bar-u preglednika kao jedan način navigacije kroz aplikaciju. Uz to je korištena biblioteka za korištenje HTML predloţaka i dinamičko popunjavanje istih iz razloga da se te stvari ne moraju raditi iz JavaScript koda, što nije najpreporučljivije u većim aplikacijama. Uz ove dvije najvaţnije, korišteno je i još nekoliko JavaScript biblioteka, kao primjerice za spremanje cookie-a, ili za rukovanje s vremenskim podacima. Za sam izgled aplikacije je zasluţan okvir Bootstrap 32, najpopularniji HTML, CSS i JavaScript okvir za izgradnji responsive web aplikacija, a koji ima predefinirane CSS klase i idealan je za početak ovakvog projekta, jer pruţa osnovan dobar izgled. Produkcijsko okruženje Tijekom izgradnje je korišten i grunt 33 koji je izvršavatelj zadataka (eng. task runner) za JavaScript, a omogućuje automatizaciju odreďenih zadataka. Upravo je on korišten za generiranje takozvanih produkcijskih datoteka, odnosno minificiranih JavaScript i CSS datoteka, tako da u produkcijskom okruţenju ne budu čitljive korisniku. Najprije je izvršena konkatenacija svih JavaScript datoteka. Nakon toga je izvršen proces poruţnjavanja (eng. uglify) te datoteke, a u njemu su sve varijable i funkcije preimenovane i nečitljiv oblik. Na kraju je se radi umanjivanje (eng. minify) datoteke, odnosno brisanje svih praznih znakova i komentara iz koda. Za CSS datoteku je napravljeno isto, osim što su prije konkatenacije LESS datoteke kompajlirane u CSS. 31 Module Pattern uzorak dizajna - dijelovi aplikacije su organizirani kao moduli, čime se moţe napraviti usporedba s objektno orijentiranim programiranjem, Izvor: [19] 32 Bootstrap - najpopularniji HTML, CSS i JavaScript okvir, Izvor: 33 grunt - JavaScript izvršavatelj zadataka, Izvor: 54

60 7.5. Korištenje sustava U nastavku je dan prikaz korištenja sustava implementiranog kao praktični dio ovog rada Instalacija Preduvjeti Preduvjeti potrebni za instalaciju sustava na kojem je bilo koja Linux distribucija 34 : mongodb 35 - sustav za upravljanje bazama podataka npm 36 - upravitelj paketima (eng. package manager) za NodeJS platformu web server - najkorišteniji i najpoznatiji web server je Apache Opcionalno, moguće je instalirati RockMongo 37, koji je alat za administraciju MongoDB baza podataka, slično kao što je PHPMyAdmin za MySQL baze podataka. Taj alat uvelike olakšava korištenje i administriranje baze podataka Postavljanje baze podataka Za normalno funkcioniranje sustava je potrebno uvesti bazu podataka koja sadrţi početne podatke, kao što su definicije radnih procesa ili testni korisnik. Za potrebe uvoza baze podataka, napravljen je izvoz početne baze podataka, a nalazi se u direktoriju maperokov-diplomski u arhivi maperokov-primjenanosqlnadms.zip priloţenoj ovom radu. Potrebno se pozicionirati na lokaciju na kojoj je arhiva otpakirana (najjednostavnije u root direktorij web servera) te pokrenuti sljedeću naredbu u komandnoj liniji: mongorestore -d maperokov-diplomski pocetna-baza/maperokov-diplomski/ Nakon izvršavanja, kreirana je nova baza podataka pod nazivom maperokov-diplomski i u nju je uvezeno početno stanje za normalno funkcioniranje sustava. Uvoz početnog stanja baze podataka se mogao napraviti i pomoću RockMongo-a, no korištenje samo jedne naredbe je jednostavnije. 34 Instalacija je testirana na sustavu Linux Mint Tutorijal za instalaciju na Ubuntu baziranim distribucijama: 36 npm - Node Package Manager. Izvor: 37 RockMongo - alat za administraciju, Izvor: Tutorijal za instalaciju: 55

61 Na slici 24 se nalazi primjer korištenja RockMongo-a. Slika 24. Korištenje RockMongo alata za administraciju baza podataka Sa slike se moţe vidjeti da se s lijeve strane nalazi popis baza podataka, dok je s desne strane prostor za administriranje odabrane baze podataka. Kada odaberemo bazu podataka, ispod nje nam se prikaţu i svi collection-i koji se nalaze u njoj Postavljanje sustava S obzirom na to da se sustav sastoji od dva dijela, klijentske i serverske aplikacije, klijentsku aplikaciju je potrebno postaviti unutar ţeljene mape u root direktoriju web servera. Kao najjednostavniji primjer, unutar /var/www/html/ se moţe kreirati mapa diplomski, a u nju postaviti cjelokupni sadrţaj sustava. Struktura mape /var/www/html/diplomski/ bi trebala izgledati kao na slici 25 na sljedećoj stranici. Najprije je potrebno pomoću npm-a instalirati sve potrebne dodatke za funkcioniranje aplikacije. Treba se pozicionirati u mapu /var/www/html/diplomski/ te pomoću naredbe: npm install instalirati sve potrebne dodatke. Nakon što je instalacija gotova, sustav se moţe pokrenuti. 56

62 Slika 25. Struktura preuzetih datoteka Da bi sustav mogao funkcionirati, potrebno je pokrenuti serversku aplikaciju napisanu u NodeJS platformi. Bitno je pozicionirati se u /var/www/html/diplomski/ mapu te pokrenuti serversku aplikaciju pomoću sljedeće naredbe: nodejs server.js Aplikacija na serverskoj strani će funkcionirati sve dok ne bude prekinuta. Naravno, u normalnom produkcijskom okruţenju bi ovakav način rada bio vrlo loš te bi aplikacija bila kreirana kao servis i pokretana pomoću naredbe service. Jednom kada je baza podataka uvezena i serverska aplikacija pokrenuta, moţe se pokrenuti cjelokupni sustav u pregledniku. Potrebno je otići na sljedeći URL: localhost/diplomski/clientapp/build/ Primjetite da je zadnji element adrese riječ build, koja odlazi u posebnu mapu u kojoj je produkcijska verzija aplikacije na klijentskoj strani. Ovime je sustav instaliran i spreman za korištenje. Testni korisnički račun, koji je član svih korisničkih grupa ima adresu diplomski@foi.hr te lozinku diplomski. 57

63 Prijava u sustav Nakon što je sustav pravilno instaliran i podešen, kada ga se otvori, potrebno se prijaviti. Prikaz dijela za prijavu se nalazi na slici 26. Slika 26. Prijava korisnika u sustav Ukoliko korisnik ne posjeduje korisnički račun, moţe se registrirati pritiskom na gumb Registriraj se. Nakon toga se pojavljuje forma za registraciju, kao na slici 27. Slika 27. Forma za registraciju Nakon što se korisnik registrira, moţe se prijaviti te ga aplikacija vodi na početnu stranicu, gdje su prikazani svi dokumenti u obliku kartica, što je prikazano na slici 28 na sljedećoj stranici. 58

64 Slika 28. Početna stranica nakon prijave korisnika U takvom prikazu, svi dokumenti imaju malu sliku koja sluţi kao pregled dokumenta, naslov dokumenta te zadatak za koji je korisnik zaduţen na tom dokumentu, ukoliko je. TakoĎer, na svaki dokument se mogu dodavati komentari Pregled svih dokumenata Pritiskom na gumb Dokumenti u navigacijskoj traci se dolazi do dijela sustava u kojem se mogu vidjeti svi dokumenti. Prikaz toga je na slici 29 na sljedećoj stranici. U ovom prikazu su prikazani svi dokumenti trenutno u sustavu. Moţe ih se pretraţivati prema bilo kojem podatku koji je u tablici te sortirati prema bilo kojem atributu. Prikazani su sljedeći podaci: ID - identifikator dokumenta Tip - tip dokumenta Naziv dokumenta Datum - datum dokumenta 59

65 Ukupni iznos Plaćeni iznos Dva posljednja podatka sluţe za praćenje financijskog dijela poslovanja. Ukoliko je neki dokument plaćen u potpunosti, plaćeni iznos će biti prikazan zelenom bojom Upload novog dokumenta Slika 29. Modul Dokumenti Novi dokument se moţe uploadati nakon pritiska na plavi gumb Novi dokument u navigacijskoj traci aplikacije. Nakon toga se otvara prozor za upload novog dokumenta gdje je potrebno odabrati skeniranu sliku dokumenta, i upisati naziv novog dokumenta. Prikaz toga se nalazi na slici 30. Nakon što novi dokument uďe u sustav, automatski se dodaje nova kartica na početnoj stranici tako da korisnik ima pregled svih dokumenata u sustavu. Slika 30. Dodavanje novog dokumenta 60

66 OdreĎivanje jedinstvenog identifikatora dokumenta Nakon što dokument uďe u sustav, potrebno mu je odrediti jedinstveni identifikator. To se moţe napraviti kroz detaljan pregled dokumenta, tako da se klikne na naslov ili sliku dokumenta unutar kartice na početnom zaslonu. Nakon toga je potrebno unijeti jedinstveni identifikator te završiti zadatak pritiskom na gumb Jesam dolje u dnu ekrana, kao što je prikazano na slici 31. Slika 31. OdreĎivanje jedinstvenog identifikatora dokumenta Nakon što je zadatak završen, automatski se prelazi na sljedeći zadatak, a to je odreďivanje tipa dokumenta OdreĎivanje tipa dokumenta Potrebno je odabrati jedan od ponuďenih tipa dokumenata (zasada su to samo ulazni i izlazni račun) te pritisnuti gumb Jesam za završetak zadatka. To je prikazano na slici 32 na sljedećoj stranici. 61

67 Slika 32. OdreĎivanje tipa dokumenta Popunjavanje podataka za dokument Jednom kada je odreďen tip dokumenta, automatski je pokrenut radni proces za taj dokument. Prvi korak je popunjavanje podataka za dokument, što se takoďer moţe napraviti kroz detaljan pregled dokumenta. Taj proces je prikazan na slici 33 na sljedećoj stranici. 62

68 Slika 33. Popunjavanje podataka za dokument Nakon što su uneseni svi podaci, potrebno je pritisnuti gumb Jesam, koja označava završetak zadatka Odobravanje dokumenta Nakon što su podaci za dokument uneseni, korisnik koji u grupi Odobravatelji, treba odobriti dokument. To moţe napraviti pritiskom na gumb Jesam, bilo u detaljnom pregledu ili na početnoj stranici na kartici, kao na slici 34 na sljedećoj stranici. 63

69 Slika 34. Odobravanje dokumenta Jednom kada je dokument odobren, za njega se mogu unositi plaćanja Unos plaćanja za dokument Plaćanja su poseban dio sustava do kojeg se dolazi pritiskom na gumb Plaćanja u navigacijskoj traci aplikacije. Prikaz dijela sustava Plaćanja se nalazi na slici 35. Slika 35. Modul Plaćanja U ovom dijelu sustava su odvojeni ulazni od izlaznih računa, da bi se lakše unosila plaćanja, jer su to odvojene stvari. Od bitnijih podataka, ovdje je prikazan ukupan iznos računa, dosad 64

70 plaćeni iznos te iznos koji je preostao za platiti. Jednom kada se račun u potpunosti plati, više neće biti vidljiv u ovom dijelu sustava, već se do njega moţe doći kroz modul Dokumenti. No, unos plaćanja funkcionira jednako i za ulazne, i za izlazne računa. Pritiskom na gumb Dodaj plaćanje se otvara mali prozor u koji je potrebno unijeti iznos te datum kada je plaćanje izvršeno. Prikaz toga je na slici 36. Slika 36. Unos podataka o plaćanju U polje za unos iznosa se automatski upisuje iznos koji je preostao za platiti. Napravljene su provjere tako da se ne moţe platiti iznos koji je veći od potrebnog Budući rad i mogući napredak sustava Sustav izraďen kao praktični dio rada sadrţi osnovu funkcionalnosti koje bi strebao imati svaki sustav za upravljanje dokumentima. No, uz tu osnovu, sustav bi mogao sadrţavati i neke naprednije stvari, pa bi se napredak mogao vidjeti u sljedećim stvarima: Grupiranje dokumenata prema zadacima - u velikoj organizaciji gdje ima puno dokumenata bi ovakav sustav bez mogućnosti pretraţivanja i grupiranja dokumenata prema zadacima bio vrlo teţak za korištenje. Stoga bi poboljšanje definitivno bilo osmisliti grupiranje dokumenata prema zadacima na njemu. Najprihvatljivije za korisnike sustava bi bilo da imaju jedan modul sustava do kojeg se dolazi putem navigacijske trake, a gdje mogu odabrati zadatak i nakon toga im se prikaţu samo oni dokumenti za koje su oni zaduţeni prema odabranom zadatku. 65