Embed Size (px)
Citation preview
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.
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.
I
Sadrţaj
1. Uvod .................................................................................................................. 1
2. Polustrukturirani model podataka ..................................................................... 3
2.1. Formalne definicije iz teorije grafova ....................................................................................................... 3
2.2. Općenito o polustrukturiranom modelu podataka ..................................................................................... 4
2.3. Prikaz podataka iz drugih vrsta izvora ...................................................................................................... 6
2.3.1. Relacijske baze podataka .................................................................................................................. 6
2.3.2. Objektno orijentirane baze podataka ................................................................................................ 7
3. JSON format ...................................................................................................... 9
3.1. Tipovi podataka u JSON formatu ............................................................................................................. 9
3.2. Primjer podataka u JSON formatu .......................................................................................................... 10
3.3. Korištenje JSON Scheme ........................................................................................................................ 10
3.3.1. Primjer JSON Scheme .................................................................................................................... 10
3.4. Korištenje JSON formata ........................................................................................................................ 11
4. NoSQL sustavi za upravljanje bazama podataka ............................................ 13
4.1. Model podataka ....................................................................................................................................... 14
4.1.1. Document Model ............................................................................................................................ 14
4.1.2. Graph model ................................................................................................................................... 15
4.1.3. Key-value model............................................................................................................................. 16
4.2. Model upita ............................................................................................................................................. 16
4.2.1. Document model............................................................................................................................. 16
4.2.2. Graph model ................................................................................................................................... 17
4.2.3. Key-value model............................................................................................................................. 17
4.3. Konzistentnost ......................................................................................................................................... 17
4.3.1. Konzistentni sustavi ........................................................................................................................ 17
4.3.2. Gotovo konzistentni sustavi ............................................................................................................ 18
4.4. Korištenje API-ja .................................................................................................................................... 18
4.4.1. Slojevi više razine ........................................................................................................................... 18
4.5. Komercijalna podrška i snaga zajednice ................................................................................................. 19
4.6. Prikaz korištenja sustava MongoDB ....................................................................................................... 19
4.6.1. Način pohrane podataka ................................................................................................................. 19
4.6.2. Čitanje podataka ............................................................................................................................. 20
4.6.3. Modeliranje podataka ..................................................................................................................... 21
4.6.3.1. Struktura dokumenta .............................................................................................................. 21
4.6.3.2. Povezivanje dokumenata ........................................................................................................ 24
4.6.4. Agregacija podataka ....................................................................................................................... 26
4.6.4.1. Agregirajući cjevovod ............................................................................................................ 26
4.6.4.2. Map-reduce ............................................................................................................................ 27
4.6.4.3. Agregirajuće funkcije jednostavne svrhe ............................................................................... 29
4.6.5. Migracija podataka u MongoDB .................................................................................................... 31
II
5. Usporedba NoSQL i relacijskih baza podataka .............................................. 32
5.1. Razlike u modelu podataka ..................................................................................................................... 32
5.2. Agregacija podataka ................................................................................................................................ 34
5.3. Integracija s aplikacijama ........................................................................................................................ 35
6. Sustavi za upravljanje dokumentima .............................................................. 36
6.1. Postojeća rješenja na trţištu .................................................................................................................... 36
6.1.1. INoffice2......................................................................................................................................... 36
6.1.2. .EDR ............................................................................................................................................... 37
6.1.3. Senso .............................................................................................................................................. 38
6.2. Osnovni zahtjevi sustava za upravljanje dokumentima........................................................................... 38
6.3. Ostale funkcionalnosti sustava za upravljanje dokumentima .................................................................. 39
6.3.1. Radni proces dokumenta ................................................................................................................ 39
6.3.2. Raspodjela poslova na zaposlenike................................................................................................. 39
6.3.3. Praćenje stanja dokumenta u sustavu.............................................................................................. 40
6.3.4. Autorizacija i sigurnost ................................................................................................................... 40
6.4. Ţivotni ciklus dokumenta ........................................................................................................................ 40
7. Praktični rad .................................................................................................... 42
7.1. Osnovni zahtjevi sustava ......................................................................................................................... 42
7.2. Korisničke priče ...................................................................................................................................... 42
7.2.1. Ulaz novog dokumenta u sustav ..................................................................................................... 42
7.2.2. OdreĎivanje tipa dokumenta ........................................................................................................... 43
7.2.3. Obrada ulaznih/izlaznih računa ...................................................................................................... 43
7.2.4. Odobravanje ulaznih računa ........................................................................................................... 44
7.2.5. Plaćanje računa ............................................................................................................................... 44
7.3. Detaljan opis sustava ............................................................................................................................... 44
7.3.1. Dijagram slučajeva korištenja ......................................................................................................... 44
7.3.2. Mogući tipovi dokumenata ............................................................................................................. 45
7.3.3. Grupe korisnika .............................................................................................................................. 45
7.3.4. Radni procesi .................................................................................................................................. 46
7.3.4.1. OdreĎivanje jedinstvenog identifikatora i tipa dokumenta ..................................................... 46
7.3.4.2. Ulazni račun ........................................................................................................................... 47
7.3.4.3. Izlazni račun ........................................................................................................................... 48
7.3.4.4. Unos podataka o plaćanju ...................................................................................................... 48
7.4. Implementacija sustava ........................................................................................................................... 49
7.4.1. Arhitektura sustava ......................................................................................................................... 49
7.4.1.1. Baza podataka ........................................................................................................................ 50
7.4.1.2. Server-side aplikacija ............................................................................................................. 51
7.4.1.3. Client-side aplikacija .............................................................................................................. 53
7.5. Korištenje sustava ................................................................................................................................... 55
7.5.1. Instalacija ........................................................................................................................................ 55
7.5.1.1. Preduvjeti ............................................................................................................................... 55
III
7.5.1.2. Postavljanje baze podataka..................................................................................................... 55
7.5.1.3. Postavljanje sustava ............................................................................................................... 56
7.5.2. Prijava u sustav ............................................................................................................................... 58
7.5.3. Pregled svih dokumenata ................................................................................................................ 59
7.5.4. Upload novog dokumenta ............................................................................................................... 60
7.5.5. OdreĎivanje jedinstvenog identifikatora dokumenta ...................................................................... 61
7.5.6. OdreĎivanje tipa dokumenta ........................................................................................................... 61
7.5.7. Popunjavanje podataka za dokument .............................................................................................. 62
7.5.8. Odobravanje dokumenta ................................................................................................................. 63
7.5.9. Unos plaćanja za dokument ............................................................................................................ 64
7.6. Budući rad i mogući napredak sustava .................................................................................................... 65
8. Zaključak ......................................................................................................... 67
9. Literatura ......................................................................................................... 69
1
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 NoSQL1 baze podataka jer
upravo one omogućuju pohranjivanje cijelih dokumenata, najčešće u JSON2 formatu.
Prednost takvih baza podataka jest u tome što one nemaju definiranu shemu, za razliku od
SQL3 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
2
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 MongoDB4 NoSQL baza podataka, sustav za
upravljanje bazama podataka otvorenog koda5 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 single-
page6 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
3
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 1.
2.1. 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 𝐵 ⊆ 𝑉 × 𝑉skup bridova. Usmjereni graf je G jest par (𝑉,𝐵). Za
svaki brid 𝑏 = (𝑣𝑖 , 𝑣𝑗 ) kažemo da je 𝑣𝑖 početak, a 𝑣𝑗 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 (𝑉,𝐵) je stablo ako postoji jedinstveni put od 𝑣𝑘 do 𝑣𝑖 za svaki 𝑣𝑖 ∈ 𝑉, 𝑖 ≠ 𝑘.
Svako stablo je ujedno i aciklički graf te ima jedinstven korijen stabla.
Definicija 4. - Podatkovni graf
Podatkovni graf je usmjereni graf (𝑉,𝐵) č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.
4
2.2. Općenito o polustrukturiranom modelu podataka
Polustrukturirani model podataka nema shemu, poput relacijskog, a često ga se opisuje
korištenjem termina self-describing7, š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 pod-
objekata. 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: "+385911234567",
email: "[email protected]"
}
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: "+385911234567",
email: "[email protected]"
}
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
5
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: "+385911234567",
email: "[email protected]"
},
osoba: {
ime: "Franjo",
tel: "+385917654321",
email: "[email protected]"
}
}
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: "+385911234567",
email: "[email protected]"
},
osoba: {
ime: {
first: "Franjo",
last: "Franjić"
},
tel: "+385917654321",
email: "[email protected]"
}
}
Prikaz koda 4. Razlike u objektima kod polustrukturiranog modela podataka
6
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.
2.3.1. 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
c4 d4
Slika 2. Prikaz relacija i njihovih vrijednosti
Podaci iz relacija se mogu prikazati kao polustrukturirani tip podatka, kao u prikazu koda 5.
{ r1: {
redak: {
{ a: a1, b: b1, c: c1 }
},
redak: {
{ a: a2, b: b2, c: c2 }
}
},
r2: {
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.
7
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
2.3.2. 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. 137.
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
8
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.
9
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.
3.1. 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: http://json.org/array.gif)
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: http://json.org/object.gif)
null - prazna vrijednost, korištenjem ključne riječi null
10
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": 180.35,
"address": {
"streetAddress": "Zagrebačka 57",
"city": "Varaždin",
"postalCode": "42000"
},
"phoneNumbers": [
{ "type": "kucni", "number": "+38542 555-1234" },
{ "type": "mobilni", "number": "+38591 555-4567" }
]
}
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 180.35cm. 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.
3.3. 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.
3.3.1. Primjer JSON Scheme
U nastavku je dan primjer JSON Scheme.
{
"$schema": "http://json-schema.org/draft-03/schema#",
"name": "Osoba",
"type": "object",
"properties": {
"OIB": {
"type": "string",
"description": "Identifikator osobe",
"required": true,
"minLength": 11,
"maxLength": 11
},
11
"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": "12345678900",
"firstName": "Ivan",
"lastName": "Ivić",
"godine": 30
}
Prikaz koda 9. Podaci za prikazanu JSON Schemu
3.4. Korištenje JSON formata
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.
12
{
"id": "120139364741828",
"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": "187751327923426",
"name": "Educational Organization"
},
{
"id": "108051929285833",
"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. 2012. godine je proslavio 50
godina postojanja. Prvih 12 godina djelovao je kao Visoka ekonomska škola,
a od 1974. 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": "https://www.facebook.com/foi.varazdin",
"location": {
"city": "Varazdin",
"country": "Croatia",
"latitude": 46.3076448617,
"longitude": 16.3382300876,
"street": "Pavlinska 2",
"zip": "42000"
},
"name": "Faculty of Organization and Informatics",
"phone": "+385 42 390 818 ",
"talking_about_count": 848,
"username": "foi.varazdin",
"website": "http://www.foi.unizg.hr"
}
Prikaz koda 10. Primjer odgovora javno dostupnog Facebook Graph API-a u JSON formatu
13
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 skalabilniji8 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
14
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.
4.1.1. 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.
15
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 BSON9, š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.
4.1.2. 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].
16
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.
4.1.3. 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.
4.2. 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 agregirati10
prema upisanim kolegijima ili smjerovima.
4.2.1. 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 MapReduce11
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 4.6.4.2.
17
4.2.2. 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.
4.2.3. 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.
4.3. 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.
4.3.1. 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.
18
4.3.2. 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.
4.4. Korištenje API-ja
Kao što nam je poznato, API12
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.
4.4.1. 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
19
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.
4.6. 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.
4.6.1. 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": "12345678900",
"firstName": "Ivan",
"lastName": "Ivić",
"hobiji": [ "tenis", "vinogradarstvo" ]
}
Prikaz koda 11. Dokument u MongoDB sustavu
20
Svi dokumenti u sustavu se pohranjuju unutar collectiona13
. 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: http://docs.mongodb.org/manual/_images/crud-annotated-collection.png)
4.6.2. Č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 projekcije14
.
U nastavku je na slici 8 prikazan jednostavan upit koji pretraţuje "users" collection.
Slika 8. Jednostavan upit u MongoDB sustavu (Izvor: http://docs.mongodb.org/manual/_images/crud-annotated-mongodb-
find.png)
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: http://docs.mongodb.org/manual/_images/crud-annotated-sql-
select.png)
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
21
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:
http://docs.mongodb.org/manual/_images/crud-query-stages.png)
Sa slike je vidljivo da je kao izvor podataka dan "users" collection. Pomoću operatora $gt15
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.
4.6.3. 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.
4.6.3.1. 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)
22
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: http://docs.mongodb.org/manual/_images/data-model-
normalized.png)
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.
23
Slika 12. UgraĎivanje dokumenata (Izvor: http://docs.mongodb.org/manual/_images/data-model-denormalized.png)
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žavanja16
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.
24
4.6.3.2. 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: "12345678900",
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: "12345678900",
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
25
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"
}
{
_id: "foi",
name: "Fakultet organizacije i
informatike",
city: "Varaždin"
}
Prikaz koda 15. Primjer veze jedan-više korištenjem referenci
26
4.6.4. 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
4.6.4.1. 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 map-
reduce 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: http://docs.mongodb.org/manual/_images/aggregation-pipeline.png)
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
27
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
4.6.4.2. 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:
http://docs.mongodb.org/manual/reference/operator/aggregation/#aggregation-pipeline-operator-reference)
28
Slika 14. Korištenje map-reduce operacije (Izvor: http://docs.mongodb.org/manual/_images/map-reduce.png)
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.
29
4.6.4.3. 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.
30
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 $lt18
),
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)
31
4.6.5. 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 Shutterfly20
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 http://www.shutterfly.com/
32
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 NoSQL baze podataka
Baza podataka Baza podataka
Tablica Collection
Redak Dokument
Indeks Indeks
JOIN21
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 99. 22
Object Relational Mapper - tehnika za pretvaranje podataka iz nekompatibilnih (najčeše iz relacijskih baza) u
objekte u objektno-orijentiranim programskim jezicima.
33
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, 47.232],
cars: [
{
model: "Bentley",
year: 1973,
value: 100000,
...
},
{
model: "Rolls Royce",
year: 1965,
value: 330000,
...
}
]
}
Prikaz koda 19. Strukturirani JSON dokument(Prema: RDBMS to MongoDB Migration Guide, str. 4)
34
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 podataka23
, 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.
5.2. 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.
35
MongoDB sustav ima Agregacijski okvir koji ima funkcionalnost sličnu GROUP BY24
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.
5.3. 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 87.
36
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.
6.1. 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.
6.1.1. INoffice2
INoffice2 je sustav tvrtke IN225
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: http://www.in2.hr/
37
6.1.2. .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: http://utilis.biz/Uploads/1/3/12/35/EDR_HR.pdf)
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: http://utilis.biz/Default.aspx?sid=11
38
6.1.3. Senso
Senso sustav za upravljanje dokumenata tvrtke Senso profi d.o.o.27
je sustav koji koristi
Alfresco28
. 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.
6.2. 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 5.
1. 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: http://www.senso.hr/ 28
Alfresco - vodeći sustav za upravljanje dokumentima otvorenog koda. Izvor: http://www.alfresco.com/
39
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.
6.3. Ostale funkcionalnosti sustava za upravljanje dokumentima
6.3.1. 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.
6.3.2. Raspodjela poslova na zaposlenike
"Sustav treba omogućiti raspodjelu poslova po djelatnicima, tj. zaduţivanje djelatnika s
rokovima dovršetka posla." Izvor [9], str. 17.
40
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.
6.3.3. 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.
6.3.4. 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.
6.4. Ţ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.
41
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.
42
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.
7.1. 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.
7.2. Korisničke priče
U nastavku je prikazano nekoliko korisničkih priča na temelju kojih će biti kreiran dijagram
slučajeva korištenja29
i implementirane funkcionalnosti aplikacija.
7.2.1. 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.
43
7.2.2. 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.
7.2.3. 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.
44
7.2.4. 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.
7.2.5. 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.
7.3. Detaljan opis sustava
7.3.1. 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
45
Slika 17. Dijagram slučajeva korištenja za sustav za upravljanje dokumentima
7.3.2. 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
7.3.3. 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.
46
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.
7.3.4. 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.
7.3.4.1. 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 "2014.0111", 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.
47
Slika 18. OdreĎivanje jedinstvenog identifikatora i tipa dokumenta
7.3.4.2. 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
48
7.3.4.3. 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
7.3.4.4. 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
49
7.4. Implementacija sustava
Praktični dio ovog rada, sustav za upravljanje dokumentima, je implementiran kao single-
page 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
7.4.1. Arhitektura sustava
Sustav je graĎen kroz tri sloja. Arhitektura sustava je prikazana na slici 22.
Slika 22. Arhitektura sustava za upravljanje bazama podataka
50
7.4.1.1. 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.
51
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.
7.4.1.2. 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 mongojs30
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
email - email 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:
https://github.com/mafintosh/mongojs
52
Metoda URL pristupa Potrebni parametri Svrha
Korisnik
POST /user method
o login
password
o 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 fullsize
o 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
53
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
7.4.1.3. 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.
54
Implementacija
Cjelokupna aplikacija na klijentskoj strani je implementirana korištenjem JavaScript
programskog jezika, i to ponajviše Module Pattern31
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 Bootstrap32
, 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 grunt33
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: http://getbootstrap.com/ 33
grunt - JavaScript izvršavatelj zadataka, Izvor: http://gruntjs.com/
55
7.5. Korištenje sustava
U nastavku je dan prikaz korištenja sustava implementiranog kao praktični dio ovog rada.
7.5.1. Instalacija
7.5.1.1. Preduvjeti
Preduvjeti potrebni za instalaciju sustava na kojem je bilo koja Linux distribucija34
:
mongoDB35
- sustav za upravljanje bazama podataka
npm36
- upravitelj paketima (eng. package manager) za NodeJS platformu
web server - najkorišteniji i najpoznatiji web server je Apache
Opcionalno, moguće je instalirati RockMongo37
, 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.
7.5.1.2. 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 17. 35
Tutorijal za instalaciju na Ubuntu baziranim distribucijama: http://docs.mongodb.org/manual/tutorial/install-
mongodb-on-ubuntu/ 36
npm - Node Package Manager. Izvor: https://www.npmjs.org/ 37
RockMongo - alat za administraciju, Izvor: http://rockmongo.com/, Tutorijal za instalaciju:
http://blog.khairulazam.net/2013/05/19/install-rockmongo-on-ubuntu/
56
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.
7.5.1.3. 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.
57
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 e-mail adresu [email protected] te lozinku diplomski.
58
7.5.2. 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.
59
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.
7.5.3. 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
60
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.
Slika 29. Modul Dokumenti
7.5.4. Upload novog dokumenta
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
61
7.5.5. 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.
7.5.6. 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.
62
Slika 32. OdreĎivanje tipa dokumenta
7.5.7. 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.
63
Slika 33. Popunjavanje podataka za dokument
Nakon što su uneseni svi podaci, potrebno je pritisnuti gumb Jesam, koja označava završetak
zadatka.
7.5.8. 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.
64
Slika 34. Odobravanje dokumenta
Jednom kada je dokument odobren, za njega se mogu unositi plaćanja
7.5.9. 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
65
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.
7.6. 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.
66
Podrška za veći broj tipova dokumenata - naravno da u stvarnim situacijama i
organizacijama postoji puno veći broj tipova dokumenata. UvoĎenjem podrške za više
tipova dokumenata bi trebalo osmisliti i radne procese za svaki od novih tipova
dokumenata.
Implementacija modula za plaćanje - modul za plaćanje bi predstavljao veliko
olakšanje i smanjenje utroška vremena potrebnog za plaćanje računa. Idealno bi bilo
kada mi sustav imao vlastiti modul putem kojeg bi se moglo direktno platiti odreĎene
račune. Mogućnosti su razne, korištenje PayPal-a38
, pa sve do razvoja vlastitog
modula za plaćanje.
Novi načini ulaska dokumenata u sustav - samo upload skeniranih dokumenata nije
dovoljan za normalno funkcioniranje ovakvih sustava jer zahtijeva još dodatnog posla.
Idealno bi bilo kada bi skener, nakon što skenira neki dokument, isti poslao na FTP
server s kojeg bi se automatski dokumenti ubacili u sustav za upravljanje
dokumentima. TakoĎer, mogao bi postojati neki servis koji bi primljene dokumente
preko elektroničke pošte automatski proslijedio u sustav.
Generiranje izvještaja - s obzirom na to da se u sustavu prate financijski dokumenti,
puno bi značila funkcionalnost koja bi mogla generirati odreĎeni izvještaj. Ti izvještaji
bi mogli biti vezani za pojedine tipove dokumenata, sve dokumente, vremenska
razdoblja i mnoge druge faktore.
Grafičko sučelje za unos radnih procesa i editiranje korisničkih grupa - grafičko
sučelje za unos i editiranje navedenih stavaka bi uvelike olakšalo kreiranje novih
radnih procesa kao i ureĎivanje korisničkih grupa i njihovih članova. Zasada je to
moguće mijenjati samo direktno u bazi podataka.
38
PayPal - organizacija koja omogućava novčane prijenose putem interneta. Izvor: https://www.paypal.com
67
8. Zaključak
Zbog sve većih problema tradicionalnog načina uredskog poslovanja javila se potreba za
izgradnjom aplikacija koje će olaškati praćenje cjelokupnih radnih procesa nad dokumentima
u organizacijama.
Sustavi za upravljanje dokumentima su pruţili upravo to - u njima se svaki dokument prati od
ulaska u organizaciju pa sve do arhiviranja. Uz radne procese za svaki dokument, trebali bi
pruţati i podršku za dozvolu pristupa pojedinim podacima, odnosno to da različitke zadatke
obavljaju različite osobe i te osobe nemaju potrebu vidjeti zadatke drugih osoba.
S obzirom na to da je u baze podataka potrebno pohranjivati polustrukturirane, pa čak i
nestrukturirane podatke, NoSQL baze podataka se sve više koriste.
Nekoliko je prednosti NoSQL baza podataka, ali najbitnije su da ne postoji shema, koja je u
relacijskim bazama podataka ograničavala unos podataka u relacije. TakoĎer, NoSQL sustavi
su skalabilniji i pruţaju bolje performanse od relacijskih sustava za upravljanje bazama
podataka.
NoSQL baze podataka pruţaju idealan način za pohranu podataka u sustavima za upravljanje
dokumentima. Dokumente je u takvim sustavima vrlo lako prikazati kao polustrukturirani
model podataka, gdje ne postoji shema, a različiti dokumenti mogu imati različite podatke.
No, NoSQL baze podataka imaju i neke loše strane, ponajprije se moţe istaknuti to što nema
sheme, pa je teţe shvatiti pravu strukturu podataka koji se pohranjuju. Isto tako, pod samim
pojmom NoSQL baza podataka se spominje veliki broj vrsta pohrane podataka, od kojih su u
ovom radu opisani modeli dokumenata, grafova kao i key-value, čime se postiţe odreĎena
doza nejasnoće korištenjem samog NoSQL pojma. Osim toga, relacijske baze podataka se
koriste dugi niz godina, dok su NoSQL baze podataka novijeg doba radi čega se moţe reći da
su relacijske baze podataka zrelije. Najteţe je zapravo reći koji pristup je bolji, a razlog tome
je taj što obje vrste baze podataka imaju prednost u odreĎenom području primjene.
U praktičnom dijelu ovog rada je korištena MongoDB baza podataka, koja je trenutno jedna
od vodećih NoSQL baza podataka. Za serversku stranu aplikacije je korištena NodeJS
platforma, koja je u posljednje vrijeme sve više korištena zbog svoje jednostavnosti i brzine.
Na klijentskoj strani je implementirana single-page web aplikacija korištenjem modernih
tehnologija, od kojih su najbitnije HTML, JavaScript, LESS te Handlebars.js za korištenje
predloţaka.
68
Ova tema je odabrana zbog toga što imam veliki interes u sustavima za upravljanje
dokumentima, ponajviše zbog toga što u organizaciji čiji sam trenutno član razvijamo jedan
sličan sustav, ali i zbog toga što smatram da ovakvi sustavi u velikoj mjeri mogu pomoći
organizacijama da prate svoje poslovanje.
69
9. Literatura
[1] MongoDB, Inc. (2013), Top 5 Considerations When Evaluating NoSQL Databases,
Dostupno na: http://www.mongodb.com/lp/whitepaper/nosql-considerations
[2] MongoDB, Inc, What is a Document Database?, Dostupno na:
http://www.mongodb.com/document-databases
[3] Binary JSON dokumentacija, Dostupno na: http://bsonspec.org/
[4] MongoDB dokumentacija, Dostupno na: http://docs.mongodb.org/manual/
[5] MongoDB, Inc. (2014), RDBMS to MongoDB Migration Guide, Dostupno na:
https://www.mongodb.com/lp/whitepaper/migration-rdbms-nosql-mongodb
[6] Couchbase (2013), Making the Shift from Relational to NoSQL, Dostupno na:
http://info.couchbase.com/Relational-to-NoSQL.html
[7] Rabuzin, K., (2013), Nastavni materijali iz kolegija: Skladišta podataka i poslovna
inteligencija, Dostupno na:
http://elfarchive.foi.hr/12_13/mod/resource/view.php?id=7199
[8] Rabuzin, K., (2011), Uvod u SQL, FOI Varaţdin, Zrinski Čakovec.
[9] Ujević, I., (2003), Sustav za upravljanje dokumentima, diplomski rad, Sveučilište u
Zagrebu, Fakultet elektrotehnike i računarstva, Dostupno na:
http://www.zpr.fer.unizg.hr/zpr/Portals/0/Osobe/Kreso/Sustav%20za%20upravljanje%20
dokumentima.pdf
[10] Document Management System, (2011), Dostupno na:
https://ruben.bolink.org/ebooks/AICTE%20Tender%20Document%20for%20Document
%20Management%20System.pdf
[11] Porter-Roth, B., Porter-Roth Associates, (2006), Applying Electronic Records
Management in the Document Management Environment: An Integrated Approach,
Xerox, Dostupno na: http://docushare.xerox.com/pdf/docushare_RM_whitepaper.pdf
[12] INoffice2 - za uredsko poslovanje, IN2 grupa, Dostupno na: http://www.in2.hr/inoffice2
[13] .EDR - sustav za upravljanje dokumentima, Utilis d.o.o., Dostupno na:
http://utilis.biz/Uploads/1/3/12/35/EDR_HR.pdf
[14] Senso sustav za upravljanje dokumentima, Senso profi d.o.o., Dostupno na:
http://www.senso.hr/dm/Upravljanje-dokumentima-i-poslovnim-procesima.html
[15] Schatten, M., Ivković, K., (2012), Regular Path Expression for Querying Semistructured
Data - Implementation in Prolog, Central European Conference on Information and
Intelligent Systems, FOI Varaţdin
[16] Abiteboul, S., Buneman, P., Suciu, D., (2000), Data on the Web - From Relations to
Semistructured Data and XML, Morgan Kaufmann Publishers, San Francisco, California
[17] Suciu, D., Semistructured Data and XML, AT&T Labs
[18] Maleković, M., (2008), Teorija baza podataka - skripta, FOI Varaţdin
[19] Osmani, A., (2014), Learning JavaScript Design Patterns, Dostupno na:
http://addyosmani.com/resources/essentialjsdesignpatterns/book/
