UNIVERZITET U BANJOJ LUCI

ELEKTROTEHNIČKI FAKULTET
STUDIJSKI PROGRAM RAČUNARSTVO I INFORMATIKA

Vid Malešević

RAZVOJ I PRIMJENA SISTEMA POSLOVNE

INTELIGENCIJE
diplomski rad

Banja Luka, jun 2015.

 Tema: Razvoj i primjena sistema poslovne inteligencije

Ključne riječi:
Skladišta podataka
OLAP
Transakcije
Star i snowflake šeme
Integracioni servisi
ETL
Izvještavanje
Denormalizacija baze podataka
Multidimenzionalno modelovanje baze podataka

Komisija: doc. dr Dražen Brđanin, predsjednik

prof. dr Slavko Marić, mentor
dipl. inž. el. Igor Dujlović, član

Uz rad je priložen CD.

Kandidat:
Vid Malešević
UNIVERZITET U BANJOJ LUCI
ELEKTROTEHNIČKI FAKULTET
KATEDRA ZA RAČUNARSTVO I INFORMATIKU

Predmet: Baze podataka

Tema: RAZVOJ I PRIMJENA SISTEMA POSLOVNE

INTELIGENCIJE

Zadatak: Opisati namjenu i područja primjene koncepta poslovne

inteligencije. Dati pregled i osnovne karakteristike postojećih
tehnologija, proizvoda i trendova u oblasti poslovne
inteligencije. Detaljnije opisati namjenu, koncept i
mogućnosti DW/OLAP tehnologija i alata, sa posebnim
osvrtom na Microsoft tehnologije. Detaljno analizirati
mogućnosti primjene DW/OLAP tehnologija i alata u oblasti
veletrgovine. Ilustrovati primjenu u navedenoj oblasti
razvojem sistema poslovne inteligencije korištenjem
Microsoft platforme i alata.

Mentor: prof. dr Slavko Marić

Kandidat: Vid Malešević (85/08)

Banja Luka, jun 2015.

SADRŽAJ
1. UVOD ................................................................................................................................ 1
2. OSNOVNE KARAKTERISTIKE I ISTORIJSKI RAZVOJ SISTEMA
POSLOVNE INTELIGENCIJE ............................................................................................. 3
2.1 Istorijski razvoj sistema poslovne inteligencije ............................................................ 3
2.2 Prikupljanje i analiza podataka u organizacionim sistemima ...................................... 5
2.3 Karakteristike BI sistema ............................................................................................ 5

3. DIMENZIONALNI MODEL .......................................................................................... 7

3.1 Fact tabele ................................................................................................................... 8
3.1.1 Granularnost ..................................................................................................................... 8
3.1.2 Aditivnost mjera................................................................................................................. 9
3.1.3 Čuvanje istorije izmjena u BI sistemima ........................................................................... 9
3.2 Dimenzionalne tabele ................................................................................................ 10
3.2.1 Dimenzije koje se sporo mijenjanju (slowly changing dimensions) ................................ 11
3.3 OLAP kocka, star šema ............................................................................................. 12
3.4 Snowflake šema ......................................................................................................... 14

4. ETL PROCES ................................................................................................................. 15

4.1 ETL podsistemi ......................................................................................................... 18
4.1.1 Ekstrahovanje podataka .................................................................................................. 18
4.1.2 “Pročišćavanje” i validacija podataka ........................................................................... 18
4.1.3 Upis podataka u dimenzionalne i fact tabele................................................................... 19
4.1.4 Podsistemi za upravljanje ETL okruženjem .................................................................... 20
5. POREĐENJE POSTOJEĆIH BI RJEŠENJA ............................................................. 21
5.1 Tableau Software ...................................................................................................... 22
5.2 Microsoft ................................................................................................................... 23
5.3 SAP ........................................................................................................................... 24
5.4 IBM ........................................................................................................................... 25
5.5 Jaspersoft .................................................................................................................. 26

6. PRAKTIČNA REALIZACIJA SKLADIŠTA PODATAKA ..................................... 28

6.1 Logički dizajn skladišta podataka ............................................................................. 29
6.1.1 Formiranje dimenzija ...................................................................................................... 29
6.1.2 Formiranje fact tabele ..................................................................................................... 34
6.2 Fizički dizajn skladišta podataka............................................................................... 35
6.2.1 Paket Extract ................................................................................................................... 36
6.2.2 Paket Transform .............................................................................................................. 37
6.2.3 Paket Load ....................................................................................................................... 37
6.2.4 Paket ExcelDimensionsExport ........................................................................................ 39
6.2.5 Paket WebServis .............................................................................................................. 40
6.2.6 Paket Main....................................................................................................................... 43
7. IZVJEŠTAVANJE U SISTEMIMA POSLOVNE INTELIGENCIJE ..................... 45
7.1 Tehnike kreiranja izvještaja u SSRS ......................................................................... 46
7.2 Pregled kreiranih izvještaja....................................................................................... 47

8. MULTIDIMENZIONALNO MODELOVANJE......................................................... 51
8.1 Implementacija koncepata multidimenzionalnog modelovanja podataka u SSAS ..... 52
 8.2 Integracija SSAS i SSRS............................................................................................ 57

9. ZAKLJUČAK ................................................................................................................. 59
LITERATURA........................................................................................................................ 61

Uz rad je priložen CD.

1. UVOD

U današnje vrijeme dosta vremena i novca se ulaže u poslovne aplikacije poput ERP
(eng. Enterprise Resource Planing), SCM (eng. Supply Chain Management) i CRM (eng.
Customer Relationship Management) sisteme. Primarna motivacija za takva ulaganja je
postizanje veće kontrole nad svakodnevnim operacijama u poslovnim sistemima. Opšte
mišljenje je da se navedeni poslovni sistemi mogu iskoristiti kao izvori podataka koje će ciljni
sistem koristiti kao podršku pri donošenju odluka. Na osnovu navedenog, potrebno je
projektovati sistem koji će na najbolji način iskoristiti ogromnu količinu podataka dobijenih iz
poslovnih transakcija (narudžbe, prodaje, vođenje evidencija o događajima itd.) radi pružanja
boljeg uvida u rad organizacije, kao i podrške pri donošenju ključnih odluka.

Ukoliko se jedna organizacija fokusira na rast i razvoj, dostupnost kvalitetnih

informacija je od ključnog značaja. Zbog razvoja novih tehnologija i konstantnog dotoka
novih podataka, organizacije postaju zatrpane različitim podacima koji nisu uvijek od koristi
za funkcionisanje organizacije. Da bi svi ti podaci bili obrađeni potrebno je uložiti mnogo
vremena, ljudskih ali i drugih resursa kojima organizacija raspolaže, što nije uvijek pogodno
budući da organizacija raspolaže sa konačnim resursima.

U cilju efikasnog funkcionisanja organizacije potrebno je uspostaviti dobre temelje na

kojima će počivati informacioni sistem organizacije. Potrebno je da on na odgovarajući način
integriše postojeća IT rješenja, strukture podataka, metode prikupljanja podataka kao i
odgovornosti za pružanje podataka. Prije nego što započne proces obrade i konsolidacije
podataka, potrebno je utvrditi da li su izvori iz kojih podaci dolaze vjerodostojni i da li su
prethodno uskladišteni podaci bili korektni. Analizom podataka iz pouzdanih izvora doprinosi
se stvaranju većeg broja prepoznatljivih vrijednosti za organizaciju što dalje vodi ka
sveukupno boljem poslovanju.

Samo donošenje odluka nije u potpunosti uniforman proces i ono je kontekstno

zavisno u smislu nivoa na kojima se donose odluke u jednoj organizaciji. Na primjer, na
operacionom (najnižem) nivou organizacije, strukturirane odluke se donose na dnevnoj bazi i
one nemaju dugoročan efekat na poslovanje. Na srednjem nivou (eng. middle level
management) odluke postaju djelimično strukturirane i posljedica su izvještaja i analize
podataka dobijenih sa operacionog nivoa, kao i samostalnih analiza na srednjem nivou.
Odluke na strateškom nivou su nestrukturirane, donose ih oni koji upravljaju firmom i one
utiču na organizaciju dugoročno, što znači da loše donesene odluke mogu imati katastrofalne
posljedice. Iz tog razloga se uvode sistemi poslovne inteligencije koji olakšavaju izvršavanje
navedenih procesa.

U radu, koji je podijeljen u devet poglavlja, razmotrene su tehnike implementacije

skladišta podataka, sistema za izvještavanje i sistema za multidimenzionalnu analizu
podataka.

U drugom poglavlju objašnjen je pojam poslovne inteligencije, istorija sistema

poslovne inteligencije kao i problemi sa kojima se suočavaju organizacije u svom poslovanju,
a koje bi poslovna inteligencija mogla da riješi. Takođe, su date i karakteristike sistema
poslovne inteligencije i razmotreni su različiti konteksti upotrebe.

1
 U trećem poglavlju objašnjen je pojam dimenzionalnog modelovanja, navedene su
prednosti i mane tog načina projektovanja BI (eng. Business Intelligence) sistema. Dat je i
detaljniji pregled koncepata star šema, snowflake šema i OLAP (eng. Online Analytical
Processing) kocka. Takođe, objašnjen je pojam fact tabela, granularnosti fact tabela i
aditivnosti mjera kao i postupci projektovanja fact tabela. U nastavku trećeg poglavlja
pokazani su načini za projektovanje dimenzionalnih tabela u sistemima poslovne inteligencije
kao i veza dimenzionalnih tabela i dimenzionalnog modela. Uveden je SCD (eng. Slowly
Changing Dimensions) koncept dimenzija koje se sporo mijenjaju i analizirani su mehanizmi
implementacije ovog koncepta.

U četvrtom poglavlju dato je detaljno objašnjenje ETL (eng. Extract, Transform,

Load) procesa pri čemu su analizirani zahtjevi za uvođenje ETL procesa u poslovni sistem.
Takođe, detaljno je razmotrena arhitektura ETL sistema i analizirana njegova 34 podsistema.

Peto poglavlje se odnosi na poređenje postojećih, najaktuelnijih sistema poslovne

inteligencije.

U šestom poglavlju pokazano je kako se teoretski koncepti izloženi u prethodnim

poglavljima mogu primijeniti u svrhu dizajna konkretnog skladišta podataka. Analizirane su
faze logičkog i fizičkog dizajna, a zatim je sprovedeno kreiranje skladišta podataka.

U sedmom poglavlju demonstrirana je implementacija sistema izvještavanja, koja se

oslanja na kreirano skladište podataka radi dostavljanja potrebnih podataka onima koji ih
zahtijevaju. Uz to, demonstrirana je podrška za izvještavanje na Web-u, kao i sam proces
dizajna jednog izvještaja u sistemu poslovne inteligencije.

Osmo poglavlje prikazuje koncepte multidimenzionalnog modelovanja podataka i

kako se ti koncepti mogu iskoristiti za predviđanje trendova, donošenje boljih odluka kao i
fleksibilnije izvještavanje. Takođe, pokazano je na koji način je moguće povezati sistem
izvještavanja, implementiran u sedmom poglavlju, sa sistemom multidimenzionalne analize
implementiranim u osmom poglavlju.

Na kraju rada dat je zaključak i navedene su prednosti i nedostaci sistema poslovne

inteligencije na osnovu dizajna jednog skladišta podataka.

2
2. OSNOVNE KARAKTERISTIKE I ISTORIJSKI RAZVOJ
SISTEMA POSLOVNE INTELIGENCIJE

Poslovna inteligencija (eng. Business Intelligence, BI) je skup tehnika i alata za

transformaciju sirovih podataka u informacije od značaja, koje se kasnije mogu iskoristiti u
svrhu poslovne analize. BI tehnologije su pogodne za upravljanje velikim količinama
podataka, omogućavaju identifikaciju, razvoj i uopšteno kreiranje novih strateških poslovnih
prilika.

Ciljevi poslovne inteligencije su omogućavanje jednostavne interpretacije ogromnih

količina podataka, identifikovanje novih poslovnih prilika i implementiranje efektivne i
efikasne poslovne strategije, dugotrajne stabilnosti i čvrste pozicije jedne organizacije na
tržištu. BI tehnologije pružaju istorijske (prošlost), trenutne (sadašnjost) i prediktivne
(budućnost) poglede na poslovne operacije. Najčešći primjeri upotrebe poslovne inteligencije:

 izvještavanje – kreiranje izvještaja prema potrebama korisnika,

 online analitičko procesiranje,
 analitika,
 rudarenje podataka (eng. data mining),
 rudarenje procesa (eng. process mining),
 kompleksno procesiranje događaja,
 upravljanje poslovnim performansama,
 prediktivna analitika.

Poslovna inteligencija se može koristiti na način da podrži širok spektar poslovnih

odluka, od operacionih (poput pozicioniranja i cijene proizvoda) do strateških (misija, vizija,
ciljevi organizacije). Najpovoljniji rezultati primjene sistema poslovne inteligencije postižu se
kombinovanjem podataka koji su dobijeni direktno kao rezultat poslovanja organizacije
(eksterni podaci) sa internim podacima jedne organizacije (finansijski i operacioni podaci).
Na ovaj način mogu se ekstrahovati podaci koji inače ne bi bili dostupni ni iz jednog
pojedinačnog skupa podataka [1]. Navedeni razlozi su doveli do popularizacije poslovne
inteligencije i danas ona predstavlja okosnicu poslovanja u organizacijama koje prepoznaju
značaj poslovne inteligencije.

2.1 Istorijski razvoj sistema poslovne inteligencije

U radu „Enciklopedija komercijalnih i poslovnih anegdota” (Richard Devens, 1865.)

prvi put je zvanično upotrijebljen pojam “poslovna inteligencija”. Autor rada je primjetio da
je bankar Sir Henrey Furnese prikupljao informacije iz velikog broja izvora, na određeni
način ih analizirao, a zatim na osnovu analize donosio odluke. Pokazalo se da je imao veliku
prednost u odnosu na svoje konkurente jer je mogao da predvidi određene trendove.

Poslovna inteligencija, u obliku u kakvom postoji danas, evoluirala je iz sistema za

podršku pri odlučivanju (eng. Decision Support Systems, DSS), koji je bio aktuelan šezdesetih
godina prošlog vijeka i koji se razvijao do sredine osamdesetih godina prošlog vijeka. Na
osnovu DSS-a, koji je nastao u modelima gdje je računar pomagao čovjeku da na neki način
upravlja, nastala su skladišta podataka (eng. Data Warehouses, DW), izvršni informacioni
sistemi (eng. Executive Information Systems, EIS), OLAP, a sredinom osamdesetih godina
prošlog vijeka i poslovna inteligencija.
3
 Nakon objavljivanja članka "A Business Intelligence System", 1958. godine (Hans
Peter Luhn, IBM) u kojem se spominje termin poslovne inteligencije, prepoznat je potencijal
poslovne inteligencije u kontekstu unapređenja poslovanja. Članak je govorio o
automatizovanom sistemu koji potencijalno može biti razvijen za širenje informacija u
različitim oblastima industrijskih, naučnih ili vladinih organizacija. Navedene oblasti su se
intenzivno razvijale nakon Drugog Svjetskog rata i bilo je potrebno organizovati i
pojednostaviti prikupljene podatke. Danas se smatra da je Luhn “otac poslovne inteligencije”,
jer je postavio temelje za današnje sisteme poslovne inteligencije. Na konferenciji “The
multiway data analysis consortium” u Rimu, 1988. godine, usvojena je jednostavnija
metodologija za projektovanje BI sistema, sa ciljem da se BI sistemi maksimalno
pojednostave za korišćenje.

Nakon toga, Gartnerov analitičar Howard Dresner je iskoristio frazu “poslovna

inteligencija” da bi obuhvatio imena koja nisu zvučala intuitivno ljudima, poput DSS i EIS u
svakodnevnom govoru. EIS su sistemi koji pružaju agregirane informacije strateškom
menadžmentu organizacije radi lakšeg upravljanja organizacijom [2], [3]. Povećanjem
konkurencije među proizvođačima došlo je do značajnog napretka u oblasti poslovne
inteligencije poput pojave skladišta podataka. Eksplozija Interneta i “Big data” koncepta
učinila je da organizacije imaju ogroman broj podataka koje treba na neki način organizovati i
obraditi prije korišćenja. Koncept Big data predstavlja podatke jedne organizacije dobijene
kroz nove tehnike za obradu podataka kao i upotrebu tih podataka u svrhu stvaranja novih
vrijednosti za organizaciju [4].

Kod skladišta podataka podaci se nalaze na jednom mjestu i dostupni su za

pretraživanje, promjenu, agregaciju, izvlačenje zaključaka, analitiku i druge operacije. Na taj
način se smanjuje vrijeme potrebno za pristup podacima koji se tradicionalno čuvaju na
različitim mjestima. Osim DW-a razvijale su se i druge tehnike i procesi koji služe kao
podrška pri korišćenju sistema poslovne inteligencije poput ETL i OLAP. Ova faza razvoja
oblasti poslovne inteligencije dobila je naziv “Poslovna Inteligencija 1.0” [5].

U periodu “Poslovne inteligencije 1.0”, devedesetih godina prošlog vijeka, dva glavna
zadatka poslovne inteligencije bila su generisanje izvještaja i podataka, kao i predstavljanje
sadržaja na razumljiv način. Dva značajna problema koja su tada bila prisutna su
kompleksnost i vrijeme. Postojeća BI rješenja bila su razvijana isključivo za IT eksperte i bila
je potrebna značajna obuka u oblasti analitike da bi korisnici iz BI sistema mogli izvesti
zaključke. Pristup podacima je bio veoma spor a generisanje izvještaja je dugo trajalo zbog
lošeg načina smještanja podataka.

U fazi razvoja poslovne inteligencije “Poslovna inteligencija 2.0” [5] značajno se

razvila tehnologija, pa su problemi kompleksnosti i vremena izvršavanja smanjeni, a u većini
slučajeva potpuno eliminisani. Uvedene su nove tehnologije, poput procesiranja podataka u
realnom vremenu, što je omogućilo kompanijama da imaju najsvježije podatke na osnovu
kojih mogu donositi odluke i upravljati kompanijom. Druge tehnologije su omogućavale da
korisnici koji nisu domenski eksperti mogu koristiti BI sisteme.

Do 2005. godine intenzivno je rasla potreba za virtuelnom saradnjom u poslovnom

svijetu, što podrazumijeva da su kompanijama bile potrebne informacije vezane za poslovne
procese koje bi dobijali u realnom vremenu (npr. komentari potrošača, komentari vezani za
proizvode, usluge i slično).

4
 Počevši od 2000. godine oblast poslovne inteligencije prošla je kroz intenzivan proces
dorade i poboljšanja. Danas se BI alati dizajniraju za veoma specifične namjene, poput
vojske, zdravstvenog sektora, robnog i materijalnog poslovanja itd. Razvoj alata za specifične
namjene napravio je značajan doprinos brzom usvajanju sistema poslovne inteligencije u
različitim organizacijama. “Samoposlužni” alati (korisnik može da koristi BI sistem bez
obzira da li je domenski ekspert) i alati za vizuelizaciju podataka se oslanjaju jedni na druge
da bi mogli da napreduju i da se razvijaju. Alati za vizuelizaciju su evoluirali na način da sada
uključuju i krajnjeg korisnika u kompletan proces, tj. krajnjem korisniku daju sve moćnije
alate da bi on samostalno mogao iskoristiti i istraživati podatke, bez dodatne obuke ili
objašnjavanja.

2.2 Prikupljanje i analiza podataka u organizacionim sistemima

Jedna od najbitnijih svojina jedne organizacije je informacija. U većini slučajeva

informacije se koriste za vođenje evidencije o osobama, stvarima ili događajima od interesa,
kao i u svrhu donošenja odluka.

U terminima poslovne inteligencije, definišemo operacioni sistem. Pojam operacioni

sistem odnosi se na sistem koji se koristi da bi se procesirale transakcije jedne organizacije na
dnevnom nivou. Takvi sistemi su dizajnirani na način da se dnevno procesiranje transakcija
obavlja vrlo efikasno i na način da se integritet transakcionih podataka u potpunosti održi.
Sinonimi koji se koriste za operacione sisteme su operacione baze podataka, sistemi za
procesiranje transakcija i OLTP (eng. Online Transaction Processing) sistemi. Podaci koji se
procesiraju od strane operacionih sistema nazivaju se “operacioni podaci”. Primjeri takvih
podataka su podaci o proizvodnji, računi u banci, podaci o pacijentima, studentima itd.

U kontekstu skladišta podataka, operacioni sistem je mjesto na koje smještamo

podatke, a DW/BI (eng. Data Warehousing/Business Intelligence) sistem je sistem iz kojeg
“izvlačimo” tj. ekstrahujemo podatke. Operacioni sistemi su optimizovani za brzu obradu
transakcija, a uglavnom se bave jednim transakcionim unosom u jednom trenutku i na
predvidiv način izvršavaju operacione zadatke. Na taj način operacioni sistemi pomažu
izvršavanje poslovnih procesa organizacije.

Operacioni sistemi ne čuvaju informacije o istoriji promjena već samo ažuriraju

podatke da bi reflektovali aktuelno stanje. Sa druge strane, korisnici BI sistema prate rad
organizacije u svrhu evaluacije performansi, odnosno da li se izvršavanje nekog poslovnog
procesa može na neki način unaprijediti, pri čemu vode računa i o tome da li se poslovni
procesi izvršavaju korektno. DW/BI sistemi su optimizovani za rad sa veoma kompleksnim
upitima koji potencijalno mogu zahtijevati obradu više stotina pa i hiljada transakcija, a zatim
i sažimanje svih podataka u jedan skup koji predstavlja rezultat. Dodatno, zahtjev za takve
sisteme je i čuvanje istorije promjena, da bi se nakon nekog vremena mogle evaluirati
performanse kompletnog sistema [1]. Nije dovoljno samo odvojiti podatke za analitiku od
operacionih podataka jer na taj način ne dobijamo DW/BI sistem, a performanse i
upotrebljivost su na osnovnom nivou.

2.3 Karakteristike BI sistema

BI sistemi moraju omogućiti da informacije budu lako dostupne, odnosno da je do njih

moguće doći na jednostavan način. Prilikom dizajna BI sistema, potrebno je voditi računa o
tome da podaci budu prezentovani na intuitivan i jednostavan način i da oni budu potpuno

5
razumljivi za krajnje korisnike, a ne samo za programere. Struktura tih podataka mora na neki
način da podsjeća na same poslovne procese unutar organizacije koje BI sistem modeluje.

Osim navedenih sistemskih zahtjeva, potrebno je da postoje i alati i aplikacije za rad

sa podacima u BI kontekstu, jednostavan pristup podacima kao i mogućnost manipulacije
podacima. Podaci u svakom trenutku moraju da budu konzistentni, o čemu je neophodno
strogo voditi računa jer lako može doći do problema zbog toga što podaci pristižu iz više
izvora. Potrebno je voditi računa i o označavanju podataka, jer u BI sistemu dva pojma (mjere
performansi) sa istom labelom moraju da se odnose na istu stvar.

Ukoliko je jedan BI sistem duže u produkciji, on mora da se prilagođava promjenama

koje nastaju zbog promjena poslovnih procesa, potreba korisnika, tehnoloških promjena ali i
drugih faktora. Nakon prilagođenja i promjene strukture sistema, BI sistem mora da bude u
mogućnosti da radi sa podacima koji su pristigli ranije, tj. sami podaci ne smiju biti
modifikovani.

U BI sistemima vrijeme figuriše kao veoma bitan faktor, pa oni u skladu sa tim moraju
da prezentuju informacije u vremenski korektnom redoslijedu. Sirovi podaci moraju imati
kontekst i značenje u vremenskom domenu (npr. sati, minute, itd). Osim toga, BI sistemi
moraju biti otporni na napade različitih eksternih faktora koji za cilj potencijalno imaju krađu,
promjenu podataka ili bilo kakvo ugrožavanje rada sistema i organizacije [1]. Nakon
dizajniranja BI sistema, puštanja u produkciju i testiranja, korisnici sistema uglavnom imaju
slike o tome kako sistem radi i koliko je on pouzdan. BI sistemi treba da budu pouzdani i
stabilni zbog toga što se koriste kao podrška pri odlučivanju i upravljanju organizacijom, što
je jedna od glavnih namjena BI sistema. Okruženje u kome se BI sistem nalazi mora da ga
prihvati kao realno rješenje koje može da bude od velike koristi u jednoj organizaciji i tek
tada BI sistem može da doprinese sveukupnom radu organizacije.

6
3. DIMENZIONALNI MODEL

Najčešće korišćena tehnika modelovanja baza podataka je treća normalna forma (3NF)
zbog prednosti koje se ogledaju u visokoj strukturiranosti modela, lakom razumijevanju
modela, efikasnom smještanju podataka, dobrim performansama itd. Negativne osobine ovog
pristupa su [6]:

 dugo vrijeme za razvoj zbog promjena u poslovnim procesima,

 zahtjevi za odvojen prezentacioni sloj,
 nešto lošije performanse zbog velike prisutnosti koncepta referencijalnog integriteta,
 česti zahtjevi za promjene od strane korisnika (relativno složene promjene strukture
modela zarad manjih promjena u funkcionalnosti sistema).

Zbog navedenih nedostataka 3NF modela, ovaj model nije pogodan za upotrebu pri
projektovanju skladišta podataka, pa je bilo neophodno napraviti novi, pogodniji model.
Glavni zahtjevi koje je novi model morao zadovoljiti su [6]:

 struktura modela je prilagođena za multidimenzionalnu analizu podataka,

 mogućnost arhiviranja podataka,
 meta-podaci o porijeklu podataka,
 hijerarhijska organizacija entiteta u modelu,
 smanjenje replikacije podataka.

Uveden je novi model koji ispunjava sve navedene zahtjeve pod nazivom „Dimenzionalni
model“ [1].

Dimenzionalni model je široko prihvaćen princip za prezentovanje analitičkih

podataka prvenstveno zbog toga što je moguće dostaviti razumljive podatke poslovnim
korisnicima, ali i zbog toga što se upiti izvršavaju velikom brzinom i sveukupne performanse
su na visokom nivou. Takođe, on rješava probleme koji su bili prisutni pri korišćenju treće
normalne forme i postao je dominantan način projektovanja skladišta podataka.

U oblasti poslovne inteligencije već dugo se pribjegava modelovanju jednostavnih

modela baza podataka, najviše zato da bi se zadovoljila osnovna ljudska potreba za
jednostavnošću. Model podataka koji je od početka jednostavan ima odlične predispozicije da
do kraja modelovanja ostane jednostavan. S druge strane, model koji je komplikovaniji u
početku biće komplikovan i kasnije, što može da rezultuje odbacivanjem od strane poslovnih
korisnika kao i veoma lošim performansama prilikom izvršavanja upita nad bazom podataka.

U kontekstu relacionog modelovanja baza podataka, i jedan i drugi model se mogu

predstaviti sa ERD (eng. Entity Relationship Diagrams), a ključna razlika između
dimenzionalnog modela i 3NF modela je u stepenu normalizacije. Kod normalizovanog
modela glavni problem je potencijalna kompleksnost korisničkih upita koje je u pojedinim
slučajevima nemoguće optimizovati, a performanse tada postaju izuzetno loše. Treba reći i da
dimenzionalni i normalizovani model sadrže iste podatke, samo su oni u dimenzionalnom
modelu predstavljeni na razumljiviji način, performanse su bolje, a osjetljivost na promjene
niža [2].

7
3.1 Fact tabele

Fact tabela u dimenzionalnom modelu služi da bi se sačuvale mjere performansi koje

su rezultat poslovnih procesa u posmatranoj organizaciji u kojoj se uvodi BI/DW sistem. Iz
razloga što su podaci o mjerama najvećeg obima u organizaciji, treba izbjegavati njihovu
replikaciju na više mjesta. Taj efekat je moguće postići uspostavljanjem jedinstvenog
skladišta podataka na nivou čitave organizacije. Na taj način se ostvaruje brz, efikasan i
pouzdan pristup podacima sa više lokacija.

Termin fact predstavlja poslovnu mjeru, što možemo predstaviti sljedećim primjerom.
Ako posmatramo jednu poslovnu jedinicu trgovačkog lanca dolazimo da zaključka da
zaposleni prodaju artikle određene količine u određeno vrijeme, određenom kupcu po cijeni
koja je važila u trenutku prodaje uz određeni popust. Primjer takve fact tabele prikazan je na
slici 3.1. Na slici su prikazane i dimenzionalne tabele o kojima će više biti riječi u odjeljku
3.2.

Slika 3.1 - Fact tabela i dimenzionalne tabele (star šema) [7]

3.1.1 Granularnost

Svaki red u jednoj fact tabeli odgovara jednom mjernom “događaju”, a podaci u
svakom redu specifikovani su na određenom nivou detalja. Ta osobina se naziva
“granularnost” i indikator je toga do koje mjere su prikupljeni podaci detaljni. Načelno, svi
redovi u fact tabeli moraju biti na istom nivou granularnosti što takođe pokriva i problem
duplog brojanja. Ukoliko generišemo izvještaj na osnovu fact tabele sa niskom granularnošću,
neće se javiti problem sa pojavljivanjem duplih redova budući da ne obuhvatamo veliki broj
kolona i vjerovatnoća za pojavljivanje istih vrijednosti je manja. Suprotno tome, ukoliko u
izvještaju obuhvatimo veći broj kolona, vjerovatnoća za pojavljivanje istih vrijednosti se
povećava te u krajnjem slučaju može doći do dupliranja redova.

Još jedna definicija granularnosti je da je to broj dimenzija povezanih sa posmatranom

fact tabelom. Na primjer, ukoliko dimenzija proizvoda nije povezana sa fact tabelom prodaje,
ne možemo dobiti informacije o proizvodima koji su prodati i samim tim nivo granularnosti je
nizak. Ova vrsta granularnosti se još naziva i dimenzionalnost star šeme [1], [2].

U fact tabelama se vrlo rijetko nalaze tekstualni podaci prvenstveno zbog svoje
slobodnije prirode. Veoma je komplikovano parsirati ili u opštem slučaju dati kontekst
tekstualnom komentaru koji se smješta kao polje u tabelu. Iz tog razloga, fact tabele sadrže
8
uglavnom numeričke vrijednosti koje su u stvari strani ključevi (najčešće dva ili više) koji
referenciraju primarne ključeve dimenzionalnih tabela. Kada svi ključevi u fact tabeli imaju
svoj ekvivalent u odgovarajućim dimenzionalnim tabelama, kažemo da tabele zadovoljavaju
referencijalni integritet i tada fact tabeli pristupamo kroz njoj pridružene dimenzionalne
tabele. Fact tabela ima svoj primarni ključ koji se sastoji od podskupa stranih ključeva koji se
naziva kompozitni ključ [2].

3.1.2 Aditivnost mjera

Rijetko kada se iz skladišta podataka pomoću upita zahtijeva ekstrakcija samo jednog
reda tabele, već uglavnom više redova nad kojima se mogu vršiti različite operacije od
interesa, poput agregatnih funkcija, pa je aditivnost mjera od suštinskog značaja u BI
sistemima.

Najjednostavniji tip mjera su one koje se mogu agregirati pomoću SUM agregatne
funkcije nad svim dimenzijama koje mogu biti npr. količine ili sume. Na primjer, ako bi
ukupna prodaja artikla A iznosila 1.000 KM, a artikla B 2.000 KM, tada bi ukupna prodaja
artikala A i B iznosila 3.000 KM. Mjere koje se mogu sumirati nad svim dimenzijama se
nazivaju aditivne mjere.

Neke mjere nisu aditivne ni nad jednom dimenzijom, kao na primjer procenti. Tako na
primjer korišćenje agregatne funkcije AVERAGE nad takvim dimenzijama ne bi donijelo
smislene rezultate. Na primjeru procenata, neaditivnost je moguće demonstrirati korišćenjem
agregatne funkcije SUM nad vrijednostima koje predstavljaju popust na kupovinu artikala, u
procentima. Nakon sumiranja iznosa popusta za više prodanih artikala, bilo bi moguće preći
vrijednost od 100% što kao sumarna informacija ne daje uvid u stvarno stanje.

Postoje i mjere koje su semi-aditivne (polu-aditivne) i za njih je ponekad moguće

koristiti agregatne funkcije, a nekad to jednostavno nema smisla. Kod polu-aditivnih mjera
nije moguće vršiti sumiranje samo po vremenskoj dimenziji. Primjer za to je trenutno stanje
na tekućem računu [1], [2]. U slučaju da klijent A na bankovnom računu ima 1.000 KM, a
klijent B 2.000 KM, oni zajedno imaju 3.000 KM, ali ako je klijent A juče imao 1.000 KM na
računu a danas ima 500 KM, to ne znači da on ima ukupno 1.500 KM na računu.

3.1.3 Čuvanje istorije izmjena u BI sistemima

Potpun BI sistem treba da sadrži i tabele u kojima će se čuvati istorija promjena, na
primjer ko, kada i zašto je mijenjao, dodavao ili brisao određene redove u tabelama BI/DW
sistema, na koliko redova su uticale izvršene promjene i sl. Osim toga, od interesa je čuvati i
informacije o tome koliko je trajalo izvršavanje svih upita ili transakcija u svrhu određivanja i
poboljšanja sveukupnih performansi BI sistema. Treba reći i da je čuvanje ovakvih podataka
korisno samo u slučaju ako će se analizom tih podataka izvući korisne informacije i preduzeti
konkretne mjere za poboljšanje performansi sistema. U suprotnom, zauzeće prostora bi bilo
veliko, a sami podaci bi bili beskorisni.

Ponekad je poželjno utvrditi odakle i kada je neki red u dimenzionalnoj ili fact tabeli
generisan, tj. potrebno je utvrditi njegovo porijeklo (eng. lineage). Kao najjednostavniji način
za implementaciju opisanog svojstva, moguće je dodati kolonu u odgovarajuću
fact/dimenzionalnu tabelu u koju će biti smješteni navedeni podaci [1], što će biti detaljnije
objašnjeno u dijelu rada u kojem se govori o ETL procesu.

9
 Da bi se mogli prikupljati ovakvi podaci, potrebno je izvršiti modifikacije ETL procesa
koji se koristi u BI/DW sistemu. Nove kolone koje se dodaju radi čuvanja istorije promjena
nikada ne treba da budu dostupne krajnjem korisniku. Ove kolone ne smiju da se pojavljuju
na izvještajima i nad njima ne smiju da se vrše operacije (poput pivotiranja).

3.2 Dimenzionalne tabele

Dimenzionalne tabele sadrže tekstualni kontekst asociran sa mjernim događajem

posmatranog poslovnog procesa. One daju odgovor na pitanja: “Ko, šta, gdje, kada, kako i
zašto” i uvijek prate fact tabele. Jedna dimenzionalna tabela je prikazana na slici 3.2.

Slika 3.2 - Dimenzionalna tabela

Dimenzionalne tabele (dimenzije) uglavnom imaju veći broj kolona i nije neobično da
ih ponekad bude pedeset do sto budući da služe za opis entiteta koji mogu da imaju mnoštvo
atributa. One imaju veliki broj kolona, ali mali broj redova, što je suprotno u odnosu na fact
tabele koje imaju ogroman broj redova, a manji broj kolona koje su uglavnom strani ključevi.

Svaku dimenziju karakteriše jedan primarni ključ koji služi kao osnova za
referencijalni integritet sa bilo kojom fact tabelom kojoj je pridružena. dimenzionalni atributi
služe kao primarni izvor ograničenja u upitima jer se po njima vrše sortiranja, grupisanja,
sumiranja i sl., te oni čine osnovu za upotrebljivost i razumljivost DW/BI sistema. Skladište
podataka je dobro samo onoliko koliko su dobri dimenzionalni atributi, a analitička moć
DW/BI okruženja direktno je proporcionalna kvalitetu i dubini dimenzionalnih atributa, pa je
zato vrlo bitno dobro definisati ove atribute.

Dimenzionalne tabele koje su povezane sa više od jedne fact tabele nazivaju se

dijeljene dimenzije, dok se one dimenzionalne tabele koje su pridružene samo jednoj fact
tabeli nazivaju privatne dimenzije [1]. U praksi se najčešće koriste dijeljene dimenzije jer
nema velike koristi od privatnih dimenzija, zbog toga što se gubi veza između više fact tabela,
pa na taj način podatke nije moguće upoređivati nad istim dimenzijama. Primjer za to je slučaj

10
u kojem se koriste privatne dimenzije za prodaju robe kupcima, pa tada nije moguće uporediti
prodaju i stanja na računima za određenog kupca jer fact tabele koje se tiču prodaje i vođenja
računa (konkretno, stanja na računima) ne bi dijelile iste dimenzije koje se tiču podataka o
kupcu.

Prilikom dizajna dimenzionalnih tabela, potrebno je voditi računa o broju vrijednosti

za svaki atribut. Ukoliko neki atribut kontinualnog karaktera želimo da koristimo u pivot
tabeli1 radi analize podataka, potrebno je izvršiti diskretizaciju tog atributa što u stvari znači
grupisanje vrijednosti u nekoliko diskretnih grupa podataka.

Druga vrsta kolona u dimenzionalnoj tabeli je ključ koji na jednoznačan način

identifikuje entitet. Dakle, kolone sa jedinstvenim vrijednostima identifikuju redove. Kolone
koje služe samo kao labele na izvještajima zovu se svojstva - članice [1], [2].

S obzirom na prethodno navedeno, tipovi kolona koji se mogu naći u jednoj

dimenzionalnoj tabeli su:

 ključevi – identifikuju entitete,

 imenovane kolone – koriste se za predstavljanje podataka sa imenima bližim ljudskoj
intuiciji,
 atributi – koriste se za pivotiranje pri analizi podataka,
 svojstva članice - koriste se za labele u izvještajima i
 porijeklo podataka – kolone u koje se smještaju informacije o porijeklu podataka, a
koje nikada nisu dostupne krajnjem korisniku BI/DW sistema.

3.2.1 Dimenzije koje se sporo mijenjanju (slowly changing

dimensions)

Postoji čest problem u vezi sa dimenzijama u skladištu podataka vezan za podatke koji
su podložni čestim promjenama. U klasičnim OLTP bazama podataka, ovo uglavnom nije
problem jer kada je potrebno izvršiti promjenu podataka, sve što je potrebno uraditi jeste
ažurirati podatak. U BI/DW sistemima, potrebno je čuvati istoriju promjena, kao što je
prethodno objašenjeno, pa se postavlja pitanje koji je optimalan način da se to uradi. Potrebno
je ustanoviti tačne vrijednosti podataka koji se sačuvaju, npr. da li se čuvaju samo poslednje
(najnovije) vrijednosti podatka ili je od interesa i početna (stara) vrijednost, razlika stare i
nove vrijednosti i slično. U BI/DW žargonu, ovaj problem se naziva Dimenzije koje se sporo
mijenjaju – SCD.

Postoji više tipova SCD [2]:

 Tip 1 – prepisivanje (eng. overwriting) istorije za posmatrani atribut i za sve
hijerarhijski više nivoe kojima taj atribut pripada.
 Tip 2 – zadržava se istorija promjena dodavanjem novih redova u bazu podataka. Radi
lakše implementacije ovog tipa SCD, dodaje se flag kolona da bi se naznačio red koji
trenutno pripada dimenziji (ostali redovi čine istoriju promjena). Drugi način za

1
Pivot tabela je alat za agregaciju podataka, najčešće ugrađen u programe za rad sa tabelama, BI alate i druge
programe koji služe za manipulaciju skupovima podataka. Upotrebom pivot tabele nad podacima je moguće
vršiti operacije poput sumiranja, sortiranja, računanja prosječne vrijednosti i dr. Podaci su, nakon primjene
agregatnih operacija, smješteni u tabelu koja se naziva pivot tabela i njena struktura ne zavisi od originalne
strukture podataka.
11
 rješavanje ovog problema je dodavanje dvije kolone koje označaju opseg važenja
podatka (datum od i datum do). Za trenutno važeći podatak, vrijednost datuma do je
null.
 Tip 3 – dodaje se nova kolona koja reflektuje promjene nad podacima. Na primjer, u
jednoj dimenziji može biti kolona trenutno mjesto prebivališta. SCD tip 3 se
implementira tako što se dodaje kolona “Prethodno mjesto prebivališta”. Tip 3 nije
naročito popularan zbog gomilanja broja kolona jer za svaki podatak treba da postoji
dodatna kolona u kojoj se čuva istoriju promjena (za samo jedan podatak).

Prilikom projektovanja BI/DW sistema potrebno je odlučiti koji od navedenih SCD

tipova je najpogodniji za čuvanje izmjena u nekom konkretnom poslovnom kontekstu. U
praksi, česta implementacija je kombinovanjem tipova 1 i 2.

Primjer na kojem možemo uočiti još jedan bitan faktor u BI sistemima je vođenje
evidencije o klijentima. Da bi smo na korektan način čuvali takvu istoriju, moramo imati neki
atribut koji jedinstveno identifikuje klijenta kroz istoriju promjena i taj atribut treba da bude
nepromjenljiv. Jedan način realizacije je da koristimo poslovni ključ klijenta jer se on u OLTP
bazama podataka ne mijenja [1], [2].

Poslovni ključevi se ne bi trebali mijenjati ni pri spajanju (združivanju) podataka iz više

različitih izvora. Za združene podatke, potrebno je uvesti nove, tzv. surogat ključeve jer
poslovni ključevi iz različitih izvora mogu da imaju istu vrijednost za različite entitete.
Upotreba surogat ključeva u skladištu podataka se uzima za najbolju praksu ali je potrebno
voditi računa i o tome da se OLTP ključevi ne mijenjaju [1].

3.3 OLAP kocka, star šema

U multidimenzionalnim bazama podataka, podaci su predstavljeni sa hiper kockom

odnosno višedimenzionalnim nizom, gdje je svaka od vrijednosti sadržana u jednoj ćeliji
dostupna preko više indeksa. Primjer jedne multidimenzionalne baze podataka prikazan je na
slici 3.3.

Slika 3.3 - Multidimenzionalna baza podataka [8]

12
 Dimenzionalni model koji je implementiran u multidimenzionalnim bazama podataka
se naziva OLAP kocka, što je prikazano na slici 3.4 a). S druge strane, dimenzionalni model
koji je implementiran u relacionom sistemu za upravljanje bazama podataka se naziva “star
šema” [1], zbog svojstva da mu struktura podsjeća na zvijezdu (slika 3.4 b)).

Star šema je dobila svoje ime zato što struktura šeme baze podataka izgledom
podsjeća na zvijezdu. Centralna tabela se naziva fact tabela koju okružuje više tabela koje se
nazivaju dimenzije, a o njima će biti više riječi kasnije. Logički, jedna star šema pokriva
jednu oblast poslovanja, kao na primjer Internet prodaju ili odnose sa kupcima. Skladište
podataka se sastoji iz više star šema koje pokrivaju različite oblasti poslovanja [1].

(a) (b)

Slika 3.4 – Pod (a) je prikazana OLAP kocka [9] a pod (b) je prikazana star šema [10]

Zvijezde i OLAP kocke dijele zajednički logički dizajn, ali se u smislu implementacije
razlikuju na fizičkom nivou. Kada se podaci učitaju u OLAP kocku, pohranjuju se i
indeksiraju koristeći formate i tehnike koji su dizajnirani za dimenzionalne podatke. Najčešće
se koriste tri tipa OLAP analize:

 MOLAP (eng. Multidimensional OLAP) – podaci su smješteni u multidimenzionalnu

kocku, u formatima zatvorene strukture,
 ROLAP (eng. Relational OLAP) – podaci su smješteni u relacionu bazu podataka, a
manipulacija podacima je implementirana kao u tipičnoj OLAP kocki. Emulacija ove
funkcionalnosti se postiže dodavanjem WHERE klauzule u SQL upitu,
 HOLAP (eng. Hybrid OLAP) – kombinacija prethodna dva pristupa.

Upotrebom OLAP kocke i star šeme moguće je vršiti razbijanje podataka po logičkim
cjelinama i pregledati podatke u zavisnosti od posmatranog konteksta dodavanjem ili
uklanjanjem atributa iz analize. OLAP kocke pružaju robusnije i naprednije analitičke
funkcije koje prevazilaze one koje su dostupne u standardnom SQL-u. Mana pristupa sa
OLAP kockama u odnosu na pristup sa star šemom je što su performanse znatno lošije,
naročito ukoliko je skup podataka veliki. Pristup koji će biti korišćen u ovom radu je da će se
razvijati prvenstveno star šeme, a zatim će se po potrebi OLAP kocke puniti sa atomičnim
podacima iz star šema.

13
3.4 Snowflake šema

Star šema čije su dimenzije normalizovane naziva se snowflake šema jer podsjeća na
snježnu pahulju, što je prikazano na slici 3.5.

Snowflake šeme se rijetko koriste, a de facto standard za modelovanje BI sistema je

star šema koja je jednostavnija i lakša za održavanje. Takođe, upiti nad star šemom su
značajno jednostavniji i performanse su bolje, zato što u tom slučaju imamo manji broj
spajanja tabela (eng. joins) [11].

Slika 3.5 - Snowflake šema [12]

14
4. ETL PROCES

U BI sistemima, ETL proces služi za ekstrakciju podataka iz izvora podataka i

smještanje podataka u skladište podataka. Sastoji se iz tri glavne aktivnosti:

 E (Extract) – ekstrakcija podataka iz izvora tj. njihove prvobitne lokacije,

 T (Transform) – nad ekstrahovanim podacima se vrše željene transformacije,
 L (Load) – smještanje transformisanih podataka u bazu podataka koje poslovni
korisnici mogu da iskoriste u svrhe za koje su im oni potrebni, na primjer za
izvršavanje upita nad dobijenim podacima i sl.

Razvoj ETL procesa u BI/DW sistemu zahtjeva značajno vrijeme i napor najviše zato
što postoji ogroman broj vanjskih faktora i ograničenja poput poslovnih zahtjeva,
nekonzistentnosti i nepredvidivosti izvornih podataka sa kojima radimo, budžeta, vremena
potrebnog za procesiranje i obučenosti kadrova.

Dizajn dobrog ETL sistema može da zavisi od više faktora poput načina na koji se
skladište izvorni podaci, ograničenja vezanih za same podatke, vještina zaposlenih kao i od BI
alata. Ovakva neodređenost vrlo lako postane izgovor za ETL dizajnere da sistem grade tako
da on u startu bude nestrukturiran što bi u najgorem slučaju dovelo do velikog broja loše
strukturiranih tabela, skripti, trigera (eng. triggers), administrativnih poslova (eng. jobs) i sl.
Prikupljajući znanje i iskustvo duži vremenski period, nekoliko ETL dizajnera je zajednički
ustanovilo smjernice za razvoj dobrog ETL sistema [1] koji nije poput prethodno opisanog,
nestrukturiranog pristupa dizajnu. Oni su došli do zaključka da je najbolja praksa da svako
dimenzionalno skladište podataka ima 34 obavezna podsistema i zbog toga je dizajn ETL
procesa u BI sistemu veliki poduhvat koji zahtjeva mnoštvo resursa.

Za uspostavljanje arhitekture ETL sistema potrebno je suočiti se sa velikim izazovom

— razmatranjem zahtjeva različite vrste poput sakupljanja, razumijevanja zahtjeva,
ograničenja i realnih situacija koje eventualno mogu uticati na razvoj ETL sistema. Primjeri
zahtjeva o kojima je potrebno voditi računa navedeni su u nastavku rada [1].

Interfejsi za prezentovanje BI sadržaja. Podaci procesirani u ETL sistemu moraju biti

na neki način predani BI sistemu radi dalje konzumacije od strane korisnika sistema. ETL tim
mora da blisko sarađuje sa timom za modelovanje i oni zajedno moraju preuzeti odgovornost
za sadržaj i strukturu podataka koja čini BI aplikacije jednostavnim, brzim i pouzdanim. Nije
poželjno niti odgovorno BI sistemu predati podatke iz ETL sistema na način da kompleksnost
aplikacije znatno poraste, da se brzina izvršavanja upita smanji, poveća vrijeme koje je
potrebno za generisanje izvještaja ili da podaci izgledaju konfuzno za krajnje korisnike
sistema. Baš iz ovog razloga, BI i ETL timovi moraju da sarađuju i da ugovore način
razmjene podataka. Svaki BI sistem je na neki način specifičan, a njegove dobre ili loše strane
neophodno je uzeti u razmatranje da bi se maksimizirao učinak pri korišćenju prenesenih
podataka. Potrebno je sastaviti listu svih dimenzionalnih i fact tabela koje će biti direktno
izložene BI alatima, kao i sve indekse i agregacije kako bi maksimizovali performanse
BI/DW sistema.

Poslovne potrebe. Ovaj zahtjev odražava informacione potrebe i zahtjeve korisnika

BI/DW sistema. Termin poslovne se odnosi na informacioni sadržaj koji poslovni korisnici
zahtjevaju da bi donijeli kvalitetne poslovne odluke. Potrebno je sačiniti listu glavnih

15
indikatora performansi (eng. Key Performance Indicators, KPI) [13] koje projekat treba da
podrži. Indikatori performansi se odnose na mjere koje je moguće kvantifikovati uz
poštovanje dogovora o faktorima koji su bitni za uspjeh organizacije i razlikuju se od
organizacije do organizacije.

Kašnjenje podataka. Ovaj zahtjev se odnosi na brzinu dostavljanja podataka iz

izvornog sistema poslovnim korisnicima koji korite DW/BI sistem. Očigledno, zahtjevi
povodom kašnjenja podataka imaju veliki efekat na ETL arhitekturu. Paralelno procesiranje,
algoritmi za procesiranje i jaka hardverska podrška mogu u velikoj mjeri ubrzati izvršavanje
klasičnih batch-orijentisanih tokova podataka. Batch-orijentisana obrada se odnosi na
sekvencijalno izvršavanje međusobno nepovezanih zadataka. Ukoliko je neophodno, sa
batch-orijentisanih transakcija može se preći na micro-batch transakcije. tj. obradu manjeg
broja upita unutar jedne transakcije istovremeno [1]. U ovom slučaju potrebno je prilagoditi
svaki dio BI sistema da bi takvo procesiranje bilo moguće, tj. bila bi potrebna potpuna
promjena paradigme. Potrebno je napraviti listu svih validnih i dobro koncipiranih poslovnih
zahtjeva za podatke koji treba da budu raspoloživi na dnevnoj bazi, više puta dnevno, sa
mogućnošću trenutnog pristupa.

Usaglašenost. Zbog učestalih promjena pravnih i zakonskih odredbi kao i zahtjeva

koji se tiču načina izvještavanja, organizacije moraju da prilagođavaju izvještavanje
propisima, i da pruže dokaze da su podaci u izvještajima tačni, potpuni i da nisu rezultat bilo
kakve manipulacije. U nekim branšama industrije poput telekomunikacija, prethodno
navedeni uslovi su već dugo ispunjeni zbog pravila i procedura propisanih od strane
regulatornih tijela, npr. Regulatorne Agencije za Komunikacije (RAK) u Bosni i Hercegovini.
Tim koji je zadužen za razvoj BI rješenja treba da kreira listu ulaznih podataka, pojmova od
interesa za izvještavanje, transformacija podataka i sl. da bi se na konačnom izvještaju moglo
pokazati porijeklo podataka, njihova ispravnost i saglasnost sa nametnutim zahtjevima,
pravilima i ograničenjima. Takođe, potrebno je ustanoviti koji podaci moraju biti dostupni i
nakon prikaza izvještaja, i kako oni treba da se skladište, bilo u online ili offline formi, uz
poštovanje zahtjeva za vrijeme skladištenja podataka.

Kvalitet podataka. Ovo svojstvo je veoma bitno za najviši, strateški, nivo bilo koje
organizacije, jer za dobro donošenje značajnih i dugoročnih odluka podaci moraju biti
maksimalno vjerodostojni i kvalitetni. Ustaljeno je mišljenje, ali i potreba onih koji donose
odluke da se podaci koriste za donošenje odluka. Druga stavka o kojoj je potrebno voditi
računa je integracija podataka, budući da su podaci distribuirani u nekim slučajevima čak i
širom svijeta, te ih je potrebno integrisati i tek onda koristiti na pravi način. Treća stavka koju
je potrebno razmotriti je nagli porast zahtjeva koji se tiču usaglašenosti podataka, što znači da
nema tolerancije u smislu lošeg rukovanja podacima, i sve se mora obaviti na efikasan način.
Prilikom praktične realizacije ETL procesa, potrebno je napraviti listu elemenata (podataka)
za koje je od ranije poznato da ne zadovoljavaju kriterijume koji se tiču kvaliteta podataka,
kao i listu već riješenih problema u vezi sa tim podacima. Navedene liste moraju često biti
preispitivane da bi se u svakom trenutku obezbijedio maksimalan kvalitet podataka.

Naslijeđeni softver. Često prije razvoja DW/BI sistema mogu postojati prethodna BI
rješenja koja je kompanija ranije kupila ili razvila. Osoblje na najvišem organizacionom nivou
kompanije (strateški nivo) mora da odluči šta želi da uradi sa postojećim softverom, da li da
zadrži softver, da li da i dalje plaća licence za stari softver ili nesto drugo. Organizacija koja
prilikom razvoja novog DW/BI sistema iskoristi stari softver za dizajn i izgradnju ETL
procesa, ne može značano da unaprijedi sistem zbog ograničenog broja funkcionalnosti iz
starog softvera.
16
 Integracija podataka. Ovaj zahtjev je vrlo bitan za BI/DW sisteme, jer jedan BI
sistem ima za cilj da integriše različite podsisteme jedne organizacije i da pristup
informacijama bude omogućen na krajnje intuitivan, pouzdan i siguran način. U mnogim
slučajevima, integracija podataka mora da se izvrši prije nego što podaci stignu u skladište
podataka, ali tako nešto se dešava rijetko jer bi to značilo da posmatrana organizacija mora da
ima savršen MDM (eng. Master Data Management) sistem [14]. MDM sistem se odnosi na
spisak podataka koje aplikacije dijele u jednom poslovnom sistemu. Integracija podataka
podrazumijeva korišćenje conforming dimenzija i fact tabela, odnosno zajedničkih
dimenzionalnih atributa kroz više razdvojenih baza podataka tako da bi se izvještaji koji
koriste ove atribute mogli lako generisati. Kod korišćenja zajedničkih fact tabela potrebno je
prethodno uspostaviti zajedničku poslovnu metriku poput KPI, i to u više odvojenih baza
podataka kako bi se podaci mogli porediti matematički kroz računanje razlika i proporcija.

Sigurnost. U tipičnom BI/DW sistemu, potrebno je obezbijediti podatke iz skladišta

podataka onim korisnicima sistema koji će na osnovu tih podataka donositi odluke. Prilikom
pružanja takvih usluga potrebno je voditi računa o sigurnosti, tj. potrebno je uvesti određene
sigurnosne mjere kako bi podatke dobili samo oni korisnici koji moraju da ih znaju (eng.
„need to know basis”). Takođe, sigurnost treba da se sprovodi i na nivou fizičke zaštite
podataka – pravljenja kopija podataka na fizičkim medijumima, enkripcija itd. Prilikom
sakupljanja zahtjeva za DW/BI sistem tim treba da traži mišljenje od strateškog menadžmenta
povodom njihovih očekivanja za sigurnost i osjetljivost podataka. Zahtjevi za usaglašenost će
se u većini situacija preplitati sa sigurnosnim zahtjevima i poželjno je da se ove dvije vrste
zahtjeva razmatraju zajedno.

Arhiviranje i porijeklo podataka. Zahtjevi za porijeklom i arhiviranjem podataka ne

moraju nužno biti nametnuti zakonski ili kroz određene procedure. Oni mogu nastati iz
potrebe organizacije da se na nivou skladišta podataka čuvaju podaci u svrhe reprocesiranja,
praćenja promjena, poređenja podataka i sl. Koristan koncept u BI/DW sistemima je staging
podataka tj. čuvanje međukoraka ETL procesa na disku kako se ne bi izgubile promjene
usljed loše transakcije podataka i slično. Staging elementi su uglavnom privremene tabele u
bazi podataka u koje se smještaju djelimično procesirani podaci, npr. kada je neka cjelina
završena tj. kada su podaci ekstrahovani, “pročišćeni”, provjereni i dostavljeni na odredište.
Staging elementi treba da postanu trajni backup elementi kada se zaključi da bi staging podaci
mogli da zatrebaju u budućnosti, dok se u suprotnom staging podaci ne čuvaju jer
potencijalno mogu da zauzmu dosta resursa. Podatke je lakše dobiti iz perzistentne memorije
nego ih ponovo procesirati, jer se vremenom algoritmi za procesiranje mogu značajno
promijeniti. Dodatno, svaki staging element tj. svaka staging tabela treba da ima popratne
meta-podatke o tome kako su ti podaci dospjeli na mjesto gdje se trenutno nalaze.

Dostupne vještine zaposlenih. Određene sistemske ETL odluke trebaju da budu

donesene na bazi dostupnih resursa za izgradnju i upravljanje sistemom. Nije optimalno
projektovati sistem da radi npr. sa Java aplikacijama za koje ne postoji dovoljna podrška
unutar same organizacije ili ako nema Java programera na raspolaganju. Takođe, ukoliko
unutar organizacije postoje pojedinci koji su vješti pri korišćenju alata određenog BI
proizvođača, optimalno je njima dati zaduženja da razviju BI sistem umjesto traženja nekog
eksternog rješenja. Drugo pitanje na koje je potrebno odgovoriti je da li je pogodno koristiti
ETL rješenje proizvođača BI sistema ili kreirati svoje sopstveno, zbog same specifičnosti
poslovanja i toka podataka unutar organizacije. Od interesa je uraditi “popis” tehnologija koje
su u upotrebi u sklopu organizacije poput SUBP (sistem za upravljanje bazama podataka) i
programskih jezika koji se koriste da bi se mogao napraviti plan za buduće implementacije i
reimplementacije sistema.
17
4.1 ETL podsistemi
ETL sistem se sastoji od ukupno trideset i četiri podsistema [1] koji čine arhitekturu
svakog ETL sistema. Razvoj ETL procesa čini ukupno 70% posla pri razvoju BI/DW sistema.
U nastavku, svi ETL podsistemi će biti navedeni i ukratko objašnjeni.

4.1.1 Ekstrahovanje podataka

Profilisanje podataka. Ovaj korak omogućava ETL timu da procijeni koliko
transformacija podataka će biti potrebno prije njihovog korišćenja i koja ograničenja mogu da
se dese u vezi sa izvorima podataka. Dakle, ovaj podsistem vrši tehničku analizu podataka da
bi se opisao sadržaj i struktura podataka [1].

Praćenje promjena podataka. Glavni zadatak ovog podsistema je da konstantno

provjerava da li se dešavaju promjene podataka. Postoji više metoda pomoću kojih se ovo
može postići, poput praćenja promjena korišćenjem timestamp kolone, tempiranim
ekstrahovanjem podataka, puno diferencijalno poređenje prošlih i sadašnjih podataka,
pregledanje logova baze podataka i praćenje redova poruka.

Ekstrahovanje podataka. Ponekad je nužno da se podaci ekstrahuju iz više izvora radi

kreiranja unije tih podataka, a to je glavni zadatak ovog ETL podsistema. Nakon
ekstrahovanja sistem vrši transformacije podataka ukoliko su one potrebne.

Narednih pet sistema služe za validaciju podataka.

4.1.2 “Pročišćavanje” i validacija podataka

“Pročišćavanje” podataka. Kroz ovaj proces pronalaze se svi podaci koji nisu
očekivani niti validni u BI/DW sistemu. Moguće je na više načina provjeriti validnost
podataka, poput provjere da li su neke od vrijednosti null, da li podaci imaju vrijednosti iz
dozvoljenog skupa vrijednosti itd. Ukoliko se pronađu podaci koji nisu validni, postoje tri
mogućnosti obrade takvih slučajeva:

 potpuno zaustavljanje ETL procesa,

 slanje reda koji nije validan u određen dio skladišta podataka za naknadno
procesiranje,
 označavanje podatka koji nije validan i proslijeđivanje u narednu fazu ETL procesa.

Podsistem za upravljanje greškama. Njegov glavni zadatak je da bilježi događaje koji

se tiču grešaka pri radu, a koje su se desile prilikom provjera korektnosti i integriteta podataka
bilo gdje u ETL procesu. Spisak grešaka mora da bude dostupan onim osobama koje će vršiti
analizu problema zbog kojih su greške nastale, ali i analizirati mogućnosti za rješavanje
problema.

Podsistem za održavanje “audit” dimenzija. U ETL sistemu, za svaku fact tabelu

treba da postoji još jedna specijalna tabela — audit dimenzija. Ova tabela treba da sadrži meta
— podatke koji se tiču trenutka kada se određen broj redova upiše u fact tabelu. U slučaju da
se nije desila greška pri prenosu podataka, u audit dimenziju se upisuje samo jedan red koji
sadrži informaciju da je prenos bio uspješan. Ukoliko se dese greške, u audit dimenziji se
dodaje jedan red koji se odnosi na te greške i na tom mjestu se čuvaju informacije o greškama
[1].
18
 Podsistem za vođenje evidencije o duplikatima. Dupli redovi u dimenzionalnim
tabelama su neminovnost i zadatak ovog podsistema je da eliminiše te duplikate iz
dimenzionalnih tabela ostavljajući samo po jednu “verziju” reda. Ponekad je situacija
jednostavna i dovoljno je samo obrisati duple podatke, a ponekad je potrebno izvršiti više
združivanja podataka da bi bilo jasno da u sistemu postoje duplikati i takvi slučajevi su
uglavnom teži za prepoznavanje.

Podsistem za usaglašavanje podataka. Ovaj podsistem usaglašava podatke iz

različitih izvora na način da su oni strukturno identični, oslobođeni duplikata, filtrirani i
standardizovani. Navedene radnje su neophodne jer se često dešava da podatke u skladište
smještamo iz više izvora poput druge OLTP baze podataka, tekstualnih datoteka, Excel tabela
itd.

4.1.3 Upis podataka u dimenzionalne i fact tabele

Sljedeći podsistemi su zaduženi za upisivanje podataka u dimenzionalne i fact tabele i
održavanje ETL okruženja. Dakle, podatke učitavamo u tabele tek nakon transformacije, što
omogućavaju sljedeći sistemi:

SCD menadžer. U dimenzionalnim tabelama promjene podataka su neminovne, a

SCD menadžeri vode računa o tome na koji način se upravlja tim promjenama. Koriste se dva
mehanizma u zavisnosti od provedenih promjena:

 Stara vrijednost atributa se mijenja novom vrijednošću atributa pri čemu se ne čuva
nikakva istorija promjena. Ovaj SCD mehanizam se koristi u slučaju kada podaci koji
se mijenjaju nisu vremenski osjetljivi, odnosno ako prethodne vrijednosti za neku
kolonu nisu od interesa.

 Dodaje se još jedan red u dimenzionalnu tabelu kada se vrijednosti promijeni.

Konkretno, u Microsoft SQL Server Integration Services ETL alatu dodaju se dvije
kolone za validnost podatka – “datum od” i “datum do” [2].

Generator surogat ključeva. Ovaj podsistem generiše ključeve za sve dimenzionalne

tabele pojedinačno. Iako se može iskoristiti mogućnost generisanja ključeva u sklopu sistema
za upravljanje bazom podataka, Kimball i Ross [1] preporučuju da se generisanje surogat
ključeva vrši kroz ETL alat da bi se povećala efikasnost i logička konzistentnost BI sistema.

Hijerarhijski menadžer. Namjena ovog podsistema je da održi hijerarhijsko

popunjavanje dimenzionalnih tabela. Da bi sistem to postigao, on vrši provjeru korektnosti
primjene poslovnih pravila.

Graditelj “fact” tabela. Fokus ovog podsistema je na arhitekturnim zahtjevima za

ETL, da bi se na ispravan način obezbijedio potreban nivo granularnosti pri transakcijama,
periodični snapshotovi baze podataka kao i akumulacija tih snapshotova. Prilikom upisivanja
redova u fact tabele, potrebno je vršiti provjeru referencijalnog integriteta, a to je zadatak
ovog podsistema [1].

Podsistem za upravljanje životnim vijekom surogat ključeva. Koristi se da bi

zamijenio operacioni “prirodni” ključ sa odgovarajućim dimenzionalnim surogat ključem. U
tom procesu imamo prvo cjelinu koja se odnosi na lookup tj. pretragu ključeva za određenom
vrijednosti, a svi problemi koji se tiču referencijalnog integriteta moraju biti vraćeni ETL

19
procesu koji je odgovoran za razrješenje tih problema. Lookup najčešće uključuje lookup
tabelu, a kolizije koje se dešavaju u vezi sa ključevima su u nadležnosti ovog sistema.

Višeznačne dimenzionalne vezne (eng. bridge) tabele. U sklopu ETL procesa, uloga
ovog podsistema je da održava vezne tabele za hijerarhije promjenljive dubine ili hijerarhije
koje bi inače imale dimenzionalne tabele sa vezama više naprema više (M:M). Na primjer,
ukoliko bi poslovni sistem za koji se implementira skladište podataka čuvao podatke o prodaji
artikala, često se desi da je u jednoj prodaji učestvovalo više prodavaca. Kod relacionih baza
podataka, ovakav slučaj bi se prevazišao upotrebom dodatnog entitetskog skupa u kojem bi se
čuvali podaci o prodavcima (šifarnik prodavaca). Prilikom projektovanja skladišta podataka,
moguće je koristiti sličan pristup za prevazilaženje problema višeznačnih dimenzija. Ponekad,
fact tabela mora da istovremeno referencira više redova iz jedne dimenzionalne tabele, kao u
navedenom primjeru sa prodajom artikala gdje bi na primjer tabela FactSales referencirala
više redova iz dimenzije DimSalesPerson. U tom slučaju potrebno je formirati veznu tabelu
između odgovarajuće fact tabele i dimenzionalne tabele iz koje je potrebno referencirati više
redova. Nakon toga, u veznu tabelu je potrebno upisati podatke koji čine željene grupe
podataka – to bi u navedenom slučaju bili podaci o prodaji artikala. Na taj način, u fact tabeli
će se na mjestu ključa odgovarajuće dimenzionalne tabele naći ključ iz vezne tabele koji
obuhvata podatke definisane unutar te grupe.

Menadžer podataka koji pristižu sa kašnjenjem. Ovaj podsistem omogućava

procesiranje dimenzionalnih podataka koji pristižu sa zakašnjenjem. Takvi podaci su oni koji
već u trenutku stizanja imaju promijenjen kontekst. Primjer za to je kada činjenica (eng. fact)
o prodaji pristigne sa podatkom o kupcu koji je na prvi pogled validan ali još uvijek nije
dodan u dimenzionalnu tabelu kupaca. Tada je neophodno pretraživati istorijske podatke radi
donošenja odluke koji dimenzionalni ključevi su bili aktuelni kada je činjenica (jedan podatak
iz fact tabele) bila prisutna. Da bi se razriješio ovaj problem, sistem mora da podržava SCD
tip 2. Način na koji je moguće riješiti navedeni problem je tako da se dodijeli surogat ključ
novom kupcu sa preuzetim početnim vrijednostima za ostala polja. Te vrijednosti se
naknadno modifikuju tako da odražavaju stvarno stanje, tj. početne vrijednosti se zamjenjuju
sa konkretnim vrijednostima u skladu sa promjenom prvog tipa i sve to kada pristignu podaci
o novom kupcu [1], [2].

4.1.4 Podsistemi za upravljanje ETL okruženjem

Podsistemi koji će biti prikazani u nastavku omogućavaju veću pouzdanost,
dostupnost i upravljivost ETL sistema.

Raspoređivač poslova. Okruženje mora biti podešeno tako da je moguće kreirati,

upravljati i nadzirati skupove ETL zadataka. Osnovna namjena ovog podsistema je da
pokrene određene poslove i zadatke tačno prema unaprijed definisanom rasporedu. Prilikom
specifikovanja zadataka koji će biti izvršeni potrebno je izvršiti provjeru da li postoje drugi
zavisni zadaci i na osnovu analize formirati redoslijed izvršavanja.

Sistem za oporavak od greške. Da bi zaštitili integritet podataka, potrebno je

obezbijediti dobar backup sistem koji će konstantno da bude u pripravnosti. Ovaj podsistem
se koristi kada se ETL sistem ne može trenutno oporaviti od greške koja je nastala u toku
rada. ETL alat ima dobar sistem provjera za greške korišćenjem checkpoint-a da bi se lakše
moglo dijagnostikovati gdje se desila greška, i da bi se problem mogao otkloniti. Postoji više
razloga zašto se može dogoditi otkaz sistema poput problema sa mrežom, problema sa bazom
podataka ili problema sa masivnom memorijom.
20
5. POREĐENJE POSTOJEĆIH BI RJEŠENJA

Male, srednje i velike firme sve više vide stvarni potencijal rješenja baziranih na
sistemu poslovne inteligencije, kao i menadžmentu performansi na nivou korporacije (eng.
Corporate Performance Management, CPM), jer one moraju da dostave podatke unutar firme
u prave ruke uzimajući u obzir strateške promjene i dinamiku poslovanja.

Nakon što je započela ekonomska kriza 2008. godine, analitička kompanija Gartner je
objavila da se broj upita vezanih za oblast poslovne inteligencije udvostručio. Firme su tražile
način da sa relativno malo ulaganja stabilizuju poslovanje kroz moćne analitičke alate i
optimizaciju poslovnih procesa, tako da gubici budu što manji. Nije iznenađujuće što
softverski giganti poput IBM, SAP, Oracle i Microsoft vrše velika ulaganja u softver koji se
tiče poslovne inteligencije, uglavnom kroz akvizicije drugih, manjih kompanija kao i kroz
razvoj unutar same kompanije.

BI alati i rješenja se mogu porediti i rangirati na osnovu većeg broja kriterijuma.

Gartnerov Magic Quadrant (MQ) je brend koji se odnosi na niz istraživanja tržišta
sprovedenih od strane kompanije Gartner, jednom godišnje ili jednom u dvije godine, zavisno
od oblasti istraživanja. Cilj MQ je da omogući kvalitativnu analizu tržišta, pravaca razvoja i
zrelosti učesnika. Metodologija za ocjenjivanje performansi posmatranog BI sistema bazira se
na dva kriterijuma:

 sveukupna potpunost vizije i

 sposobnost za izvršenje planiranih mjera.

Pozicija proizvođača BI rješenja se na osnovu prethodne analize svrstava u jednu od

četiri kategorije:

 Vođe – imaju najviši skor na oba kriterijuma. To su uglavnom veće, zrelije kompanije
sa tradicijom dobrog poslovanja.
 Izazivači – imaju veći skor na dijelu koji se tiče sposobnosti provođenja plana, a
manji skor na kompletnosti vizije. Uglavnom se radi o većim, stabilnijim preduzećima
koja imaju dobre predispozicije da uspiju na tržištu ali ih istovremeno sputava
nedostatak strategije za plasman proizvoda ili usluga unutar nekog tržišnog segmenta.
 Vizionari – imaju niži skor na dijelu koji se tiče sposobnosti provođenja plana a viši
skor za kompletnost vizije. Tipično, radi se o manjim kompanijama.
 Novajlije – imaju niži skor na oba kriterijuma. Radi se o kompanijama koje su tek
dospjele u Magični kvadrant.

Na slici 5.1 prikazan je Gartnerov Magični kvadrant za 2015. godinu, najnoviji u

trenutku pisanja rada.

21
 Slika 5.1 - Gartner BI Magic Quadrant [15]

BI rješenja, kao i druga rješenja za analitiku se uglavnom ne mijenjaju dramatično za

jednu godinu, tako da su inkrementalne promjene ono što se očekuje. Takođe, kompanija
Gartner svake godine povećava svoja očekivanja za kriterijum koji se odnosi na sveukupnu
kompletnost vizije da bi ponuđači BI rješenja uvijek dali svoj maksimum i unijeli inovacije u
njihove proizvode.

Na osnovu analize, izvedeno je mnogo zaključaka, kao npr. da giganti poput IBM,
SAP, Oracle i MicroStrategy nisu uspjeli da obezbijede dovoljno dobre funkcionalnosti za
otkrivanje novih podataka i trendova.

5.1 Tableau Software

Firma Tableau Software je u magičnom kvadrantu zauzela prvo mjesto, na osnovu

rezultata anketa zadovoljnih korisnika, kao i naglog porasta udjela na tržištu iz godine u
godinu. Anketirani korisnici smatraju da je najveća prednost ovog BI paketa jednostavnost
korišćenja zbog njegovog intuitivnog interfejsa, ali i lakoće razvoja novih funkcionalnosti za
programere i sveukupne funkcionalnosti. Tableau rješenja za BI su intuitivna, elegantna uz
jednostavan način pregledanja i analiziranja podataka od značaja. BI rješenja ove firme su
bogata mogućnostima, vrlo skalabilna sa mogućnostima vrlo detaljne analitike prema velikom

22
broju kriterijuma i filtara. Mjerenjem performansi je dokazano da su Tableau BI rješenja deset
do sto puta brža od konkurencije [16]. Što se tiče same prodaje Tableau softvera, rezultati
nisu podjednako dobri kao oni koji se tiču zadovoljstva korisnika, najviše zbog nefleksibilnog
sklapanja ugovora sa klijentima, strogih pravila i manjka prostora za pregovaranje sa
klijentima [15] [16].

Mogućnosti koje pruža Tableau Desktop:

 intuitivan korisnički interfejs (drag and drop mogućnosti),

 OLAP,  vođenje evidencije o
 prediktivna analiza, performansama sistema,
 indikatori trendova,  mobilne aplikacije za BI,
 automatizovano izvještavanje,  mali hardverski zahtjevi,
 finansijska predviđanja,  indikatori problema.

Tableau danas ima dosta principalnih klijenata poput The Coca Cola Company, BNP
Paribas, Dow Jones and Company, Bank of America, University of California i drugi [16].

5.2 Microsoft
U magičnom kvadrantu, Microsoft je izgubio visoku poziciju koju je imao duže
vrijeme, najviše iz razloga što nisu ponudili nova i inovativna rješenja u oblasti poslovne
inteligencije. Kompanija Gartner im je dala nisku ocjenu za dio koji se tiče konzumacije BI
usluga sa mobilnih uređaja budući da još uvijek nemaju nativno rješenje za Apple iOS
platformu [18]. Dio Microsoftove ponude koji je unapređen je podrška za Power View u
Microsoft Excel-u uz mogućnost korišćenja HTML5 formi kao i podrška za SAP Business
Objects. Predviđa se da će u narednom periodu konkurencija postati sve veća, i da će rješenja
Excel Power BI, Power Query i Power View biti značajno unapređena od strane Microsofta
kako bi ostali konkurentni na tržištu.

Microsoft-ovo provjereno dobro rješenje je SQL Server koji uključuje SQL Server
Integration Services (SSIS), SQL Server Analysis Services (SSAS), SQL Server Reporting
Services (SSRS) kao i SharePoint bazirana rješenja. O SSIS, SSAS i SSRS će biti više riječi
kasnije, u praktičnom dijelu rada. Jedna stavka kod Microsoftovih BI cloud-baziranih rješenja
na koju su korisnici imali najviše prigovora je previsoka cijena koja se plaća za korišćenje
softvera na godišnjem nivou.

Za razliku od SQL Servera koji je orijentisan ka programerima, SharePoint alati za

poslovnu inteligenciju su dizajnirani da pruže korisnicima metode za analitiku koje su vrlo
intuitivne i jednostavne i koje mogu implementirati bez mnogo nadgledanja i asistencije.
Aplikacije poput Excel-a koje su predviđene za korišćenje od strane krajnjih korisnika su
potpuno poznate te je pregledanje BI izvještaja u Excel-u jednostavno i intuitivno. Moćan
dodatak za Excel predstavlja Power Pivot koji omogućava korisnicima pristup i jednostavno
poređenje velikih količina sirovih podataka iz bilo kakvog izvora i pri tome se ogroman broj
redova može efikasno analizirati.

Kao platforma za Web aplikacije, SharePoint kompanijama daje podršku za Intranet

gdje mogu pohraniti, organizovati i dijeliti sadržaj (dokumente, fotografije, video sadržaj, itd.)
unutar jedne grupe. Intranet usluga može poboljšati komunikaciju između zaposlenih tako što
se bitne informacije dijele efektivno i pouzdano. Sa druge strane, SharePoint se može koristiti

23
na način da se kreiraju Extranet ili Internet Web stranice gdje se pristup informacijama može
kontrolisati upotrebom domenske autentifikacije [15],[17].

Mogućnosti koje pruža Microsoft SharePoint:

 indikatori problema,  kreiranje Web stranica prema

 ad hoc izvještavanje, odabranim parametrima,
 finansijska predviđanja i analiza  detaljniji uvid u podatke sa aspekta
budžeta, predviđanja trendova.
 upravljanje rizikom,

Microsoft ima veliku bazu korisnika a SharePoint koriste velike firme poput Chevron,
CAT, Volvo Car Corporation, Universal Music Group, The Weather Channel i drugi [18].

Kao glavne negativne osobine SharePointa korisnici su naveli spor odziv sistema i
povremenu kompleksnost radnog okruženja. Budući da se sa Microsoft SharePoint-om mogu
kreirati „rješenja po mjeri“, dizajneri ponekad ne prepoznaju potrebe SharePoint korisnika i to
je razlog za nastajanje navedenih problema. To znači da bi svaka firma koja koristi
SharePoint trebala da ima SharePoint administrator, što nije uvijek jeftino rješenje.
SharePoint je moguće koristiti u Apple sistemu samo uz preuzimanje odgovarajućih eksternih
aplikacija, a trenutno ne postoji plan od strane Microsofta da SharePoint orijentišu ka Apple
Macintosh platform, zbog čega gube sve veći udio na tržištu BI softvera.

5.3 SAP
Prema kompaniji Gartner, SAP je u magičnom kvadrantu poboljšao svoju
metodologiju provođenja planova, ali izgubio potpunost vizije [18]. SAP Business Objects je
rješenje koje je vrlo sporo za implementaciju i trenutno je glavni fokus na ubrzanju i
generalnom unapređenju implementacije softvera.

Ponuda kompanije SAP u BI segmentu sastoji se od četrnaest BI rješenja koja se

odnose na kompanije različitih veličina i različitih grana industrije. Na primjer, neka SAP
rješenja mogu biti implementirana u malim i srednjim firmama, dok su druga orijentisana ka
firmama koje rade sa Microsoft Office-om. Takođe, SAP omogućava i pristup BI podacima i
izvještajima sa mobilnih uređaja poput telefona i tableta kao i dodatnim analitičkim alatima
[19].

Glavni BI proizvod kompanije SAP je SAP Business Objects koji omogućava pristup
BI podacima i krajnjim korisnicima bez ikakve intervencije IT osoblja. Većina BI platformi
teže da obuhvate jednu funkciju kompanije (na primjer ljudske resurse, obračun plata, robno i
materijalno poslovanje, finansije, itd.), dok SAP Business Objects platforma pruža šira
rješenja koja mogu kombinovati više modula jednog tipičnog poslovnog informacionog
sistema. Korisnici mogu vršiti BI analizu iz višestrukih izvora podataka, agregirati,
transformisati podatke i vršiti druge operacije sa podacima. Takođe, prednost SAP BI
platforme je što omogućuje integraciju podataka sa programskim jezikom Java kao i
Microsoft SharePointom te je sistem moguće učiniti još fleksibilnijim razvijajući dodatke za
bazni sistem. Business Objects rješenje podržava kontrolu pristupa sadržaju na način da je
moguće definisati opsege vidljivosti skupova podataka za ciljne korisnike.

24
Mogućnosti koje pruža SAP Business Objects:
 pregled agregiranih podataka na
 OLAP, jednom mjestu,
 prediktivna analiza,  finansijska predviđanja i planiranje
 indikatori trendova i Key budžeta,
Performance Indicators,  mobilne BI aplikacije.
 intuitivan korisnički interfejs,
 detaljno izvještavanje,

Najvažniji korisnici SAP BI rješenja su 3M, Dow Corning, T-Mobile, Proctor &
Gamble, Pennsylvania State University i drugi [19].

Korisnici smatraju SAP-ov ERP softver za neintuitivan i potencijalno može biti vrlo
teško naučiti korisnike navigaciji unutar samog softvera. Od trenutka kada je SAP počeo da
nudi svoja BI rješenja, proces licenciranja je naročito komplikovan, a same licence skupe
budući da se za jedan funkcionalan sistem mora kupiti više BI modula.

Zbog slojevitosti i kompleksnosti, mnogi SAP eksperti koji pružaju podršku osoblju
koje koristi sistem su kvalifikovani samo u jednom području ili softverskom modulu. Ovo
može izazvati dodatne troškove kao i smanjenu efikasnost pri radu zbog potrebe za
koordinisanjem osoblja koje može da pruži tehničku podršku korisnicima u slučaju da se javi
potreba za tim.

5.4 IBM
IBM (International Business Machines) je ranije bio jedan od lidera u oblasti razvoja
softvera za poslovnu inteligenciju, ali su u poslednjih deset godina značajno izgubili na
rejtingu. Njihovo glavno BI rješenje je IBM Cognos. U magičnom kvadrantu IBM drži jaku
poziciju povodom potpunosti vizije i u tom segmentu su vodeća kompanija u magičnom
kvadrantu. Razlog za to je što imaju bogatu ponudu BI rješenja za različite profile
organizacija i oblasti primjene. Nakon akvizicije kompanije “SPSS” 2009. godine, IBM je
značajno upotpunio svoju ponudu BI alata dodajući podršku za rudarenje podataka,
operacione analitike i procjene rizika.

Sa druge strane, IBM Cognos je online platforma za poslovnu inteligenciju koja nudi
potpun skup BI rješenja za praktično bilo kakve ciljeve organizacije. Cognos se sastoji od
preko trideset različitih proizvoda i uzima se da je jedan od lidera u oblasti poslovne
inteligencije. IBM aktivno sluša primjedbe od strane korisnika softvera i zbog toga odlično
poznaje potrebe svojih klijenata, pa u skladu sa tim može da kreira softverska rješenja koja
njima najviše odgovaraju. Podržane su i mogućnosti za napredno analitičko donošenje odluka
što omogućava organizacijama da donose bolje poslovne odluke i da u njih budu u potpunosti
sigurni. Slično kao i ostala BI rješenja, nova verzija Cognos-a je uvela podršku za integraciju
podataka iz velikog broja izvora što omogućava centralizaciju sistema za obradu podataka.

Cognos takođe sadrži jedinstven skup proizvoda koji omogućavaju najvećim

organizacijama, ali i malim i srednjim preduzećima da istovremeno koriste jedan sistem za
različite potrebe. Verzija softverskog paketa koja se zove Cognos Express namijenjena je za
implementaciju unutar sektora neke veće organizacije ili za organizacije male i srednje
veličine kojima nisu potrebne sve opcije i mogućnosti koje nudi puna verzija IBM Cognos-a, i
organizacijama koje ne žele da ulože mnogo novca u sistem poslovne inteligencije. Pokazalo
se da nakon implementacije, IT sektori organizacije koja je implementirala ovo rješenje
25
nemaju pretjerano puno posla povodom administracije samog sistema, a moguće je podesiti
kontrolu pristupa tako da zaposleni mogu da vide samo ono što trebaju da vide.

Cognos se pokazao kao pouzdano rješenje, međutim glavna zamjerka korisnika je u

vezi sa performansama koje su prilično loše u više verzija Cognos-a i IBM ne uspijeva da
riješi taj problem [18], [20].

Mogućnosti koje pruža IBM Cognos:

 OLAP,  prilagođenje mogućnosti sistema,

 grafički alati za analitiku,  finansijska predviđanja i planiranje
 prediktivna analitika, budžeta,
 intuitivan korisnički interfejs,  detaljna kontrola pristupa.
 ad hoc izvještavanje,

Jedna karakteristična zamjerka koju imaju korisnici softvera je na način obavještavanja

korisnika o nastalim greškama [15]. Greške su ispisane u iskačućim prozorima i prikazana su
neintuitivna objašnjenja koja ne mogu pomoći korisnicima da dijagnostifikuju probleme. Još
jedan problem primjećen od većine korisnika je sporo kompajliranje izvještaja dok konkurenti
nemaju problema sa tim tako da to frustrira veliki broj korisnika IBM Cognos-a.

Glavni korisnici IBM Cognos-a su: Nike, British Airways, Chemring, Lufthansa
Cargo, Michigan State University i drugi [20].

5.5 Jaspersoft
Prilikom kreiranja BI rješenja Jaspersoft, kompanija TIBCO je pokušala da izgradi
softver koji je čvrsto baziran na standardima, kako bi bio što fleksibilniji i modularniji. Zbog
ove karakteristike, Jaspersoft omogućava jednostavan i intuitivan pregled podataka, na više
računarskih platformi i infrastrukturnih okruženja. Treba reći i da je Jaspersoft open source
rješenje koje je moguće brzo i lako implementirati pa je iz tog razloga pogodno za
implementaciju i u manjim firmama kojima nisu potrebna kompleksna i prilagođena rješenja
koja nude velike softverske kompanije.

U magičnom kvadrantu Jaspersoft se nalazi u dijelu sa novajlijama ali uprkos tome

kompanija Gartner je ocijenila da Jaspersoft može brzo i efikasno da provodi planirane
aktivnosti, ali da kaska u kompletnosti vizije za ostalim velikim “igračima” [21].

Postoji više načina za pristup izvještajima i multidimenzionalnoj analitici podataka i to

kroz lokalno instaliranu aplikaciju ili kroz cloud. Pregled, vizuelizacija i analitika bazirani su
na skalabilnoj Web platformi. Korisnici mogu da koriste izvještaje koje je moguće ugraditi u
interne aplikacije organizacije, kao i u aplikacije komercijalne prirode. Omogućena je i
kontrola pristupa u smislu omogućenja pristupa izvještajima samo onima koji imaju dozvolu
za to. Sama kontrola pristupa je intuitivna i tehnički trivijalna, pa tako da i korisnici sa
slabijim IT vještinama mogu administrirati sistem na jednostavan način.

Ono što karakteriše Jaspersoft je upotreba Big Data koncepta koji je potpuno prisutan,
jer se ovaj softverski alat može vrlo lako uvezati sa Cassandra Analytics, MongoDB
Analytics, Hadoop Analytics itd. Izvještaje je moguće kreirati na osnovu podataka iz skladišta
podataka i nije neophodno pomjerati podatke u drugu bazu podataka.

26
Mogućnosti koje pruža Jaspersoft Business Intelligence:

 OLAP,  izvještavanje,
 prediktivna analitika,  grafička analitika,
 indikatori trendova,  mjerenje performansi.

Glavni klijenti kompanije Jaspersoft koji koriste Jaspersoft Business intelligence su:
Sierra Club, Puma, Kronos, University of Nebraska, United States Marine Corps, USDA i
drugi [21].

Jaspersoft nudi samo minimalnu tehničku podršku što je karakteristično za open

source softver, ali za većinu korisnika ovo nije naročito problematično zbog toga što je
korisnički interfejs intuitivan i interaktivan, a korisnici imaju i mogućnost da sami potraže
rješenje za određen problem.

27
6. PRAKTIČNA REALIZACIJA SKLADIŠTA PODATAKA
Za potrebe izrade praktičnog dijela rada, najpogodnija su Microsoft-ova rješenja
budući da uključuju sve aspekte koncepta poslovne inteligencije koji su od interesa za ovaj
rad. Sa Microsoft BI alatima moguće je dizajnirati skladište podataka, sistem za izvještavanje,
vršiti multidimenzionalnu analizu podataka itd. S obzirom na to da je Microsoft SQL Server
globalno jedan od najkorišćenijih SUBP, BI rješenja implementirana korišćenjem Microsoft
alata bi bila dugoročno podržana i eventualni problemi bi bili lakše otklonjeni zbog velike
baze znanja generisane od strane postojećih korisnika. Konkretno, za izradu praktičnog dijela
rada biće korišćeni Microsoft SQL Server 2014, Visual Studio 2013 i Office 2013.

Sistemi poslovne inteligencije imaju širok kontekst upotrebe, a naročito su primjenljivi

u poslovnim informacionim sistemima. Za potrebe realizacije praktičnog dijela rada, odabrana
je Microsoft Northwind baza podataka. Podaci koji se nalaze u Northwind bazi podataka su
rezultat poslovanja kompanije Northwind koja se bavi prodajom dominantno prehrambenih
proizvoda. Kompanija Northwind je fiktivna i podaci koji se nalaze u bazi podataka su
sintetizovani ali uz poštovanje određenih statističkih raspodjela, tako da podaci nisu
stohastični po prirodi. Šema baze podataka je prikazana na slici 6.1.

Slika 6.1 - Northwind baza podataka

Northwind baza podataka sadrži sljedeće entitetske tipove (tabele):

 region,  prevoznik,
 teritorija,  zaposleni,
 proizvod,  narudžba,
 kategorija proizvoda,  detalji narudžbe,
 dobavljač,  kupci.

28
 Na osnovu identifikovanih tabela i preporuka koje su navedene ranije, biće izvršena
denormalizacija baze podataka na način da će se formirati jedna fact tabela kao i potrebne
dimenzije.

Skladište podataka će biti kreirano u Microsoft SQL Server Integration Services
razvojnom okruženju, na osnovu Northwind baze podataka. Izvještaji će biti kreirani u SQL
Server Reporting Services razvojnom okruženju, dok će multidimenzionalno izvještavanje i
analiza podataka biti demonstrirana pomoću SQL Server Analysis Services razvojnog
okruženja.

6.1 Logički dizajn skladišta podataka

Glavna djelatnost kompanije Northwind je prodaja artikala, tako da je od interesa

vođenje evidencije o prodanim artiklima i drugih podataka koji se tiču same prodaje. Kako je
sama prodaja od suštinskog značaja u sistemu, evidencija o prodaji bi trebala da se izdvoji kao
jedna fact tabela. Dimenzije koje će biti formirane će služiti da detaljnije opišu prodaju.
Skladište podataka će biti formirano prema preporukama navedenim u [1].

6.1.1 Formiranje dimenzija

Nakon izvršene analize strukture baze podataka Northwind, prvi korak je formiranje
dimenzionalnih tabela. Dimenzije treba da detaljnije opišu konkretan poslovni proces,
odnosno u ovom slučaju prodaju artikala.

Prva dimenzija koja će biti formirana je DimCustomers. Ona čuva podatke o kupcima
(partnerima) u sistemu poput naziva kompanije, adrese, broja telefona, faksa i drugih
podataka. Kolona IDDimCustomer predstavlja surogat ključ za navednu dimenziju koja je
naknadno dodana, dok je porijeklo ostalih kolona iz Northwind OLTP baze podataka. Kolona
CustomerID predstavlja poslovni ključ i ta vrijednost je jedinstvena. Podaci o kupcima
preuzeti su iz tabele Customers iz Northwind baze podataka. Kolone EffectiveDate i
ExpiryDate služe za implementaciju SCD tipa 2 i biće korišćene na isti način i u ostalim
dimenzijama. Kolona EffectiveDate se odnosi na datum od kojeg odgovarajući red u dimenziji
važi dok se kolona ExpiryDate odnosi na datum do kojeg red važi, a on se popunjava nakon
što se red proglasi za nevažeći. Na slici 6.2 prikazana je struktura dimenzije DimCustomers.

Slika 6.2 - Dimenzija DimCustomers

29
 Dimenzija DimEmployees čuva podatke o zaposlenima u kompaniji Northwind poput
imena, prezimena, datuma rođenja, datuma zaposlenja, adrese, broja telefona, nadređene
osobe, teritorije za koju je zadužen itd. Podaci o zaposlenima su preuzeti iz tabele Employees
iz OLTP baze podataka Northwind. Kolona IDDimEmployee predstavlja surogat ključ za
dimenziju, dok je EmployeeID poslovni ključ preuzet iz OLTP baze podataka i on je takođe
jedinstven. Microsoft BI alati ne podržavaju tipove podataka blob (eng. binary large object)
kao ni tip podatka text tako da su oni isključeni iz određenih BI zadataka, a u dimenzijama su
zadržani zbog njihove prisutnosti u OLTP bazi podataka kao i zbog eventualne potrebe za tim
podacima u drugim kontekstima upotrebe. Na slici 6.3 je prikazana dimenzija DimEmployees.

Slika 6.3 - Dimenzija DimEmployees

Potrebno je voditi evidenciju i o dostavljačima robe odnosno logističkim preduzećima,

a to je zadatak dimenzije DimLogistics. Ova dimenzija je jednostavnije strukture i sadrži
kolone IDDimLogistics koja predstavlja surogat ključ dimenzije, ShipperID – poslovni ključ,
naziv kompanije, broj telefona i SCD kolone. Na slici 6.4 prikazana je struktura dimenzije
DimLogistics.

30
 Slika 6.4 - Dimenzija DimLogistics

Podaci o proizvodima se čuvaju u dimenziji DimProducts koja sadrži kolone čije

vrijednosti opisuju proizvod – njegov naziv, cijenu, kategoriju, raspoložive količine itd.
Kolona IDDimProduct predstavlja surogat ključ dimenzije, a kolona ProductID predstavlja
poslovni ključ OLTP baze podataka Northwind. Podaci u dimenziji DimProducts su preuzeti
iz tabela Products i Categories iz Northwind baze podataka.

Na primjeru ove dimenzije dolazi do izražaja denormalizacija baze podataka koja

mora da bude sprovedena radi formiranja skladišta podataka. To je vidljivo u slučaju kolona
CategoryName i CategoryDescription koje se ponavljaju za svaki red, odnosno svaki
proizvod. U slučaju da se radi o bazi podataka koja je u trećoj normalnoj formi (3NF), na
mjestu kolona CategoryName i CategoryDescription bi se nalazila kolona CategoryID koja bi
referencirala primarni ključ kategorije u zasebnoj tabeli Category. Alternativno rješenje je da
se formira dimenzija DimCategory, a zatim povežu dimenzije DimProduct i
DimCategorypomoću ključeva. Taj slučaj nije razmotren u ovom radu, budući da je ta
organizacija baze podataka snowflake šema. Na slici 6.5 prikazana je dimenzija DimProducts.

Slika 6.5 - Dimenzija DimProducts

Sistem treba da vodi evidenciju i o dobavljačima artikala poput naziva kompanije,

brojeva telefona, adrese i ti podaci se nalaze u dimenziji DimSuppliers. Kolona
IDDimSupplier predstavlja surogat ključ dimenzije, dok kolona SupplierId predstavlja
jedinstveni poslovni ključ iz OLTP baze podataka Northwind. Podaci su preuzeti iz tabele
Suppliers. Na slici 6.6 je prikazana dimenzija DimSuppliers.
31
 Slika 6.6 - Dimenzija DimSuppliers

Potrebno je definisati i dimenziju DimTerritories za predstavljanje geografskih

pojmova odnosno lokacija. Podaci za ovu dimenziju su preuzeti iz OLTP tabela Region i
Territories. Kolona IDDimTerritory je surogat ključ za ovu dimenziju, dok je kolona
TerritoryID poslovni ključ dimenzije. Na slici 6.7 prikazana je dimenzija DimTerritories.

Slika 6.7 - Dimenzija DimTerritories

Na kraju, potrebno je formirati i dimenziju DimDate koja će predstavljati vremensku

dimenziju u BI sistemu. Kolona IDDimDate kao i kod ostalih dimenzija predstavlja surogat
ključ dimenzije, a kolona DateKey poslovni ključ dimenzije. U fact tabeli vrijednost surogat
ključa IDDimDate predstavlja datum jedne narudžbe i u dimenziji DimDate se nalaze detaljni
podaci o navedenom danu poput rednog broja dana u mjesecu, dana u sedmici, podataka da li
je navedeni dan praznik itd. Atributi dimenzije DimDate su prikazani na slici 6.8. Podaci u
dimenziji DimDate nisu podložni promjenama te za nju nije implementiran SCD koncept.

32
Slika 6.8 - Dimenzija DimDate

33
 6.1.2 Formiranje fact tabele

Nakon što je postupak dizajniranja dimenzija završen, moguće je preći na dizajn fact
tabele. Budući da je baza podataka Northwind orijentisana ka prodaji i da sadrži sve potrebne
informacije o prodaji, možemo formirati fact tabelu FactSales koja će sadržavati podatke o
prodaji artikala.

Dimenzije služe kao podrška tabeli FactSales i sadrže detaljnije informacije o prodaji
artikala. Struktura fact tabele je prikazana na slici 6.9. Ona sadrži kolone koje su strani
ključevi ka dimenzijama i to IDDimSupplier, IDDimProduct, IDDimCustomer,
IDDimLogistics, IDDimTerritory, IDDimEmployee, IDDimDate. Veza između fact tabele i
njenih dimenzija je 1:M (1 na strani dimenzija, a M odnosno više na strani fact tabele).

Slika 6.9 - Tabela FactSales

Fact tabela takođe sadrži i svoj sopstveni surogat ključ – IdFactSale. On je

sintetizovan na osnovu rednog broja reda – navedena kolona ima auto-increment svojstvo.
Pošto se radi se o star šemi, vidimo da nema veza između dimenzija, i kako imamo samo
jednu fact tabelu, niti jedna dimenzija nije dijeljena od strane više fact tabela. Osim kolona
koje su ključevi, u tabeli se nalaze i kolone koje dodatno opisuju jednu prodaju artikla, a nije
im mjesto u dimenzijama. Broj ovih kolona određuje granularnost sistema. Podaci koji se
nalaze u fact tabeli potiču iz svih tabela iz baze podataka Northwind. U slučaju kolona koje su
ključevi u fact tabeli, podaci su uveženi na osnovu poslovnih ključeva odgovarajućih OLTP
tabela, a zatim je izvršena ekstrakcija surogat ključa koji odgovara posmatranom poslovnom

34
ključu. Nakon toga, u odgovarajuću kolonu fact dimenzije upisan je pronađeni surogat ključ.
Nakon faze logičkog dizajna, skladište podataka ima izgled kao na slici 6.10.

Slika 6.10 - Northwind Data warehouse

6.2 Fizički dizajn skladišta podataka

Fizička implementacija skladišta podataka je izvršena u razvojnom okruženju

Microsoft SQL Server Integration Services (SSIS). Ono funkcioniše na principu kreiranja
paketa koji se zatim izvršavaju na Microsoft SQL Serveru. SSIS je alat koji omogućava
izvršavanje ETL operacija poput ekstrahovanja podataka iz velikog broja izvora podataka,
transformacije podataka (npr. konverzija tipova podataka, kalkulacije, agregiranje podataka i
sl.), definisanje radnog toka (eng. workflow) itd.

Sam alat je vrlo moćan i dozvoljava definisanje naprednih radnih tokova koji
uključuju korišćenje Web servisa, parsiranje XML dokumenata i drugih mogućnosti koje su
podjeljene u dvije glavne kategorije:

 zadaci koji se tiču toka podataka,

 zadaci koji se tiču kontrolnog toka.

U slučaju kontrolnog toka, raspoloživi predefinisani zadaci su izvršavanje SQL koda,

FTP zadatak, XML zadatak, rad sa Web servisom, iteratori i for each petlje, backup baze
podataka, izgradnja indeksa u SQL tabelama i sl. Kod toka podataka imamo izbor zadataka
koji se tiču ekstrahovanja podataka iz izvora i učitavanje podataka u odredište pri čemu izvor
i odredište mogu da budu Excel tabela, OLE DB baza podataka, Access baza podataka,
tekstualni fajl i XML fajl kao i mnoštvo drugih zadataka.

Realizacija svih navedenih zadataka vrši se unutar paketa koje je potrebno kreirati u
SSIS alatu. Svaki paket predstavlja zasebnu cjelinu i uglavnom se odnosi na jedan logički
zadatak koji je potrebno obaviti. Paketi međusobno mogu biti povezani i njihovo izvršavanje
je uslovljeno izvršavanjem drugih paketa ili kontrolnim promjenljivim. SSIS takođe podržava
i druge mogućnosti poput rukovaoca događajima (eng. event handler), pa je moguće
implementirati interaktivan tok izvršavanja paketa. Nakon dizajna paketa i verifikacije

35
ispravnosti potrebno je izvršiti stavljanje paketa u produkciju (eng. deployment) na SQL
Server. Nakon toga, oni se mogu izvršavati periodično kao poslovi (eng. jobs) na nivou SQL
Servera pri čemu se može definisati i plan izvršavanja paketa.

Svi zadaci definisani u kreiranim paketima nalaze se u Sequence Container-u koji

omogućava da se zadaci izvršavaju tačno onim redoslijedom kojim su definisani. Usljed
optimizacije procesa izvršavanja paketa, SQL Server kreira svoj plan izvršavanja, pri čemu je
izvršavanje pojedinih zadataka u paketu konkurentno i tada može doći do problema. Primjer
za to bi bio kreiranje dimenzija i fact tabela: s ozbirom na to da postoje veze 1:M od
dimenzija ka fact tabeli, ako bi zbog konkurentnosti fact tabela bila kreirana prije kreiranja
svih dimenzija, izvršavanje paketa ne bi bilo uspješno. Prije samog izvršenja paketa,
neophodno je definisati i konekcione menadžere (eng. Connection Managers) da bi se SSIS
mogao povezati na njih i ekstrahovati neophodne podatke u svrhu izvršavanja paketa.
Konekcioni menadžeri se mogu definisati na nivou paketa (vidljivi unutar paketa u kojem su
definisani) ili na nivou čitavog projekta (vidljivi u svim paketima). Skladište podataka u ovom
slučaju je implementirano kroz pet ta koji će biti opisani u nastavku.

6.2.1 Paket Extract

U paketu Extract prvo se obavlja backup baze podataka Northwind, a zatim kreiranje
baze podataka koja će da postane skladište podataka pod nazivom Northwind_DW. Zatim se
formiraju dimenzije koje su dizajnirane u prethodnom koraku i na kraju se formira fact tabela.
Kompletan proces je vidljiv na slici 6.11, pri čemu strelice određuju redoslijed izvršavanja
zadataka u paketu.

Slika 6.11 – Paket Extract

36
 U ovom trenutku, tabele su samo kreirane izvršavanjem DDL (eng. Data Definition
Language) skripti i u njima se ne nalaze nikakvi podaci. Konekcioni menadžer Northwind
definisan u paketu je tipa OLE DB (Microsoft SQL Server) i referencira OLTP bazu podataka
Northwind na osnovu koje će biti kreirano skladište podataka. Takođe, definisan je i
konekcioni menadžer Northwind_Extract koji služi kao podrška za pravljenje rezervne kopije
baze podataka Northwind, kao i konekcioni menadžer Northwind_DW koji će referencirati
skladište podataka. Baza podataka Northwind_DW ne mora nužno da postoji kao preduslov
za kreiranje konekcionog menadžera koji će je referencirati pa je iz tog razloga potrebno
uključiti opciju Delay validation da bi SSIS nastavio sa izvršavanjem paketa sve dok se taj
konekcioni menadžer ne bude koristio.

6.2.2 Paket Transform

Ovaj paket je vrlo jednostavan i sastoji se samo od jednog zadatka – definisanje

referencijalnog integriteta u tabeli FactSales. Na slici 6.12 prikazan je sadržaj paketa
Transform.

Slika 6.12 – Paket Transform

Paket ne sadrži dodatne parametre niti korisnički definisane promjenljive, a koristi

konekcione menadžere Northwind i Northwind_DW.

6.2.3 Paket Load

U paketu Load obavljaju se dva bitna zadatka:

 punjenje dimenzija i fact tabele podacima iz baze podataka Northwind,
 implementacija koncepta SCD.

Punjenje dimenzija i fact tabele podacima urađeno je korišćenjem opcije Execute SQL
Task. Podaci su u tabele napunjeni direktno, SQL skriptama, i identični su onima iz originalne
baze podataka uz dodatak da su surogat ključevi automatski generisani. Pojedinačni zadaci se
opet nalaze u Sequence container-u da bi se prvo napunile sve dimenzije, a tek na kraju fact
tabela jer bi u suprotnom mogla da se desi greška na nivou SQL Servera zbog toga što uslov
referencijalnog integriteta nije zadovoljen. Korišćeni su konekcioni menadžeri Northwind i
Northwind_DW.

Prilikom izvršavanja paketa mogu se desiti različite greške i nepredviđeni slučajevi, pa

je zbog toga implementirano logovanje grešaka. SSIS ima širok skup funkcionalnosti koji se
tiče obrade grešaka, a u ovom radu je korišćen „SSIS Logging“. U tu svrhu su za ovaj paket
definisana dva konekciona menadžera koji rade sa tekstualnim fajlovima,
„PunjenjeDimenzijaPodacima“ i „VerzionisanjeDimenzija“. Potrebni tekstualni fajlovi u koje
će biti smještene informacije o nastalim greškama su prethodno kreirani, a konekcioni
menadžeri koji su korišćeni su Northwind i Northwind_DW. Izgled dijela paketa koji se tiče
popunjavanja podataka je prikazan na slici 6.13.

37
 Slika 6.13 – Paket Load – Punjenje podataka

Drugi dio paketa Load se odnosi na implementaciju SCD koncepta, odnosno na

omogućavanje čuvanja istorije promjena u dimenzijama. Nakon definisanja Data flow zadatka
za svaku od dimenzija, moguće je iskoristiti zadatak Slowly changing dimensions radi
definisanja tipa promjena nad dimenzijom i načina na koji će se promjene čuvati u sistemu.
Dio paketa Load koji se odnosi na implementaciju SCD ima izgled kao na slici 6.14.

Slika 6.14 – Paket Load – Implementacija SCD

Konkretna implementacija mehanizma verzionisanja za dimenziju DimProducts ima

izgled kao na slici 6.15, a za ostale dimenzije implementacija je izvršena na isti način.

38
 Slika 6.15 – Paket Load – SCD Data Flow za dimenziju DimProducts

6.2.4 Paket ExcelDimensionsExport

Namjena paketa ExcelDimensionsExport je da demonstrira rad sa Excel datotekama

kroz izvoz podataka iz svih dimenzija u jednu Excel datoteku sa više radnih listova. U ovom
slučaju, izvor podataka je tabela u SQL Serveru i konekcioni menadžer je OLE DB tipa dok je
odredišni konekcioni menadžer Excel Connection Manager. U Excel Connection Manager-u
je dovoljno definisati putanju do Excel datoteke u koju se upisuju podaci i verziju datoteke
odnosno da li se radi o formatu fajla .xls ili .xlsx.

Na slici 6.16 prikazan je izgled data flow elementa za izvoz podataka o kupcima iz
dimenzije DimCustomers u Excel datoteku naziva „Sifarnici_NorthwindDW.xls”, u radni list
„Kupci”. Prilikom izvoza podataka potrebno je izvršiti mapiranje kolona u odredišnoj Excel
datoteci. Najjednostavniji način da se to uradi je da se u Excel datoteci automatski kreiraju
kolone sa istim nazivima kao u izvorišnoj tabeli pri čemu se neke kolone mogu izostaviti
ukoliko je to od interesa.

Slika 6.16 – Paket ExcelDimensionsExport – Izvoz podataka o kupcima

39
 6.2.5 Paket WebServis

SSIS je omogućio lako i intuitivno korišćenje nadogradnji za SQL Server koje su ga

učinile veoma funkcionalnim i konkurentnim, a jedna od takvih nadogradnji je i podrška za
rad sa Web servisima (eng. Web Service).

U paketu WebServis pokazano je kako se SSIS može iskoristiti za konzumaciju Web

servisa, a zatim za korišćenje dobijenih podataka u skladištu podataka. Kako u tabelama
Region i Territory u originalnoj Northwind bazi podataka podaci nisu potpuni, odnosno tabele
ne sadrže podatke o državama kao ni potpuno tačne nazive gradova, iskorišten je Web servis
za ažuriranje podataka koji nedostaju. Web servis koji je korišćen se nalazi na sljedećoj
adresi: http://www.webservicex.net/uszip.asmx.

Web servis sadrži sljedeće metode:

 GetInfoByAreaCode,
 GetInfoByCity,
 GetInfoByState,
 GetInfoByZIP.

Atributi koje Web servis vraća kao odgovor su:

 kod države,
 grad,
 kod područja,
 vremenska zona,
 ZIP kod (ekvivalent poštanskog broja).

Metoda Web servisa koja je pozivana u SSIS je GetInfoByZIP budući da Northwind

baza podataka sadrži ispravne podatke o ZIP kodovima gradova koji su već učitani u
dimenziju DimTerritories u paketu Load. U paketu WebServis prvo je formiran Result set
uzimajući sve ZIP kodove iz dimenzije DimTerritories pri čemu je korišćen konekcioni
menadžer Northwind_DW. Takođe, potrebno je dodati kolone privremenog karaktera u
dimenziju DimTerritories kako bi bilo moguće smjestiti podatke dobijene iz Web servisa.
Kolone fizički dodajemo u dimenziju izvršavanjem sljedeće SQL naredbe:

ALTER TABLE dbo.DimTerritories

ADD
CITY VARCHAR(127) NULL,
STATE VARCHAR(127) NULL,
ZIP VARCHAR(63) NULL,
AREA_CODE VARCHAR(127) NULL,
TIME_ZONE VARCHAR(127) NULL

Na slici 6.17 vidljiva su prva dva koraka definisana u paketu WebServis.

40
 Slika 6.17 – Paket WebServis, formiranje result set-a i dodavanje privremenih kolona

Nakon što smo preuzeli ZIP kodove iz skladišta podataka i formirali neophodne
kolone, potrebno je pozvati Web servis za svaki od ZIP kodova, a zatim dobijene podatke
smjestiti u skladište podataka. S obzirom na to da su ZIP kodovi iz skladišta podataka pristigli
u obliku result set-a koji je složena kolekcija podataka, potrebno je iterirati kroz taj skup
podataka da bi mogli da ih iskoristimo. Iz tog razloga, neophodno je koristiti for each petlju
da bismo mogli da pristupimo svakom pojedinačnom elementu.

U SSIS postoji implementacija foreach petlje koja se naziva foreach loop container i
pogodna je za upotrebu u ovom konkretnom slučaju. Potrebno je definisati parametre foreach
loop container-a tako da je izvorni skup podataka result set koji sadrži ZIP kodove gradova.
Kako je result set formiran na osnovu podataka iz Microsoft SQL Server baze podataka,
koristimo foreach ADO enumerator pogodan za procesiranje podataka iz Microsoft baza
podataka i podešavamo vrijednost iteracije na varijablu TerritoryID koja predstavlja jedan
ZIP kod grada iz skladišta podataka.

Unutar Foreach Loop Container-a vršimo poziv Web Servisa prilikom čega koristimo
konekcioni menadžer kreiran za poziv Web Servisa, pod nazivom HttpConnectionManager.
HttpConnectionManager poziva Web servis na već navedenom URL-u i pri tome se ne koristi
proxy server niti je potrebna autentikacija da bi se koristio Web servis. Web servis nakon
poziva vraća XML sadržaj i taj sadržaj je potrebno smjestiti na proizvoljnu lokaciju, a zatim i
parsirati. Za potrebe smještanja XML sadržaja na disk, kreiran je konekcioni menadžer pod
nazivom „rezultat.xml“ i on je tipa file connection manager. Nakon poziva Web servisa i
preuzimanja rezultata, SSIS kreira fajl „rezultat.xml“ na proizvoljnoj lokaciji na disku i u
datoteku smješta preuzeti XML sadržaj. Takođe, prethodno je kreirana i datoteka koja sadrži
opis Web servisa (eng. WSDL file) pri čemu je WSDL datoteku moguće preuzeti i automatski,
prilikom poziva Web servisa.

U narednom koraku izvršena je konverzija tipa promjenljive TerritoryID iz tipa Object

u tip String da bi bilo moguće koristiti promjenljivu kasnije, u Data Flow dijelu paketa.
Konverzija je izvršena upotrebom komponente „Script task“ i to korišćenjem programskog
jezika C# (moguće je koristiti i VisualBasic programski jezik). Posmatrano za jednu iteraciju
foreach loop container-a, sada imamo preuzete podatke iz Web servisa za jedan grad čiji ZIP
kod smo proslijedili kao argument Web servisa a koji smo dobili iz result set-a. Podaci su
smješteni u XML fajl naziva „rezultat.xml“ i još je potrebno parsirati XML fajl i smjestiti
podatke u odredište, odnosno ažurirati dimenziju DimTerritories. Dio koji se tiče parsiranja

41
podataka će biti obavljen u Data Flow zadatku koji je nazvan „Import podataka“. Kontrolni
tok paketa WebServis ima izgled kao na slici 6.18.

Slika 6.18 – Paket WebServis, kontrolni tok

Sa slike 6.18 takođe je vidljivo da će zadatak „Prilagođenje dimenzije“ biti izvršen
nakon uspješnog izvršavanja jedne iteracije foreach loop container-a, budući da je takvo
ponašanje definisano ograničenjem (eng. constraint) tipa Completion. U ovom zadatku biće
obrisane privremene kolone definisane radi smještanja podataka dobijenih iz Web servisa.
Data flow dio paketa WebServis ima izgled kao na slici 6.19.

Slika 6.19 – Paket WebServis, Data flow

42
 U Data flow dijelu paketa WebServis prvi korak je definisanje izvora podataka a to je
u ovom slučaju XML datoteka pod nazivom „rezultat.xml” kao i definisanje XML šeme na
osnovu koje će biti izvršena validacija izvorne XML datoteke. Korišćeni su isti konekcioni
menadžeri definisani na nivou projekta. Sljedeći korak je konverzija podataka dobijenih iz
Web servisa u odgovarajući format koji koristi SQL Server da bi se podaci mogli smjestiti u
skladište podataka. Izvršena je konverzija u SSIS format „DT_STR“ dužine 255 karaktera
prilikom čega je korišćena kodna strana 1252 (Ansi - Latin I) što osigurava da će se podaci
moći smjestiti u odredišnu bazu podataka – Northwind_DW.

U sljedećem koraku vrši se konverzija parametra TerritoryID u tip String kako bi on

mogao da se koristi u SQL upitu za ažuriranje podataka u dimenziji DimTerritories. U
posljednjem koraku Data flow dijela paketa WebServis vrši se ažuriranje dimenzije
DimTerritories sa novim podacima za posmatrani grad. Nakon ovog koraka započinje
izvršavanje nove iteracije foreach loop container – a za sljedeći grad čiji je ZIP kod preuzet iz
result set-a. Navedeni postupak se ponavlja sve dok foreach loop container ne prođe kroz
čitav result set i ažurira sve podatke o gradovima u dimenziji.

Da bi se izvršilo ažuriranje dimenzije i brisanje privremenih kolona, potrebno je

izvršiti sljedeće SQL naredbe:

UPDATE dbo.DimTerritories
SET
dbo.DimTerritories.TerritoryDescription = CITY,
dbo.DimTerritories.RegionDescription = STATE

ALTER TABLE dbo.DimTerritories

DROP COLUMN CITY,STATE, ZIP, TIME_ZONE

Nakon uspješnog izvršavanja paketa WebServis skladište podataka je u potpunosti

spremno za stavljanje u produkciju pa je iz tog razloga potrebno uraditi deployment projekta
na SQL Server. SSIS paketi će nakon ovog koraka biti dostupni za izvršavanje na SQL
Serveru pri čemu je moguće kreirati raspored izvršavanja paketa, periodično izvršavanje
paketa itd. Ukoliko se dizajn svih paketa smatra završenim, potrebno je uraditi deployment
projekta na SQL Server i nakon toga prestaje potreba za korišćenjem SSIS alata za posmatrani
projekat već je sve zadatke moguće izvršiti na nivou SQL Servera.

6.2.6 Paket Main

Kako je redoslijed izvršavanja paketa od suštinskog značaja, potrebno je ograničiti

izvršavanje paketa na nivou SSIS. Konkretan postupak koji je primijenjen u ovom slučaju je
definisanje novog paketa koji je nazvan Main i u kojem je definisan Sequence Container, koji
sadrži niz Execute Package elemenata. Svaki od Execute Package elemenata izvršava jedan
paket koji je definisan u podešavanjima elementa. Na ovaj način biće omogućeno izvršavanje
paketa u korektnom redoslijedu i prilikom izvršavanja svih paketa (u SSIS i na nivou SQL
Servera) biće dovoljno pokrenuti izvršavanje paketa Main. Izgled paketa Main je prikazan na
slici 6.20.

43
 Slika 6.20 – Paket Main

Nakon završetka izvršavanja paketa Main skladište podataka Northwind_DW postaje

dostupno za dalju upotrebu. U trenutnom stanju, skladište podataka ima definisane dimenzije
sa implementiranim SCD, fact tabelu, podatke iz baze podataka Northwind, podatke iz
dimenzija u Excel datoteci kao i ažurnu dimenziju DimTerritories. Skladište podataka se sada
može iskoristiti u produkcione svrhe, na primjer za izvještavanje ili multidimenzionalnu
analizu podataka.

Na slici 6.21 prikazan je dio podataka sadržanih u tabeli FactSales.

Slika 6.21 – Sadržaj tabele FactSales

44
7. IZVJEŠTAVANJE U SISTEMIMA POSLOVNE
INTELIGENCIJE

U ovom dijelu biće pokazan način implementacije sistema izvještavanja u prethodno

kreiranom skladištu podataka NORTHWIND_DW. U tu svrhu biće korišćeno razvojno
okruženje SQL Server Reporting Services (SSRS).

SSRS je serverska platforma za izvještavanje, koja omogućava kreiranje različitih

vrsta izvještaja kao i isporuku izvještaja u velikom broju formata. Izvještaji mogu da
uključuju tabele, matrice, grafikone, podizvještaje (izvještaj unutar izvještaja) itd. Arhitektura
sistema je prikazana na slici 7.1.

Slika 7.1 – Arhitektura SSRS [22]

Prilikom stavljanja sistema u produkciju, mora da postoji instanca SQL Servera koja
će da podrži SSRS i na njoj će biti kreirane dvije baze podataka neophodne za funkcionisanje
SSRS [22]:
 ReportServer – služi za smještanje samih izvještaja odnosno definicija izvještaja,
korisničkih podešavanja vezanih za izvještaje, istorije izvršavanja izvještaja,
 ReportServerTempDb – baza podataka u koju se privremeno smještaju izvještaji koji
treba da se izvrše kao i drugi meta-podaci.

Takođe, potrebno je instalirati i modul ReportServer Web Service na instancu SQL

Servera (ne nužno na instancu na kojoj se nalaze navedene baze podataka) da bi bio
omogućen Web pristup izvještajima kao i Web stranica za podešavanje SSRS. Krajnji korisnik
šalje HTTP zahtjev za izvještaj eventualno prosljeđujući neophodne parametre koji SSRS
server prima, parsira i pronalazi meta-podatke vezane za zahtjevani izvještaj. SSRS server
zatim zahtijeva konkretne podatke iz izvora podataka, kombinuje strukturu izvještaja sa
vraćenim podacima, a zatim formirani izvještaj dostavlja korisniku u njegovom Web
pretraživaču. U svrhu demonstracije funkcionalnosti SSRS, kreirano je pet izvještaja i izvršen
je deployment izvještaja na instancu SQL Servera 2014 na kojoj se nalaze potrebne baze
podataka kao i ReportServer Web Service.

45
7.1 Tehnike kreiranja izvještaja u SSRS

Dizajniranje izvještaja pomoću SSRS sastoji se iz više koraka, ali je intuitivno i

razumljivo. SSRS može da kao izvor podataka koristi razne sisteme za upravljanje bazama
podataka poput Microsoft SQL Server, Oracle, Teradata, Windows Azure i druge. Izvještaje
je moguće kreirati koristeći čarobnjak za kreiranje izvještaja ili ručno, bez asistencije.
Čarobnjak za kreiranje izvještaja (eng. Report wizard) vodi dizajnera kroz niz koraka
potrebnih za kreiranje jednog izvještaja, što uključuje definisanje izvora podataka, upita na
osnovu kojeg će podaci biti ekstrahovani, dizajn izvještaja itd.

Prilikom kreiranja izvještaja, potrebno je specifikovati SQL upit ili uskladištenu

proceduru na osnovu čega će podaci biti ekstrahovani iz baze podataka. Grafički alat koji
može značajno da pomogne pri specifikovanju SQL upita je Query Builder. Potrebno je
izvršiti odabir tabela i kolona koje će se pojaviti u izvještaju, a zatim specifikovati filtre i
parametre a SQL upit će biti automatski generisan.

Drugi korak je specifikovanje izvora podataka (eng. Data source) iz kojeg će biti
ekstrahovani podaci koji će se pojaviti u izvještaju. U praktičnom dijelu rada kreiran je izvor
podataka Northwind_DW koji referencira skladište podataka Northwind_DW. Slično kao kod
SSIS, izvor podataka može da bude definisan na nivou projekta (eng. Shared data source) ili
na nivou jednog izvještaja (vidljiv samo u izvještaju u kojem je definisan).

Po izvršenom podešavanju izvora podataka potrebno je definisati jedan ili više

skupova podataka (eng. Data sets) koji će se pojaviti u izvještaju. Jedan skup podataka
predstavlja i matematički podskup podataka dostupnih u izvoru podataka, ali on može da
obuhvata i čitav izvor podataka. Za skup podataka je potrebno definisati SQL upit da bi bilo
moguće ekstrahovati potrebne podatke koji će biti korišćeni u izvještaju, i to je opet moguće
uraditi pomoću Query Builder-a. Ukoliko upit sadrži SQL parametre koje prosljeđujemo
prilikom generisanja izvještaja, oni se nalaze u podešavanjima Data set-a i moguće im je
mijenjati tip, naziv i druga podešavanja. Vrijednosti parametara je moguće ispisati unutar
izvještaja navođenjem uglastih zagrada unutar kojih se nalazi simbol @ i nakon njega naziv
parametra, na primjer [@DatumOd].

Nakon što su definisani izvor i skup podataka, na raspolaganju imamo spisak polja
koja smo specifikovali u SELECT upitu i njima možemo manipulisati na način da ih
ispisujemo u izvještaju, kreiramo nova izračunata polja na osnovu postojećih, formatiramo ih
itd. U SSRS postoji i veliki broj ugrađenih polja poput:

 Execution time – predstavlja trajanje generisanja izvještaja,

 Page number – broj tekuće stranice,
 Overall total pages – ukupan broj stranica,
 Report Server URL – Web lokacija servera za izvještavanje,
 User ID – ID korisnika koji trenutno pregleda izvještaj.

U izvještaj je moguće dodati sljedeće elemente:

 tekstualno polje – polje za unos teksta u kojem je moguće ispisati polja izvještaja, a
moguće je specifikovati i izraze koji će se izračunavati prilikom izvršavanja izvještaja
i u zavisnosti od rezultata ispisivati odgovarajuće vrijednosti,
 linija – za detaljnije formatiranje izvještaja ili razdvajanje cjelina,

46
  tabela – služi za prikaz podataka, moguće je dodavati redove i kolone i formatirati je
po potrebi,
 matrica – slična tabeli ali sadrži i dio sa „detaljima“ odnosno vrijednostima koje se
nalaze na presjeku redova i kolona,
 pravougaonik – element koji može da služi kao „spremnik“ za druge elemete odnosno
da omogući da neki elementi budu sakriveni a neki prikazani,
 lista – moguće je kreirati liste koje podsjećaju na Web forme i podržava sve
mogućnosti koje podržava i tabela u SSRS,
 slika – moguće je koristiti slike u izvještajima,
 podizvještaj (eng. subreport) – predstavlja izvještaj u izvještaju ali uz uslov da se
podizvještaj dizajnira odvojeno od glavnog izvještaja,
 grafikon – omogućava grafičku predstavu podataka, podržan je veliki broj tipova
grafikona poput onih iz Microsoft Excel-a,
 mjerač (eng. gauge) – koristi se za predstavljanje jedne vrijednosti unutar opsega
vrijednosti,
 mapa – služi za predstavljanje podataka na mapi, pri čemu podaci mogu da budu
učitani iz raznih izvora podataka poput specijalizovanih SQL baza podataka,
Microsoft Virtual Earth datoteka i drugih,
 indikator – omogućuje predstavljanje poslovnih trendova i ciljeva koristeći strelice,
obojene rombove i druge grafičke elemente.

Za svaki od navedenih elemenata kao i za izvještaj koji dizajniramo, dostupna su

detaljna podešavanja koja se nalaze u „Properties“ sekciji razvojnog okruženja. Tu je moguće
podesiti fontove, boju pozadine, formatiranje polja, lokalizaciju, dimenzije elementa, ivice,
opis itd.

Uz to, SSRS podržava i kreiranje izvještaja koji mogu da posluže kao šabloni (report
templates) nakon čega ih je moguće iskoristiti za kreiranje drugih izvještaja. Prvi korak je
kreiranje standardnog SSRS izvještaja koji će da predstavlja šablon, a zatim je potrebno
manuelno smjestiti kreirani .rdl fajl na sljedeću lokaciju na disku:
\PutanjaDoInstalacionogFolderaVisualStudia\Common7\IDE\PrivateAssemblies
\ProjectItems\ReportProject.

7.2 Pregled kreiranih izvještaja

U svrhe demonstracije mogućnosti BI sistema i SSRS, kreirano je više izvještaja od

kojih će biti prikazana dva.

Izvještaj „Najbolji kupci” je prikazan na slici 7.2. Vrijednosti parametara su vidljive u

naslovu izvještaja i iznose:

 Datum od: 01.01.2013.

 Datum do: 31.12.2013.
 Grad: Orlando

47
 Slika 7.2 – Izvještaj „Najbolji kupci“

Podaci prikazani u izvještaju „Najbolji kupci“ su dobijeni na osnovu sljedećeg SQL

upita:

SELECT DimCustomers.CustomerID, DimCustomers.CompanyName,

DimCustomers.ContactName, DimCustomers.Address, DimCustomers.City,
DimCustomers.Country, SUM(FactSales.Total) AS UkupanIznos

FROM DimCustomers
INNER JOIN FactSales ON DimCustomers.IDDimCustomer =
FactSales.IDDimCustomer
INNER JOIN DimTerritories ON FactSales.IDDimTerritory =
DimTerritories.IDDimTerritory
INNER JOIN DimDate ON FactSales.IdDimDate = DimDate.IdDimDate

WHERE (DimDate.Date BETWEEN @DatumOd AND @DatumDo) AND

(DimTerritories.TerritoryDescription = @Grad)

GROUP BY DimCustomers.CustomerID, DimCustomers.CompanyName,

DimCustomers.ContactName, DimCustomers.Address, DimCustomers.City,
DimCustomers.Country

ORDER BY UkupanIznos DESC

Kreirani izvještaji su dostupni za pregledanje iz Visual Studio-a kao i iz Web

pretraživača na adresi http://localhost/Reports_SQL2014/Pages/Folder.aspx. U prethodnoj
adresi, dio localhost je potrebno zamijeniti sa adresom SSRS servera. Prilikom izrade
praktičnog dijela ovog rada SSRS serveru je bilo pristupano sa lokalne mašine na kojoj je bio
instaliran SSRS server.

Na slici 7.3 je prikazan izvještaj „Najvrijednije narudžbe po teritorijama“ koji sadrži

grafikon na kojem su predstavljeni podaci o narudžbama po gradovima u zadanom
vremenskom periodu.

48
 Slika 7.3 – Izvještaj „Pregled narudžbi po teritoriji“

Na vertikalnoj osi prikazan je iznos narudžbe, a na horizontalnoj osi su prikazani

gradovi. Vrijednosti parametara:

 Datum od: 01.06.2013.

 Datum do: 30.06.2013.

Podaci prikazani u izvještaju „Pregled narudžbi po teritoriji“ dobijeni su na osnovu

sljedećeg SQL upita:

SELECT DimTerritories.TerritoryDescription,
DimTerritories.RegionDescription, DimTerritories.AREA_CODE AS
SifraPodrucja, SUM(FactSales.Total) AS UkupanIznos, DimDate.Date

FROM FactSales

INNER JOIN DimCustomers ON DimCustomers.IDDimCustomer =

FactSales.IDDimCustomer
INNER JOIN DimTerritories ON FactSales.IDDimTerritory =
DimTerritories.IDDimTerritory
INNER JOIN DimDate ON FactSales.IDDimDate = DimDate.IDDimDate

GROUP BY DimTerritories.TerritoryDescription,
DimTerritories.RegionDescription, DimTerritories.AREA_CODE, DimDate.Date

HAVING (DimDate.Date BETWEEN @DatumOd AND @DatumDo)

U izvještaju „Najvrijednije narudžbe po teritorijama“ prilikom odabira parametara za

parametre „DatumOd“ i „DatumDo“ datume možemo unijeti ručno ili ih možemo odabrati iz
kontrole date picker. Parametar „Grad“ biramo iz kontrole Combo box u koju su podaci

49
napunjeni ručno napisanim SQL SELECT upitom da ne bi bilo moguće izabrati grad koji se
ne nalazi u bazi podataka. SQL upit za odabir grada je sljedeći:

SELECT DISTINCT TerritoryDescription

FROM DimTerritories

Nakon unošenja parametara i prikaza izvještaja, moguće je izvršiti izvoz (export)

izvještaja u sljedeće formate:

 XML datoteka,
 CSV datoteka (odvajanje slogova je zapetom),
 TIFF datoteka,
 PDF datoteka,
 Excel datoteka,
 Word datoteka,
 MHTML arhiva (izvještaj se čuva kao snimljena Web stranica).

Moguće je vršiti i dodatna podešavanja za izvoz i prikaz podataka poput dimenzija

stranice, orijentacije stranice, načina štampanja izvještaja itd.

50
8. MULTIDIMENZIONALNO MODELOVANJE
U ovom dijelu biće pokazano kako se na osnovu projektovanog skladišta podataka
može izvršiti multidimenzionalna analiza dostupnih podataka kroz kreiranje OLAP kocke.
Alat koji će biti korišćen u tu svrhu je Microsoft SQL Server Analysis Services (SSAS).

OLAP kocka je objašnjenja u trećem poglavlju rada, a u nastavku će biti navedene
razlike između OLAP kocke i klasičnog OLTP pristupa procesiranju podataka. U tabeli 8.1. je
dato poređenje OLAP i OLTP načina procesiranja podataka.

Tabela 8.1 – Poređenje OLAP i OLTP načina procesiranja podataka [23]

ONLINE TRANSACTION PROCESSING ONLINE ANALYTICAL PROCESSING

(OLTP) (OLAP)
Dizajnirana da podrži svakodnevne DML Dizajnirana da podrži detaljno čuvanje
operacije u poslovnom sistemu istorije promjena i porijekla podataka radi
predviđanja trendova
Čuva podatke o transakcijama na dnevnom Podaci u sistemu su konzistentni do trenutka
nivou kada je izvršeno ažuriranje OLAP kocke
Podaci se čuvaju u normalizovanom obliku Podaci se čuvaju u denormalizovanom obliku
Veličina baze podataka je uglavnom od 100 Veličina baze podataka je uglavnom od 100
MB do 100 GB GB do nekoliko TB
Koriste je članovi organizacije sa nižim Koriste je članovi organizacije na najvišem
nivoima poput operativnog (strateškom) nivou organizacije
Hardverski zahtjevi su niži Hardverski zahtjevi su vrlo visoki
Izvršavanje je sporije ukoliko postoji veliki Izvršavanje upita je brzo zbog malog broja
broj podataka spajanja tabela. Generisanje izvještaja je
znatno brže.
Za upite se koristi strukturirani jezik za upite Za upite se koristi MDX jezik
nad relacionom bazom podataka (SQL)

Arhitektura SSAS je prikazana na slici 8.1.

Slika 8.1 – Arhitektura SSAS [23]

51
 Sa slike 8.1 je vidljivo da se skladište podataka koristi kao izvor podataka. Nakon
procesiranja kocke podaci postaju dostupni za korišćenje i moguće je izvršavati MDX
(MultiDimensional eXpressions) upite nad kockom. Za izvještavanje odnosno pregled
podataka u kocki moguće je koristiti SSRS ili Excel PowerPivot. U nastavku će biti definisani
osnovni pojmovi koji se koriste u multidimenzionalnoj analizi podataka [24].

Kocka. Ona predstavlja osnovnu jedinicu za smještanje podataka i sadrži podatke koji
su potencijalno prikupljeni iz više izvora podataka. To mogu da budu različite baze podataka,
lokalne datoteke na disku, dijeljene datoteke na mreži itd. Kocka je uglavnom optimizovana
na način da su podrazumijevano urađene agregacije po konačnom iznosu, datumu ili nazivu
radi boljih performansi pri generisanju izvještaja i uopšteno pristupa podacima.

Dimenzionalna tabela. Ova vrsta tabela je objašnjena u trećem poglavlju i predstavlja

standardnu dimenzionalnu tabelu.

Dimenzija. U SSAS, svaka kocka sadrži jednu ili više dimenzija pri čemu su one
bazirane na dimenzionalnim tabela s tim da mogu imati i dodatna, izračunata polja i
uspostavljene hijerarhije.

Hijerarhija. Hijerarhija omogućava pregled agregiranih podataka na više nivoa.

Hijerarhije mogu da budu prirodne odnosno (veze roditelj-potomak već postoje u podacima) i
navigacione (veze roditelj-potomak su vještački uspostavljene).

Fact tabela. Ova vrsta tabela je objašnjena u trećem poglavlju i predstavlja standardnu
fact tabelu.

Mjera. Svaka kocka sadrži jednu ili više mjera pri čemu je jedna mjera bazirana na
jednoj koloni iz fact tabele nad kojom je od interesa vršiti različite analize.

Šema. Veze između tabela u kocki formiraju šemu.

8.1 Implementacija koncepata multidimenzionalnog modelovanja podataka u

SSAS

U šestom poglavlju implementirano je skladište podataka koje je korišćeno da bi se

demonstrirali koncepti multidimenzionalnog modelovanja podataka. U ovom dijelu je
objašnjen postupak kreiranja jedne kocke na osnovu koje će biti izvršena analiza podataka.

Prvi korak je definisanje izvora podataka koji će u ovom slučaju biti skladište
podataka NORTHINWD_DW, ali potrebno je definisati i koji korisnički nalog će biti korišćen
za funkcionalnosti koje se odnose na analizu podataka. Odabrana je opcija „naslijeđenog“
povezivanja na izvor podataka, odnosno korišćenje onog korisničkog naloga za analizu
podataka koji je korišćen i za prijavu na izvor podataka.

Nakon definisanja izvora podataka potrebno je definisati i „pogled ka izvoru

podataka“ (eng. data source view) koji omogućuje odabir onih elemenata iz izvora podataka
koji čine jednu logičku cjelinu za analizu podataka. U prethodnom poglavlju, kod SSRS,
objašnjeno je kako se skup podataka (eng. Data Set) mogao iskoristiti da se ekstrahuje
podskup podataka iz izvora podataka i ovde je situacija slična. Glavna razlika je način
ekstrahovanja podataka, kod SSRS je to bio SQL upit dok je kod SSAS radi o odabiru
elemenata iz izvora podataka korišćenjem čarobnjaka za kreiranje pogleda ka izvoru podataka

52
(eng. Data Source View Wizard). Nakon što je kreiran pogled ka izvoru podataka, definisano
je i novo izračunato polje pod nazivom „Puno ime“ i ono je dodano u dimenziju
DimEmployees. Prilikom analize podataka i u različitim izvještajima biće potrebno puno ime
zaposlenog koje se sastoji od imena i prezimena zaposlenog, a koji se trenutno vode kao dva
različita atributa. SSAS sadrži mnoštvo čarobnjaka koji olakšravaju izvršavanje mnogih
zadataka te jednostavan i intuitivan korisnički interfejs.

Preduslovi za kreiranje kocke su postojanje veze ka izvoru podataka i pogled ka izvoru

podataka a budući da su ti uslovi sada ispunjeni moguće je kreirati i kocku koja je nazvana
„NorthwindAnalitickaKocka“. Kreiranje kocke je jednostavno i obavlja se uz pomoć
čarobnjaka za kreiranje kocke te se svodi na izbor mjera i dimenzija koje će biti prisutne u
kocki a koje su dostupne u pogledu ka izvoru podataka. Izgled kreirane kocke je prikazan na
slici 8.2.

Slika 8.2 – Northwind analitička kocka

U SSAS moguće je vršiti detaljno podešavanje dimenzija poput dodavanja hijerarhija,

dodavanja veza između atributa itd. U definisanoj kocki, hijerarhije su dodane na mjestima na
kojima to ima smisla. U dimenziji DimSuppliers definisana je geografska hijerarhija koja
uključuje kolone Country, Region, City, Address. Posmatrajući navedene četiri kolone lako se
dolazi do zaključka da bi hijerarhija trebala da bude definisana u redoslijedu u kojem su
kolone i navedene, kolona Country bi bila na vrhu hijerarhije dok bi kolona Address bila na
dnu hijerarhije. Definisana hijerarhija je vidljiva na slici 8.3. Osim definisanja hijerarhije
moguće je definisati i koje kolone iz pogleda ka izvoru podataka će biti korišćene u nekoj
dimenziji kocke odnosno ne moraju sve kolone biti u upotrebi. Odabir kolona se vrši

53
jednostavnim prevlačenjem (eng. drag and drop) iz pogleda ka izvoru podataka u konačan
spisak kolona.

Slika 8.3 – Definicija geografske hijerarhije u dimenziji DimSuppliers

SSAS podržava i pretraživač (eng. browser) za dimenziju i za kocku. Na slici 8.4 je

prikazan izgled pretraživača dimenzija za dimenziju DimSuppliers u kojem možemo vidjeti
konkretne instance prethodno definisane hijerarhije. Takođe, prikazan je i trenutni nivo u
hijerarhiji i ukoliko izaberemo najnižeg člana hijerarhije vidljivo je da je vrijednost za
trenutni nivo hijerarhije adresa.

Slika 8.4 – Pregled hijerarhije za dimenziju DimSuppliers

Na nivou kocke moguće je definisati i izračunata polja, slično kao kod pogleda ka
izvoru podataka gdje je definisano izračunato polja „PunoIme“. Glavna razlika je što se u
ovom slučaju koristi MDX jezik za definisanje polja umjesto T-SQL koji je podrazumijevani
jezik za upite u relacionim bazama podataka. Definisano je polje „SumaSvihNarudžbi“ koje
predstavlja ukupnu sumu narudžbi iz mjere FactSales i koje će biti potrebno prilikom
generisanja izvještaja o narudžbama.

U oblasti multidimenzionalne analize podataka, od interesa je i analizirati ključne

indikatore performansi koji mogu da pokažu da li su ciljevi organizacije ispunjeni, u kojem
smjeru se organizacija razvija kao i koje korake je potrebno preduzeti da bi poslovanje bilo
još uspješnije. U SSAS definisan je KPI pod nazivom „ProdajaKPI“ koji daje uvid u
uspješnost poslovanja kompanije Northwind na osnovu narudžbi odnosno prodanih artikala.
KPI se definiše u više koraka prilikom čega je potrebno definisati na koju mjeru se KPI
odnosi, koji je cilj koji je potrebno postići kao i trenutni status kako bi bilo jasno u kojem se
smjeru organizacija kreće. Prilikom definisanja „ProdajaKPI“ odabrana je mjera „Total“,
odnosno ukupna vrijednost narudžbi iz fact tabele FactSales.

54
 Za ciljnu vrijednost (eng. Goal) defisan je MDX upit u kojem je navedeno da je cilj
ispunjen ukolio je vrijednost narudžbe u nekom kontekstu veća ili jednaka prosječnoj
vrijednosti svih narudžbi u sistemu. MDX upit je sljedeći:

CASE
WHEN ([Measures].[Total] >= 12648)
THEN 'Cilj zadovoljen'
ELSE 'Cilj nije zadovoljen'
END

Prilikom prikaza podataka u Excel-u, KPI status promjenljiva će biti predstavljena
strelicama koje grafički predstavljaju status pojedinačnih stavki u izvještajima. MDX upit
korišćen za promjenljivu status je sljedeći:

CASE
WHEN KPIGoal("ProdajaKPI") = 'Cilj zadovoljen'
THEN 1
WHEN KPIGoal("ProdajaKPI") = 'Cilj nije zadovoljen'
THEN -1
ELSE 0
END
Primjer upotrebe definisanog KPI je prikazan na slici 8.5.

Slika 8.5 – Primjer upotrebe „ProdajaKPI” indikatora performansi

Nakon definisanja kocke i KPI, potrebno je izvršiti stavljanje kocke u produkciju a

zatim i procesiranje kocke kako bi podaci mogli biti pripremljeni za upotrebu. Stavljanje
kocke u produkciju (eng. deployment) se obavlja odabirom navedene opcije u SSAS i kocka
se tada smješta na instancu SQL Servera koja je definisana u izvoru podataka. Procesiranje
kocke se može vršiti na načine navedene u trećem poglavlju (MOLAP, ROLAP, HOLAP) dok
je u ovom slučaju korišćen MOLAP.

Nakon svake promjene podataka u kocki, na primjer nakon presipanja novih podataka
u kocku na kraju dana, potrebno je izvršiti procesiranje kocke ali i ponovo se konektovati na
instancu kocke kako bi podaci bili svježi. U odjeljku 10.1. je ranije rečeno da se za prikaz
podataka i izvještavanje može koristiti Microsoft Excel i SSRS. U ovom radu korišćen je
Microsoft Excel za prikaz i analizu podataka budući da je taj način prikaza podataka
55
najfleksibilniji i vrlo intuitivan. Podatke koji se nakon procesiranja nalaze u kocki je moguće
pregledati i korišćenjem pretraživača kocke (eng. cube browser), međutim on ne nudi nivo
fleksibilnosti koji nudi Microsoft Excel. U slučaju da se koristi pretraživač kocke, uvijek je
potrebno otvoriti Microsoft SSAS koji je hardverski zahtjevan i ne podržava filtriranje i
detaljno agregiranje podataka koje podržava Excel. Takođe, ukoliko bi se radilo o
produkcionom režimu rada, krajnjim korisnici BI sistema bi morali da na raspolaganju imaju
SSAS koji im je potencijalno neintuitivan za korišćenje, a morali bi plaćati i skupe licence za
SSAS.

U pretraživaču kocke, odabirom Microsoft Excel-a za pregled kocke, kreira se makro

za Excel koji pri otvaranju Excel-a ostvari konekciju ka skladištu podataka, kreira novu pivot
tabelu koja će biti korišćenja za analizu podataka i pripremi spiskove dimenzija, fact tabela i
KPI. U Excel pivot tabeli dimenzije, mjere i KPI možemo prikazati u jednoj od tri kategorije:

 kolone (svaka vrijednost biće prikazana kao kolona),

 redovi (svaka vrijednost biće prikazana kao red),
 detalji (vrijednosti na presjeku kolone i reda).

Prilikom odabira vrijednosti za prikaz, moguće je odabrati i hijerarhije koje su

definisane u prethodnom koraku na osnovu čega je moguće vršiti “razbijanje po
kategorijama“ (eng. drilldown). Na taj način možemo vidjeti iznose pojedinih mjera za
podatke grupisane po logičkim kategorijama. Primjer drilldown-a je prikazan na slici 8.6 gdje
je prikazan ukupan iznos narudžbi za dobavljače artikala pri čemu je razbijanje izvršeno po
definisanoj hijerarhiji za dimenziju DimSuppliers.

Formirani Excel fajlovi se mogu na uobičajen način snimiti i dalje distriburirati za one
kojima je od interesa da ih koriste. Excel konstantno održava vezu sa skladištem podataka i
automatski ih osvježava ukoliko dođe do bilo kakve promjene podataka. Ukoliko se
promijene podešavanja konekcionog menadžera, odnosno strukture kocke u nekim
slučajevima je neophodno izvršiti ručno osvježavanje konekcionog menadžera.

Slika 8.6 – Pregled iznosa narudžbi po teritoriji i nazivu dobavljača

56
8.2 Integracija SSAS i SSRS

Alati SSAS i SSRS su u uskoj sprezi i u ovom odjeljku će biti pokazano kako se oni
mogu integrisati radi dobijanja detaljnijih informacija o kupcima iz Excel pivot tabele. Prvi
korak je definisanje radnje vezane za izvještaje (eng. report action) u SSAS koja će poslužiti
kao veza između SSAS i SSRS. Radnja je nazvana „SSASIzvjestajKupci“ i vezana je za
kolonu „CompanyName“ u dimenziji DimCustomers. Način korišćenja definisane radnje je da
kada korisnik u Excel-u vrši pregled podataka koji su vezani za kupce može desnim klikom
na konkretnog kupca i odabirom opcije „Detaljniji pregled kupca“ vidjeti detaljnije podatke o
kupcu, u SSRS. U tu svrhu, kreiran je poseban izvještaj naziva „SSASIzvjestajKupci“ koji
obezbjeđuje potrebne podatke o kupcu. Izvršen je deployment izvještaja na sljedećoj Web
adresi:
http://localhost:80/ReportServer_SQL2014/Pages/ReportViewer.aspx?%2fDiplomskiRadSSR
S%2fSSASIzvjestajKupci.

Navedeni izvještaj kao parametar prima naziv kupca o kojem će prikazati detaljnije
podatke i taj parametar se proslijeđuje kroz URL ka izvještaju. Kompletan URL kojim je
zahtjevan izvještaj je sljedeći:
http://localhost/ReportServer_SQL2014/Pages/ReportViewer.aspx?%2fDiplomskiRadSSRS%
2fSSASIzvjestajKupci&CustomerName=Berglunds%20snabbköp&rs:Command=Render&rs:
Renderer=HTML5

Na slici 8.7 prikazan je način pokretanja detaljnog izvještaja o kupcima iz Excel-a.

Nakon definisanja radnje koja se tiče izvještaja potrebno je izvršiti deployment kocke, ponovo
je procesirati da bi promjene bile vidljive, a zatim ručno osvježiti izvor podataka u Excel-u.

Slika 8.7 – Pokretanje SSRS izvještaja sa detaljima o odabranom kupcu

Na slici 8.8 prikazan je dio SSRS izvještaja o kupcima koji je dobijen iz Excel-a. U
fazi dizajna izvještaja u SSRS koji će poslužiti kao podrška SSAS analizi podatka nije
potrebno voditi računa o dodatnim stavkama u odnosu na dizajn tipičnog SSRS izvještaja. To

57
čini promjene na izvještaju i kreiranje novih izvještaja jednostavnim i jednom kreirani
izvještaji se mogu bez održavanja koristiti duži vremenski period.

Slika 8.8 – Detaljan izvještaj o kupcu u SSRS

58
9. ZAKLJUČAK

U radu su izloženi načini implementacije sistema poslovne inteligencije u oblasti

veletrgovine i to: implementacija samog skladišta podataka, sistema izvještavanja i
multidimenzionalna analiza podataka. Nakon implementacije sistema, organizacija postaje
agilnija, spremnija za promjene, svjesnija svog trenutnog stanja kao i prilika koje može da
iskoristi. Danas, organizacije sve više prepoznaju prednosti koje sistem poslovne inteligencije
može da im pruži te ga uvode prvenstveno kao sistem za podršku pri donošenju strateških
odluka kao i u svrhe izvještavanja. Nakon uvođenja BI sistema, organizacije mogu ili da
smanje broj zaposlenih koji su do sada vršili prikupljanje i agregaciju podataka ili da im
dodijele nove poslove, kako bi na značajan način doprinijeli poslovanju organizacije.

Prednosti sistema poslovne inteligencije su brojne i nakon implementacije sistema

moguće je donositi odluke koje se tiču upravljanja organizacijom sa većom sigurnošću,
budući da su ranije menadžeri na strateškom nivou organizacije često odluke donosili
instinktivno i bez neke osnove. Proces donošenja odluka je u jednoj mjeri morao da bude
takav, s obzirom na to da podaci u informacionim sistemima organizacija često nisu bili
dovoljno strukturirani da bi na osnovu njih mogle da se donose konkretne odluke. Takođe,
korisnici sistema, bilo na strateškom ili na nekom nižem nivou mogu da u vrlo kratkom
vremenskom roku dobiju odgovor na pitanja vezana za poslovanje organizacije. Bez sistema
poslovne inteligencije korisnici bi morali da čitaju veliki broj izvještaja i da sami izvode
zaključke koji često nisu ispravni, dok u BI sistemu oni dobijaju odgovore na postavljena
pitanja koji su sintetizovani na osnovu konkretnih podataka.

Korisnici BI sistema nakon njegove implementacije mogu lako i brzo da dobijaju

podatke o KPI i drugim poslovnim metrikama u pokretu, odnosno na njihovim mobilnim
uređajima, prenosnim računarima i sličnim uređajima, budući da su podaci centralizovani u
skladištu podataka. Korisnici BI sistema više ne moraju da se oslanjaju na IT osoblje da bi
dobili izvještaje ili u opštem slučaju podatke koji su im potrebni, budući da ih mogu sami
preuzeti u BI sistemu. Dodatna prednost sistema poslovne inteligencije je predviđanje
trendova, na primjer za koji artikal se kupci najčešće odlučuju i kako je moguće poboljšati
prodaju manje popularnih artikala. BI sistem omogućuje organizacijama da unaprijede i
proces nabavke robe od dobavljača odnosno da mogu predvidjeti tačno koje količine robe će
im biti potrebne u nekom vremenskom opsegu što smanjuje gomilanje zaliha robe kod
prodavca.

S obzirom na sve navedene prednosti, može se reći da uvođenjem sistema poslovne

inteligencije organizacija dobija na efikasnosti i efektivnosti izvršavanja svojih poslovnih
procesa. Prestaje potreba za prikupljanjem ogromne količine različito strukturiranih podataka
iz više različitih sektora organizacije koji se zatim ne mogu iskoristiti dovoljno brzo i efikasno
da bi donijeli prepoznatljivu vrijednost organizaciji.

Sistem poslovne inteligencije ima i negativne strane, ali je njihov broj manji od
pozitivnih strana i predstavlja nešto što je moguće optimizovati da rad organizacije ne bude
doveden u pitanje. Jedna od glavnih negativnih strana BI sistema je gomilanje istorijskih
podataka koji se tiču promjena podataka u sistemu. Istorijski podaci su neophodni za dobro
donošenje odluka i predviđanje trendova ali su potrebni značajni hardverski resursi da bi se ti
podaci mogli skladištiti. Sa svakim dolaskom novih podataka u skladište podataka potrebno je
obezbijediti čuvanje istorije promjena tih podataka i na taj način količina podataka u sistemu

59
naglo raste. Implementacija samog BI sistema može da potraje i zahtijeva vrlo detaljnu
specifikaciju korisničkih zahtjeva, što dodatno produžava vrijeme implementacije sistema i
izaziva velike troškove za organizaciju. Sami BI sistemi nisu jeftini i uglavnom dolaze kao
pratnja uz druge informacione sisteme nekog proizvođača poput detaljno razmotrenih SSIS,
SSRS, SSAS koji prate Microsoft SQL Server i Microsoft Visual Studio.

Nakon implementacije sistema, administracija sistema može da bude potencijalno

kompleksna za BI administratora zbog prirode sistema da podržava integraciju većeg broja
drugih sistema. Iz tog razloga neophodno je angažovati BI administratora, bilo unutar same
organizacije ili putem outsource-inga, koji će biti konstantno dostupan organizaciji za sva
pitanja i probleme u vezi sa BI sistemom. Na taj način, BI sistem će biti korišćen efikasno i
stepen vraćanja investicije (eng. Return Of Investment, ROI) će biti visok, što će investiciju u
BI sistem učiniti opravdanom.

Alati SSRS i SSAS korišćeni za izradu praktičnog dijela rada su se pokazali kao vrlo
pogodni, pouzdani i intuitivni za korišćenje u svakom trenutku. Oni omogućavaju korišćenje
sistema poslovne inteligencije i za krajnje korisnike koji nemaju široko znanje u oblasti
informacionih tehnologija. Alat SSIS koji je takođe korišćen za izradu praktičnog dijela rada
je najmoćniji i najsveobuhvatniji od korišćenih alata ali potrebno je pristati na određene
kompromise da bi cilj bio postignut. SSIS je od samog početka dizajniran kao alat koji će da
podržava mnoštvo sistema za upravljanje bazama podataka, formata datoteka, operacija sa
bazom podataka, transformacija podataka, ali u praksi korišćenje alata može u nekim
situacijama da bude komplikovano. Zbog širokih mogućnosti upotrebe, interfejs alata je
morao da bude dizajniran konzistentno kao i da fokus bude na tome šta je potrebno uraditi, a
ne kako je to moguće uraditi. Kao rezultat, mogu da se jave nelogičnosti u grafičkom
korisničkom interfejsu koje zbunjuje čak i iskusnije programere i BI dizajnere. Bez obzira na
navedene mane, SSIS je postao moćan alat za dizajn BI sistema i ima veliku korisničku bazu.

Sa aspekta sigurnosti, SSIS, SSRS i SSAS su se pokazali kao veoma sigurni alati,
budući da se u pozadini nalazi sistem sigurnosti dizajniran za SQL Server koji ima tradiciju u
oblasti sigurnosti i koji važi za siguran i pouzdan sistem. Na kraju faze dizajna, vrši se
deployment SSIS, SSAS i SSRS projekata na SQL Server te su na taj način pri korišćenju BI
sistema podržane sve mjere zaštite koje su podržane na nivou SQL Servera. Prava na
izvršavanje SSIS paketa, SSRS izvještaja ili izvršavanje upita nad SSAS kockom je moguće
precizno definisati za svakog korisnika pojedinačno te se već na tom nivou može osigurati BI
sistem. Moguće je svakom korisniku izdati po jedan certifikat za autentikaciju kako bi se
dodatno povećao nivo sigurnosti u BI sistemu.

Iz svega navedenog, može se zaključiti da je implementacija BI sistema neophodna za

kvalitetno poslovanje jedne organizacije i da prednosti uvođenja BI sistema znatno nadmašuju
negativne strane. U doba kapitalizma, kada se svaka poslovna odluka pažljivo važe, sistem
poslovne inteligencije olakšava donošenje takvih odluka i dugoročno „čuva“ i podržava
uspješno poslovanje poslovnog sistema, zbog čega je došlo do velike popularizacije i sve šire
primjene BI sistema.

60
LITERATURA

[1] Kimball, R., Ross, M. , The Data Warehouse Toolkit 3rd Edition. WILEY, 2013.

[2] Sarka, D., Lah, M., Jerkič, G. , Implementing a Data Warehouse with Microsoft SQL
Server 2012, Training Kit. O' Reilly Media, Inc, 2012.

[3] Elektronski izvor – Internet stranica http://www.umsl.edu/~joshik/msis480/chapt10.htm,

posjećeno 03.01.2015. godine

[4] Elektronski izvor – Internet stranica http://www.techrepublic.com/blog/big-data-

analytics/big-data-basic-concepts-and-benefits-explained/, posjećeno 03.01.2015. godine

[5] Elektronski izvor - Internet stranica http://www.bisoftwareinsight.com/history-of-

business-intelligence/, posjećeno 04.01.2015. godine

[6] Elektronski izvor – Internet stranica http://roelantvos.com/blog/?p=740, posjećeno

16.01.2015. godine

[7] Elektronski izvor – Internet stranica http://www.zentut.com/data-warehouse/factless-fact-

table/, posjećeno 24.01.2015. godine

[8] Elektronski izvor - Internet stranica http://www.alphadevx.com/a/36-Comparison-of-

Relational-and-Multi-Dimensional-Database-Structures, posjećeno 16.01.2015. godine

[9] Elektronski izvor - Internet stranica http://www.oracle.com/technetwork/articles/sql/11g-

dw-olap-100058.html, posjećeno 20.01.2015. godine

[10] Elektronski izvor - Internet stranica http://www.sys-seminar.com/data_mart_structure,

posjećeno 20.01.2015. godine

[11] Elektronski izvor – Internet stranica, http://www.dotnetinterviewquestions.in/article_sql-

server-interview-questions:-what-is-the-difference-between-star-schema-and-snow-flake-
design_121.html, posjećeno 22.01.2015. godine

[12] Elektronski izvor – Internet stranica http://prashanthobiee.blogspot.com/2012/12/star-

schema-and-snowflake-schema.html, posjećeno 22.01.2015. godine

[13] Elektronski izvor – Internet stranica

http://management.about.com/cs/generalmanagement/a/keyperfindic.htm, posjećeno
25.01.2015. godine

[14] Elektronski izvor – Internet stranica https://msdn.microsoft.com/en-

us/library/bb190163.aspx, posjećeno 01.02.2015. godine

[15] Elektronski izvor – Internet stranica http://www.informationweek.com/big-data/big-data-

analytics/gartner-bi-magic-quadrant-2015-spots-market-turmoil/d/d-id/1319214, posjećeno
02.03.2015. godine

61
[16] Elektronski izvor – Internet stranica http://www.bisoftwareinsight.com/reviews/tableau-
business-intelligence/, posjećeno 09.03.2015. godine

[17] Elektronski izvor – Internet stranica

http://www.bisoftwareinsight.com/reviews/microsoft-sharepoint-business-intelligence/,
posjećeno 09.03.2015. godine

[18] Elektronski izvor – Internet stranica

http://www.gartner.com/technology/reprints.do?id=1-2AD8O9T&ct=150223&st=sb,
posjećeno 25.03.2015. godine

[19] Elektronski izvor – Internet stranica http://www.bisoftwareinsight.com/reviews/sap-

business-intelligence/, posjećeno 15.03.2015. godine

[20] Elektronski izvor – Internet stranica http://www.bisoftwareinsight.com/reviews/ibm-

cognos-business-intelligence/, posjećeno 15.03.2015. godine

[21] Elektronski izvor – Internet stranica http://www.bisoftwareinsight.com/reviews/tibco-

jaspersoft-business-intelligence/, posjećeno 15.03.2015. godine

[22] Elektronski izvor – Internet stranica https://www.simple-talk.com/sql/reporting-

services/sql-server-reporting-services-basics-building-ssrs-reports/, posjećeno 04.04.2015.
godine

[23] Elektronski izvor – Internet stranica

http://www.codeproject.com/Articles/658912/Create-First-OLAP-Cube-in-SQL-Server-
Analysis-Serv, posjećeno 05.04.2015. godine

[24] Elektronski izvor – Internet stranica https://www.accelebrate.com/library/tutorials/ssas-

2008, posjećeno 16.04.2015. godine

62