olap- on-line analytical processing

Seminarski rad iz kolegija MANAGEMENT INFORMACIJSKE TEHNOLOGIJE

Primjena OLAP tehnologije u korporacijskim informacijskim sustavima s osvrtom na

poslovnu inteligenciju Zvonimir Vuković Poslijediplomski studij: MANAGEMENT Sveučilište Josipa Jurja Strossmayera u Osijeku Ekonomski fakultet

2/33

Sadržaj Uvod................................................................................................................................ 3 Pojam baza podataka ..................................................................................................... 4 Uloga baza podataka u poslovnim informatičkim sustavima ....................................... 5

Detaljnije o relacijskim bazama podataka ....................................................................... 6 Osnovni pojmovi o relacijskim bazama podataka ........................................................ 6 Što je to “Skladište Podataka” (engl. “Data Warehouse”) .......................................... 10 Uloga relacijskih baza podataka................................................................................ 13

Detaljnije o višedimenzionalnim bazama podataka....................................................... 13 Što je to OLAP?......................................................................................................... 13 Struktura i primjena višedimenzionalnih baza podataka............................................ 15 Usporedba karakteristika relacijskih i višedimenzionalnih baza podataka................. 20

Integrirani relacijski i višedimenzionalni sustav upravljanja podacima .......................... 21 Zaključak....................................................................................................................... 24 Prilog............................................................................................................................. 27 Literatura....................................................................................................................... 33

3/33

Uvod U današnje je vrijeme u poslovnom svijetu informatička podrška sveprisutna i nezamijenjljiva. Poslovni informatički sustavi pružaju mogućnosti koje su donedavno bile nezamislive, te na taj način daju prednost u tržišnom natjecanju onim učesnicima koji su spremni i sposobni iskoristiti napredne mogućnosti informatičke tehnologije u svim elementima svoga poslovanja. Problemi s kojima se tvrtke u tom smislu susreću su raznolike prirode. S jedne strane tu su ljudi koji su kao poslovni resurs većim dijelom, ipak, nezamijenjljivi a često je njihov strah (ili bolje reći nedostatak informatičkog znanja) kočnica koju bez dodatnih napora nije moguće otpustiti. S druge strane, potrebna su financijska ulaganja i vrijeme da bi se razvili i uspješno primjenili moderni informatički sustavi u sredinama gdje ih prije nije bilo, ili su bili slabo zastupljeni. Također, potrebno je znanje i iskustvo da bi se uspješno implementirali informatički sustavi koji odgovaraju potrebama korisnika i pružaju im željene informacije. Na sreću, sve je više onih koji su shvatili da primjena informatike nije opasnost nego prilika i nužnost kako bi se u poslovnom okruženju ostvarili pozitivni poslovni rezultati. Cilj je ovog seminarskog rada čitatelja upuznati s tehnologijom baza podataka, točnije skladištenja podataka (engl «Data Warehousing») i interaktivnog analitičkog procesiranja – OLAP (engl. «On-Line Analytical Processing») koje su dvije relativno mlade informatičke tehnologije s velikim potencijalom za primjenu u našem poslovnom okruženju. One, naravno, nisu jedine niti dostatne za jedan cjelokupan informatički poslovni sustav neke tvrtke, ali mogu predstavljati njegov vrlo važan dio. Posebno je stavljen naglasak na praktične detalje realizacije takvog sustava, a manje na primjenu od strane krajnjeg korisnika. Razlog za to leži u činjenici da su mogućnosti primjene neograničene i mogu biti vrlo raznolike, dok je, s druge strane, realizaciju sustava moguće u većoj mjeri prikazati univerzalno. Važno je, međutim, da potencijalni korisik upozna prednosti i mogućnosti ovakvog sustava kako bi pronašao interes za primjenu u svom poslovanju. Stručna podloga za ovaj rad je prethodno iskustvo autora na projektima realizacije skladišta podataka i nadogradnje istih s OLAP mogućnostima u području telekomunikacija, višegodišnje iskustvo na projektima realizacije poslovnih sustava sa naglaskom na područje baza podataka, nekoliko stručnih prezentacija na tu temu i pohađanje stručnih školovanja iz spomenutih tehnologija.

4/33

Pojam baza podataka Postoji više definicija pojma baze podataka. Ovdje ćemo iznijeti neke od njih: Baza podataka se, prema definiciji g. John G. Huges1, može opisati kao kolekcija međusobno povezanih podataka sa slijedećim svojstvima: - podaci su dijeljeni između različitih korisnika i aplikacija, no postoji zajednički i

kontrolirani način upisivanja, brisanja, mijenjanja i dohvaćanja podataka - korisnici i aplikacije koje pristupaju podacima ne moraju poznavati detalje interne

strukture podataka u bazi Možemo jednostavnije reći i da je baza podataka skup podataka koji su organizirani tako da mogu zadovoljiti zahtijeve korisnika. U svakom slučaju, podaci su u bazi podataka organizirani prema određenom modelu podataka (engl. «Data Model»). Pri tome je model podataka osnova sustava i prema njemu se definiraju dizajn i veze među podacima, te okruženje u kojem se baza podataka razvija. Danas poznajemo više modela baza podataka, no u ovom radu ćemo se ograničiti na relacijski model baze podataka i višedimanzionalni model baze podataka. Bitno je, također, naglasiti zašto govorimo o bazi podataka a ne o datotekama. Organiziranje podataka u bazu podataka smanjuje potrebu za održavanjem aplikacija i podataka. Također, omogućeno je koristiti čitav niz pogodnosti koje datotečni sustav nije u stanju ponuditi. Ukratko:

• smanjuje se zalihost (redudancija) podataka – broj postojećih kopija jednog te istog podatka se smanjuje na minimum

• povećava se integritet podataka – podaci su lakše dostupni i veće kvalitete, a moguće im je jamčiti sigurnost i privatnost

• osigurana je neovisnost podataka i aplikacija – podaci i aplikacije koje te podatke koriste nisu međusobno vezani. To omogućava da se strukturom i sadržajem podataka može lako manipulirati, a bez potrebe da se intervenira na strani aplikacija. Vrijedi i obrnuto.

Važno je napomenuti i to da u današnjim programskim rješenjima bazama podataka najčešće upravlja sustav koji se naziva sustav upravljanja bazama podataka - DBMS (engl. «Database Management System»). Takav sustav je u stanju kontrolirati rad jedne ili više baza podataka te njihovu osnovnu funkcionalnost nadograditi različitim mogućnostima kao što su kontrola pristupa, centralizirana administracija i kontrola, zaštita protiv gubitka podataka izradom sigurnosnih kopija, mogućnost povezivanja sa vanjskim sustavima (Internet, drugi DBMS-ovi, ...), distribuiranost i sl. Za sve DBMS-ove je karakteristično da za svoj rad koriste usluge repozitorije podataka (engl «Data Repository»). To je interna (ili «vlastita») baza podataka jednog DBMS-a za koju vrijede ista pravila kao i za sve ostale baze podataka kojima isti upravlja, a u kojoj je pohranjeno sve ono što je potebno za rad (definicije svih baza podataka i objekata u njima). Također, trend je među vodećim proizvođačima sustava za upravljanje bazama podataka da integriraju tehnologiju relacijskih baza i višedimenzionalnih baza podataka u jedno sveobuhvatno rješenje. Time se integriraju mogućnosti OLTP (eng. «Online Transaction Processing») sustava i OLAP sustava u jednu cjelinu koja tada nudi

1 John G. Huges, «Database Technology. A software engineering approach»

5/33

jednostavnost implementacije i uporabe. Takvi se primjeri mogu pronaći kod Oracle-a i Microsoft-a, kao i kod drugih prozivođača. Dodajmo ovome i koncept troslojne arhitekture koji je karakterističan za današnje DBMS-ove. Radi se, naime, o tome da je fizička struktura (način kako su podaci zaista pohranjeni) odvojena od njihove logičke strukture a time i od korisničkog «pogleda» na podatke. Ono što se time dobiva je pojednostavljena administracija sustava i, već ranije spomenuta, međusobna neovisnost aplikacija i podataka. Pogledajmo sliku (Slika 1: Troslojna arhitektura relacijskog DBMS-a) gdje je i grafički prikazana shema troslojne arhitekture jednog DBMS sustava.

Fizička shema Fizička razina

Relacijska shema Logička razina

Aplikacija Terminal WEB

Pogled 1 Pogled 2 Pogled 3

Korisnička razina

Slika 1: Troslojna arhitektura relacijskog DBMS-a

Bitno je naglasiti da između slojeva (fizičke, korisničke i logičke razine) ne postoji fizička povezanost, te da je izmjene i potrebne prilagodbe moguće vršiti na svakoj razini zasebno, neovisno o ostalim razinama.

Uloga baza podataka u poslovnim informatičkim sustavima Baza podataka, čiji su specifični oblici skladište podataka i višedimenzionalna baza podataka, jeste u pravilu jedan od ključnih elemenata poslovnog informatičkog sustava nad kojim se grade ostali potrebni elementi i podsustavi. Razlog tome leži u činjenici da ona, općenito govoreći, prihvaća podatke, čuva ih i obrađuje, razmjenjuje ih sa ostalim elementima sustava te ih daje na raspolaganje korisnicima temeljm upita. Pri tome je osigurana potrebna brzinau radu, sigurnos i pouzdanost. Baza podataka, međutim, sama za sebe nije dostatna za cjelovito poslovanje jer joj je potrebna aplikativna nadgradnja koja je u stanju podatke iz baze podataka staviti u pravi kontekst i na taj način krajnjem korisniku pružiti kvalitetnu informaciju. Problem koji se ovdje nazire jeste kako postići to da dobivena informacija bude kvalitetna, odnosno točna, pravodobna i svježa te dostatna? Jedan od mogućih odgovora na to pitanje jeste i sustav koji će u ovom radu biti detaljnije prikazan.

6/33

Detaljnije o relacijskim bazama podataka

Osnovni pojmovi o relacijskim bazama podataka Osnove relacijskog modela podataka postavio je matematičar E. F. Codd2 1970. godine. Taj model podataka u potpunosti počiva na matematičkoj teoriji relacijske algebre. Podaci se prikazuju pomoću relacija (u svakodnevnom govoru koristi se i riječ tablica). Kako model podataka predstavlja sliku stvarnog svijeta, sve što je bitno u stvarnom svijetu moguće je adekvatno prikazati modelom podataka, pa tako u relacijskom modelu podataka razlučujemo tri osnovna pojma: entitet, atribut i relacija. Entitet je opći pojam koji možemo jednoznačno odrediti, a o kome su u bazi podataka čuvaju podaci. To može biti objekt, proces, pojava, stanje, osoba ili slično. Svaki entitet ima svoja svojstva ili atribute. Pa je tako atributom jednoznačno određena vrsta svojstva entiteta. U modelu podataka se promatra uvijek onaj skup svojstava koja su za određeni entitet važna sa stanovišta informatičkog sustava, tj. baze podataka koja se realizira. Vrijednost atributa je element opisa koji daje sadržaj entitetu sa stanovišta promatranog atributa. Također, vrijednosti atributa su podložne promijeni tijekom vremena. Za atribute je karakteristično da mogu imati definiranu domenu kao skup vrijednosti koje određeni atribut može poprimiti. Relacija je ključni element relacijskog modela. Može se definirati kao pravokutno područje (npr. dvodimenzionalna tablica) koje se sastoji od stupaca i redaka. Svaki stupac, pri tome, prikazuje vrijednosti jednog od atributa, a u zaglavlju čuva naziv promatranog atributa. Svaki redak (tzv. n-torka) predstavlja opis jedne od instanci entiteta sadržanih unutar relacije. Kada bismo gore navedeno pokušali prikazati slikovito, mogli bismo se poslužiti slijedećim primjerom (Slika 2: Primjer relacije “Proizvodi”):

RB NAZIV PROIZVOĐAČ CIJENA 001 TV Sony 3.500,00 002 DVD Panasonic 2.000,00 003 HIFI JVC 2.880,00 004 DSC-

P72 Sony

005 DSC-P32

N-TORKA

ATRIBUTI

TIJELO RELACIJE

RELACIJSKA SHEMA

Slika 2: Primjer relacije “Proizvodi”

Iz primjera (vidi Slika 2) može se vidjeti da je struktura relacije prilično intuitivna, i lako se može misaono predstaviti. To je velika prednost ovog modela podataka, te pored

2 Doprinos. g. Codd-a je u području teorije relacijskih baza podataka izniman. 1970. godine objavio je članak „A Relational Model of Data for Large Shared Data Banks“, Comm. ACM 13, No. 6, June 1970.

7/33

ostalih tehničkih prednosti, možda i jedan od najvažnijih razloga zašto je relacijski model baze podataka vrlo dobro prihvaćen. Naravno, među relacijama mogu postojati veze ili odnosi. Oni su logički prikaz stvarnih međusobnih ovisnosti entiteta koji su opisani relacijama. Tako, odnosi ili veze imaju svoja svojstva pa se i njih može promatrati kao zasebne entitete. Ovdje je bitno naglasiti da je, s obzirom na implementaciju konkretne baze podataka, bitno identificirati spojnost veze, tj. odrediti kakav je brojčani odnos instanci dva entita koji se nalaze u vezi. Postoji nekoliko mogućih opcija:

• odnos 1:1 (jedan prema jedan) – sa svake strane veze može učestvovati točno jedna instanca entiteta

• odnos N:1 (više prema jedan) – sa jedne strane veze može učestvovati više instanci entiteta, dok sa druge strane može učestvovati samo jedna instanca. Isto vrijedi i za odnos 1:N (jedan prema više)

• odnos M:N (više prema više) – sa obje strane veze može učestvovati više instanci entiteta. U praksi ovaj odnos upućuje na mogućnost i potrebu daljnje normalizacije kako bi se veza svela na oblik 1:N ili N:1, no o tome ovdje neće biti govora

Specifičan slučaj veze je kada se entitet referencira na samoga sebe, tada govorimo o refleksivnoj vezi. Pokažimo primjerom: Neka je u praski situacija takva da djelatnik neke tvrtke zadužuje najviše jedno računalo za potrebe posla te da je ono tada na raspolaganju isključivo tom djelatniku. Takav bi odnos odgovarao vezi 1:1. Pokažimo slikom (Slika 3: Primjer veze 1:1):

1 1 DJELATNIK RAČUNALO ZADUŽUJE

Slika 3: Primjer veze 1:1

Uzmimo, zatim, da na jednom projektu sudjeluje više djelatnika, no pri tome svaki djelatnik može biti angažiran na najviše jednom projektu. Takav bi odnos odgovarao vezi 1:N. Pokažimo slikom (Slike 4: Primjer veze N:1):

1 N DJELATNIK PROJEKT SUDJELUJE

Slike 4: Primjer veze N:1

Primjer na prethodnoj slici bismo interpretirali na slijedeći način: “Jedan djelatnik sudjeluje na jednom projektu, a na jednom projektu sudjeluje više djelatnika”

8/33

Kada smo iznijeli osnovne teoretske postavke i primjerom pokazali slikovito kako izgleda relacija i kakvi su odnosi među njima, možemo ukratko iznijeti i najvažnije praktične paradigme s kojima se susrećemo u radu s relacijskim baza podataka. Iz relacijske teorije slijedi da u jednoj relaciji ne postoje dvije potpuno jednake n-torke, te da je svaku n-torku moguće jednoznačno odrediti pomoću nekog podskupa njenih atributa. Takav podskup atributa je ujedno i ključ relacije, te je on u relaciji uvijek prisutan. Osim ključa relacije važno je napomenuti i to da se u relacijskim bazama podataka primjenjuju stroga pravila integriteta koja osiguravaju ispravnost i istinitost podataka sadržanih u bazi. Ta su pravila poznata pod nazivom entitetski integritet i referencijalni integritet Spomenimo i to da relacijske baze podataka poznaju koncept transakcije. Transakcija je jedinica poslovne aktivnosti ili operacija koja se mora izvršiti u cijelosti ili uopće ne izvršiti. Primjera za to bi se u bankarskom poslovanju moglo pronaći mnogo, npr. prijenos novca s jednog računa na drugi. Premda to možda djeluje kao jedna promjena, riječ je o barem dva ili tri koraka koja je potrebno izvršiti: prvo je potrebno provjeriti stanje na računu sa kojega se novac uzima, zatim je potrebno oduzeti iznos sa tog računa i naposlijetku pribrojati taj iznos drugom računu. Pri tome se mora jamčiti da je transakcija uspjela u cijelosti ili da upoće nije obavljena, te, ukoliko je uspjela, da je obavljena samo jednom čak i ako je bilo više prethodno neuspjelih pokušaja. Transakcije su od neizmjerne važnosti za poslovnu logiku koju relacijske baze podataka moraju poštivati i to vrlo uspješno čine. Dodajmo još i jedan opsežniji, slikoviti primjer strukture jedne relacijske baze podataka (Slika 5: E-R dijagram).

9/33

Katedra

Predavač

Student

Kolegij

Daje Vodi

Pripada

Pohađa

Predaje

1 1

1

1

1

N

M

N N

N Naziv

Broj sati

JMBG Ime

JMBG

Ime Adresa

Naziv

Br. djelatnika

Godina

Slika 5: E-R dijagram

Na prethodnoj slici prikazan je dijagram entiteta i veza, poznatiji kao E-R Dijagram (engl. „Entity Relationship Diagram“). Entiteti su prikazani plavom bojom, atributi zelenom, a veze crvenom bojom. Ovakav je dijagram, zapravo, slika realnog svijeta prilagođenog konkretnoj potrebi, a daje uvid u strukturu kakvu će imati i relacijska baza podataka. I ovdje se može primjetiti intuitivnost te će i slabije upućeni čitalac moći lako zaključiti o čemu se radi. Naposlijetku recimo i to da je za sve relacijske baze podataka na raspolaganju jedinstveni jezik kojim se podacima pristupa i manipulira. Kao takav, danas je poznat jezik SQL (engl. „Structured Query Language”) koji je standardiziran i općeprihvaćen. Njime je moguće definirati strukturu baze podataka, tj. opisati sve relacije, njihove karakteristike i međusobne odnose, također moguće je upisivati, brisati, mijenjati i dohvaćati podatke. Primjer jedne naredbe SQL jezika bi bio (Slika 6: Primjer naredbe SQL jezika): SELECT ime, prezime, naziv_projekta FROM djelatnici, projekti

WHERE djelatnici.projekt_id = projekti.projekt_id ORDER BY ime, prezime;

Slika 6: Primjer naredbe SQL jezika

Gornjim se primjerom iz relacijske baze podataka traži ime, prezime i naziv projekta za sve djelatnike koji rade na nekom projektu, a za to su kontaktirane dvije relacije: djelatnici i projekti

10/33

Što je to “Skladište Podataka” (engl. “Data Warehouse”) Relacijske baze podataka mogu biti koncipirane kao klasične OLTP baze kada im je prvenstvena namjena odrađivanje svakodnevnih poslovnih aktivnosti. Tu se u najvećoj mjeri radi o unosu velike količine novih podataka, obradi i izmjeni postojećih podataka, praćenju dnevnih stanja i rezultata, statičkom izvješćivanju i sl. Takav koncept baze podataka se često može pronaći i pod nazivom operativna baza podataka. Ovdje treba naglasiti kako je relacijskim bazama podataka uvijek lakši zadatak unos i obrada podataka u odnosu na pretraživanje i izvješćivanje. U svakom slučaju, naglasak je, na sve oblike poslovnih aktivnosti koje se baziraju na podacima relativno novijeg datuma, primjerice od istog dana do nekoliko mjeseci unazad, te na aktivnostima koje su naglašeno transakcijski orijentirane. Naravno, tada su one optimizirane za takav način rada, tj. postižu potrebne performanse. One su u toj domeni poslovanja nezamijenjljive i još uvijek drže tehnološki korak s vremenom. No, danas se organizacije susreću sa potrebom ovladavanja sve većom i većom količinama podataka, te potrebom za odgovore i na ona pitanja koja za klasično koncipiranu, transakcijski orijentiranu relacijsku bazu podataka nisu lagan zadatak. Tu se pojavljuje potreba za realizacijom koncepta informacijske baze podataka koja bi, za razliku od baze podataka operativnog tipa, trebala svrhovito poslužiti za potrebe analize i potpore odlučivanju na najvišim nivoima managementa. Na taj je način, pravilnom kombinacijom operativne i informacijske baze podataka, moguće u potpunosti zadovoljiti zahtijeve svih korisnika. Generalno govoreći, pojavljuju se sve veći zahtjevi za brzinom pristupa informacijama i njihovu dostupnost. Razvojni timovi su suočeni sa sve većim kompromisima u realizaciji strukture baze podataka. Primjerice, nekada je bilo važno normalizirati bazu podataka koliko je to moguće kako bi se uštedjelo na potrebnom prostoru za pohranu podataka. To pak za sobom vuče relativno složeni način pristupa željenim podacima zbog većeg broja involviranih relacija, a time i do duljeg vremena potrebnog da se podaci prezentiraju korisniku. Danas, kako cijena prostora za pohranu podataka pada tako polagano prevladava zahtjev za brzinom pristupa podacima pa to dovodi do promjena u strategiji realizacije strukture same baze. Gore navedeno približava nas pojmu skladište podataka. Prema definiciji gospodina Bill Inmon3, skladište podataka je tematski orijentirano, integrirano, vremenski dugotrajno i nepromjenjljivo (pri tome se ne misli na podatke koji se tek trebaju pojaviti u skladištu podataka) spremište podataka sa osnovnom namjenom da svojim analitičkim mogućnostima podrže proces donošenja odluka. Drugim rječima bi se moglo reći da je skladište podataka specijalizirana baza podataka koja se temelji na podacima iz operativnih baza podataka, sadrži podatke za dulji vremenski period, a namijenjena je prvenstveno za potrebe analize i potpore odlučivanju od strane srednjeg i visokog management-a. U skladištu podataka se nalaze podaci integrirani iz jedne ili više različitih operativnih baza podataka, kao i iz različitih eksternih izvora podataka. Ti su podaci adekvatno obrađeni, često agregirani na određenim nivoima i čuvaju se dulji vremenski period kako bi omogućili vremensku analizu, praćenje trendova i sl. Najčešći korisnici takvih izvora podataka su odjeli financija, prodaje, marketinga, no u različitima sferama poslovanja to mogu biti i drugi korisnici kao npr. istraživanje i razvoj. Vrste podataka

3 "What is a Data Warehouse?" W.H. Inmon, Prism Technology, Volume 1, Number 1, 1995

11/33

koje mogu biti u skaldišu su tekst (brojke i slova) , slike, zvuk, video, i sl. Općenito govoreći, sve one vrste podataka kojima se danas u informatici služimo. Recimo ovdje i nekoliko riječi o fizičkoj strukturi takve baze podataka. Skladište podataka ne mora nužno biti izgrađeno koristeći se tehnologijom relacijskih baza podataka, to može biti i višedimenzionalna baza podataka. No u ovdje ćemo se posvetiti relacijskom modelu skladišta podataka, koje ćemo u konačnici obogatiti (nadograditi) OLAP mogućnostima. Kada se govori o strukturi relacijskog skladišta podataka, tada postoje dva osnovna koncepta realizacije: kocept zvijezde (engl “star schema”) i koncept pahuljice (engl. “snowflake schema”). Za “star” shemu je karakterističan manji broj relacija, veća redundancija podataka i brži odaziv sustava, za “snowflake” shemu je karakterističan veći broj relacija, manja redundancija i sporiji odaziv sustava. U oba slučaja se skladište podataka gradi na osnovi jedne ili više centralnih relacija koje su nadopunjene nizom dimenzijskih relacija, a cijela struktura nije do kraja normalizirana. Centralne ili činjenične (engl. “fact”) relacije u sebi sadrže konkretne vrijednosti svih onih atributa koji su predmetom promatranja odnosno interesa od strane korisnika skladišta podataka. Za te je relacije karakteristično da fizički mogu sadržavati vrlo velike količine podataka koji se redovito u definiranim vremenskim intervalima nadopunjavaju novim podacima, vrlo rijetko ili nikada se postojeći podaci u njima ne mijenjaju, a samo prema potrebi (primjerice oni najstarijeg datuma, koji zakonski više nisu potrebni) se podaci iz njih uklanjaju. Dimenzijske tablice sadržavaju pomoćne, opisne podatke koji se pojavljuju na više mjesta (u više n-torki) centralnih relacija. Ove tablice mogu biti više ili manje normalizirane, što upravo čini razliku između “star” sheme i “snowlake“ sheme skladišta podataka. Konkretno, odluka je realizacijskog tima, temeljem identificiranih zahtijeva korisnika, procijenjene prosiječne količine podataka u skladištu i raspoloživih mehanizama DBMS-a koji se koristi za realizaciju, da li će se koristiti jedna ili druga shema a da bi se postigle zadovoljavajuće performanse i cijena sustava. Pokažimo slikovito kako bi mogla izgledati struktura jednog skladišta podataka (Slika 7: Primjer strukture skladišta podataka, “snowflake” shema)

12/33

PRODAJA * redni broj * dan * trgovina * sat * proizvod * cijena * količina * način plaćanja ° kupac ° trgovac ...

PROIZVODI * oznaka * naziv proizvoda * grupa ° opis prozivoda

PRODAJNA MJESTA * oznaka * naziv trgovine * lokacija

LOKACIJE * oznaka * naziv lokacije * regija

REGIJE * oznaka * naziv regije

GRUPE PROIZVODA * oznaka * naziv grupe ° opis

VRSTE PLAĆANJA * oznaka * opis

° provizija

KUPCI * oznaka * naziv kupca * kategorija ° spol (M/Ž) ° dob

TRGOVCI * oznaka * ime * prezime * funkcija

° spol ° dob

KATEGORIJE KUPACA * oznaka * naziv ° opis

DANI * datum * dan u tjednu * tjedan * mjesec

° radni dan (D/N)

1

N

N

N N

N

N

N

N

1

1

1

1

1

1

1

1

1

N

SATI * oznaka * vrijeme od * vrijeme do ° happy hour (D/N)

N

1

Slika 7: Primjer strukture skladišta podataka, “snowflake” shema

Na prikazanom primjeru možemo vidjeti tzv. “snowflake” shemu skladišta podataka koja se temelji na jednoj centralnoj tablici (relacijia prodaja) koja u sebi sadrži podatke o prodaji proizvoda neke tvrtke tijekom vremena. Ta se tablica, primjerice dnevno, puni podacima iz operativnih izvora, a podaci se prije spremanja u skladište podataka prilagođavaju potrebama krajnjih korisnika. Tako dobiveni podaci ostaju u skladištu podataka i u pravilu se naknadno ne mijenjanju. Takvim se postupkom izdvajaju svi oni podaci koji iz neke buduće perspektive nisu od interesa krajnjih korisnika. Također, dobivena struktura je prilagođena potrebama izvješćivanja, analize, a pri tome je pogodna za nadogradnju OLAP mogućnostima. Kada se govori o skladištu podataka ne smije se zaboraviti na koncepciju baze podataka poznatu pod nazivom “Data Mart”. “Data Mart” je oblik skladišta podataka koji je namijenjen, primjerice, odjelima ili još manjim organizacijskim jedinicama unutar jedne tvrtke. Pri tome se podrazumijeva da na višim organizacijskom nivoima, ili na nivou čitave organizacije, postoji jedno ili više funkcionalnih skladišta podataka. Ta su skladišta podataka, tada, izvori podataka za “Data Mart”-ove. Za jedan “Data Mart” može biti osobito interesantno da u sebi, između ostaloga, sadržava agregirane (sumirane) podatke na određenim nivoima hijerarhije. Time se omogućava još efikasnije sagledavanje stvarnog stanja na način da se uklanja potreba za agregiranjem prilikom izvršavanja upita ili analiza od strane krajnjih korisnika. Tako se postižu mnogo bolje performanse, a redundancija podataka se izbjegava (najniži nivo agregacije – činjenice - su uvijek na raspolaganju u postojećem skladištu podataka). Slijedeća tablica (Tablica 1: Usporedba karakteristika skladišta podataka i “Data Mart-a”) daje usporedbu nekih karakteristika sladišta podataka i «Data Mart-a» Karakteristika Skladište podataka Data Mart područje primjene čitava organizacija / tvrtka odjel unutar organizacije /tvrtke tematska područja mnogo nekoliko izvori podataka mnogi nekoliko veličina od 100 GB do preko 1 TB do 100 GB

13/33

potrebno vrijeme implementacije

od nekoliko mjeseci do godinu dana

nekoliko mjeseci

Tablica 1: Usporedba karakteristika skladišta podataka i “Data Mart-a”

Uloga relacijskih baza podataka Relacijske baze podataka su danas najšire prihvaćene i u najvećoj mjeri se koriste kako u poslovnim informatičkim sustavima tako i u svim ostalim sferama života gdje postoji potreba za upravljanje podacima. One predstavljaju osnovnu programsku infrastrukturu koja je zadužena za prikupljanje, obradu, pohranu i prezentaciju informacija. U tom smislu je struktura konkretne implementacije relacijske baze podataka definirana u skladu sa definiranim i identificiranim zahtjevima i potrebama korisnika, ali i na način koji omogućava lako povezivanje sa svim ostalim informatičkim podsustavima koji se unutar jedne organizacije pojavljuju i koriste (ili se mogu pojaviti u budućnosti) sa osobitim naglaskom na dostupnost podataka preko Interneta. Tu se u današnje vrijeme pojavljuje sve više zahtjeva koje je potrebno ispuniti da bi poslovni sustav bio u stanju odgovoriti svim izazovima okruženja u kojem se koristi, a to je, s obzirom na globalnu povezanost, cijeli svijet. Stoga, vodeći proizvođaći sustava za upravljanje bazama podataka već u osnovnom programskom paketu nude široku paletu standardiziranih sučelja, aplikacija i mogućnosti, a na razvojnom timu, čiji je zadatak implementirati konkretnu relacijsku bazu podataka jedne organizacije, ostavljaju zadatak realizacije specifičnih potreba i zahtjeva kroz svrhovitu strukturu i logiku baze podataka. Za relacijske baze podataka je karakteristično to da su najčešće transakcijski orjentirane. Transakcije su od neizmjerne važnosti za poslovnu logiku koju relacijske baze podataka moraju poštivati i to vrlo uspješno čine. Također, relacijske baze podataka pokazuju velike prednosti u okruženjima gdje je potrebno unositi velike količine podataka ili izvršiti velike količine transakcija, od strane više paralelno prijavljenih korisnika, a sve to u relativno kratkom vremenu. Pri tome se jamči integritet i konzistentnost podataka. Sve gore navedeno, uz još čitav niz ostalih pogodnosti, stavljaju relacijske baze podataka u središte poslovnih informatičkih sustava današnjice.

Detaljnije o višedimenzionalnim bazama podataka

Što je to OLAP? OLAP u prijevodu znači «interaktivno analitičko procesiranje». Prema definiciji Internet servisa The OLAP Report4, OLAP je kategorija aplikacija (programskih rješenja) i tehnologija koje omogućavaju sakupljanje, obradu, procesiranje i prezentaciju višedimenzionalnih podataka za potrebe analize i upravljanja odlukama. Druga moguća definicija bi bila da je OLAP kategorija programskih rješenja koja omogućava rukovodećem osoblju (managerima) uvid u podatke kroz brz, konzistentan i interaktivan pristup, korištenjem različitih pogleda na podatke proizašle iz operativnih, nestrukturiranih podataka, a na način kojim se naglašava dimenzionalnost podataka.

4 Može se pronaći na slijedećoj Internet adresi: http://www.olapreport.com/index.htm

14/33

Već ranije spomenuti gospodin E. F. Codd je 1993 godine definirao OLAP kao sustav koji je komplementaran OLTP sustavu. Sve u svemu, radi se o tome da se poslovnim podacima dobivenim iz operativnih i vanjskih izvora, a koji su obrađeni prema specifičnim potrebama korisnika, pristupa interaktivno, brzo i na jedinstveni način bez obzira na kompleksnost postavljenih pitanja. Pri tome se za potrebe uvida u podatke koriste aplikacije koje su u stanju grafički prikazati rezultate upita i omogućiti izvršavanje svih raspoloživih OLAP analiza. Da bismo razumijeli kakve su mogućnosti analiza na raspolaganju korištenjem jednog OLAP sustava potrebno je prije svega objasniti dva osnovna koncepta koja se pri tome koriste, a to su: mjere ili varijable (engl. «Measures» i «Variables») i dimenzije (engl. «Dimensions») Mjera je numerička vrijednost koja je od centralnog interesa za analizu. Na primjer, cijena proizvoda, količina prodanih proizvoda, trajanje telefonskih poziva, trošak transporta, ukupni prihod i sl. Temeljem nekih osnovnih mjera mogu se promatrati i mjere koje su iz njih izvedene, a fizički se ne nalaze među izvornim podacima. Primjerice, moguće je definirati mjeru ukupni prihod kao umnožak cijene i količine. OLAP sustav će tada takvu mjeru tretirati kao i sve ostale. Dimenzija je opisna kategorija koja ima svoju hijerarhiju. Za svaku mjeru u OLAP sustavu mouće je definirati jednu ili više dimenzija koje joj daju kontekst promatranja, odnosno koje pobliže određuju vrijednosti mjere. Možemo slobodno reći i to da dimenzije djeluju poput indeksa kojim se dolazi do traženih vrijednosti. Na primjer, dimenzije mogu biti vrijeme, proizvod, lokacija, usluga, vrsta trgovine, način plaćanja i sl. Dimenzija može biti, i u pravilu ih ima, mnogo. OLAP sustav omogućava praćenje vrijednosti mjera u odnosu na sve za njih definirane dimenzije. U tom smislu su razvijene i aplikacije za prikaz takvih višedimenzionalnih podataka na trodimenzionalni način. Dimenzije imaju definiranu hijerarhiju, a ponekad je definirano i više različitih hijerarhija za istu dimenziju. Primjerice dimenzija vrijeme može imati dvije hijerarhije: jedna koja vrijeme promatra po hijerarhiji: sat – dan – tjedan – godina, a druga koja vrijeme promatra po hijerarhiji: sat – dan – mjesec – godina. Razlog za to bi bio taj da se tjedni i mjeseci svojim početkom i krajem ne preklapaju (zanemarimo pri tome problem prvog/zadnjeg tjedna u godini). Osnovne mogućnosti analize koje OLAP sustavi pružaju su:

• Odabir dimenzija (engl. «Selection of dimensions») Tom je tehnikom moguće iz mnoštva hijerarhijskih vijednosti pojedinih dimenzija odabrati upravo one vrijednosti koje su za daljnju analizu konstantne

• Rotacija dimenzija (engl. «Rotation of dimensions») Tom je tehnikom moguće istu mjeru promatrati na različite načine, zamjenom mjesta ili odabira dimenzija koje opisuju promatranu mjeru. Time se vrijednosti koje promatrana mjera poprima i značenje dobivenih informacija mijenjaju

• Pogled u dubinu (engl. «Drill down») Ovom je tehnikom moguće vrijednosti iste mjere promatrati na nižem stupnju hijerarhije, odnosno agregacije. Na primjer, ako smo promatrali vrijednosti trajanja i količine telefonskih poziva iza 20h za prvo tromjesečje neke goine, tada ovom tehnikom možemo dobiti vrijednosti trajanja i količine telefonskih poziva iza 20h za svaki pojedini mjesec prvog tromjesečja. Slijedećim korakom bismo dobili uvid u iste informacije za svaki pojedini dan nekog od mjeseci prvog tromjesečja

15/33

promatrane godine. Ovom se tehnikom, dakle, ulazi u detaljniji pogled na podatke

• Pogled prema vrhu (engl. «Drill up») Ovo je upravo suprotan postupak od ranije opisanog. Ovom se tehnikom ide ka većem hijerarhijskom nivou, odnosno većem stupnju agregacije

Za sve gore navedene mogućnosti je zajedničko to da se za njihovo izvršavanje, u pravilu, ne mora dugo čekati bez obzira na količinu involviranih podataka. One su praktički dostupne na «klik miša». Ove i ostale mogućnosti koje OLAP sustavi pružaju daju odgovore na mnoga kompleksna pitanja koja se u poslovnom svijetu pojavljuju. Moguće je raditi analize prodaje i marketinga, izrađivati financijske izvješća, analizirati profitabilnost i kvalitetu, izvješćivati management o ključnim trendovima i sl. Ne treba posebno naglašavati da svi OLAP sustavi pružaju mogućnosti korištenja Interneta za pristup podacima i analize. Spomenimo još i tri osnovne arhitekture OLAP sustava. To su:

• ROLAP (engl. «Relational OLAP») Ova arhitektura se koristi postojećom relacijskom bazom podataka, najčešće skladištem podataka i «Data Mart-om», za pohranjivanje svih činjenica i agregacija, dok se u višedimenzionalnoj bazi podataka nalaze svi podaci o dimenzijama i sve potrebne definicije mjera, formula i sl. Ovakva se arhitektura odlikuje mogućnošću rada sa neograničenim količinama podataka, no zaostaje u brzini davanja odgovora na postavljena pitanja.

• HOLAP (engl. «Hybrid OLAP») Ova arhitektura se koristi relacijskom bazom podataka (najčešće skladištem podataka) za pohranu činjenica dok se agregacije, dimenzije, mjere i sve ostale potrebne definicije spremaju u višedimenzionalnu bazu. Ova se arhitektura odlikuje nešto većom brzinom rada i nešto manjom količinom podataka koju može procesirati.

• MOLAP (engl. «Multidimensional OLAP») Ova arhitektura se koristi isključivo uslugama višedimenzionalne baze podataka koja tada u sebi sadržava sve potrebne činjanice, agregacije i ostalo. Odlikuje se najvećom brzinom rada, no količina podataka koju je moguće spremiti je ograničena.

Struktura i primjena višedimenzionalnih baza podataka Kao što je već ranije spomenuto, OLAP tehnologija iziskuje postojanje višedimenzionalnih struktura podataka, a to je iz temelja drugačija struktura od relacijskog modela koji se bazira na samo dvije dimenzije. Pogledajmo usporedbu dvodimenzionalnog i višedimenzionalnog prikaza istih podataka na slijedećem primjeru (Slika 8: Usporedba dvodimenzionalne i trodimenzionalne strukture podataka):

16/33

PARIS

LONDON

PROIZVOD VRIJEME LOKACIJA KOLIČINA CD JAN97 LONDON 5782 RECEIVER JAN97 LONDON 6739 AMPLIFIER FEB97 LONDON 4434 VCR JAN97 LONDON 275 CD MAR97 PARIS 6365 RECEIVER FEB97 PARIS 6744 . . . . . . . .

PROIZVOD

VRIJEME

LOKACIJA

JAN97 FEB97 MAR97

5782 6739 97

4434

6365

6744

Slika 8: Usporedba dvodimenzionalne i trodimenzionalne strukture podataka

Na gornjoj slici vidimo tablični prikaz podataka, koji je sam za sebe dovoljno jednostavan i intuitivan da ne zahtijeva detaljnija objašnjenja. Nešto niže vidimo iste podatke prikazane pomoću višedimenzionalne strukture, na primjeru 3 dimenzije. Možemo primjetiti da bridovi prikazane kocke predstavljaju vrijednosti pojedinih dimenzija, dok se u svakoj unutarnjoj kockici nalaze vrijednosti promatrane mjere (u ovom primjeru bi to bio broj prodanih primjeraka određenog proizvoda). Koncept višedimenzionalne baze podataka najlakše je opisati na primjeru kocke. Pogledajmo strukturu prema slijedećoj slici (Slika 9: Struktura višedimenzionalne baze podataka):

17/33

Slika 9: Struktura višedimenzionalne baze podataka

Zamislimo si da promatramo mjeru koja je definirana nad tri dimenzije. Tada imamo kocku koja u sebi sadrži sve moguće vrijednosti promatrane mjere, a na rubovima hijerarhijske vrijednosti dimenzija koje tu mjeru opisuju. Ako za svaku dimenziju odaberemo konkretan raspon vrijednosti, tada smo početnu kocku sveli na manju kocku koja u sebi sadrži sve moguće vrijednosti promatrane dimenzije, ali ovaj put za limitirane vrijednosti dimenzija. Odemo li još korak dalje, izborom konkretne vrijednosti jedne od dimenzija, tada smo dobili plohu koja sada sadrži sve moguće vrijednosti promatrane mjere za dvije preostale dimenzije. Konačno, odaberemo li konkretne vrijednosti za sve tri dimenzije tada smo došli do elementarne kockice (ili točke) koja u sebi sadrži samo jednu vrijednost promatrane mjere. Pokažimo konkretno kako bi se mogla koristiti jedna višedimenzionalna struktura od strane različitih korisnika OLAP sustava (Slika 10: Primjer primjene višedimenzionalne strukture od strane korisnika).

18/33

Financijski manager Lokacijski manager

Produkt manager «Ad hoc» pogled

Slika 10: Primjer primjene višedimenzionalne strukture od strane korisnika

U gornjem primjeru je vidljivo kako različiti korisnici OLAP sustava mogu iz mnoštva mogućih pogelda na podatke izabrati upravo onaj koji najviše odgovara njihovim specifičnim potrebama. Naravno, svaki od njih vrlo lako može dobiti i drugačiji pogled na iste podatke, a time i drugačiju, možda potpuniju informaciju. Treba naglasiti kako su sve te aktivnosti dostupne gotovo trenutno i to jednostavnim korištenjem ponuđenih opcija kroz korisničko sučelje OLAP aplikacije. Pokažimo i primjer korištenja više od tri dimenzije (Slika 11: Primjer strukture višedimenzionalne baze podataka sa 4 dimenzije)

19/33

LONDON

PARIS

LONDON

PARIS

JAN97 FEB97 MAR97

JAN97 FEB97 MAR97

CD RECEIVER

AMPLIFIER

CD RECEIVER

AMPLIFIER

VELEPRODAJA

MALOPRODAJA

5792 6739 4434

6365 6744 3400

2671 3628 1323

3264 3533 1299

KOLIČINA

KOLIČINA

Slika 11: Primjer strukture višedimenzionalne baze podataka sa 4 dimenzije

Ovdje možemo vidjeti kako je moguće prikazati više od 3 dimenzije (u ovom slučaju to su: lokacija, vrijeme, proizvod i vrsta prodaje) koristeći se trodimenzionalnim prikazom. Naravno, sve ranije opisane mogućnosti su i dalje na dohvat ruke. Dodajmo još i primjer iz kojega se vidi kako iste dimenzije mogu opisivati različite mjere (Slika 12: Dijeljenje dimenzija)

20/33

PRIHOD (kn) KOLIČINA (kom)

CIJENA (kn)

Slika 12: Dijeljenje dimenzija

Ovdje vidimo da su mjere prihod i količina definirane nad istim dimenzijama, konkretno lokacija, proizvod i vrijeme, a da je cijena definirana nad samo dvije dimenzije vrijeme i proizvod. Zaključimo da je u višedimenzionalnim strukturama podataka moguće pohranjivati i mnogo složenije kombinacije mjera i dimenzija, a sve temeljem definirane matematičke podloge koja se u sustavu pri tome koristi.

Usporedba karakteristika relacijskih i višedimenzionalnih baza podataka Pokušamo li usporediti relacijske i višedimenzionalne baze podataka vidjeti ćemo da se radi o dva različita koncepta upravljanja podacima koji se, pak, mogu vrlo uspješno međusobno nadopunjavati. Transakcijske relacijske baze podataka (OLTP sustavi) su orijentirane prije svega na obavljanje svakodnevnih poslovnih aktivnosti gdje je naglasak na unosu i obradi podataka, izvršavanju transakcija i na jednostavnijim oblicima izvješćivanja. One uspješno odgovaraju na pitanje «Što se događa ?» S druge strane, OLAP sustavi, nisu namijenjeni širokom krugu korisnika, niti zahtijevnim transakcijama i obradama, nego uskom krugu korisnka koje zanimaju odgovori na poslovna pitanja tipa «Zašto?», «Što dalje činiti?», «Što ako ...?»

21/33

Integrirani relacijski i višedimenzionalni sustav upravljanja podacima U ovom poglavlju biti će predstavljena arhitektura sustava upravljanja podacima koja integrira operativne relacijske baze podataka, skladišta podataka i OLAP sustav u jednu funkcionalnu cjelinu. Na slijedećoj slici su prikazani osnovni elementi takvog sustava (Slika 13: Shema integriranog sustava)

RDBMS

Data Warehouse

Data Mart

Data Mart

(H)OLAP Cube

Internet

tijek informacija

vanjski izvori podataka

(H)OLAP Cube

(R)OLAP Cube

(R)OLAP Cube

backup uređaj

backup uređaj

operativni podaci

Slika 13: Shema integriranog sustava

Pretpostavimo da je, kao u većini slučajeva, poslovni sustav opremljen različitim izvorima podataka koji međusobno nisu kompatibilni, ali postoji potreba da se podaci iz takvih izvora promatraju zajedno sa ostalima kao jedna cjelina. Prema tome prvi korak obrade jeste prikupiti sve podatke iz vanjskih izvora (koji su kao takvi u nestrukturiranom obliku) i preseliti ih u operativnu bazu podataka. Time oni postaju univerzalno dostupni svima unutar organizacije te jednostavni za daljnju obradu. Vanjski izvori podataka mogu biti svi oni dokumenti koji se proizvode u dnevnom poslovanju, podaci iz proizvodnje, podaci sa Interneta, razna izvješća i sl. Za potrebe prebacivanja takvih podataka u operativnu bazu izrađuju se adekvatne aplikacije te se taj postupak nastoji maksimalno automatizirati. Jednim je dijelom, ukoliko to poslovni proces dozvoljava, takve podatke moguće prebacivati direktno u skladište podataka. Osnovni preduvjet za to je da su izvori takvih podataka informatički kompatibilni sa sustavom skladišta podataka. Operativna baza podataka je u pravilu podložna izradi sigurnosnih kopija i to korištenjem dvije strategije: izrada sigurnosnih kopija za vrijeme

22/33

rada (online, «hot backup») i izrada sigurnosnih kopija cijele operativne baze podataka (offline, «cold backup»). Potonja strategija se primjenjuje periodički, primjerice na tjednoj bazi, ukoliko je dozvoljeno da se operativna baza podataka učini nakratko nedostupna korisnicima. Pitanje sigurnosnih kopija jeste vrlo bitno jer niti jedan sustav kvalitete ne može previdjeti činjenicu da operativna baza podataka nije podvrgnuta izradi sigurnosnih kopija. Iz operativne baze podataka se tehnikom ETL (eng. «Extraction, Transformation and Loading») podaci prebacuju u skladište podataka. Za potrebe ETL-a postoji čitav niz gotovih programskih rješenja, najčešće dostupnih od strane DBMS-a koji se koristi. Podaci se tom prilikom selektivno odabiru i prilagođavaju strukturi skladišta podataka. Moguće je, iako rijetko, da se podaci već tom prilikom agregiraju do određenog nivoa. To ovisi, prije svega, od toga da li se je projektom informatičkog sustava predvidjelo korištenje operativne baze podataka za dobivanje najdetaljnijih podataka ili ne. Takva bi, pak, odluka pred operativnu bazu podataka stavila težak zadatak čuvanja podataka dulji vremenski period čime bi se značajno degradirale performanse cijelog sustava. Iz operativne baze podataka se podaci periodički i inkrementalno prebacuju u skladište podataka. Tom prilikom se oni, ukoliko je to potrebno, prilagođavaju specifičnoj strukturi skladišta podataka. Za takve intervencije se koriste specifične aplikacije kojeposao obavljaju automatski prema unaprijed zadanim parametrima. U svakom slučaju, za skladište podataka je karakteristično da preuzme ulogu centralnog elementa u sustavu upravljanja podacima, te da kasnije posluži kao osnova za daljnje nadograđivanje i specifične prilagodbe korisničkim zahtjevima. Ovdje treba naglasiti da je za tehničku realizaciju skladišta podataka potrebna znatna investicija u adekvatnu računalnu podršku. Naime, u pravilu je u skaldištu podataka prisutna velika količina podataka, a zahtjevi na dostupnost podataka su vrlo strogi. Kako skladište podataka preuzima centralnu ulogu u informatičkom sustavu organizacije, tako su zahtjevi na maksimalno dozvoljeno vrijeme kada je sustav nedostupan (engl. «Down time») svedeni na minimum, ponekad i na nulu. Zbog toga je potrebno osigurati adekvatne uređaje za pohranu podataka i izradu sigurnosnih kopija. Poznata i često korištena koncepcija jeste tzv. miroring (engl. «mirroring»). U tom je slučaju svaki pojedini medij za pohranu podataka popraćen barem jednom svojom fizičkom kopijom. Također, potrebno je osigurati zalihost računala na kojima se aplikacija skladišta podataka izvršava. To znači osigurati minimalno dva računala (u praksi često puta i više) koja se u normalnom radu nadopunjavaju, a u slučaju kvara jednog od njih ono drugo automatski i bez ljudske intervencije preuzima na sebe čitav posao. Takva je koncepcija poznata pod nazivom HA (engl. «High availability») ili klaster (engl. «Cluster»). Naravno, ne postoje druge prepreke osim financijskih za korištenje HA koncepcije bilo gdje drugdje u informatičkom sustavu. Slijedeći korak je zadovoljiti specifične zahtjeve na sadržaj i način prezentacije podataka od strane oganizacijskih jedinica ili pojedinaca. U tu se svrhu realiziraju specifični «Data Mart»-ovi i višedimenzionalne baze podataka. U smislu integracije sa višedimenzionalnim bazama podataka, u ovom će radu biti riječi o ROLAP i HOLAP arhitekturama jer obje koriste usluge skladišta podataka u većoj ili manjoj mjeri. Da ponovimo, u slučaju ROLAP-a, radi se o kombinaciji gdje se u višedimenzionalnoj bazi podataka čuvaju podaci o dimenzijama, potrebne definicije mjera i formula, a u relacijskoj bazi podataka se čuvaju činjenice i, prema potrebi, agregacije. U slučaju HOLAP-a radi se arhitekturi gdje se u relacijskoj bazi (skladištu) podataka čuvaju samo

23/33

činjenice (dakle neagregirani podaci) a sve ostalo je sadržano u višedimenzionalnoj bazi. U takvoj je sredini osnovna zadaća «Data Mart-ova», ukoliko se koriste, da u sebi čuvaju i periodički obnavljaju agregirane podatke koje dobivaju iz skladišta podataka. U tom smislu se realiziraju specifična aplikativna rješenja koja se brinu za automatsko obnavljanje (osvježavanje) agregiranih podataka i eventualno potebna prilagođavanja podataka koji dolaze iz alternativnih izvora. Tu je bitno osigurati da takve aplikacije poznaju koncept djelomičnog ili delta osvježavanja podataka (engl. «Delta refresh»), kao i koncept potpunog osvježavanja podataka. U prvom slučaju (delta osvježavanje) se radi o procesiranju samo onih podataka koji su se pojavili nakon prethodnog osvježavanja. Takav postupak se odlikuje velikom brzinom osvježavanja podataka. U drugom slučaju se radi o procesiranju svih podataka koji se nalaze u skladištu podataka. Takav postupak je spor, ali neophodan barem na samom početku ili u slučaju bilo kakvog gubitka podataka u «Data Mart-u». Za takav oblik «Data Mart-ova» može se pretpostaviti da ne zahtijevaju izradu sigurnosnih kopija jer je, čak i u slučaju kvara, neprekinutost rada djelomično (uz slabije performanse) omogućena korištenjem skladišta podataka kao izvora informacija, a regeneriranje sadržaja «Data Mart-a» je, također, moguće iz skladišta podataka korištenjem istih aplikativnih rješenja koja se i inače koriste za njegovo osvježavanje. Naposlijetku recimo da se sadržajem «Data Mart-« mogu koristiti krajnji korisnici sustava. Za specifične potrebe analize se temeljem postojećeg «Data Mart-a» izgrađuju i višedimenionalne baze te se korisnicima pružaju i OLAP mogućnosti na raspolaganje. U ovakvoj sredini se u višedimenzionalnim bazama čuvaju prije svega podaci o dimenzijama i ostale potrebne definicije, a krajni se korisnici mogu neometano koristiti kako podacima sadržanim u relacijskim bazama tako i onima koji su dostupni iz višedimenzionalnih baza. Interesantno je reći nekoliko riječi i o specifičnim programskim rješenjima koja služe za izvršavanje OLAP analiza. To su korisnička sučelja (prema OLAP sustavu) koja na raspolaganje daju sve mogućnosti konkretnog OLAP sustava. Ona mogu biti instalirana na korisnička računala kao tzv. debeli klienti (engl. «Thick client») ili dostupna putem Interneta kao tzv. tanki klienti (engl. «Thick client»). Za tanke kliente je karakteristično da ne zahtijevaju nikakve intervencije na računalu korisnika pod uvjetom da taj korisnik na raspolaganju ima vezu prema Internetu i bilo kakav standardni Internet preglednik (engl. «Web browser»). Pomoću takvih aplikacija korisnik interaktivno pretražuje podatke i njima manipulira, pri čemu dobiva vremenski vrlo brze odgovore sustava. Također, vrlo je intersantno da korisnik ne mora unaprijed pripremati izvješća (recimo prije poslovnog sastanka), već ih može kreirati u trenutku kada mu zaista trebaju i na za taj trenutak najprikladniji način. U prilogu se nalaze primjeri grafičkog korisničkog sučelja (engl. «GUI – Graphical User Interface») jedne OLAP aplikacije.

24/33

Osvrt na poslovnu inteligenciju Poslovna inteligencija (eng. Business Intelligence) je «rezultat dobro upravljanog i promišljenog procesa izvođenja novih ili prikrivenih znanja iz podataka koji se u poslovnoj svakodnevici rutinski generiraju, zahvaćaju, memoriraju i koriste» (Panian, Klepec: «Poslovna inteligencija») U današnje su vrijeme tvrtke (ili organizacije) koje djeluju na svjetskom tržištu suočene sa potrebom pronalaženja brzih i kvalitetnih odgovora na vrlo složena pitanja. To je vrlo zahtjevan zadatak koji iziskuje napore u organiziranju adekvatne infromatičke infrastrukture koja je u stanju proizvesti takve informacije na temelju onih izvora informacija koji su tvrtki na raspolaganju. Općenito je količina raspoloživih informacija vrlo velika, pogotovo kada se tvrtka pojavi na svjetskom tržištu i počne se koristiti internetom kao jednim od izvora informacija. Iz prethodno rečenoga je vidljivo da su podaci kojima se organizacije svakodnevno koriste osnova sustava poslovne inteligencije. Takvi su podaci u izvornom obliku najčešće nedovoljno kvalitetni ili izvan adekvatnog konteksta, te kao takvi ne mogu poslužiti za potrebe realizacije i učinkovitog korištenja poslovne inteligencije. Upravo iz tog razloga je način kako se ti podaci prikupljaju, obrađuju, spremaju i prikazuju korisnicima vrlo bitan za stvaranje učinkovitog sustava poslovne inteligencije. Interesantno je naglasiti slijedeće karakteristika sustava poslovne inteligencije:

• Namjera koncepta poslovne inteligencije nije stvaranje veće količine podataka već generiranje kvalitetnijih informacija koje su potrebne pri donošenju poslovnih odluka.

• Poslovna inteligencija teži pružiti korisnicima samo one informacije koje su im u datom trenutku potrebne na način na koji im tada najbolje odgovara

• Poslovna inteligencija smanjuje količinu informacija kojoj su zaposlenici tvrtke izloženi, istovremeno povećavajući njihovu kvalitetu

• Poslovna inteligencija se zasniva na personalizaciji, ona teži pružiti informaciju koja je prilagođena potrebama pojedinca.

• Podaci kojima se sustav poslovne inteligencije služi su operativni podaci, dolaze iz operativnih izvora

• Poslovna inteligencija je proaktivna, u stanju je samostalno generirati i proslijediti bitne informacije krajnjim korisnicima

Kao što možemo vidjeti iz ranije rečenoga, sustavi poslovne inteligencije se koriste operativnim podacima tvrtke koje dodatno obrađuju i daju na uvid krajnjim korisnicima na jedan novi, vrijedniji način. Upravo su sustavi skladišta podataka, višedimenzionalnih baza podataka i OLAP sustavi ti instrumenti kojima se relaiziraju sustvi poslovne inteligencije Za operativne podatke je karakteristično da se čuvaju u transakcijski orijentiranim sustavima, a to su u praksi relacijske baze podataka kakve su u ovom radu u ranijim poglavljima detaljnije opisane. Količina tamo prisutnih podataka može biti vrlo velika. No često kvaliteta tih podataka nije dostatna za primjenu u sustavu poslovne intaligencije. Naime, operativni izvori podataka mogu biti raznoliki (odjeli unutar tvrtke, Internet, e-mail, podaci koji dolaze od strane dobavljača i distributera, i sl.) a to za sobom povlači i opasnost da je određena količina tih podataka nedosljedna, nepotpuna i zalihosna. Jedan od osnovnih preduvjeta izgradnje učinkovitog sustava poslovne inteligencije je postići zadovoljavajuću kakvoću ulaznih informacija. Postupak prikupljanja i obrade podataka za potrebe sustava poslovne inteligencije je već ranije opisani ETL

25/33

(eng. «Extraction, Transformation and Loading») postupak. Sa stanovišta poslovne inteligencije može se reći da je od tri koraka ETL postupka (dohvaćanje, transformacija i punjenje) upravo korak transformacije onaj koji je najkritičniji i vremenski najdugotrajniji. U tom koraku se, između ostaloga, povećava kvaliteta raspoloživih podataka tako što se oni dovode u stanje kada su:

• Standardizirani Podaci koji imaju isto značenje, ali su formalno različito iskazani, se od strane sustava mogu prepoznati kao različiti. Time nastaju anomalije u sadržaju koje otežavaju i onemogućavaju korektno odgovaranje sustava na postavljene korisničke upite. Takve se anomalije moraju ukloniti da bi svi sadržani podaci bili standardizirani

• Podudarni Sitne varijacije u načinu registriranja određenih podataka (npr. naziva, adresa i sl.) dovode do višestrukih zapisa u bazi podataka koji se odnose uvijek na jedan te isti entitet. Takvo umnožavanje podataka u bazama se mora uočiti i ukloniti.

• Verificirani Postupkom verifikacije se uspoređuju i utvrđuju podudarnosti podataka sa nekim poznatim i općeprihvaćenim izvorom.

• Proširivi Podaci su proširivi ako dozvoljavaju dodavanje novih podataka ili njihovu izmjenu na način kojim će isti postati dugoročno korisniji.

Kao što je već rečeno, sustavi poslovne inteligencije se uvelike oslanjaju upravo na u ovom radu prikazane tehnologijeskladišta podataka, višedimenzionalnih baza podataka i OLAP sustava. Ti sustavi svojim kvalitetama i mogućnostima upravo ciljaju na takvu primjenu gdje pokazuju svoju punu snagu i kvalitetu. No, samim time što neka tvrtka donese odluku za investiciju u takve sustave problem nije riješen, odnosno cilj nije dostignut. Potrebno je dodatno investirati u vrijeme i trud za izgradnju sustava, njegovu optimalizaciju i obuku krajnjih korisnika koji će biti u stanju razumijeti što im poslovna inteligencija donosi i znati na koji način im je to znanje dostupno. Rezultati koji dolaze konačnom produktivnom primjenom sustava poslovne inteligencije, te znanje i iskustvo koje se prikupi za vrijeme relizacije sustava u konačnici bogato nagrađuju uloženi trud, vrijeme i novac.

26/33

Zaključak Skladišta podataka i OLAP sustavi daju jednu novu, do sada gotovo nepoznatu, kvalitetu poslovnim informatičkim sustavima i sustavima poslovne inteligencije. Njihovi korisnici u svakom trenutku i na svakom mjestu imaju na raspolaganju ključne poslovne informacije i mogućnosti analize na vrlo jednostavan, brz i učinkoviti način. To je danas u poslovnom svijetu vrlo korisno, usudio bih se reći i nužno potrebno.

27/33

Prilog U slijedećim primjerima je prikazano kako izgleda grafičko korisničko sučelje OLAP aplikacije koja je na raspolaganju u Microsoft SQL Server 2000 sustavu. Uzmimo za primjer da se koritimo svim raspoloživim podacima o prodaji određenih proizvoda jedne tvrtke. Na slijedećoj slici (Slika 14: OLAP Aplikacija – slika 1) vidimo da se u višedimenzionalnoj bazi podataka o prodaji nalazi veći broj dimenzija i mjera. Svaka raspoloživa mjera je prikazana pomoću gumba i liste mogućih vrijednosti, a sve raspoložive mjere su prikazane jednim gumbom i listom vrijednosti koja sadrži nazive mjera. U konkretno prikazanom slučaju se promatra mjera Unit Sales, za koju se detaljnije vrijednosti vide tablično u ovisnosti o dimenzijama Yearly Income i Customers (prikazan je hijerarhijski nivo Counry). Sve ostale dimenzije su predstavljene u gornjem dijelu prikazane forme i imaju konkretno određene hijerarhijske vrijednosti. Inače, uobičajan naziv za sadržaj prikazanih dimenzija i mjera u gornjem dijelu forme jeste «rub stranice» (engl. «Page Edge»), za lijevu stranu prikazane tablice je uobičajan naziv «rub redova» (engl. «Row Edge»), te za gornji dio prikazane tablice je uobičajan naziv «rub kolona» (engl. «Column Edge»).

Slika 14: OLAP Aplikacija – slika 1

Page Edge Row Edge Column Edge

28/33

Na slijedećoj slici (Slika 15: OLAP Aplikacija – slika 2) možemo vidjeti da je prikaz podataka promijenjen, sada su u tablici prikazane vrijednosti svih raspoloživih mjera u odnosu na hijerarhijske vrijednosti dimenzije Customers


Na slijedećoj slici (Slika 16: OLAP Aplikacija – slika 3) je izvršena rotacija, odnosno, vrijednosti prikazanih mjera i dimenzije Customers su zamijenile mjesta

29/33


Na slijedećoj slici (Slika 17: OLAP Aplikacija – slika 4) se mogu vidjeti vrijednosti mjere Unit Sales ovisno o dimenzijama Store (vidljiv je nivo Store Country) i Time (prikazan je nivo Year). Pri tome se vrijednosti mjere Unit Sales promatraju za konkretnu hijerarhijsku vrijednost dimenzije Product (konkretan odabir je vidljiv u gornjem dijelu forme - Drink)


Na slijedećoj slici (Slika 18: OLAP Aplikacija – slika 5) se može vidjeti da se u odnosu na prethodnu sliku (Slika 17: OLAP Aplikacija – slika 4) otišlo jedan korak dublje (“drill down”) u hijerarhiju dimenzije Store i to za konkretnu hijerarhijsku vrijednost USA.

30/33


Na slijedećoj slici (Slika 19: OLAP Aplikacija – slika 6) je učinjen “drill down” za dimenziju Time


31/33

Na slijedećoj slici (Slika 20: OLAP Aplikacija – slika 7) je učinjena rotacija dimenzija (“Rotation of Dimensions”), te su zamijenjena mjesta u prikazu dimenzijama Time i Store


Na slijedećoj slici (Slika 21: OLAP Aplikacija – slika 8) je uz dimenzije Store i Time prikazana i dimenzija Gender

32/33


Ovdje je važno naglasiti da su sve aktivnosti manipuliranja podacima u ovakvoj aplikaciji dostupne gotovo trenutno (dakle bez potrebe ponovljenog izvršavanja kompleksnih upita) uz jednostavno korištenje standardnih mogućnosti rada u grafičkim korisničkim okruženjima (korištenje miša, izbornika, trake s alatima, kombinacije navedenoga ili sl.)

33/33

Literatura [1] John G. Hughes, “Database Technology. A software engineering approach”,

1988, Prentice Hall International Ltd, ISBN 0-13-197914-0 [2] Jeff Spicer, “Edgar (Ted) Codd, 1923-2003, Remembering the father of the

relational database”, Oracle Magazine, Volume XII, Number 4, stranica 9 [3] Anne Marie Smith, “ Data Warehousing: A Short Overview”,

[email protected] [4] Dave Wickert , “Creating Large-Scale, Highly Available OLAP Sites: A Step-by-

Step Guide”, 2001, Microsoft Corporation, http://www.microsoft.com/, 06.01.2004 [5] “The OLAP Report”, http://www.olapreport.com/index.htm, 06.01.2004 [6] P. Michael Bennet, “Oracle Express Foundation”, Oracle University, Student

Guide, Volume 1, siječanj 1999 [7] Lauran K. Serhal, “The Essentials of Data Warehouse Database Design“, Oracle

Education, Student Guide, siječanj 1999 [8] Ž. Panian, G. Klepec: “Poslovna inteligencija”, MASMEDIA, Zagreb 2003

olap- on-line analytical processing

Documents