sistemi za podr{ku odlu~ivawa zasnovani na data warehouse...

Univerzitet u Novom SaduEkonomski fakultet Subotica

Postdiplomske studije: MENAXMENT

Smer: INFORMACIONI SISTEMI U MENAXMENTU

Sistemi za podr{ku odlu~ivawa zasnovani naData Warehouse arhitekturi

MENTOR KANDIDAT

Prof. dr Ne|o Balaban dipl. in`. Dejan ^uki}

Novi Sad, Septembar 2001.

UNIVERZITET U NOVOM SADUEKONOMSKI FAKULTET SUBOTICA

KQU^NA DOKUMENTACIJSKA INFORMACIJA

Redni broj, RBR:Identifikacioni broj, IBR:Tip dokumentacije, TD: Monografska dokumentacijaTip zapisa, TZ: Tekstualni {tampani materijalVrsta rada, VR: Magistarska tezaAutor, AU: Dejan ûki}Mentor/Komentor, MN: Prof. dr Ne|o BalabanNaslov rada, NR: Sistemi za podr{ku odlu~ivawa

zasnovani na Data Warehouse arhitekturiJezik publikacije, JP: srpski (}irilica)Jezik izvoda, JI: srpskiZemqa publikovawa, ZP: JugoslavijaUè geografsko podru~je, UGP: VojvodinaGodina, GO: 2001.Izdava~, IZ: Autorski reprintMesto i adresa, MA: 24000 Subotica, Ekonomski fakultet,

Put Mo{e Pijade 9-11Fizi~ki opis rada, FO:(broj poglavqa/strana/citata/tabela/slika/grafika/priloga)

(5/198/13/29/28/0/6)

Nau~na oblast, NO: InformatikaNau~na disciplina, ND: Sistemi za podr{ku odlu~ivawaPredmetna odrednica/Kqu~ne re~i, PO: Sistemi za podr{ku odlu~ivawa,

Data WarehouseUDKûva se, Û: Biblioteka Ekonomskog fakulteta,

SuboticaVa`na napomena, VN: nemaIzvod, IZ: Teorijsko i prakti~no istraìvawe

Data Warehouse kao arhitekture za razvojsistema za podr{ku odlu~ivawa.

Datum prihvatawa teme, DP: Decembar 1999.Datum odbrane, DO: Septembar 2001.^lanovi komisije, KO: Predsednik:

Mentor:

^lan:

Dr Jovica \urkovi}, redovni profesor,Ekonomski fakultet SuboticaDr Ne|o Balaban, redovni profesor,Ekonomski fakultet SuboticaDr @ivan Risti}, redovni profesor,Ekonomski fakultet Subotica

UNIVERSITY OF NOVI SADFACULTY OF ECONOMICS

KEY WORDS DOCUMENTATION

Accession number, ANO:Identification number, INO:Document type, DT: Monograph documentationType of record, TR: Textual printed materialContents code, CC: Master of sc. thesisAuthor, AU: Dejan ^uki}Mentor/Comentor, MN: Ph.D Ne|o Balaban, ProfessorTitle, TI: Decision Support Systems based on Data

Warehouse architectureLanguage of text, LT: SerbianLanguage of abstract, LA: SerbianCountry of publication, CP: YugoslaviaLocality of publication, LP: VojvodinaPublication year, PY: 2001.Publisher, PU: Faculty of Economics SuboticaPublication place, PP: 24000 Subotica, Faculty of Economics,

Put Mo{e Pijade 9-11Physical description, PD:(chapters/pages/literature/tables/pictures/graphs/additional lists)

(5/198/13/29/28/0/6)

Scientific field, SF: Computer ScienceScientific discipline, SD: Decision Support SystemsSubject/Key words, S/KW: Decision Support Systems,

Data WarehouseUCHolding data, HD: The library of Faculty of Economics, Subotica

Note, N:Abstract, AB: Theoretical and practical research of Data

Warehouse as architecture for development ofDecision Support Systems.

Accepted by the Scientific Board on, ASB: December 2001.Defended on, DE: September 2001.Thesis defend board, DB: President:

Mentor:

Member:

Ph.D Jovica \urkovi}, full professor,Faculty of Economics SuboticaPh.D Ne|o Balaban, full professor,Faculty of Economics SuboticaPh.D @ivan Risti}, full professor,Faculty of Economics Subotica

Sadràj

1. UVOD 1

2. PROBLEM, CIQEVI I METOD ISTRA@IVAWA 52.1 Problem istraìvawa i obrazloèwe problema 62.2 Ciqevi istraìvawa 82.3 Metod istraìvawa 10

3. ARHITEKTURA DATA WAREHOUSE: TEORIJSKO -METODOLO[KE OSNOVE 13

3.1 O ODLUÎVAWU I SISTEMIMA ZA PODR[KUODLUÎVAWA 143.1.1 Odlu~ivawe i problemi odlu~ivawa 143.1.2 Sistemi za podr{ku odlu~ivawa 16

3.2 OSNOVNI POJMOVI DATA WAREHOUSE 203.2.1 Potreba za DW 203.2.2 Priroda, svrha i funkcije DW 213.2.3 OLTP i DW 233.2.4 Kvalitet podataka i metapodaci 273.2.5 Data Warehouse & Data Mart 31

3.3 DIMENZIONO MODELOVAWE 333.3.1 Smisao i svrha dimenzionog modelovawa 33

II Дејан Чукић/Магистарска теза

3.3.2 îwenica: pojam i vrste - tabele ~iwenica 363.3.3 Dimenzija: pojam i vrste - tabele dimenzija 383.3.4 Modeli podataka u DW 41

3.4 FAZE PROCESA OBLIKOVAWA DIMENZIONALNE BP 453.4.1 Izbor poslovnog procesa za modelovawe 453.4.2 Izbor nivoa granulacije poslovnog procesa 463.4.3 Izbor dimenzija koje }e biti primewene na svaki zapis tabele

~iwenica 483.4.4 Izbor ~iwenica koje }e biti u svakom zapisu tabele ~iwenica 49

3.5 AGREGIRAWE 513.5.1 Pojam i svrha agregirawa 513.5.2 Kreirawe agregata 523.5.3 Tehnike skladi{tewa agregata 543.5.4 Agregaciona navigacija 55

3.6 IZGRA\IVAWE DATA WAREHOUSE 593.6.1 Projektovawe DW 593.6.2 Odre|ivawe korisni~kih zahteva DW 623.6.3 Oblikovawe podataka DW 643.6.4 Arhitektura DW 673.6.5 Implementacija DW 68

3.7 DATA MINING 713.7.1 Definicija, evolucija i namena rudarewa podataka 713.7.2 Sistemi za upravqawe znawem 753.7.3 Neuronske mreè 793.7.4 Fazi logika i neuro-fazi aplikacije 81

4. REZULTATI EMPIRIJSKIH ISTRA@IVAWA 91

4.1 PRIKAZ POSLOVNOG SISTEMA 924.1.1 Zadaci NBJ 924.1.2 Podsistem monetarno-kreditnog regulisawa 944.1.3 Podsistem o ekonomskim odnosima sa inostranstvom 964.1.4 Informacioni sistem NBJ 98

4.2 ISTRA@IVAWE INFORMACIONIH ZAHTEVA KORISNIKA 1014.2.1 Izbor metoda odre|ivawa informacionih zahteva 1024.2.2 Odre|ivawe i priprema tima za ispitivawe 1024.2.3 Odabirawe i priprema respondenata 1034.2.4 Raspored ispitivawa respondenata 1054.2.5 Sprovo|ewe ispitivawa 1064.2.6 Analiza podataka dobivenih ispitivawem 1074.2.7 Odre|ivawe prioriteta i revidirawe obima projekta 108

4.3 KONCEPT I STRUKTURA DW U PODR[CI ODLUÎVAWA UOKVIRU NBJ 1064.3.1 Data Marts (modeli) 1064.3.2 Shema DW 109

Садржај III

4.4 LOGI^KI NIVO PROJEKTOVAWA – DIMENZIONI MODELI 1144.4.1 Dijagrami tabela fakata 1144.4.2 Dijagrami tabela dimenzija 1164.4.3 Dimenzioni modeli 119

4.5 DIZAJN FIZI^KE STRUKTURE 1254.5.1 Fizi~ki modeli 126

4.6 NA^IN REALIZACIJE KORISNI^KIH ZAHTEVA 1304.6.1 Bazi~ne korisni~ke akcije 1314.6.2 Korisni~ke aplikacije 1324.6.3 Upitni alat 1344.6.4 Performantnost mre`e 136

5. ZAKQU^CI 139

PRILOZI 143

LITERATURA 197

1. Uvod

Od uvo|ewa pre 50 godina, progres u procesirawu elektronskih podatakaprimarno je bio vo|en pomacima u tehnologiji. Sa prvim sistemima za paketnuobradu, korisnici su morali da ~ekaju neko vreme na rezultate izra~unavawa.Uvo|ewe sistema sa vremenskim deqewem omogu}ilo je korisni~ki pristuppodacima u realnom vremenu, dok su mreè i klijent/server sistemi dali pristupsa raznih lokacija.

Tradicionalne konceptualne komponente informacionih sistema su biliinputi, procesi i autputi. Fokus je bio na automatizaciji procesa ispecifikovawu {ta sistem treba da radi - funkcionalna orijentacija. U ciquugradwe {to ve}eg nivoa fleksibilnosti u aplikacione sisteme, odvajawepodataka od procesa je postalo standardna metodolo{ka praksa. Ova tendencija sezasnivala na premisi da podaci ostaju stabilni tokom vremena, a da su procesi tikoji se bitno mewaju vremenom. Ovo je, naravno, dobrim delom i ta~no - npr. kodaplikacija o komitentima neke banke. Ovaj pogled na svet se zasnivao samo na prvedve komponente IS - autput je bio zanemaren.

Na po~etku nije bilo koncepta BP, ~ak ni fajlova. Podaci su ugra|ivani uprogram. Pove}ane koli~ine podataka su „izrodile“ fajlove, koji su sme{tani naneki medijum (papirna trake, kartice i kasnije magnetne trake). Magnetni diskovisu omogu}ili nove aplikacione sisteme. Ovi sistemi su zahtevali aùrne podatkeza svoje programe, {to su novi fajl sistemi i tehnike svakako pruàli. Me|utim,fizi~ka struktura podataka je i daqe bila u tesnoj vezi sa aplikacionimprogramima.

2. Дејан Чукић/Магистарска теза

To je uzrokovalo dva problema. Prvo, svaka nova upotreba podataka jeiziskivala pisawe novih programa; zbog velikih tro{kova i dugog trajawa,pristupalo se startovawu ad hoc upita. Drugo, pojavio se ozbiqan problemsinhronizacije podataka (koji se nalaze u vi{e fajlova) - mogu}e je bilo dobijawepogre{nih odgovora, ~ak i ukoliko se napravi specijalni ad hoc upit.

BP su imale zadatak da odvoje aplikacione programe od fizi~ke strukturepodataka. Olak{avale su fizi~ko sme{tawe podataka i znatno su redukovaleproblem sinhronizacije. Izmene BP su iziskivale minimalne promene uaplikacijama, {to se za obrnuti smer ne moè re}i. Prvi se pojavio hijerarhijskimodel podataka. Ve}ina hijerarhijskih BP je pripadala korporaciji IBM. BP jemorala biti optimizovana za konkretnu aplikaciju i ve}ina problema fajlsistema je i daqe postojala. Mre`ne BP su nastale iz hijerarhijskih inajpoznatija je bila IDMS (Cullinet). Kori{}ewe internih pointera BP jeomogu}ilo fizi~ko povezivawe slogova koji su u nekoj logi~koj vezi. Mnoge zdraveideje su se pojavqivale uz ove BP (uz razvoj programskih jezika kao {to je COBOL),ali su se pojavile relacione BP.

Relacione BP su oti{le korak daqe u odvajawu podataka i aplikacija.Pojednostavqeno, to su kolekcije dvodimenzionih tabela (relacija). Ovakvaprezentacija podataka je bila blià poslovnim korisnicima. Op{irnije oosnovama relacionih baza podataka je dato u Prilog 1.

Ta~no je da su relacione BP predstavqale veliki napredak. Me|utim,osnovni razlog smewivawa hijerarhijskih i drugih BP je bio san o fleksibilnompristupu. Originalno obe}awe, iz ranih 1980-tih, da se isporu~enim podacimamoè ravnopravno pristupiti (Chris Date: „Uvod u sisteme BP“) nije ispuweno -izgubio se trag po~etne fatalne privla~nosti. Uvreìlo se mi{qewe da je smisaoRBP dobijawe, pre nego davawe podataka - a u stvari je obrnuto. Pored toga, prvirelacioni sistemi su bili spori (jedna transakcija u sekundi), dok se danaspostiè i 1000 transakcija u sekundi. Na sre}u, vi{e se ne moè kazati „cenafleksibilnosti je sporost“.

Verovatno je postalo truizam re}i da u svim planskim i kontrolnimaktivnostima menaxeri ne donose odluke koje su dobre ili lo{e, ve} da odlu~uju naosnovu dobrih ili lo{ih informacija. Gomila isporu~enih izve{taja sugeri{eda podaci verovatno nisu u adekvatnom formatu. Svaki put kada se neki izve{tajanalizira od strane poslovnih qudi, javqa se trenutni zahtev za tri daqaizve{taja. Pri tome, potrebni ekstrakcioni programi su uglavnom unikatni, samalo ponovqivih komponenata. Sve to ukupno iziskuje od informati~kog odeqewaneprihvatqivo velik napor, koji nije posledica samo specifikovawa, pisawa itestirawa programa, ve} i traèwa odgovaraju}eg vremena za startovawe programanad produkcionim sistemom.

Sistemi za podr{ku odlu~ivawa (DSS - Deciosion Support Systems) se baveproduktivno{}u znalaca, pomaù}i polustrukturirano i nestrukturiranoodlu~ivawe. Osnovni poslovni pokreta~i, motivi, za uvo|ewe DSS su:

● reducirawe tro{kova,● pove}awe kontrole,● obezbe|ewe planirawa,● pove}awe kvaliteta poslovawa i● rast prihoda.

Увод 3.

O~igledan trend u devedesetim godinama su nezavisni informati~kiresursi na nivou departmenta. Strate{ko odlu~ivawe je fragmentirano ifunkcionalno odeqeno, po{to su takvi i odgovaraju}i poslovni procesi. Nijeveliko iznena|ewe pojava da se u odvojenim sektorima (uz pomo} ra~unara)generi{u razli~ite informacije, a na osnovu istih podatka. Pored toga, socijalnipsiholozi tvrde da je odlu~ivawe ~esto arbitraran i nekonzistentan proces. To jeuglavnom zbog postojawa predrasuda (svesnih ili nesvesnih) i strategijskogparadoksa. U prilog tome, teorija kognitivne disonance Leona Fistingeraobja{wava kako individua moè imati dva mi{qewa ili uverewa koja sunekonzistentna ili kontradiktorna. Sama organizacija ispoqava disonantnostkroz neuskla|enost politika.

Kada je donosilac odluka emocionalno i politi~ki vezan za odluke koje jedoneo, one postaju neopozive uprkos empirijskoj evidenciji. Tendencija da seracionalizuje odluka (tj. da se smawi disonanca sa iskustvom) pomo}u svihraspoloìvih podataka koji podràvaju originalnu odluku je odbrambenareakcija, svojstvena za mnoge (naro~ito doma}e) organizacije. Konstruisawekorporativnog DSS o~ito ugroàva postoje}u strukturu mi{qewa i moè seo~ekivati jak otpor usled straha od „centralizovanog“ odlu~ivawa.

Sami podaci se prema stepenu sumarnosti mogu podeliti na: detaqne,agregirane i agregirane sa uzorkovanim detaqnim podacima. Pri tome, postoje dvevelike kategorije izvora podataka:

● interni - finansijski, logisti~ki, prodaja, produkcija, personal,ra~unovodstvo, IS, ...

● eksterni - konkurencija, ekonomski, industrija, ekonometrijski,psihometrijski, meteorolo{ki, demografski, prodajni i marketin{ki, itd.

Mora se priznati da i savremeni pristupi sistemskom dizajnu iprogramirawu izgra|uju aplikacije tako da su podaci „obmotani“ oko procesa. Uzpomo} naprednih korisni~kih alata i grafi~kih interfejsa, ovi sistemi su mnogopogodniji za korisni~ki pristup podacima. Osnovne odlike kori{}ewatransakcionoh sistema za podr{ku odlu~ivawa - neodgovaraju}e strukturepodataka, neintegrisanost podataka iz razli~itih izvora i nedovoqno pokrivawepro{losti - jo{ uvek su tu. Ipak, pristup standardnim izve{tajima je znatnoolak{an.

Integrisani pogled na podatke preduze}a je od davno bio jedan od ciqevasoftver inèwera (iniciran prvobitno visokim cenama ma{ina i periferijskihjedinica); nedovoqna integrisanost podataka nije jedini uzrok neuspe{nih DSS -najva`niji ostali razlozi su: neodgovaraju}i modeli podataka, nizak kvalitetpodataka, konceptualna zastarelost hardvera [28], parametri zasnovani napogre{nim pretpostavkama, logi~ke nekonzistentnosti u dizajnu DSS ialgoritamske razlike u aplikacionim programima.

Osnovne tehnike analize podataka su: verovatno}a, statisti~kozakqu~ivawe, analiza (regresiona, korelaciona, kompoziciona, vrednosna;vremenskih serija, osetqivosti, uticaja, what-if; proporcije dispariteta -Lorencova, Pareto, ...), indeksi i dr. Me|utim, u realnom svetu korporativnogdono{ewa odluka ne postoje ~isti i elegantni problemi kao takvi. Postojeopasnosti i pogodnosti. Mewaju se karakteristike odlu~ivawa. Dono{ewe odluka


je postalo suvi{e kompleksno i neizvesno da bi se podvrglo preciznoj,preskriptivnoj analizi.

To je osnova ubrzanog prelaza sa konvencionalnih tehnika analizeodlu~ivawa, ka tehnikama koje se zasnivaju na „mekom ra~unu“ (fazi logika,neuronske mreè, geneti~ko izra~unavawe, ...). U su{tini, meki ra~un jekonzorcijum metodologija koje su tolerantne na gre{ke, neizvesnost i parcijalnuistinitost, a koje omogu}uju da softver donosi „qudske“ odluke. Efektivnostmekog ra~una umnogome zavisi od raspoloìvosti softverskih alata ihardverskih resursa.

Pedesetih godina pro{log veka se smatralo da 50 IBM-ovih mainframera~unara model 704 moè da zadovoqi potrebe SAD za izra~unavawima. Danas,procesorsku snagu modela 704 sadrì jedan PC. Razlog veoma lo{e procene je bilatada{wa prevelika cena hardvera. Me|utim, sa razvojem komponentni poputtranzistora i integrisanih kola, tro{kovi su drasti~no pali. Virtuelnamemorija je dovela do fascinantnih pove}awa brzine rada. Senzacionalno zvu~ida je performantnost kompjuterskog hardvera porasla za osamnaest redovaveli~ine (1 000 000 000 000 000), dok je produktivnost razvoja softvera porasla zared veli~ine jedan (1) u istom periodu! Pri tome, najve}i rast je postignut previ{e od 30 godina, kada su prvi proceduralni programski jezici zamenilima{inski kod. Verovatno su najve}i problemi softvera konceptualna nezrelost ipreterana vezanost za tehniku.

Termin Data Warehouse (DW) je uveo W.H.Inmon 1992. godine. Data Warehouse(informaciono skladi{te podataka) nije nova IT aplikacija sa uticajem nastandardni model poslovawa. DW je nova IT arhitektura koja objediwuje skoro svepostoje}e tipove informacionih sistema i koja je jedan od faktorafundamentalnih promena. DW inovacija nema teì{te u oblasti hardvera isoftvera, ve} u arhitekturi. Su{tina DW filosofije su integracija podataka ikvalitetna metamorfoza (ekstrakcija, kombinacija i konverzija) podataka uinformacije.

DW ne obezbe|uje konceptualnu eleganciju za kojom se toliko ùdi, nitidaje èqeni nivo porasta produktivnosti razvoja asoftvera. Me|utim, zna~ajanporast produktivnosti analiti~ara, knowledge worker-a i donosilaca odluka, koja jebila zastra{uju}e stati~na u posledwe dve decenije, je izvesna. Najbitnija pojavavezana za DW, u oviru zna~ajne uloge u evolucionom kontinuumu informacionihsistema, je da ne transformi{e samo prirodu poslovawa, ve} i aktuelno pona{awena trì{tu i ukupnom ekonomskom okruèwu.

NBJ se nalazi u fazi kvalitetnog funkcionisawa interaktivnetransakcione obrade. Ovaj rad }e se baviti teoretskim aspektima DW (kaoarhitekture za razvoj DSS) i aspektima primene DW u konkretnom sistemu.

2. Glava

Problem, ciqevi i metod istraìvawa

Nau~no istraìvawe je sistematski, kriti~ki, kontrolisani i ponovqivproces sticawa novih znawa, neophodnih (a ponekad i dovoqnih) zaidentifikovawe, odre|ivawe i re{avawe nau~ih (teorijskih i empirijskih)problema. Pre detaqnije egzegeze pitawa istraìvawa u ovom radu, par re~i oosnovnim pojmovima: nauci, znawu, ~iwenicama ...

Nauka (latinski scientia, od scire - znati) se vi{e ne moè definisati naiskqu~iv i izri~it, a pri tome i potpun na~in. Jedno od rubnih shvatawa ukidarazliku izme|u nauke i znawa, odnosno sinonimizuje ova dva pojma. Nauka seposmatra kao organizovano znawe, tj. dinami~ki sistem znawa. Sistem nau~nihznawa je „ure|en, povezan, obuhvatan, proverqiv i ispravqiv skup nau~nih~iwenica, iskustvenih generalizacija, nau~nih zakona i nau~nih teorija, zasnovanna odre|enim principima“ [23].

Drugo (opet ekstremno) shvatawe isti~e da nauka nije znawe odnosnoposedovawe znawa, ve} (qudska) delatnost. Nauka je kriti~ko, agresivno i upornonastojawe - tragawe za znawem. Pri tome se koristi odgovaraju}i nau~ni metod.

Na jednostranost prvog shvatawa ukazuje ~iwenica da je nauka vi{e odznawa. Znawa su ciq, ali i proizvod nauke. Drugo shvatawe je u koliziji saistinom da se tragawe oslawa na postoje}i sistem znawa i da je zavisno odprethodnih raspoloìvih znawa. Me|utim, ova dva shvatawa su osnovnekomponente ispravnog stava o nauci, gde se pomo}u nau~nog metoda uti~e i mewa


postoje}i sistem znawa. Nau~na delatnost se uvek odvija u nekom sociokulturnomkontekstu i mora se posmatrati iz vremenske perspektive razvoja - Wartofsky:„nauka je forma qudske saznajne delatnosti koja je svrhovita i koja se istorijskirazvija“ [23].

Pitawa o znawu, teorijama znawa, vrstama i svojstvima znawa, izvorima isticawu znawa, nau~nim izrazima, iskazima, argumentima, kao i o jeziku naukeprevazilaze okvire ovog rada. Suptilna razrada ovih pitawa se moè na}i u [23].

Osnovne funkcije nau~nog znawa (u empirijskim naukama) su:

● nau~no opisivawe● obja{wavawe● predvi|awe● kontrolisawe - instrumentalno preobraàvawe.

Prema jednom shvatawu ovim funkcijama se moè prikqu~iti i razumevawe.

Kendler utvr|uje ~etiri vida razumevawa: deduktivno obja{wavawe,interpretativnu doslednost, poimawe posredstvom kontrole pona{awa iintuitivno razumevawe. Postoje opre~nosti u mentalnom objediwavawu ovihvidova razumevawa. Razrada ovih pitawa, kao i pitawa strukture i razvoja nau~nogznawa, tako|e se mogu na}i u pomenutom izvoru. Pogodno je da bude istaknuto danauka ne daje odgovore na tzv. posledwa pitawa. U nastavku }e se detaqnijeobraditi pitawa problema, ciqeva i na~ina kako nekog op{teg, tako ikonkretnog istraìvawa.

2.1 PROBLEM ISTRA@IVAWA I OBRAZLO@EWEPROBLEMA

Izraz nau~ni problem se naj~e{}e koristi kao brevijatura za „znawe oneznawu“. Sa saznajnog gledi{ta, nau~ni problem je vrsta znawa ~iji objekat nijeneposredna predmetna stvarnost, nego stawe ne~ijeg znawa o toj stvarnosti. Izborproblema je uvelike odre|en ontolo{kim, epostemiolo{kim, teorijskim,aksiolo{kim i eti~kim okvirom istraìvawa i istraìva~a.

Jasno definisani problemi istraìvawa predstavqaju osnov i po~etnikorak nau~nog istraìvawa. Uvi|awe vrednog nau~nog problema ima izrazitizna~aj za razvoj nau~nog znawa. Pored toga, tragawe, izabirawe i prou~avaweliterature, kao i sam redosled izu~avawe literature su vo|eni problemima,odnosno vizijom odgovora na pitawa koja defini{u problem.

Problem (nedostatak znawa koji se èli prevazi}i, nadomestiti) ovogistraìvawa }e biti izraèn u prirodnom jezi~kom obliku. Osnovnu vodiquistraìva~kog poduhvata ~ine slede}a pitawa, koja predstavqaju predmetistraìvawa:

P1: Koje su kriti~ne odluke, sa akcentom na top menaxment, u sistemu –organizaciji u kojoj }e biti sprovedno empirijsko istraìvawe?

Глава 2 – Проблем, циљеви и метод истраживања 7.

P2: Koje su kriti~ne, a koje su poèqne informacije za datu strukturuodlu~ivawa?

P3: Koji je sadràj i forma zahtevanih informacija?

P4: Kakvi su model i struktura DW?

P5: Koje su pogodne metode i tehnike crpqewa informacija iz sloàjevapodataka u DW?

Smatram da predstavqeni problem poseduje sve potrebne metodolo{keatribute:

1. psiholo{kog sadràja problema:

● raspolagawe odre|enom koli~inom znawa i informacija o predmetuprou~avawa - osnovni ~inilac problemske situacije,

● saznawe nepotpunosti raspoloìvog znawa (ukazano saznawe o logi~komneskladu raspoloìvih znawa, neta~nosti i neodre|enosti znawa) и

● intencija ka prevazilaèwu nepotpunosti (odabir izme|u upore|enihalternativnih postavki);

2. strukture jezi~kog izraàvawa - „pravilno postavqen problem je vi{e odpolovine re{ewa“; ta~nije re~eno, ispravnost pitawa je nu`ni uslov zadobijawe istinitog odgovora.

Od mno{tva oblika ispoqavawa nau~nog problema, posebno se isti~upoku{aji da se re{e neki problemi koji su me|usobno nesaglasni, kao inesaglasnosti starih teorijskih predstava i novih nau~nih ~iwenica; ne{to mawesu prime}ene praznine u sistemu nau~nog znawa i ~iwenice koje se na osnovuraspoloìvog znawa ne mogu objasniti, dok logi~ke nesagla{qivosti(protivre~nosti) teorija koje se odnose na istu oblast stvarnosti (u okviru jedneteorije) prakti~no ne postoje. Ovi vidovi ispoqavawa se mogu prepokrivati, asvaki potencijalno govori da postoji mawak znawa u datoj oblasti.

Smatram da navedeni problem (problemi) zasluùje tragawe za re{ewem,zbog toga {to ne spada u prividne, pravilno je postavqen (zadovoqava sintaksi~kai semanti~ka pravila) i zadovoqava nivo timolo{kog konteksta. Problemistraìvawa zadovoqava logi~ke i metodolo{ke kriterije provere vaqanosti iepistemolo{ka merila, kao i pitawe plodnosti prakti~ke primene znawaste~enih re{ewem datog problema (prakti~ki zna~aj problema).

Treba naglasiti da eroteti~ka (interogativna) logika jo{ uvek nemanaro~ito izraèna dostignu}a u ocewivawu pitawa kojim je izraèn nau~niproblem. Tako|e, kontekst opravdavawa je jo{ uvek prenagla{en u odnosu nakontekst otkri}a, a vrednovawe samog postavqawa problema je prakti~no jo{ uveku povoju.


Kao slikovit prilog za obrazloèwe (va`nosti) problema moè posluìtislede}a tabela:

Nomadskodru{tvo

Agrarnodru{tvo

Trgova~kodru{tvo

Industrijskodru{tvo

Dru{tvoznawa

Glavnatehnologija

grubaoru`ja

manuelnaoru|a

trgova~kibrodovi

ma{ine kompjuter

Ikona lova~kamotka

plug veliki tr-gova~. brod

benzinskimotor

mikropro-cesor

Nauka sujeverje civilno in-èwerstvo

lu~ko in-èwerstvo

ma{inskoinèw.

kompjuter-ske nauke

Autput ulovqeneìvotiwe

hrana safarme

trgovina masovna po-tro{na dobra

znawe

Energetskiizvor

vatra ìvotiwe vetar fosilnagoriva

um

Osnovabogatstva

lovne spo-sobnosti

zemqa trgova~kibrodovi

zemqa, rad ikapital

informa-cije

[ta donosiprednost

hrabrost mi{i}i flota ekonomijaobima

inteligen-cija

Odre|uju}ezanimawe

lovac farmer trgovac radnik radnikznawa

Smisaoìvota

opstanak prehrana trgovina automati-zacija

informa-tizacija

Organiacio-na forma

pleme feud tr`nica korporacija mreè

Logisti~kosredstvo

qudi ìvotiwe brodovi avion, voz,brod, kamion

mreà

Trì{te personalno seoskaraskrsnica

gradskeprodavnice

tr`ni centri trgov. hi-perprostor

Tabela 2.1 Informacione tehnologije su osnova glavnog oru`ja zadostizawe prednosti i bogatstva - znawa [22]

Postavqeni problemi istraìvawa, uop{te govore}i, ~ine sam predmetneke nauke. Otvorena je mogu}nost da {irewem prostora znawa (re{avawempostavqenih problema) i растом granice sa neznawem, do|e do uo~avawa ipostavqawa (nastajawa) novih nau~nih problema i pitawa - ba{ u toj grani~nojoblasti. Moè se re}i da se razvoj nauke odvija kroz re{avawe nau~nih problema,odakle se opet nagla{ava va`nost samog (kreativnog) nalaèwa problema.

2.2 CIQEVI ISTRA@IVAWA

Ciqevi i metodi za postizawe ciqeva se vide razli~ito zavisno odfilosofskog rakursa, a pritom i ciqevi i metodi same filosofije evoluiraju.Dodatno, izbor ciqeva je odre|en nekim vrednosnim i eti~kim korpusom.

Odre|ivawe ciqeva istraìvawa je tipi~no druga faza procesaistraìvawa. Ostale faze se mogu odnositi na hipotezu, kqu~ne izraze,istraìva~ku strategiju, sredstva istraìvawa, uzorkovawe, sprovo|eweistraìvawa i rezultate istraìvawa. Pri ovom nabrajawu se ne insistira da jelista kona~na i kompletna, da su sve faze uvek ukqu~ene i u datom redosledu, kaoni na tome da su granice izme|u faza jasne.


Ciqevi istraìvawa su èqena okon~awa na koja su usmerene aktivnosti uistraìvawu. Izraàvaju se preskriptivnim i preciznim iskazima, {to omogu}ujeda projekat bude svrsishodan. Mogu se podeliti na teorijske i prakti~ne ciqeve.

Kqu~ni teoretski ciqevi u ovom istraìvawu su:

(a) Integralni prikaz izgradwe DW (u svetlu primene za podr{ku odlu~ivawa):● odabir metodologije izgradwe DW,● analiza dimenzionog modelovawa i● prikaz agregata i agregirawa;

(b) Spoznaja uticaja informacija na proces dono{ewa odluka:● osvrt na teoriju dono{ewa odluka i sisteme za podr{ku odlu~ivawa, i● kriti~ni zna~aj informacija kod odlu~ivawa u top menaxmentu;

(v) Izu~avawe Data Mining-a:● skica modela, metoda i tehnika za Data Mining,● spoznaja odnosa Data Mining-a i sticawa znawa, odnosno sistema za

upravqawe znawem i● jezgrovit prikaz neuronskih mreà i fazi logike.

Glavni ciqevi prakti~nog karaktera:

(g) Ispitivawe respodenata:● konstrukcija metoda i definisawe na~ina za izvo|ewe istraìvawa,● odabir i priprema, kako tima za ispitivawe, tako i respodenata i● sprovo|ewe ispitivawa;

(d) Odre|ivawe koncepta i strukture (kao arhitekture za sisteme za podr{kuodlu~ivawa) u okviru NBJ:● prikaz poslovnog sistema,● analiza korisni~kih zahteva i● adekvatno locirawe DW;

(|) Implementacija DW:● prilago|avawe metodologije izgradwe DW i● implementacija i prakti~na primena DW.

Odre|ena priroda odnosa izme|u ciqeva uobli~ava grupe i nizove ciqeva,kao god i prvenstva me|u ciqevima. Moè se govoriti o stepenu zavisnosti izme|uciqeva, stepenu me|usobnog iskqu~ivawa, genealo{kom odnosu. Tako|e, postojeuporedni vs. sekvencijalni, posredni vs. neposredni ciqevi, kao i kompozitniciqevi.

Odnosi u kompleksu ciqeva (i podciqeva) mogu se predstavitiodgovaraju}om matricom odnosa ili stablima ciqeva. Tip istraìvawa, tipproblema i skup ciqeva izloèn u ovom radu ne iziskuju suptilnu analizu odnosa,te }e se ukazati samo na neke detaqe. Generalno, ciqevi ne iskqu~uju jedni druge.Dati prikaz ciqeva je intuitivan i prirodan i lako ga je preslikati u nekojenostavno stablo, gde su podciqevi (ciqevi listovi) nezavisni i neizvodqivi


me|usobno. Prakti~ni ciqevi su izrazito povezani i sekvencijalni, dok suteoretski ciqevi vi{e nezavisni. Kao {to je ina~e ~est slu~aj, rezultatiteorijskog karaktera pomaù ostvarewu empirijskih targeta.

2.3 METOD ISTRA@IVAWA

„Epistemologija je ili objektivna smokritika duha ili je nema ... a ovajizraz koji je suvoparan, moè se zameniti istinskim zna~ewem: qubav premaistini i radost saznawa“ (Pol Dil).

Kao {to je ve} ukazano, nau~no istraìvawe se ne da dovoqno dobrodefinisati bez celovitog posmatrawa primewenog nau~nog metoda. Nau~ni metodse posmatra iz razli~itih perspektiva i s obzirom na razli~ite probleme, ciqevei kontekste (vremenski, kulturni, socijalni, teorijski).

Od brojnih shvatawa i definicija metoda, prednost se daje onima koja seodnose ne samo na kontekst opravdavawa, ve} i na kontekst otkri}a. „Izraz nau~nimetod ozna~ava na~in postavqawa i re{avawa nau~nih problema i sticawa,obrazlagawa, povezivawa, kritikovawa, ocewivawa i razvijawa nau~nog znawa“[23]. Pri tome se nagla{ava da je nau~no znawe mnogo zna~ajniji proizvod nau~nogistraìvawa od podataka.

Prihvataju se ideje nove istraìva~ke paradigme, gde se konkretnomistraìvawu dodequje idiografski pristup. Ne postoji o~ekivana apsolutnaobjektivnost metoda - uvek je prisutan subjekt saznawa. Metodologija naukepripada oblasti metanauke (metanauka je kompozicija studija koje su organizovanena filosofskom, metateorijskom ili empirijskom nivou). Savremenumetodologiju odlikuje sadejstvo racionalnog i empirijskog, kao i deduktivnog iinduktivnog. Odbacuju se metodolo{ki monizam, metodolo{ki dualizam, kao inezavisnost metodologije od teorijskog okvira.

Postoje velike te{ko}e u stvarawu elegantnog i konzistentnog spiska vrstaistraìvawa. Sledi punktualan prikaz najpoznatijih podela istraìvawa (povrstama):

- Klasi~na podela:● prema prirodi (teorijska i empirijska istraìvawa),● prema ciqu (fundamentalna-bazi~na i primewena istraìvawa) i● prema fokusu (eksplorativna i istraìvawa za proveru hipoteza);

- Podela koju su sa~inili Scott i Wertheimer:● istraìvawa usmerena na prete`no prakti~ke probleme,● istraìvawa usmerena na razvoj teorija i● istraìvawa usmerena na proveru teorija;

- Podela istraìvawa koju je sa~inio Helmstadter:● prema {irini primene nalaza:

a) fundamentalna (osnovni motiv je radoznalost istraìva~a)b) primewena (usmerena na prakti~ke probleme)v) uslu`na (ideja ne pripada istraìva~u, a primewenost rezultata

je ograni~ena)


g) akciona (najmawa {irina primene rezultata istraìvawa),● prema nivou ishoda:

a) sa deskriptivnim ishodima (odgovori na pitawa „{ta“ i „kako“)b) sa prediktivnim ishodima (anticipativna istraìvawa)v) sa dijagnosti~kim ishodima (odgovori na pitawa „za{to“) i

● prema stepenu kontrole:a) laboratorijska istraìvawa (stroga kontrola)b) istraìvawa „u poqu“ (jedino se kontroli{u vreme i mesto

istraìvawa)v) bibliote~ka istraìvawa (bave se ve} publikovanim nalazima).

Izbor istraìva~ke strategije odre|uje okvir unutar kojeg se odabiranacrt istraìvawa. Tipovi i nacrti istraìvawa mogu biti slede}i:

eksperimentalni kvazi-eksperimentalni ex-posto-facto korelacione studije razvojne studije Survey akcioni evaluacione studije studije slu~aja i sl.

Istraìvawe u ovom radu ima u prvom redu odlike razvojnog i empirijskogistraìvawa. Naime, rad sadràva dve ve}e celine. Prvi deo istraìvawa jeteorijske, a drugi vi{e prakti~ne prirode; naravno, granice izme|u ovih tipovaistraìvawa nisu reske, ve} rasplinute.

Iz ovoga sledi da istraìvawe u celini nema striktnu pripadnost premaciqu - spektar ciqeva je relativno {irok i raznolik. Istraìvawe je usmerenomahom na prakti~ke probleme, a mawe na proveru teorija; prema {irini primenenalaza istraìvawe je uglavnom primeweno. Pripada istraìvawima sadeskriptivnim nivoom ishoda i sa slabim stepenom kontrole.

Na~in istraìvawa

Na~in istraìvawa je uskla|en sa ontolo{kim i epistemolo{kimpretpostavkama o predmetu (problemu) istraìvawa. Razvojno istraìvawe sebavi nedostacima ER modela u OLAP okruèwu i teorijsko-prakti~nim pitawimadimenzionog modelovawa. Tako|e, obuhva}ena je Kimbalova (Ralph Kimpball) metodaza dizajn i razvoj DW. Razvoj je iterativan, uz kori{}ewe poslovnog dimenzionogìvotnog ciklusa. Zna~ajno sredstvo istraìvawa, pored izu~avawa u zadwevreme sve brojnijih bibliografskih jedinica iz ove oblasti, je bio Internetodnosno kori{}ewe nekoliko najpoznatijih pretraìva~a; obim materijala kojise moè na}i ilustruje aktuelnost i atraktivnost DW problematike.

Empirijsko istraìvawe obra|uje konkretnu arhitekturu DW u sistemuNarodne banke Jugoslavije (NBJ). Projektna metodologija je prilago|ena saglasnojedinstvenim potrebama organizacije. Empirijsko istraìvawe koristimetodologiju kriti~nih faktora uspeha (CPI), kombinovanu sa metodom intervjua


(ankete). Nestandardizovani intervju je sproveden sa petnaestak kqu~nihrukovodilaca i analiti~ara u NBJ, sa ciqem da se uo~e problemi u dosada{wemradu i perspektive u budu}em periodu. Intervjui su prilago|eni s obzirom na~iwenicu da je ve}ina predvi|enih respodenata u~estvovala u procesimadosada{we izgradwe informacionog sistema NBJ.

Na osnovu prikupqenih zahteva, odre|en je koncept i struktura DW upodr{ci odlu~ivawa u NBJ. Ve}ina istraìvawa je sprovedena u Filijali NBJ uNovom Sadu.

Uzorak za istraìvawe je odabran iz populacije koju ~ine radnici NBJ-FNS. Uzorkovawe u drugom (empirijskom) delu istraìvawa ima nacrtneverovatnosnog uzorkovawa. Neverovatnosno uzorkovawe nije zasnovano nateoriji verovatno}e, ve} na konkretnom kontekstu istraìvawa. Nedostatak daonemogu}ava odre|ivawe preciznosti - gre{ke uzorka (statisti~ke ocene dobivenena osnovu uzorka, a time i ta~nosti ocewivawa) nije dovoqan da iskqu~i ovu vrstuuzorkovawa, naro~ito u eksplorativnim istraìvawima. Neverovatnosnouzorkovawe moè dati neki od slede}ih uzoraka:

● prigodni (izrazito subjektivan)● kvotni (poprili~no subjektivan)● namerni (izrazito subjektivan)● uzorak „sne`nih grudvi“ (iskqu~ivo za slu~aj qudske populacije).

Uzorak u ovom istraìvawu ima prvenstveno odlike namernog, a delom iprigodnog uzorka; procena je da je time postignuta ekonomi~nost uzorka. Tuma~ewerezultata ispitivawa se vr{i sa semanti~kog i teorijskog nivoa.

3. Glava

Teorijsko-metodolo{ke osnove DW

DW se danas smatra za najobuhvatniju arhitekturu i novu informacionuinfrastrukturu koja objediwuje sve dosada{we koncepte i podvrsteinformacionih sistema. Su{tina DW filosofije se zasniva na konceptuintegracije podataka. Naime, celovitost podataka je vrednija od zbira delova.

Izgradwa DW predstavqa vi{e od prostog kopirawa podataka iprepu{tawa korisnika alatima za podr{ku odlu~ivawa. Da bi se iskoristilipotencijali DW potrebno je restruktuirati podatke: izvr{iti denormalizacijutabela i/ili dodati nova poqa (radi zadovoqewa korisni~kih potreba zasortirawem, kombinovawem i sumirawem podataka). Formiraju se novi entitetikoji }e omogu}iti da podaci postanu prave informacije. Novi entiteti nastajuspajawem ili derivirawem entiteta osnovne baze. Mogu se ukqu~iti i podaci izeksternih izvora, kao i trendovi, prognoze i procene, na osnovu kojih seizvr{avaju simulacije ~iji rezultati predstavqaju dragocenu podr{ku zadono{ewe strate{ih odluka

Prvi deo ove glave }e se odnositi na odlu~ivawe, podr{ku odlu~ivawa isisteme za podr{ku odlu~ivawa. Zbog toga {to odlu~ivawe nije osnovna tema ovograda i zbog ograni~enog prostora, nabrojana pitawa }e biti obra|ena vi{etelegrafski. Najve}i deo glave }e se striktno odnositi na arhitekturu zasnovanuna DW. Posledwi deo glave }e obra|ivati pitawa znawa i rudarewa podataka.Pored standardno navedene literature, u delu istra`ivawa sadr`anom u ovojglavi, intenzivno su kori{}eni radovi profesora N. Balabana i @. Risti}a uposledwih pet godina.


3.1 O ODLUÎVAWU I SISTEMIMA ZA PODR[KUODLUÎVAWA

3.1.1 Odlu~ivawe i problemi odlu~ivawa

Odlu~ivawe predstavqa proces svrsishodnog odabirawa u skupualternativnih akcija. Proces odlu~ivawa ukqu~uje postavku ciqeva,identifikaciju problema, otkrivawe i procenu alternativnih akcija, odabir irealizaciju jedne od akcija, i ocewivawe postignutosti ciqa. Upravqa~ki procesje duboko utemeqen kao proces dono{ewa poslovnih odluka - odlu~ivawe jesinonim upravqawa.

Standardna klasifikacija odlu~ivawa i odluka ukqu~uje slede}ekriterijume:

● broj osoba koje odlu~uju: individualno i grupno odlu~ivawe● koli~ina raspoloìvih informacija i znawa: odlu~ivawe u uslovima

izvesnosti, odlu~ivawe u uslovima rizika, odlu~ivawe u uslovimaneizvesnosti i odlu~ivawe u uslovima kombinacije rizika i neizvesnosti

● strukturisanost odlu~ivawa: strukturisano (programirano), nestrukturisa-no(neprogramirano) i poslustrukturisano odlu~ivawe

● dovoqnost raspoloìvih informacija: terminalne i istraìva~ke odluke.

Racionalno odlu~ivawe

Racionalna aktivnost vodi postavqenom ciqu, u datim okolnostima. Moèse govoriti i o racionalnosti ciqeva, metoda i drugim. ôvekovo pona{awe nijesamo reaktivno, nego aktivno i proaktivno. Odlu~ivawe je motivisano ciqevima inaj~e{}e se odvija u uslovima nizvesnosti.

Jedna od osnovnih komponenti sheme odlu~ivawa je iskqu~uju}a disjunkcijaalternativnih akcija. Akcije mogu biti proste ili sloène. Zna~ajna komponentaje i iskqu~uju}a disjunkcija neizvesnih stawa stvari. Neka akcija i neko stawestvari daju odre|enu posledicu. Neizvesno stawe stvari ima verovatno}upojavqivawa.

Odabirawe odre|ene akcije iziskuje odre|ewe verovatno}a sa kojimaalternativne akcije vode razli~itim posledicama. Neophodno je odrediti ivrednost (poèqnost, korisnost) posledica, {to je ~esto i teì zadatak.

Smatra se da svako gledi{te koje proklamuje nadmo} intuicije izvr{ioca,uz povremene aktivnosti tipa {pijunaè, vr{i jak regresioni uticaj naodlu~ivawe (~ak u oblast magije - magijskog mi{qewa). Me|utim, verovatno je dasu najpoznatije strukturne tehnike za odre|ivawe „best course of action“ (stablaodlu~ivawa, payoff tabele, analiza rizika i korisnosti) previ{e jednostavanodnosno rudimentaran okvir za podr{ku komplesnih odluka u fluidnom idinami~kom (turbulentnom) okruèwu.

Глава 3 – Теоријско-методолошке основе DW 15.

Modeli odlu~ivawa

Na proces odlu~ivawa najsna`nije uti~u slede}e grupe ~inilaca: svojstvadonosioca odluke, svojstva problema odlu~ivawa i svojstva uslova u kojima seodlu~uje. Sledi saèt pregled modela odlu~ivawa:

● ekonolo{ki model: preskriptivni model, govori kako bi "racionalna" osobatrebala da odlu~uje

● Simonov model: racionalan model koji teì maksimizovawu, ali jeracionalnost ograni~ena

● heuristi~ki model: savremen model, koji opisuje iskrivqavawe prosu|ivawa,odnosno pojednostavqene strategije i domi{qata naga|awa; donosioci odlukase koriste slede}im heuristicima, od kojih svaki ima specifi~nepristrasnosti (koje mogu voditi predvidqivim gre{kama):

- heuristik raspoloìvosti- heuristik reprezentativnosti- heuristik ukotvqavawa i pode{avawa.

● socijalni model: opozitan je racionalnom modelu i ukazuje na uticaj emocija,nesvesnih èqa i socijalnih ~inilaca (kohezivnih grupa) na procesodlu~ivawa.

Moderna teorija odlu~ivawa se sve vi{e oslawa na rezultate iz oblastikognitivne psihologije. Edvard de Bono ukazuje na ~etiri vrste mi{qewa:naturalno, logi~ko, matemati~ko i lateralno mi{qewe. Tako|e, socio-kulturalne norme procesa dono{ewa odluka su faktor koji se vi{e ne daprenebregnuti i koji ukazuje na neophodne promene u normativnoj orjentaciji.

Problemi odlu~ivawa

Nalaèwe problema organizacije je zna~ajnije od samog re{avawa iukqu~uje potpuno druga~ije i sloènije saznajne procese. Uvi|awe i procewivawezna~aja problema je pogre{ivo. „Dijagnosti~ko zakqu~ivawe je teè od kauzalnog“(Tverski).

Najva`nija stanovi{ta posmatrawa procesa dono{ewa odluka, s obzirom naprobleme odlu~ivawa, su:

● normativni: u fokusu je racionalnost, re{avaju se (naro~ito) struktuirani ipolustruktuirani problemi - ponavqaju}e odluke

● deskriptivni: vrednuje kognitivne i ostale sposobnosti, uzima u obzir sverelevantne (eksterne i interne) faktore, re{avaju se polustruktuirani i(naro~ito) nestruktuirani problemi.

Pristup re{avawa problema odlu~ivawa je tradicionalan i najpoznatijina~ini su:

● kvantitativno usredsre|en na~in: utemeqen na normativnom pristupu ikori{}ewu optimizacionih matemati~kih modela


● na~in usredsre|en na menaxersko odlu~ivawe: kombinuje normativni ideskriptivni pristup, upravqen je na prete`no kori{}ewe kvalitativnihmetoda i tehnika.

Pristup postavqawa problema odlu~ivawa i kori{}ewa povoqnostiide korak daqe i traì kreativno i logi~ko analiti~ko razumevawe situacijaodlu~ivawa. Akcenat je na identifikaciji, re{avawu i kori{}ewu budu}ih„skrivenih“ problema i mogu}nosti.

Tragawe za alternativnim akcijama, mogu}im problemima i povoqnostimasu kreativnog karaktera, te se tada preporu~uju kreativne tehnike. Ograni~enostvremena i limitiranost u~esnika ~ini razvoj novih tehnika jednom od kqu~nihoblasti menaxmenta. Sledi pregled osnovnih kreativnih i drugih tehnika imetoda za postavqawe i re{avawe problema odlu~ivawa:

brainstorming delfi tehnika tehnika nominalnih grupa skale procewivawa (Thurstoneovog i Likertovog tipa) ~ek liste tehnika Q-sortirawa analiza sadràja semanti~ki diferencijal metod pore|ewa u parovima strukturisane rasprave tehnika izri~itog (preciznog) definisawa problema odlu~ivawa tabela za definisawe i analizu problema odlu~ivawa tehnika redefinisawa problema odlu~ivawa.

3.1.2 Sistemi za podr{ku odlu~ivawa

Savremeni IS se mogu podeliti u operativne transakcione sisteme (OTS) isisteme za podr{ku odlu~ivawa (DSS).

Operativni transakcioni sistemi mogu da budu OLTP, PCS (Process ControlSystems) ili OAS (Office Automation Systems). Fokus ovih sistema je naautomatizaciji. Uglavnom se zasnivaju na relacionoj tehnologiji i ER modelima.ER modeli sme{taju svaki entitet u posebnu tabelu, povezuju}i tabele spojevima.U ER modelu, entitet reprezentuje tip fizi~kog objekta ili transakcije.

Dizajnirane za sme{taj velikog broja diskretnih slogova, tradicionalnetransakcione DB su prete`no zahtevale kompleksne spojeve da minimizuju brojslogova. Transakcije uglavnom ukqu~uju jednu ili dve tabele, ~esto aùriraju}isamo jedan slog, te kompleksne relacije ne umawuju zna~ajno performanse.Neophodno je da su OTS rigorozno specificirani unapred. Ve}ina ovih sistema suu stvari prese~na oblast izme|u organizacije i stranaka. OTS ne bi trebali dabudu podru~je u kojima bi se obavqala odre|ena analiti~ka istraìvawa. OTSpredstavqaju osnovu i sredstvo za razvoj DSS.


Pojam, priroda i svrha DSS

Kako se vremenom upotreba IS {iri i intenzivira, rastu obim i detaqnostpodataka. U tim podacima se nalazi skriveno znawe, sa potencijalno velikimuticajem na uspe{nost organizacije. Logi~no, menaxeri teè da unaprederazvijawe marketin{ke strategije, ciqnih trì{ta, prilagode investicije,minimizuju rizik i elimini{u nepotrebne tro{kove, pove}aju efekat odinvesticija. Javila se potreba za DSS (Decision Support Systems).

Koncept obuhva}en DSS u prvi je jasno izrazio po~etkom 1970. godine Skot-Morton. Prvi grafi~ki DSS (tzv. EIS – Executive Information Systems) sistemi suimplementirani koriste}i ER dizajn. Sa pove}awem volumena i sloènosti bazapodataka, sistemi su postajali teì za kori{}ewe i izgradwu.

Klasi~ni DSS su nazivani upravqa~ki informacioni sistemi (MIS) ipripadaju drugoj razvojnoj fazi IS. MIS su produkovali odre|ene informacije,ali sa jakim fokusom na kontrolu. Dana{wi DSS i ES (ekspertski sistemi) nisuusredsre|eni na procesirawe informacija, ve} na proces odlu~ivawa. Semizvr{nih IS, pojavquju se izvr{ni sistemi za podr{ku.

Slede}u generaciju predstavqaju sistemi za podr{ku grupnog odlu~ivawa,takozvani grupni DSS. Ovi sistemi su pove}ali produktivnost u~esnika dono{ewaodluka, ubrzali proces dono{ewa odluka i poboq{ali kvalitet rezultataodlu~ivawa.

Paralelno sa GDSS su razvijani inteligentni DSS ili DSS zasnovani naznawu. Najnoviji, i jedini pristup kod kojeg kvalitet celine nadvladava kvalitetposebnog, ~ine DDWS (Dimenzional Data Warehouse Systems) - u nastavku DW. DSS seposmatra ~e{}e kao pristup ili filosofija, negoli kao precizna metodologija.

Karakteristike i mogu}nosti DSS

Za obezbe|ewe podr{ke odlu~ivawu, DB mora imati prostu, konsolidovanu{emu, koja u slu~aju upita minimizuje broj procesiranih slogova. DSS produkujumali broj transakcija sa velikim brojem podataka, dok su ER modeli pogodni zaveliki broj transakcija sa malim brojem slogova. Mogu} je pristup stotinama ihiqadama redova u upitu, pa kompleksni spojevi mogu drasti~no da ugrozeperformanse. DSS upotreba je veoma nestrukturisana, jer korisnici ~estoodlu~uju {ta da analiziraju neposredno pred postavqawe upita i pristupni putevise mewaju ~esto.

DSS otvaraju novu dimenziju kori{}ewa baza podataka u odnosu na ono {tosu tradicionalni modeli podataka omogu}avali. DSS su dizajnirani za On LineAnalytical Processing (OLAP). Velika je {arolikost me|u korisnicima i na~inimaupotrebe DSS-a. Neki korisnici su u izvr{nom birou, a neki u top menaxmentu.Neki pristupaju podacima jednom u kvartalu, a drugi deset puta dnevno. Tako|e,DSS nisu ~isto informati~ka tehnologija, ve} je potrebno dodatno znawemenaxmenta. DSS postaje kqu~ni faktor korporacijske strategije.

Slede}a tabela daje sinopti~ki prikaz osnovnih karakteristikaoperativnih transakcionih sistema u odnosu na DSS:


Osobina/Funkcija Operativa Podr{ka odlu~ivawu

Sadràj podataka Trenutna vrednost Arhivski, sumarni ira~unski

Organizacija podataka Aplikacijska Obuhva}en deo preduze}a

Priroda podataka Dinami~ka Stati~ka do osveèwa

Struktura podataka,format

Kompleksna, pogodna zaoperativna izra~unavawa

Prosta, zgodna za poslovneanalize

Verovatno}a pristupa Velika Sredwa do niska

Aùrirawe podataka Na principu poqe-po-poqe

Pristupawe i manipulac.;bez direktnog aùrirawa

Upotreba Visoko struktuisanoponavqaju}e procesirawe

Nestruktuisanoanaliti~ko procesirawe

Vreme odgovora Deo sekunde do 2-3 sekunde Sekunde do minuta

Tabela 3.1. Komparacija funkcionalnosti OTS i DSS [2]

Aktivnosti i vrste DSS

Za uspe{no reaktivno, a naro~ito za proaktivno upravqawe organizacijom(pogotovo strategijsko) neophodno je anticipirawe promena i blagovremenoreagovawe, tj. neophodna je odgovaraju}a podr{ka odlu~ivawa i DSS.

Upravqa~ke aktivnosti se mogu svrstati u tri kategorije, koje ujedno dajuosnov podele samih DSS za te aktivnosti:

● strategijsko upravqawe● upravqa~ka kontrola● oprativno planirawe i kontrola.

Odlu~ivawe u strategijskom upravqawu vodi dalekose`nim i sudbonosnimposledicama za organizaciju i pripada prete`no nestrukturisanom ipolustrukturisanom odlu~ivawu. Zna~aj informati~ke podr{ke strategijskomupravqawu upu}uje na razvoj sistema za podr{ku odlu~ivawa u toj oblastiupravqawa. Dobar DSS podrazumeva mogu}nost odgovaraju}eg integrisawa iupravqawa kako detaqnim, tako i sumarnim podacima.

Treba naglasiti da je zna~aj podataka ne samo za operacionalnu kontrolu,ve} i za operacionalnu strategiju jedan od kqu~nih pokreta~a modernih oblikaimplementacije DSS. Operacionalna strategija se moè u~initi kaokontradiktoran termin (oksimoron), ali u stvari ukazuje na potrebu da sestrategija, u kompetitivnom i turbulentnom okruèwu, kontinuirano inovira ipode{ava u rokovima koji su prekratki da bi se postigli strategijskimplanirawem u klasi~nom smislu.


Arhitektura i razvoj DSS

Osnovne komponente arhitekture DSS su:

● podsistem za upravqawe podacima (komponenta podataka)● podsistem za upravqawe modelima (komponenta modela)● podsistem dijaloga (komponenta komunikacije).

Ove komponente konstitui{u softverski deo DSS. Komponente se moguizgraditi programirawem, spajawem postoje}ih komponenata ili kori{}ewemgeneratora DSS. Podrazumevani deo DSS su i sami korisnici DSS. Krajwikorisnik obi~no projektuje DSS alatima kao {to su Excel ili Lotus.

DSS ima dve {iroke klase korisnika: rukovodioce i stru~ne specijaliste(analiti~are, planere i istraìva~e). Kada rukovodilac koristi DSS, mogu}e jeangaòvawe posrednika koji vr{i analize i saop{tava rezultat.

Unapre|eni DSS poseduje komponentu znawe. Podsistem znawa moèpodràti svaki drugi podsistem ili da se koristi kao nezavisna komponenta,obezbe|uju}i znawe za re{avawe specifi~nih problema. Vi{e re~i o znawu iupravqawu znawem }e biti u ta~ki 3.7.

Ve{ta~ka inteligencija se ~esto povezuje sa konceptom znawa.Inteligentni sistem podrazumeva komercijalnu primenu ve{ta~ke inteligencije.Ocewuje se da }e u prvim godinama novog veka 15-20% svih ra~unarskih aplikacijaukqu~ivati neki inteligentni sistem. Najva`niji inteligentni sistemi su:kori{}ewe prirodnog govora, razumevawe qudskog glasa, roboti i sistem senzora,kompjutersko predvi|awe, inteligentne ra~unarske konstrukcije i sve tehnologijevezane za data mining. Kombinacija dva ili vi{e pomenutih sistema predstavqahibridni inteligentni sistem.

Proces razvoja DSS se sastoji iz slede}ih faza i subfaza:

1. predizajn: planirawe, istraìvawe i analiza2. dizajn: dizajn BP, dizajn baze modela, dizajn subsistema dijaloga3. izgradwa: programirawe i testirawe DSS4. implementacija: evaluacija, demonstrirawe, trenaà i funkcionisawe5. odràvawe6. adaptacija.

Metodologija izgradwe DSS se deli na dva osnovna prilaza:

● tradicionalni na~in ìvotnog ciklusa● evolutivni (iterativni, prototipski) pristup.

Tehnolo{ke nivoe DSS tehnologije ~ine: specifi~ni DSS, DSS generatori iDSS sredstva. Izgradwa DSS se moè izvesti pomo}u pristupa brzog efekta,etapnim razvojem ili razvojem kompletnog DSS. Broj u~esnika u razvoju DSSvarira, a ~ine ih: korisnici, posrednici, DSS graditeqi, specijalisti za tehni~kuasistenciju i graditeqi sredstava.


3.2 OSNOVNI POJMOVI DATA WAREHOUSE

3.2.1 Potreba za DW

Posledwih 30 godina fokus angaòvawa informati~kih resursa su bilihardver, softver i mreè. Glavni ciq je bio prikupqawe i generisawe korisnihpodataka. Ovaj ciq je dobrim delom postignut, te se danas resursi preusmeravaju kanovom izazovu - analizi podataka i generisawu korisnih informacija.

Pojavom novih tehnolo{ko-sistemskih poboq{awa (paralelnoprocesirawe, masivno paralelno procesirawe, simetri~no paralelnoprocesirawe), novih tehnika za spasavawe i ~uvawe podataka, novih metodologija,metoda i tehnika projektovawa, koncepata BP (multidimenzionalne BP, OLAP),sistema za podr{ku odlu~ivawa i dr., kao i drasti~nim padom cena hardveraprevazi|ena su odre|ena postoje}a ograni~ewa. Organizacije su pove}alekoli~inu podataka koje su prikupqale o svom poslovawu i do{lo se do saznawa dasu postoje}i IS neadekvatni za narastaju}e potrebe za informacijama, koje sezahtevaju pri dono{ewu odluka.

Slede}a tabela predstavqa evoluciju koja je dovela do pojave DW:

Evolucioni korak Poslovna pitawa Raspoloìvatehnologija

Karakteristike

Prikupqawe poda-taka (70-te godine)

Ukupna prodaja uposledwih petgodina

Kompjuteri, trake,diskovi

Retrospektiva,stati~ka isporukapodataka

Pristup podacima(90-te godine)

Pojedina~na proda-ja na nivou regiona,pro{log juna

Relacione BP(RSUBP), Structu-red Query Language(SQL), ODBC

Retrospektiva,dinami~ka isporu-ka podataka na ni-vou slogova

DSS i DW (posle-dwa decenija veka)

Pojedina~na pro-daja na nivouregiona, pro{logjuna - po gradovima

OLAP, multidi-menzionalne BP,DW

Retrospektiva,dinami~ka isporu-ka po vi{e nivoa

Data Mining (dana-{wa potreba)

Doga|awa u odre|e-nom gradu slede}egmeseca, sa uzroci-ma

Napredni algori-tmi, multiproce-sorski kompjuteri,masivne baze

Dalekovidnost,proaktivna ispo-ruka informacija

Tabela 3.2. Evolucija koja je dovela do pojave DW

Promena u strukturi DW tro{kova je znatno pove}ala interesovawebiznisa za uvo|ewe DW. U~e{}e tro{kova hardvera opada 5-10 % godi{we, ceneSUBP miruju, u~e{}e alata za upravqawe kopijama raste 1-2 % godi{we, doku~e{}e tro{kova za sistemske integratore i konsultante raste po stopi 4-8 % zagodinu dana.


Drasti~no pojeftiwewe hardvera je obezbedilo dvostruku prednost. Prva jepove}awe obima operativnih podataka koje sada sistemi prikupqaju, a sa drugestrane period ~uvawa podataka se znatno produìo iako je do{lo do neznatnogpove}awa cena alata za ~uvawe podataka.

Poslovna namena DW

DW je u intenzivnoj interakciji sa poslovawem i poslovnim potrebama.Poslovne oblasti, procesi i celine su neka vrsta gra|evnih objekata za DW.

Poslovni korisnici obi~no znaju koje informacije su im potrebne iz DW,ali ne mogu uvek da utvrde da li raspoloìvi podaci i obezbe|uju te informacije.Primera radi, funkcija marketinga èli da obradi sve podatke iz transakcionogsistema o prodaji, pozajmicama, kreditnim karticama, nepokretnostima iinvesticijama. Sistem koji prikupqa te podatje je dizajniran specifi~no zaodre|enu poslovnu funkciju. Informacija koja je od interesa za marketing,prilikom rasu|ivawa o odre|enom kupcu, je veoma razli~ira od onoga {to jeneophodno za transakcioni proces i zahteva odre|ena izra~unavawa i obrade.

Me|utim, ako su podaci sme{teni i sortirani prema regionu, starosnojgrupi i sl., poprili~no je olak{ano dobijawe izve{taja, grafa ili ~aktrodimenzionalne prezentacije aktivnosti kupaca (u oviru nekih rangova ilidimenzija). To je primer za metamorfozu podataka u informacije.

DW ne moè biti stati~na i nikad ne prestaje da se razvija. Stalnopristiù zahtevi od strane biznisa (menaxera i izvr{ioca), ~esto i neo~ekivani.DW se razvija kako se razvija i organizacija, te su dinami~ka i turbulentnaokruèwa izazovnija za DW ({to ne zna~i da stabilna organizaija ne treba DW).Za razliku od tradicionalnih sistema, promene se kod DW posmatraju kao znakuspeha, a ne kao gre{ke - one su znak dugotrajnog zdravqa implementirane DW.

3.2.2 Priroda, svrha i funkcije DW

DW je izraz osnovne namene IS: prikupqawe informacija o organizaciji i~iwewe da one budu korisne (upotrebqive). Evolutivni podaci i baza modelakarakteri{u DW. Data Warehousing je proces integracije obuhvatnih informacija ujedan repozitorij, iz kojeg krajwi korisnici mogu startovati izve{taje ipostavqati ad hoc upite.

Po{to su problemi koji se re{avaju u strate{kom odlu~ivawu uglavnomnestruktuirani, potrebno je u procesu odlu~ivawa uzeti veoma veliki brojpodataka iz nekog perioda kako bi kvalitet odlu~ivawa zadovoqavaju}i. Iz tograzloga DW sistemi se name}u kao dobra osnova za DSS.

Podaci i informacije se su{tinski razlikuju. Podatak ukazuje na kolekcijudiskretnih elemenata, recimo fajl. Struktura podataka je dizajnirana za upotrebuu kompjuterskom sistemu koji podràva specifi~an proces. Operacionalnisistemi procesiraju podatke za podr{ku poslovnih aktivnosti organizacije.

Kada se podaci kombinuju, agregiraju, deriviraju, sortiraju, struktuiraju iprikazuju, postaju informacije. Omogu}ivawe postupaka kojima se oboga}uje


vrednost podataka, odnosno transfirmi{u podaci u informacije, je jedan odosnovnih razloga gra|ewa DW.

U ve}ini organizacija, postoje}a struktura sistemske podr{ke ne moè dazadovoqi sve zahteve DSS okruèwa i javqa se potreba za specifi~nim tipomosobqa - administratori DW (DWA). Obim podataka u DW je do dva reda veli~ineve}i. Tako|e, administrator operacionalnih sistema moè predvideti koli~inubudu}ih podataka i stepen rasta, dok se DWA suo~ava sa eksplozivnim inepredvidivim rastom. Razlozi za to su da DW sadrè istorijske podatke (naslage)i va`nost kako sumarnih, tako i detaqnih podataka.

Transakcije imaju druga~iju prirodu nego kod OTS - variraju po veli~ini iretko se koriste za aùrirawe (primarni zadatak su upiti). Ve}ina transakcija sekoristi za analiti~ke, informacione svrhe - vreme odgovora je bitan, ali ne ikriti~an faktor performansi sistema DW.

Zadaci DW

Osnovni zadaci jednog DW su:

1. Dostupnost informacija o realnom sistemu: sadràj DW treba da buderazumqiv, korektno ozna~en i upravqiv. Upravqivost se manifestuje pojavomsadràja DW pomo}u obi~nog klika mi{em. Tako|e, pristup treba da bude brz ilak.

2. Konzistentnost informacija o organizaciji: potreban je visok kvalitetinformacija u smislu da dva poqa imaju isto ime ako, i samo ako, predstavqajuisti pojam iz okruèwa.

3. DW treba da bude prilagodqiv i elasti~an izvor informacija: DW supredvi|ene za stalne promene, tj. za zadavawe novih upita ili dodavawe novihpodataka. Postoje}i podaci i tehnologije ne bi trebalo da se pod uticajem tihpromena obezvre|uju ili znatnije mewaju.

4. Sigurnost.5. Osnov za dono{ewe odluka - po{to je DW u stvari DSS, odluka je jedini pravi

output DW.

Moè se re}i da je DW baza podataka dizajnirana eksplicitno za potrebepodr{ke odlu~ivawa, gde se u aplikacijama teì optimizaciji vremena upita ielimini{e se kontakt sa produkcionim OLTP sistemima. „DW je ka subjektimaorjentisana, integrisana, vremenski varijantna, postojana kolekcija podataka kojapodràva odlu~ivawe menaxmenta“ [4].

W.H. Inmon je 1993. godine definisao DW kao „kontekstno orjentisanu,integrisanu, vremenski sporo promenqivu kolekciju podataka za izve{tavawe, saosnovnom namenom pruàwa podr{ke vrhunskom menaxmentu organizacije“.Pojednostavqeno, DW sadrì poslovne podatke u integrisanoj BP i nudiistorijsku perspektivu nad informacijama za DS aplikacije i upite poslovnihkorisnika. Stoga se u doma}oj i stranoj literaturi DW moè na}i pod nazivominformaciona skladi{ta podataka.


3.2.3 OLTP i DW

OLTP su sistemi u kojima se podaci obra|uju odmah (neposredno) po nastankutransakcije. Sre}u se pod nazivima operativni poslovni sistemi, sistemitransakcione obrade, a u starijoj dokumentaciji i produkciona baza (naspramizve{tajne BP). Kada proces dobijawa potrebnih informacija imakarakteristike OLTP obrade, uo~avaju se dva osnovna problema:

1. standardni SQL upiti su se pokazali dosta nepodesnim i neefikasnim ukori{}ewu sloènih struktura podataka velikih baza podataka,pogotovo ako korisnici imaju potrebu da defini{u zahteve izvr{ewasloènijih upita i

2. komunikacija korisnika (operatera) sa serverom, koja se u ovom slu~ajusvodi na niz SQL upita i prenos podataka preko mreè, dovodi do veomalo{ih performansi celokupnog sistema usled optere}ewa kako samemreè tako i servera BP.

DW ima su{tinski razli~ite potrebe, klijente, upravqawe, strukturu iritam (slogova - zapisa) nego operacionalni sistemi. Stoga mnoge dizajnersketehnike koje su adekvatne u uslovima transakcionih sistema nisu prihvatqive uuslovima DW. Me|utim, prakti~no je neostvarivo da se realizuje DW sistem, a daorganizacija nije prethodno razvila i implementirala dobar (perfektan) OLTP.

U Tabela 3.3 je dat komparativni pregled deset osnovnih elemenata:

Data Warehouse OLTP

Kori{}ewe intenzivni upiti intenzivne transakcije

Korisnici relativno mali broj relativno veliki broj

Pokrivenost teku}i i istorijski podaci samo teku}i podaci

Integracija podaci integrisani uzavisnosi od subjekta

podaci integrisani u zavi-snosti od prirode poslov-nih aktivnosti ili procesa

Kvalitet podataka definisan sa stanovi{takonzistencije

definisan sa stanovi{taintegriteta

Baza podataka nepostojana zbogintervalnog osveàvawa

postojana zbogkontinualnog aùrirawa

Modeldenormalizovan uzavisnosti oddimenzionalnosti subjekta

normalizovan u zavisnostiod podràvanih transakcija

Tabela 3.3 Osnovne razlike klasi~nih operativnih sistema i DW


Data Warehouse OLTP

Opsegskalabilna, pro{iriva ifleksibilnainfrastruktura za DS

definisan opsegomaplikacije koja je fiksna

Razvoj princip evolucije iiteracije

striktno prihvatawezahteva i pra}eweutvr|enog razvojnog metoda

Sponzorstvo zahteva se izrazitosponzorski model

vlasnici procesa imaju ja-sno pozicioniranu odgovor-nost u organiz. hijerarhiji

Tabela 3.3 nastavak

Arhitektura podataka

Poslovni procesi su automatizovani u formi aplikacija, koje ukupno ~ineportfolio poslovnih sistema i koje se mogu podeliti u dve velike grupe:

● Biznis aplikacije: operacionalno izvr{avawe poslova (dnevno, nedeqno,mese~no itd.). Kada prestanu da rade, prestane i funkcionisawe biznisa.

● Aplikacije o biznisu: interpretiraju poslovne doga|aje i odre|uju budu}eakcije. S prestankom wihovog rada nema trenutnog (o~iglednog) zaustavqawabiznisa, ali su kriti~ne za dugoro~nu kompetitivnost organizacije. DWobuhvata ove tipove aplikacija.

Teorija inèwerstva podataka (inèwerstvo podataka je disciplina koja sebavi modelovawem, analizom i dizajnom podataka u svrhu maksimalne korisnosti)ukazuje da postoje ~etiri generi~ka okruèwa podataka na kojima se gradeposlovne aplikacije. Iz brojnih tehni~kih i arhitekturalnih razloga one nisupodjednako dobre. Slika 3.1 ilustruje ~etiri opcije.

Namenska fajl arhitektura: svaka aplikacija poseduje set fajlova, koji sudizajnirani specijalno za potrebe te aplikacije. êsto kao direktan rezultatstrukturne analize, podaci se ugra|uju u datu funkciju.

Zatvorena arhitektura BP: SUBP je kori{}en da obezbedi tehnolo{keprednosti nad fajl sistemima (pogledi, bezbednost, atomarnosst, zakqu~avawe,oporavak BP itd.) ali razli~ite, odvojene i nezavisne BP se jo{ uvek dizajnirajuza svaku aplikaciju. Kao i u slu~aju prethodne arhitekture, postoji visok stepenredundancije i ~esto oskudne administracije podataka. Zamr{eni i nepouzdani(“spaghetti-like”) interfejsi vr{e razmenu podataka izme|u zatvorenih BP. Oviinterfejsi se ~esto nazivaju ”~ista~i podataka” ili translatori; oni ne dodajuvrednost, oni kompenzuju neadekvatnu administraciju podataka.

Zavisna arhitektura BP: podacima se rukuje na bazi wihovih internihatributa, nezavisno o bilo kojoj specifi~noj aplikaciji. Podaci seadministriraju kao deqivi resurs. Ekstenzivno deqewe podataka se odvija pomo}upogleda koji su senzitivni prema aplikaciji. Ove BP pokre}u dnevne operacije.


ekstrakcijapodataka

File Data Architecture Closed DatabaseArchitecture

Aplikacija 2 Aplikacija 3 Aplikacija 4

Fajl B

Fajl A Fajl V

Fajl G SUBP SUBP

Aplikacija 1

BPa

BPb

BPb

BPv

Aplikacija 3 Aplikacija 4

SUBP SUBP

BPa

BPb

BPv

DSSBP

Korisnik 2

Korisnik 1

Korisnik N

Subject DatabaseArchitecture Decision SupportDatabaseArchitecture

Slika 3.1 Arhitekture podataka

Arhitektura BP za podr{ku odlu~ivawa: BP su konstruisane za spontano ibrzo traèwe, pretraìvawe, ad-hoc upite i laku upotrebu. Podaci se uglavnomperiodi~no ekstrahuju iz zatvorene BP ili javnog informacionog servisa. Da bise smawio broj ekstrahovawa i osigurala vremensko/sadràjna konzistentnostpodataka, podaci su deqeni na korporativnom, departmentalnom i lokalnom nivou- nema ekstrakcije za pojedina~nog korisnika. Definicije podataka su usinhronizmu sa zatvorenim BP, da bi seliminisala eventualna potreba za„~ista~ima podataka”. Sre}u se kao i sistemi za informaciono pretraìvawe.

Preporu~ena arhitektura je mikstura posledwe dve opcije. Zavisne BP bipodràvale biznis aplikacije, a BP za podr{ku odlu~ivawa bi omogu}ileaplikacije o biznisu. Ova dualna arhitektura ima nadmo} iz slede}ih razloga:

kvalitet podataka, pristupnost i deqewe su maksimizovani, neplanirana redundancija podataka je eliminisana, me|uaplikacijska interakcija je pojednostavqena,


obezbe|ena je standardizacija podataka, produktivnost ìvotnog ciklusa aplikacija je maksimizirana i razvoj novih aplikacija je ubrzan.

Neki dizajneri preferiraju okruèwe gde bi se OLTP i DS potrebezadovoqavale konkurentno iz jedne BP, ~ime bi se eliminisala duplikacija iekstrakcija. Me|utim, ovo okruèwe ima fundamentalno razli~ite inekompatibilne zahteve. Tabela 3.4 sumira glavne ta~ke konflikta.

Operacionalno okruèweZatvorene BP

Aplikacije biznisa

DW okruèweBP za podr{ku odlu~ivawa

Aplikacije o biznisuSadrè veoma detaqne podatkeSadrè celu zatvorenu BPIziskuju ta~nost do posledwe transakcijeKontrolisane, visoko strukturisane iplanirane transakcijeOptimizovane za performantnost,efikasnost i raspoloìvostGrade rigidne strukture podatakaPokre}u biznisIsti~u potrebe svih potencijalnihkorisnikaKratke i konstruisane transakcije

Sadrè detaqne i/ili sumarne podatkeSadrè samo podatke od interesaIziskuju “as of” ta~nostNestrukturisane i ad-hoc transakcije

Optimizovane za fleksibilnost i lakokori{}ewePodràvaju dinami~ke strukture podatakaAnaliziraju biznisIsti~u potrebe svih korisnika

Potencijalno duge i dinami~kidefinisane transakcije

Tabela 3.4 Dihotomije zatvorenih i DS baza podataka

Kada se rutinski pristup operacionalnih BP dodeli DS korisnicima mogunastati veliki problemi:

● Performanse: nepredvidiva priroda ad-hoc upita razbija zahtev predvidivogvremena odgovora operacionalnih sistema. Predvidive i garantovaneperformanse se ne mogu konstruisati u sistemskom dizajnu, ako transakcijenisu predvidive;

● Zadràvawe (retencija) podataka: DS aplikacije ~esto zahtevaju duèzadràvawe podataka za kumulativne analize nego operacionalni sistemi,kojima su podaci potrebni samo za aktivni prakti~ni poslovni ciklus. RastBP moè negativno uticati na performanse, integritet i sposobnost da sezadovoqi bilo koje vremensko ograni~ewe za oporavak;

● Logi~ko rezonovawe: dok se BP dinami~ki mewa sa svakom transakcijom,informacioni upiti nisu ponovqivi i promeweni upiti operi{u nad mo`dapromewenim skupom podataka.

DW je moderan izraz koji se koristi da opi{e zrelo i robusno okruèwe DSbaze podataka. DW su danas primarno samostalne, fizi~ke BP. Moglo bi seanticipirati da sa tehnologijom upravqawa distribuiranim BP, DW }e postatilogi~ke BP koje transcendiraju fizi~ki distribuirane BP za DS.


3.2.4 Kvalitet podataka i metapodaci

DW projekat ~esto po~iwe propagacijom istorijskih podataka, koji traèkontrolu pre~i{}enosti i kvaliteta. U DW u eksploataciji, pre~i{}eni podacipoti~u iz dva procesa: unos (~istih) podataka i pre~i{}avawe podataka po{to suuneti. Proces prikupqawa podataka mora biti vaqano dizajniran. Tako|e, procesunosa podataka mora obezbediti informaciju o kvalitetu. Me|utim, ovi procesise obi~no odvijaju daleko od DW tima i uglavnom nisu pod kontrolom DW tima.Kada se jednom dostigne prihva}enost vrednosti DW, lak{e je posti}i izmeneprocesa unosa u ciqu obezbe|ivawa boqih podataka.

Ne postoji sistem sa perfektnim podacima. U svakoj implementaciji semora definisati individualni standard kvaliteta podataka. Kvalitet podataka senaj~e{}e kontroli{e na globalnom nivou od strane odgovaraju}eg menaxera,po{to je izvr{eno puwewe podataka. Ukoliko za te svrhe nisu raspoloìvi fle{totali, primewuju se kontrole kompletnosti (brojno stawe) i kontroleprihvatqivosti (kqu~na fakta ~ine ekstrapolaciju istorijskih vrednosti).

Naj~e{}e karakteristike kvaliteta podataka su:

ta~nost kompletnot konzistentnost jedinstvenost blagovremenost.

Infrastruktura i metapodaci predstavqaju temeq svih arhitekturalnihelemenata u DW. Infrastruktura podrazumeva hardver, mreù i funkcije niskognivoa i predstavqa osnov za rad komponenata na vi{im nivoima. Metapodacipredstavqaju vi{e eteri~nu komponentu, ali u su{tini obezbe|uju isti vidpodr{ke.

Tako|e, metapodaci su (uz granularnost podataka) od najbitnijih pitawaadministracije BP. Metapodatak je termin koji se koristi da opi{e definicijepodatka sme{tenog u DW - podatak o podatku. Bez metapodataka korisnik nije ustawu da ineraguje sa podacima u DW jer nema znawe o starosti podataka,strukturama tabela, preciznim definicijama podataka, ili koji je izvor podataka.

U konvencionalnim transakcionim okruèwima potreba za metapodacima jezadovoqena postojawem re~nika podataka ili repozitorija. U DW okruèwupotreba za metapodacima je ve}a, jer je od vitalnog zna~aja da korisnik razume {tapodaci predstavqaju. Kod transakcionih sistema je uglavnom dovoqno dainformati~ko osobqe ima uvid u metapodatke. Dodatnu va`nost kod DWpredstavqa ~iwenica da podaci imaju razli~ite izvore (ukqu~uju}i eksterne),koji trebaju biti dobro definisani. Poèqna je da ova dva repozitorija buduintegrisani, ali ne u fizi~kom smislu.

Kаталог metapodataka treba da identifikuje "pedigre" podataka u DW tj.kvalitet, izvor, starost i integritet podataka. To ima znatan uticaj na faktorpoverewa korisnika prema podacima, jer je druga~iji stav prema podacima koji supa`qivo derivirani iz internih izvora u odnosu na podatke iz novinskih ~lanaka.Naravno, validno je imati podatke iz oba izvora sve dokle korisnici znaju zarazliku. Tako|e su bitni detaqi o transformacionom procesu, tako da je mogu}ereverzno inèwerstvo deriviranih i sumarnih podataka u originalne komponente.


Veliku ulogu metapodaci imaju i kod projektovawa korisni~kih aplikacija, jer suupitni alati duboko zavisni od metapodataka (aditivnost ~iwenica i sli~no).

Stepen u kome su podaci raspoloìvi korisniku i lako}a kori{}ewa imajuzna~ajan uticaj na inicijalni uspeh DW. Postoje zna~ajni finansijski razlozi zaulagawe dodatnog napora u dizajn i sme{taj metapodataka. Bez obzira koliko supodaci pre~i{}eni ili kompletni, ne}e biti rezultata ukoliko nisupredstavqeni (na korisni~kom ekranu) u pouzdanoj, razumqivoj i predvidqivojformi.

Katalog metapodataka

Terminolo{ki pojam metapodataka jo{ uvek nije usagla{en i ovde }e seprezentovati samo deskriptivna definicija. Poprili~no rasplinuta definicijave} navedena (podaci o padacima) ne daje jasnu sliku. Pogodno je podelitimetapodatke na one koji se ti~u procesa (ekstrakcija, ~i{}ewe i puwewe) i navi{e opisne (u slu`bi su alata za upite i generatora izve{taja). Procesni iopisni metapodaci se ipak donekle preklapaju. Metapodaci koji omogu}uju da DBAprosledi podatke u DW su verovatno bitni i krajwim korisnicima, po{to sadrèinformaciju o poreklu podataka.

Na Slika 3.2 je dat primer za uloge metapodataka, odakle moè biti jasnoza{to je toliko te{ko dati preciznu definiciju. Metapodaci su poputtradicionalne sistemske dokumentacije (oni i jesu dokumentacija), pa je ~estapojava da budu zapostavqeni. Re{ewe predstavqa pristup koji se zasniva naaktivnim metapodacima. Aktivni metapodaci pokre}u proces, a ne sluè samoza puko dokumentovawe. Dokumentovawe se sada javqa kao nu`na posledica.

Sa slike se uo~ava velika va`nost modela podataka, koji predstavqapo~etnu osnovu i neophodan resurs u kasnijim fazama. Me|utim, katalogmetapodataka ima centralnu ulogu, {to ilustruje ~iwenica da samo 3 od 12interakcija zapravo ukqu~uje podatke - ostalo su metapodaci.

Katalog metapodataka je ukupnost metapodataka koji se koriste u DW.Ponegde se sre}u termini informaciona biblioteka, repozitorijum ili metaBP.U idealnom slu~aju, katalog metapodataka je jedinstvena ta~ka sme{tawainformacija koje pokre}u DW proces. Svaki korak, od inicijalnog modela prekoekstrakcije do navigacije i pristupawa sa ra~unara krajwih korisnika, bikoristio taj katalog. Realno je posmatrati katalog metapodataka kao logi~kukonstrukciju koja egzistira na vi{e fizi~kih lokacija. Alati za katalogizacijumetapodataka su nameweni za upravqawe tako razme{tenim metapodacima,kreirawe udaqenih poziva procedura (RPC) i bezbednost.

Metapodaci mogu imati aktivnu ili pasivnu ulogu u DW. Mogu posluìtikao dokumentacija podataka i procesa, ali mogu biti direktan set instrukcija zate procese. Dokumentaciona uloga obezbe|uje najefektivniji na~in za edukaciju~lanova DW tima i korisnika. Aktivni metapodaci su jedna od kqu~nih crtatehni~ke arhitekture. Kada metapodaci pokre}u procese, to zna~i da procesiprikupqaju informacije (o tabelama. kolonama, procesima i sl.) iz metakataloga,a ne iz COBOL ili SQL koda. Na trì{tu postoji nezadovoqena tra`wa zakvalitetnim metatabelama za agregacione navigatore (bi}e predstavqeni u ta~ki3.5) i ekstrakcione alate.


Slika 3.2 Активни каталог метаподатака

Алат замодело-

вање

физичкимодел

логичкимодел

дефини-ције изв.

статист.упита

послов.групе

статист.пуњења

мапирањаизвор-циљ

Каталог метаподатака

алат заприређи-вање по-

датака

алаткрајњих

кори-сника

изворнисистеми

Data Warehouse

(1) DWмодел

(4) мапирања(8) статистике пуњења

(3) дефиниције табела(5) инфо о мапирању и

трансформацијама

(2) дефини-ције извора

(6) екстрахо-вани подаци

(5) физичке информације(величине табела, ...)

(7) трансформисаниподаци

(11) подаци

(10) упити

(9) по-словниописи(имена исадржајтабела иколона,вредно-сти при-мера,итд.)


Standardi za metapodatke

Metapodaci su vezivno sredstvo unutar DW. Тврдња da je DW nova irazli~ita kategorija softverskog inèwerstva je mahom zasnovana na potrebi zametapodacima. Svaki drugi aspekt DW je na neki na~in ve} vi|en. Trì{te jedobro popuweno alatima za modelovawe podataka, dizajn BP, ekstrakciju, upiteili grafi~ke aplikacije. Primena svih ovih ve{tina u jednom kompleksnomsistemu je veoma izazovna i zahteva specijalne tehnike upravqawa projektom, aline zahteva fundamentalno nova znawa. Upravqawe metapodacima je poprili~nonov koncept.

Posluìlac (stjuart) podataka je nova vrsta informati~kog osobqa, kojaima mnogo {iri opseg dejstva od konvencionalnih administratora DB.Organizacije obi~no imaju nekoliko razli~itih administratora DB za nekolikorazli~itih sistema. Posluìlac podataka je u centru функционисања DSS-a, jer sebavi uprаvqawem metapodacima du` ~itave organizacije. To je potpuno novpristup i u principu ne postoji odgovaraju}i pomo}ni alat.

Replicirawe podataka o podacima je podosta glomazno i nezgrapno. Naprimer, podaci iz izvornih re~nika podataka (~esto COBOL arhive) se morajumanuelno prenositi. Oktobra 1995. je obrazovana Inicijativa za razmenumetapodataka u okviru Saveta za metapodatke, kao odgovor na uo~ene probleme.

Standard za razmenu metapodataka postavqa podelu na aplikacionemetamodele i metamodele metapodataka. Ovo predstavqa interni pogled nametapodatke, koji je potreban posluìocu podataka. Еksterni pogled nametapodatke se obi~no naziva informacioni katalog i predstavqa esencijalnuvezu krajwih korisnika DW i podataka. Moè sluìti samo za listawe (pasivan)ili podràvati i naprednije funkcije (aktivan).

Katalog bi trebao da ima i fizi~ki i logi~ki pogled na podatke, tako dakorisnik moè da lista BP, tabelu i kolone kao i entitete i atribute. Poslovnedefinicije podataka kao i poslovna pravila nad podacima treba da se nalaze ukatalogu.

Pored funkcije listawa, katalog treba da ima funkciju traèwa postringovima i funkciju upita (koja }e selektovane podatke proslediti od DW nalokalni server). Veoma sofisticirani katalozi podràvaju dinami~kopreme{tawe podskupova podataka od DW ka lokalnim aplikacijama, kao imonitoring. U zrelim DW potreba za aktivnim katalogom postaje akutna, koji biuz to imao interfejse od aplikativnog programirawa ka raznim alatima (CASE,repozitoriji, alati za ekstrakciju i upite). Katalog obezbe|uje korisnicima mapuDW okruèwa sa ugra|enim funkcijama.

Kao rezime, moè se re}i da sve informacije u DW okruèwu koje se ne ti~uaktuelnih podataka spadaju u metapodatke. Opseg metapodataka je veoma {irok, saveoma razu|enim formatima i upotrebama. Metapodaci se koriste agresivno iekspanzivno i nije realno o~ekivati da se nalaze u samo jednoj centralnoj BP.


3.2.5 Data Warehouse & Data Mart

Prvi rezultati DW koncepta nisu bili potpuno zadovoqavaju}i. DWprojekti u proseku traju dve do ~etiri godine i ko{taju milione $ (prosek je 3,5miliona i 24 meseca za izgradwu i implementaciju), {to je uticalo na promenupristupa i stvarawe distribuiranih DW. Osnovna modifikacija se sastojala upronalasku jednostavnijeg, jeftinijeg i br`eg puta za dobijawe prvih rezultata.Fokus u takvom pristupu je na aplikacijama i na Data Marts (DM), koji relativnobrzo razvija lokalne i ostrvske baze koje su prvi korak u DW strategiji na nivoucelog poslovnog sistema.

DM je logi~ki podskup DW, dizajniran za upotrebu od strane odre|enihkorisnika ili za odgovore na specifi~na pitawa. DW se odnosi na sve podatke uokviru organizacije, a Data Mart je specificiran za odre|eni department ilibiznis. Treba naglasiti da DW nije samo prosta unija Data Marts, ve} da postojeme|usobne veze i uslovqenosti. Posmatran kao „mali“ DW, DM poseduje dostaosobina DW: prikupqawe podataka iz drugih izvora, podaci su sumirani u read-onlyformatu pogodnom za upite i analize i sl. Prema tome, veliki deo napomena za DWse odnosi i na Data Mart.

Potreba za Data Marts nije o~igledna, po{to zahtevaju dodatni anga`man okopripreme i puwewa podataka. Me|utim, oni obezbe|uju br`e upite u svakomdepartmentu po{to je mawa koli~ina podataka nad kojima se vr{e upiti. DM jeaplikativni sistem za podr{ku odlu~ivawa, koji se gradi zajedno sa poslovnimmodelom podataka predupre|uju}i dezintegraciju DSS sistema, nekonzistentnostposlovnih informacija i nesposobnost rasta i uskla|ivawa sa DW.

Slede}a tabela daje prikaz osnovnih razlika izme|u DM i DW:

Data Warehouse Data Mart

OpsegAplikacija je neutralnaCentralizacija, deqivostNa nivou poslovnog sistema

Specifi~ni aplikativni zahteviOdelewa ili korisni~ka podru~jaPoslovno-procesno orjentisan

Perspektivapodataka

Istorijsko-detaqni podaciPoneka sumirawaDelimi~na normalizacija

Detaqna (neka istorijska)SumiranostVisoka denormalizacija

Subjekt Mno{tvo subjektnih podru~jaJedan subjekatVi{e delimi~nih subjektnihpodru~ja

Izvori podatakaMno{tvoOperativni, eksterni podaci

NekiOperativni, interni podaci

Vremenski okvirimplementacije

9-18 meseci kao prvi stepen (2ili 3 osnovna podru~ja)

4-12 meseci

KarakteristikeFleksibilanPostojanPodatkovno orjentisan

RestriktivanKratkotrajanProjektno orjentisan

Tabela 3.5 Data Warehouse i Data Mart


Izgra|ivawe Data Marts

Data Marts se mogu izgra|ivati po fazama i od strane odvojenih timova.Nezavisni Data Marts se javqaju kada vi{e delova kompanije gradi Data Mart radizadovoqewa svojih izolovanih potreba. U nekim situacijama, separatna izgradwamoè biti dovoqno dobro re{ewe ako ne postoji intencija ka interakciji sadrugim departmentima. Me|utim, to moè spre~iti budu}u integraciju i dodatirazvojne tro{kove ako se pojavi interes za deqewe informacija izme|udepartmenata. Iskustvo pokazuje da se veliki deo vremena mora potro{iti zareparaciju Data Marts, u skladu sa konformiziranim (zavisnim) dimenzionalnimokvirom, pre nego {to se mogu uspe{no ukqu~iti u DW.

Zato se preporu~uje izgradwa zavisnih Data Marts. Data Warehouse Busdozvoqava paralelan razvoj poslovnih Data Marts, sa mogu}no{}u wihoveintegracije. Glavni zadatak DW tima je identifikovawe i formirawekonformnih dimenzija, koje omogu}uju tu integraciju. Matrica za DW Bus se moèuporediti sa sistemskim bus-om u ra~unaru. Svaka dimenzija je konektor iliprovodnik koji provodi standardni (tj. konformni) „signal“. Svaki poslovniproces je dodatna kartica koja se prikqu~uje na odgovaraju}e mesto.

Globalno se Data Mart gradi po jednoj od tri osnovne metode, uz mogu}evarijacije:

● Od gore na dole, gde se iz eksternih i/ili internih okruèwa podaci najpreizvla~e, transformi{u i prosle|uju u DW, a zatim se ti isti podaci drugimpostupkom izvla~ewa, transformacije i slawa koriste za gradwu Data Mart-a.

● Od dole na gore, gde se podaci iz internog i/ili eksternog okruèwapretraùju, transformi{u i zatim prosle|uju direktno grade}i DM. Iz tih sezatim podaci ponovo pretraùju, transformi{u i prosle|uju grade}ikompleksni i jedinstveni DW.

● Kombinovana metoda, trenutno i najpopularnija, gde DM imaju znatan stepensamostalnosti, a pravilno modelirawe }e sa~uvati integritet DW.

Velika organizacija treba da ima 10 do 30 Data Mart-ova. Data Mart treba dapredstavqa visok poslovni nivo. Mawe broj od 10 ukazuje da su definicije DataMarts neopravdano {iroke i da }e biti te{ko ovladati celim sistemom.

DM moè prekriti neki drugi DM. Na primer, DM sa vi{e izvora podataka(Obra~un Profita) moè prekriti jednoizvorni DM (Obra~un Rashoda).

Postoje dva tipa Data Marts: sa atomarnim podacima i sa agregatnimpodacima. U principu izme|u wih nema razlike, ali se ~esto sme{taju u razli~iteSUBP na razli~itim platformama. Zavisno od poslovnih zaheva, veli~ine DW, ialata koji se odaberu, mogu se koristiti oba ili samo jedan od ovih tipova.


3.3 DIMENZIONO MODELOVAWE

3.3.1 Smisao i svrha dimenzionog modelovawa

Dimenziono modelovawe zna~ajno podiè performanse nekog DSS-a; ta~nije,disciplina dimenzionog modelovawa je najboqi na~in modelovawa podataka zapodr{ku odlu~ivawa. Prezentovawem informacija u formatu koji prativi{edimenzionalno poslovno okruèwe, ono nudi intuitivan model podataka lakza navigaciju.

DW ìvotni ciklus se zasniva na disciplini dimenzionog modelovawa,odnosno ova tehnika logi~kog dizajna je jedina raspoloìva tehnika zadostavqawe podataka krajwim korisnicima u DW. Razumqivost za korisnike,performantnost upita i elasti~nost su bliski, nesuprotstavqeni zahtevi za DW.Dimenzioni pristup, za razliku od E/R pristupa, je pogodan za realizaciju ovihzahteva. Dimenzioni pristup ne zahteva restruktuirawe BP i upita po upisu novihpodataka, odn. kada se relacije izme|u elemenata podataka moraju revidirati.Dimenzioni DataMart, za raliku od E/R DataMart-a, ne treba da anticipirakorisni~ke upite i veoma je otporan i fleksibilan prema promenama ukorisni~kim analizama.

Smisao dimenzionog modelovawa se moè saèti u slede}em:

● dimenziono modelovawe omogu}ava da veoma jednostavan model podatakadefini{e kompleksnu, vi{edimenzionalnu strukturu podataka - omogu}ena jedefinicija hijerarhijskih relacija;

● dolazi do smawewa obima i broja fizi~kih spojeva (performantnost);● jednostavnija je formulacija preciznijih upita, ~ime se smawuje mogu}nost

gre{ke i nepotrebnog angaòvawa resursa (u slu~aju pogre{nih kompleksnihupita);

● postiè se fleksibilnost - rast i razvoj uz razumna angaòvawa sredstava iresursa.

Veza izme|u dimenzionog i E/R modelovawa

Dimenziono modelovawe se u su{tini oslawa na disciplinu koja koristirelacioni model, ali uz neka va`na ograni~ewa. Naime, svaki dimenzioni modelse sastoji od jedne tabele fakata i seta mawih dimenzionih tabela (terminidimenzije i fakti datiraju iz kasnih sedamdesetih godina, a prvi su ih koristiliGenerall Mills i Darmouth University).

Pored toga, osnovno pravilo je da se jedan E/R dijagram razlaè na vi{edimenzionih dijagrama. Veliki E/R dijagram reprezentuje sve mogu}e poslovneprocese u organizaciji. Me|u tim procesima sigurno postoje neki, koji nikad nekoegzistiraju u jednom skupu podataka u jednom trenutku vremena. S toga je prvi


korak u konvertovawu E/R dijagrama separacija u diskretne poslovne procese imodelovawe svakog tog procesa ponaosob.

Drugi korak je selektovawe onih N:M relacija u E/R modelu koje sadrènumeri~ka i aditivna nekqu~na fakta, i imenovawe tih relacija kao tabelafakata. Tre}i korak je denormalizacija preostalih tabela u flat (ravne, fiksne)tabele sa jedno~lanim kqu~em, koje su povezano direktno sa tabelom fakata.

Slika 3.3 prikazuje jednostavan dimenzioni model podataka.

Slika 3.3 Dimenzioni model podataka

Svrha dimenzionog modelovawa

Sledi pregled najosnovnijih pote{ko}a pri radu sa E/R modelima podataka:

● krajwi korisnici ne mogu da razumeju ili zapamte E/R model, ne mogu davr{e navigaciju tog modela i ne postoji GUI koji preuzima generalni E/Rmodel i ~ini ga upotrebqivim za krajwe korisnike

● softver ne moè da upotrebqivo vr{i upite nad E/R modelom - tro{kovnioptimizatori koji su nameweni za tu svrhu listom prave pogre{ne izbore,sa grubim uticajem na performanse

● upotreba E/R modela je u kontradikciji sa osnovnim namenama DW

Dimenzioni model ima odre|eni broj va`nih DW prednosti. Prvo,dimenzioni model predstavqa predvidiv, standardni okvir rada. Generatoriizve{taja, alati za upite i korisni~ki interfejsi su mnogo razumqiviji i obradaje mnogo efikasnija. Primera radi, skoro sva ograni~ewa koje je zadao krajwikorisnik poti~u od dimenzionih tabela, i alat krajweg korisnika moèobezbediti visoko-performantni browsing (listawe) atributa u okviru dimenzijezahvaquju}i upotrebi bit-vektorskog indeksirawa. Predvidivost tako|eobezbe|uje znatne prednosti u samom procesirawu. Umesto da se koristetro{kovni optimizatori, potrebno je prvo sprovesti zadato ograni~ewe naddimenzionim tabelama i potom odjednom zahvatiti celu tabelu fakata sakartezijanskim proizvodom (onih kqu~eva dimenzione tabele koji zadovoqavaju

Vreme Zemlja

NamenauvozaRežim

Izvoz--uvoz

DDK

Valuta

Vrstaposla

Roba


korisni~ka ograni~ewa). Za~udo, ovim pristupom je mogu}e re{iti proizvoqno n-tostruko spajawe sa tabelom fakata u jednom prolazu kroz indeks tabele fakata.Uvreèno je mi{qewe da su n-tostruki spojevi previ{e zahtevni, tako da ~itavageneracija DBA nije uvidela da je problem n-tostrukog spoja formalnoekvivalentan jednostrukom sortirawu.

Drugo, neo~ekivane promene u pona{awu korisnika vi{e nisu problem. Svedimenzije su ekvivalentne i mogu biti posmatrane kao simetri~no ravnopravneulazne ta~ke u tabelu fakata. Logi~ki dizajn moè biti izvr{en skoro nezavisnou odnosu na o~ekivane obrasce upita. Korisni~ki interfejsi su simetri~ni, kao{to su i strategije upita i generisani SQL.

Tre}e, dimenzioni model je elegantno pro{iriv za slu~aj neo~ekivanonovih elemenata podataka i novih dizajnerskih odluka. To zna~i da podaci nemoraju biti kompletno obnavqani. Tako|e, to zna~i da alati za upite iizve{tavawe ne moraju biti reprogramirani. Kona~no, stare aplikacije seizvr{avaju bez pruàwa kontradiktornih (razli~itih) rezultata. Mogu}i tipovipromena su:

1. dodavawe novih nepredvi|enih fakata2. dodavawe kompletno novih dimenzija3. dodavawe novih nepredvi|enih dimenzionih atributa4. razlagawe postoje}ih dimenzionih slogova na niè nivoe.

êtvrto, postoji zna~ajan broj standardnih pristupa za rukovawe tipskimsituacijama modelovawa u poslovnom svetu. Svaka od tih situacija poseduje dobropoznat set alternativa koje mogu biti specifi~no isprogramirane. Evo nekihmogu}ih situacija pri modelovawu:● lagano mewawe dimenzija, kada se „konstantna dimenzija“ kao Preduze}e ili

Zemqa u stvari razvija sporo i asinhrono● heterogeni produkti, kada recimo banka ima potrebu da prati nekoliko

razli~itih linija biznisa zajedno (u jednom zajedni~kom setu atributa ifakata), ali u isto vreme treba da opi{e i vrednuje individualne poslovnelinije (na visoko idiosinkrati~nom nivou, koriste}i nekompatibilne fakte)

● BP pla}awa unapred, gde poslovne transakcije nisu delovi prihoda, ali biznisima potrebu da ima uvid u individualne transakcije kao i u redovan izve{taj oprihodima

● BP usmerena na rukovawe doga|ajima, gde su tabele fakata naj~e{}e factless(„oskudne“).

Peto, ali ne i najmawe bitno, narasta volumen administratorskihpogodnosti i softverskih procesa koji upravqaju i koriste agregate (svaka sredwaili velika DW po pravilu poseduje agregate). Sve navedene prednosti dimenzionogmodelovawa kompletno vaè i za odgovaraju}e multidimenzionalne BP (OracleExpress, Arbor Essbase, Microsoft SQL Server OLAP Component i dr.).

E/R modeli imaju svoje mesto u DW. Oni bi trebali biti kori{}eni u svimOLTP aplikacijama baziranim na relacionim tehnologijama. To je najboqi na~inda se postignu maksimalno mogu}e transakcione performanse i integritetpodataka. Tako|e, mogu}e ih je koristiti u prire|ivawu podataka. Ipak,dimenzioni model je jedina postoje}a tehnika za istovremeno postizawerazumevawa od strane korisnika i performantnost upita u svetlu stalnopromenqivih korisni~kih zahteva.


3.3.2 îwenica: pojam i vrste - tabele ~iwenica

Dimenzioni model se sastoji od ~iwenica (fakata) i atributa. îwenica jene{to {to se obi~no ne zna unapred. Svako poqe sa numeri~kim podatkom,naro~ito ako je u pitawu broj sa pokretnim zarezom, }e u dizajnu biti tretiranokao ~iwenica (~ak i npr. standardna cena, koja se pode{ava do par puta godi{we,nije atribut koji se zna unapred).

Ve}ina ~iwenica u poslovnom svetu su numeri~ke ~iwenice. Poprili~noretko se javqaju tekstualne ~iwenice i tada je preporu~qivo je sme{tati ovakvemere u dimenzije, gde mogu biti efektivnije korelirane sa drugim tekstualnimatributima. Tako|e, bi}e potrebno mawe prostora, naro~ito ako je prvobitnotekstualno poqe u tabeli fakata veliko poqe fiksne duìne (~esto nepopuweno).

Pogodan primer za tekstualna fakta su vemenske prilike koje jeidentifikovao milicioner prilikom uvi|aja, za odre|enu saobra}ajnu nezgodu.Ako bi opis vremena bio slobodan tekst, za sme{tawe u dimenziju bi bilopotrebno kreirati slog za svaku pojedina~nu nezgodu. Opis vremenskih uslova, kaotekstualna ~iwenica, moè biti kori{}en za grupisawe ograni~ewa. Me|utim,po{to je u pitawu slobodan tekst, ove uobi~ajene aktivnosti su tada od malevrednosti. Drugim re~ima, „prave“ tekstualne ~iwenice su neprimerene u DW.

îwenice su mere biznisa koje se retko prezentuju samostalno i s toga jepoèqno da budu savr{eno aditivne (zbrojive). To zna~i da ima smisla sabiratiove ~iwenice du` svih dimenzija. Diskretne numeri~ke mere aktivnosti, kao {toje vrednost izvezene robe ili usluga, su ~esto savr{eno aditivne. Numeri~ke mereintenziteta, me|utim, nemaju tu osobinu. Najva`nije mere intenziteta su stawa nara~unima i zalihama. Ove ~iwenice su prese~na stawa u nekom trenutku vremena iobi~no su aditivne du` svih dimenzija sem vremenske dimenzije - semiaditivnafakta. Za povezivawe je neophodno sabrati ove ~iwenice du` vremena i podelitiih brojem vremenskih perioda (ovo nije isto {to i kori{}ewe SQL funkcijeAVG). Ve}ina bankarskih izve{taja su prose~na dnevna stawa na ra~unima.

Neke numeri~ke mere intenziteta ne mogu biti zbrajane du` ijednedimenzije - nezbrojive ~iwenice. Mere temperature su tipi~ne ~iwenice, alimoraju biti uprose~avane du` svake dimenzije du` koje se vr{i kombinovawetemperatura (prigodno je koristiti SQL funkciju AVG). Nezbrojivaizra~unavawa, kao {to su odnosi poput bruto marginalnih vrednosti, se morajuobavqati kao odnos suma, a ne suma odnosa. Drugim re~ima, izra~unavawa se morajudistribuirati du` suma, a ne suprotnim putem.

„Op{te je prihva}eno da su najboqi i najkorisniji ono fakti koji sunumeri~ki, trajno merqivi i aditivni“ [4], s tim {to aditivnost povla~i prve dveosobine, a obrnuto ne mora da vaì.

Tabele ~iwenica

Tabela ~iwenica (tabela fakata) sadrì numeri~ke mere biznisa - keyperformance indicators (KPI). KPI su u stvari atributi tabele ~iwenica. U strukturidimenzionog modela, tabela ~iwenica je primarna (centralna) tabela. Svaka ovatabela reprezentuje M:N relaciju i sadrì dva ili vi{e stranih kqu~eva, koji jepovezuju sa odgovaraju}im dimenzionim tabelama. Tako|e, svaka tabela koja ima


kompozitni kqu~ je tabela ~iwenica, odnosno svaka tabela koja ne reprezentujeM:N relaciju je tabela dimenzija. Tabela fakata je uglavnom visokonormalizovana, bez duplikacije sadrì svaku jedinstvenu kombinaciju kqu~evadimenzionih elemenata.

Svaka tabela fakata ima odre|eni nivo granulacije, odnosno tokommodelovawa je potrebno odrediti granulu za tabelu fakata. Tabela fakata jerelativno i apsolutno vrlo velika (pri prora~unavawu veli~ine BP dimenzionetabele mogu biti zanemarene). Me|utim, kori{}ewem modernih visokoperformantnih servera i bilo kog industrijskog SUBP, mogu}e je sme{tawe izadavawe upita nad jednom tako velikom tabelom uz dobre performanse.

Veoma je bitno nepopuwavati tabelu fakata nulama za prezentacijunepostojawa poslovnih zbivawa. S toga su uglavnom tabele fakata sparse (retke). Uslu~aju „gustih“ tabela fakata, dostiù se veli~ine ~ak do reda terabajta (1012) itada se mora i}i na kompromisna re{ewa, odnosno na redukciju veli~ine na u{trbdetaqnosti.

Tabele ~iwenica za pra}ewe statusa obi~no imaju poduù listu pomo}nihdatumskih poqa. Jedan od tih datuma treba odabrati za primarni i nad timdatumom }e se naj~e{}e zadavati ograni~ewa. Primarni datum se koristi kaokomponenta glavnog kompozitnog kqu~a tabele ~iwenica.

U principu, ~iwenice su razlog postojawa tabele ~iwenica i kqu~evi susamo administrativno sredstvo za pristupawe tim ~iwenicama. Postoje, me|utim,brojni poslovni procesi za koje po prirodi ne postoje merqiva fakta! Tada se zatakve tabele ~iwenica kaè da su factless (oskudne). Pri tome ~esto dolazi dopojave asimetri~nog i ne~itkog SQL-a, {to se re{ava uvo|ewem ve{ta~kih fakata.Dve osnovne varijacije ovakvih tabela ~iwenica su:

● tabele za evidentirawe doga|aja - na primer, vo|ewe prisutnosti studenata napredavawima ili primqene terapije pacijenata u bolnicama

● reporta`ne tabele - u principu opisuju {ta se nije dogodilo (a ne {ta sedogodilo).

Prvi indeks tabele ~iwenica je B-stablo nad primarnim kqu~em. Ve}inaDW upita su ograni~eni po datumu i datumsko poqe bi trebalo da bude na prvommestu u primarnom kqu~u. Sa datumskim poqem na prvom mestu tako|e ubrzavamoproces izgradwe DW, u kome se inkrementalna puwewa vode po datumu.

Odre|ivawe ostalih indeksa tabele ~iwenica je veoma zavisno od tipovaindeksa (postoje he{ indeksi, bit-mapirani indeksi i drugi) i optimizacionestrategije. U novije vreme, za razre{avawe upita je mogu}e kori{}ewe vi{e odjednog indeksa nad tabelom u isto vreme. Nije vi{e obavezno definisawevi{estrukih kompozitnih indeksa nad tabelom ~iwenica. Lak{e je kreiratijedno~lane indekse nad svakim kqu~em i prepustiti optimizatoru da iskombinujeindekse.

Mogu}e je kreirawe indeksa nad vrednostima ~iwenica (iznosima).Tipi~ni, nekqu~ni indeksi tabele ~iwenica se odnose na jednu kolonu, relativnosu retki i obi~no su mawe upotrebqivi od kqu~nih indeksa.


3.3.3 Dimenzija: pojam i vrste - tabele dimenzija

Dimenzije determini{u mogu}e na~ine organizacije podataka - drugimre~ima, kako bi podaci trebali biti filtrirani, sme{tani i grupisani.Inicijalno, organizacija podataka se zasniva na intervjuima i uzorcima upita(koji se sti~u tokom analize). Potrebno je kreirati dizajn koji organizuje podatkena na~in prilago|en poslovnim korisnicima i wihovom pristupawu timpodacima.

Nezavisno od procesa koji se modeluje, vreme je dimenzija koja je prakti~nouvek prisutna. Svaka DW je vremenska serija i sadrì slojeve podataka sli~nogeolo{kim naslagama. Vremenska dimenzija obezbe|uje istorijski element DW ispecificira podelu vremenskog razdobqa, kao i korisni~ka ograni~ewa povremenu. Tako|e, mogu}e je identifikovati „specijalna vremena“ (radne dane,vikende, praznike, sezone, fiskalne periode i sli~no).

Za efektivno modelovawe dimenzija, neophodno je usaglasiti tri pitawa:

● dimenzione karakteristike,● karakteristike dimenzione tabele i● lagano mewawe dimenzija.

Dimenzione karakteristike

Dimenzione tabele moraju biti dizajnirane uz pomo} poslovnih korisnika isa obzirom na analiti~ku upotrebu. Dimenzije ostaju u relacionim tabelama i,kao takve, sastoje se od kqu~a i pomo}nih atributa. Trebale bi da sadrè visokokorelirane atribute, vrlo kvalitetne op{irne tekstualne informacije,razdvojena imena i elemente adrese, i ve{ta~ki kqu~.

Svi atributi su vrlo povezani sa odre|enim entitetom. Na primer, svipodaci u dimenzionoj tabeli za preduze}e su podaci o preduze}u.

Da bi atributi bili laki i upotrebqivi za korisnika moraju imati slede}ekvalitete:

● deskriptivnost - na primer, ime atributa MaticniBroj radije nego PriKey● potpuno razvijene re~i ili kratke fraze, a ne kodovi ili skra}enice -

BrojRegistracijeDDK pre nego BrRDDK● osiguran kvalitet - bez nepostoje}ih ili nula vrednosti, eliminisane slovne

gre{ke ili nevaè}e ili zastarele vrednosti.

Va`no je da su poqa podeqena na svoje najjednostavnije elemente. Evo nekihpreporuka:

deqewe imena:o osoba - recimo ime, sredwe slovo (ili puno o~evo ime), prezime,

titula i sufiks (ml., MD, III);o organizacija - ime organizacije (Ledewak), podime (Pogon za

osvetlewe), drugo podime (Odeqewe za pla}awe); deqewe adresa - na primer, ku}ni broj, ulica, broj stana ili apartmana, mesto,

republika ili okrug, po{tanski broj, zemqa i dr.


Razdvojeni elementi omogu}uju ve}u fleksibilnost u upitima, ukqu~uju}i:

o podr{ku za internacionalne po{tanske idiosinkrazijeo personalizaciju u prepiskamao podr{ku za upite nad geografskim oblastima.

Umesto da se koriste vrednosti kqu~eva iz izvornih sistema, trebalo bigenerisati jedinstvene vrednosti za identifikaciju upisa u dimenzione tabele.Najjefikasnije je koristiti jednostavne, sekvencijalne numeri~ke vrednosti. Toobezbe|uje slede}e pogodnosti:

● nezavisnost u odnosu na izvorni sistem, koja onemogu}ava slede}e pote{ko}e:o modifikacija aplikacija moè iziskivati promenu strukture kqu~ao izvorna aplikacija moè ponovo koristiti isti kqu~

● efikasnije za indeksirawe.

Ostali tipovi dimenzija

Postoje atributi kojima je nepogodno ili nemogu}e rukovati pomo}ustandarnih ili deqenih tipova dimenzija. Ovde }e biti obra|ena dva specijalnatipa dimenzija.

Degenerisane dimenzije reprezentuju poslovni doga|aj u tabeli fakata.Degenerisane dimenzije su kontrolni dokumenti kori{}eni za upravqaweposlovnim doga|ajima i detaqima tih doga|aja. Takva kontrola omogu}ava mo}nijeizve{tavawe na nivou poslovnog doga|aja.

Na primer: poslovni doga|aj se moè sastojati od poruxbenice, dostavnice,ili otpremnice. Kontrolne vrednosti u tim doga|ajima (poput broja dostavnice,broja poruxbenice ili broja otpremnice) su vi{eg nivoa granularnosti negoaktuelna stavka, tako da vi{e nego jedan slog u tabeli fakata mora imati istukontrolnu vrednost.

Degenerisane dimenzije:

● nisu dimenzioni kqu~evi ili delovi aditivnih numeri~kih fakata● nemaju odgovaraju}u dimenzionu tabelu, odnosno dati elementi primarnog

kqu~a tabele ~iwenica nije podràn u vidu postojawa odgovaraju}edimenzione tabele

● nisu strani kqu~evi● ne trebaju biti odba~ene i zanemarene● sadrè kontrolne vrednosti koje ostaju po{to su svi slogovi poslovnih

doga|aja definisani za svaku dimenziju.

Kontejnerske dimenzije sa~iwavaju atributi koji nisu u vezi sa poslovnimobjektima kori{}eni za definisawe drugih dimenzija. Kori{}ewe ovihspecijalnih dimenzija omogu}ava eliminisawe indikatora i atributa iz tabelafakata i sme{tawe u upotrebqiv dimenzioni model. Takvo izme{tawe omogu}avaprikupqawe va`nih informacija, bez pove}awa veli~ine tabele fakata.


Kontejnerske dimenzije se mogu kreirati iz slede}ih izvora:

● kombinovani indikatori i tekstualni atributi iz izvornih sistema koji nisuu vezi sa ni jednom utvr|enom informacionom (ne vremenskom) dimenzijom

● atributi koji su va`ni za biznis i koji ina~e mogu biti iskqu~eni iz {eme.

Pri kreirawu ovih dimenzija, mogu}e je:

● popuwavati ih utvr|ivawem pojave za svaku jedinstvenu kombinaciju vrednosti- postiè se kreirawem svih mogu}ih kombinacija vrednosti, ali uz oprezprema mogu}no velikom broju slogova

● popuwavati ih kreirawem pojave za svako pojavqivawe sloga - umestoutvr|ivawa svih mogu}ih kombinacija vrednosti, mogu}e je vr{iti kreirawa zakombinacije koje postoje i aùrirati nove kombinacije kako se pojavquju;me|utim, mogu}a je potreba za dodatnim resursima za umetawe novih slogova udimenzije

● dodavawe ve{ta~kog kqu~a.

Konformne dimenzije

Jedna od opasnosti u iterativnom implementirawu DataMarts je mogu}nostgra|ewa analiti~kog okruèwa koje nije integrisano. Definisawem svihdimenzionih tabela na op{tem nivou pre kreirawa finalnih {ema, obezbe|eno jeda svaki DataMart moè koristiti fakte u svakom DataMart. Deqene dimenzije kojese odnose na dve poslovne oblasti ili na dva DataMart se zovu konformne dimenzije.Kori{}ewem konformnih dimenzija, komparacije du` DataMarts dobijaju nazna~ajnosti.

Konformne dimenzije imaju slede}e karakteristike:

● zajedni~ke za vi{e osnovnih {ema● ustanovqene na nivou organizacije● kori{}ene u dizajnu svih {ema● omogu}avaju upite nad razdvojenim {emama● dozvoqavaju kreirawe integrisane i obuhvatne DW.

Slika 3.4 prikazuje upro{}eni DW Bus.

Karakteristike dimenzionih tabela

Dimenzione tabele imaju zajedni~ke karakteristike, koje omogu}avajuwihovo lak{e definisawe. Pri definisawu dimenzionih tabela, treba sepridràvati nekoliko glavnih napomena.

Dimenzione tabele imaju primarni kqu~, koji se prostire i ima osobinujedinstvenosti du` cele tabele. Preporuka je da se koristi jedno~lani ve{ta~kikqu~. Treba izbegavati komponovane kqu~eve. U slu~aju promene aplikacija i sl.,pojavi}e se nekompatibilnost sa prethodnom strukturom kqu~a.

Dimenzione tabele su u 1:N relaciji sa tabelom fakata. Svaki zapis udimenzionoj tabeli je u vezi sa vi{e odgovaraju}ih zapisa u tabeli fakata.


Dimenziona tabela poseduje bar jednu deskriptivnu kolonu (koloneatributa). Deskriptivne kolone se koriste za kvalifikaciju korisni~kih upita,kori{}ewem asociranih primarnih kqu~eva za traèwe relevantnih slogovafakata. Kolone atributa obezbe|uju razli~ite nivoe agregacije du` dimenzionihhijerarhija, kao i kategorizaciju podataka koji se ne mogu organizovatihijerarhijski.

Dimenzione tabele poseduju skup slogova koji se pove}ava lagano tokomvremena. Pove}avawe DW odn. DataMart se de{ava prvenstveno usled upisa u tabelufakata. Slogovi dimenzionih tabela bi trebalo da budu dodavani prvenstveno kaododatni atributi za datu dimenziju.

Slika 3.4 DW Bus

3.3.4 Modeli podataka u DW

Fundamentalna ideja dimenzionog modelovawa je da skoro svaki tipposlovnog procesa moè biti reprezentovan u vidu kocke podataka. Tada }elijekocke sadrè merqive vednosti, a ivice kocke defini{u prirodne dimenzijepodataka. Po{to je dozvoqeno postojawe vi{e od tri dimenzije, tehni~ki je mogu}naziv hiperkocka. Realni dimenzioni modeli u poslovnom svetu obi~no imajuizme|u 4 do 15 dimenzija.

Prezentovani dimenzioni model se u praksi naj~e{}e naziva modelzvezdastog spoja. Zvezdasta {ema je osnovna arhitektura dimenzionog modela.Sledi pregled bitnijih karakteristika zvezdaste {eme:

Dimenzije

VremeValutaVrsta PoslaRobaNamenaZemljaInokreditor

KOI

DKL

D

b

W

u

s


● Denormalizacija dimenzija - osnovna karakteristika vi{edimenzionalnihmodela podataka.

● Dimenzioni elementi - predstavqaju zasebne nivoe u dimenzionoj hijerarhiji.Najniì nivo se zove osnovni element, a svaki naredni nivo sjediwuje podatkena prethodnom i prosle|uje ih slede}em vi{em nivou. Hijerarhijske relacijedu` dimenzionoh elemenata obezbe|uju drill-up i drill-down.

● Referencijalni integritet - svaki strani kqu~ u tabeli ~iwenica mora imatiodgovaraju}u pojavu u nekoj dimenzionoj tabeli. Primarni kqu~ tabeledimenzije je osnova za refencijalni integritet.

● Spojevi - „spojevi u dimenzionoj {emi BP imaju va`niju ulogu nego u E/R {emiBP“ [10]. Obi~no postoji samo nekoliko spojeva u dimenzionoj BP i svaki odwih predstavqa fundamentalne relacije u odgovaraju}em biznisu.

● Filteri - retko ima smisla i retko je mogu}e primeniti ograni~ewesimultano du` dve dimenzije, ~ime bi se direktno povezale te dve dimenzije.Dimenzije su povezane iskqu~ivo preko tabele ~iwenica. Ograni~ewadefinisana nad samom tabelom fakata se zovu filteri.

Ne prosle|uju sve dimenzione hijerarhije podatke uniformno. Zgodanprimer su vremenske dimenzije, gde se prosle|ivawe po sedmicama i mesecimavr{i odvojeno - mesec se ne moè podeliti ta~no na sedmice, pa se podaci ne moguprosle|ivati od sedmica ka mesecima. Tako|e, od meseca se moè prosle|ivati nakvartale, a od sedmica ne moè. Zbog toga ova dimenzija ima vi{e puteva sumacije -re~ je o kompleksnoj hijerarhiji.

[ema pahuqice

Zvezdasta {ema ili kako se jo{ naziva, {ema sa konsolidovanimhijerarhijama ima slede}e nedostatke:

● denormalizovana {ema moè iziskivati previ{e prostora na disku● veoma velike dimenzione tabele mogu uticati na performanse, posebno na

koristi postignute agregacijom.

[ema (sne`ne) pahuqice je zvezdasta {ema sa normalizovanim dimenzionimtabelama, nazvana tako zbog dodatne strukturne kompleksnosti. Poqa sa malimkardinalitetom se izme{taju u odvojene tabele i povezuju se sa originalnomtabelom pomo}u ve{ta~kog kqu~a. Svaka dimenziona tabela ima jedan kqu~ zasvaki elemenat dimenzione hijerarhije. Kqu~ najnièg nivoa spaja dimenzionutabelu sa tabelom fakata; taj kqu~ (ili neki drugi) tako|e spaja dimenzionutabelu sa tabelom atributa, koja sadrì opisne informacije za najniìdimenzioni element. Ostali kqu~evi spajaju dimenzionu tabelu sa odgovaraju}omtabelom atributa.

Normalizovawe dimenzionih tabela smawuje redundantnost i potrebanprostor. Nesumwivo je da }e ve{ta~ki kqu~ potreban za nove spojeve, koji je upraksi uvek kra}i od tekstualnog poqa koje smewuje, dovesti do o~uvawa prostorana disku. Na primer, u BP od 500000 slogova u{teda (postignuta normalizacijom)od 2 MB po slogu daje ceo GB diska. Tako|e, u nekim situacijama, ova {ema moèbiti znatno brà od zvezde.


Spoj u {emi pahuqice je najvredniji za dimenzije u kojima:

● postoji mnogo slogova (10 000 - 1 000 000)● postoji mnogo atributa sme{tenih na niskim nivoima dimenzione

hijerarhije, a prostor na disku je deficitaran● postoje agregacione tabele na vi{im dimenzionim elementima i mnogo

upita koji pristupaju podacima na tim nivoima.

U principu se ova {ema ne preporu~uje, jer se uzima da ne dovodi dosignifikantnih u{teda u prostoru. Na primer, ako se u tabeli od 250000 slogovazamene imena duìne 15 bajta sa kqu~evima od 2 bajta, dobi}e se 3,25 MB {to je upraksi obi~no oko 0,03%. Tako|e, smawuje se razumqivost za korisnike,ugroàvaju se performanse browsing-a i onemogu}ava se kori{}ewe nove iupotrebqive klase bitmap indeksa (koji interno za potrebe upita vr{e odre|enenormalizacije).

S toga je u praksi veoma ~esta parcijalna pahuqica, koja kombinujedimenzije zvezde i pahuqice u jednu {emu. Tada neke dimenzione tabele sadrè sveidentifikacije i atribute, dok druge sadrè samo identifikacije koje se spajajusa izdvojenim tabelama atributa. Efikasno je smestiti podatke o najnièm nivouu samu dimenzionu tabelu, dok vi{i nivoi svoje sumarne informacije mogu imati utabelama atributa.

Treba se dràti strukture zvezde, dok god ne postoje jaki razlozi za„pahuqu“. Za razvijene aplikacije, pahuqa nije problemati~no kompleksnija odzvezde. Me|utim, za korisni~ki generisane (ad hoc) upite, kompleksniji modelpodataka stvara mnoge pote{ko}e. S toga je najboqe normalizovati jednu ili dvedimenzije.

Optimizovawe izvr{ne strategije upita u dimenzionim modelima

Dana{wa generacija relacionih SUBP poseduje odre|eni stepennestabilnosti pri procesirawu upita nad zvezdastim spojem. Treba izbe}isituacije u kojima se procesiraju neke dimenzione tabele, potom tabela ~iwenicai na kraju preostale dimenzije. To obi~no zna~i da SUBP zapisuje neki podskuptabele ~iwenica na disk i potom testira taj podskup u odnosu na preostaledimenzije, slog po slog. Time bi upit trajao 10 do 100 puta duè nego {to bitrebalo. To bi se de{avalo ~esto ako optimizator proceni da su ograni~ewa nadnekim dimenzijama previ{e slaba ili previ{e komplikovana. Tada DBA imaulogu da nekako navede optimizator na pravilno postupawe, {to je sve ukupnoveoma nerealno.

Optimizacione strategije }e biti pod su{tinskim uticajem razvojavi{epristupnih kompozitnih indeksa za tabele ~iwenica. Generalno, mada svakiupit nad {emom zvezde ima skoro isti oblik SQL-a, zna~aj ograni~ewa nadrazli~itim dimenzijama }e veoma varirati. Poenta optimizacije je da se uo~i kojiod brojnih mogu}ih skupova dimenzionih kqu~eva moè biti upotrebqen zanajefikasniji pristup tabeli ~iwenica.

Postoje dva bitna skupa dimenzionih kqu~eva u ovim upitima. Prvi je skupkombinacija kqu~eva dimenzija pod korisni~kim ograni~ewima. Grubo gledano,


taj skup je kartezijanski proizvod svih kqu~eva separatno generisanih od stranedimenzionih ograni~ewa. Dodatno se mogu uo~iti korelacije izme|u dimenzijaradi redukovawa skupa pre pristupawa tabeli ~iwenica. Drugi skup dimenzionihkqu~eva je definisan od same tabele fakata, iz odgovaraju}ih indeksa. Najprostijaevaluaciona strategija je posmatrawe prvog skupa i pojedina~no uparivawe uindeksu tabele fakata. Kompleksnija strategija uo~ava momenat kada prvi skupnadrasta listu kqu~eva u tabeli ~iwenica, kada je uparivawe pogodnije usuprotnom smeru. Mogu} je i sofisticirani pristup koji kombinuje ove dvestrategije.

Najefikasniji na~ini, koji stoje na raspolagawu DBA, za kontroluperformansi DDW su korektan optimizator i agregaciona strategija.Prevazi|eno relaciono shvatawe je da }e SUBP otkriti relacije izme|u dvetabele koje se pojavquju u upitu i da }e potom odrediti na~in na koji }e one bitiprocesirane. Sada postoji mali broj tabela, sa predeterminisanim relacijama kojene moraju biti otkrivane hiqadama puta dnevno. Po{to su te tabele stati~netokom dana (izme|u dva puwewa), moè se izbe}i kreirawe skupih stati~kihindeksa koji pomaù upite.

U praksi optimizatori dovode i do 60 puta boqih performansi. MnogiRSUBP ne sadrè optimizatore zvezdaste {eme, zbog toga {to strategija iziskujekartezijanski proizvod izme|u nepovezanih dimenzionih tabela. Teoretski,kartezijanski proizvod je nepovoqan, ali u slu~aju upita nad {emom zvezde, mnogoje efikasniji nego spajawe dimenzionih tabela kroz tabelu fakata pojedina~no.Neki RSUBP koji podràvaju ovu optimizaciju iziskuju specijalne postupkeindeksirawa, dok drugi imaju algoritam za procenu primenqivosti optimizacije.


3.4 FAZE PROCESA OBLIKOVAWA DIMENZIONEBAZE PODATAKA

Postoji devet glavnih ta~aka odlu~ivawa pri oblikovawu dimenzione BP,tokom kojeg se vr{i stalno preispitivawe kvaliteta (zadovoqavawe potreba) ijednostavnosti DW. U tim ta~kama odlu~ivawa defini{u se:

1. procesi i identiteti tabela ~iwenica koje slede2. granulacija svake tabele ~iwenica3. dimenzije svake tabele ~iwenica4. ~iwenice5. dimenzioni atributi (opisi i terminologija)6. pra}ewe laganog mewawa dimenzija7. agregacije, heterogene dimenzije, minidimenzije, modovi upita i sl.8. istorijsko trajawe BP9. urgentnost ekstrakcije i unosa podataka.

Prva ~etiri pitawa spadaju u logi~ki dizajn, a preostalih pet u fizi~kidizajn BP. Faze logi~kog dizajna su po~etne, kqu~ne i ovde }e biti detaqnorazmatrane. Ponekad se ta ~etiri koraka nazivaju metodologija dizajnaindividualne tabele ~iwenica. Pitawa fizi~kog dizajna ne}e biti detaqnoanalizirana, ali }e u nastavku teksta biti re~i i o wima.

Korake u procesu dizajna dimenzione {eme je najboqe posmatrati ukontekstu dizajnirawa jednog OLAP Data Mart. Prednost ovakvog posmatrawa jejednostavnost, jer su koraci pri kreirawu DW u su{tini isti. U svakoj od ~etiriglavne faze posmatraju se razli~iti faktori i procesi.

3.4.1 Izbor poslovnog procesa za modelovawe

Poslovni proces je skup (set) poslovnih aktivnosti koje imaju smisla zaposlovnog korisnika DW. Ova definicija nema veliku upotrebnu vrednost, pa }ese smatrati da je poslovni proces upotrebqivo (korisno) grupisaweinformacionoh resursa sa koherentnom temom. U mnogim slu~ajevima seimplementira jedan ili vi{e DM za svaki poslovni proces. Stoga se u literaturi[25] se ova faza naziva korak definisawa OLAP Data Mart.

Izbor Data Mart u najjednostavnijem slu~aju je ekvivalentan odabiru izvorapodataka. Treba izbegavati idealizovane dizajne koji modeluju podatke kakvi bitrebali da budu, umesto kakvi jesu. Uobi~ajeno je da Data Mart ima jedan izvornisistem, dok se u kompleksnijim slu~ajevima defini{u Data Marts koji ukqu~ujuvi{estruke izvorne sisteme. Najboqi primer ove kompleksnosti jeprofitabilnost, gde se kombinuju sistemi koji se odnose na prihode sa onima kojise odnose na tro{kove.

Definicioni proces je esencijalni deo ukupnog razvoja i on bi trebao da:

● bude utvr|en tokom procesa prikupqawa zahteva,


● bude ograni~en na jedan diskretan poslovni proces - to dovodi dopojednostavqewa ekstrahovawa zahteva, smawuje rizik i promovi{e brzinurealizacije i

● utvrdi zahtev za trajawe.

Istorija je fundamentalni aspekt DW, ali nije neophodno ista za sve {e-meunutar jedne DW. Trajawe se odnosi na opseg istorije koji }e se nalaziti u ta-beli~iwenica. Obi~no bi trajawe trebalo biti bar dve godine (ova godina vs pro{lagodina), dok je gorwa granica sedam do deset godina. Istorijski podaci sa duìmtrajawem mogu biti problemati~ni (pa i nemogu}i) za ekstrakciju, na-ro~ito akose nalaze na vi{e platformi. Naravno, tokom razvoja i eksploataci-je se moèukazati potreba za mewawem inicijalno planiranog trajawa.

3.4.2 Izbor nivoa granulacije poslovnog procesa

Obavezno je utvrditi detaqnost pra}ewa, odnosno koliko „duboko” }e senalaziti centar dimenzionog modela. Atributi fakata moraju biti pa`qivoodabrani, jer su oni baza za sve donete odluke. Granularnost tabele ~iwenica }eodrediti konfiguraciju atributa fakata, odnosno sve odluke u fazama tri i~etiri - „deklarisawe granularnosti je ekvivalentno iskazivawu {ta jeindividualni slog tabele ~iwenica” [1]. Kapacitet sistema (sme{tajni iprocesorski) i korisni~ke potrebe odre|uju granularnost i trajawe ~iwenica.

Stepen sumarizacije koji se odabere za tabelu ~iwenica ima fundamentalniuticaj na DW. Najniì mogu}i nivo detaqnosti je sme{tawe fakata na atomarnomtransakcionom nivou. To je isti nиvо detaqnosti kao na izvornom sistemu.Sme{tawe ~iwenica na atomarnom transakcionom nivou ima zna~ajnu prednostizgradwe sposobnosti za „burgijawe” do detaqa, u svakom trenutku vremena. Tako|epostoje i neki zna~ajni nedostaci. êsto je neprakti~no ili ~ak nemogu}eposedovati toliko mnogo podataka, a detaqni podaci ponekad samo usporavajuupite, јер ve}ina upita ukqu~uje neki stepen sumarizacije. Sme{tawe ~iwenica naodre|enom sumarnom nivou reducira iznos podataka koji je potrebno posedovati,ali elimini{e neke nivoe detaqnosti iz analize.

Granula ili rezolucija tabele ~iwenica odredi}e dubinu do koje bilo kojaanaliza nad {emom moè biti na~iwena. Treba imati u vidu da су svi atributi~iwenica u nekoj tabeli ~iwenica у korelацији sa specifi~nom ta~kom u vremenu.Slede}i argumenti ukazuju da ipak treba i}i na {to niè nivoe granulacije:

● robusnost dizajna je direktno srazmerna fino}i granulacije, tj. pove}ava seizraàjnost i vi{e dimenzija ima smisao,

● mogu} je boqi odgovor na neo~ekivane zahteve korisni~kih upita sa niìmnivoima granulacije i

● {ema je prilagodqivija prema uvo|ewu novih ~iwenica, novih dimenzijaili novih atributa u okviru poсtoje}ih dimenzija (nema potrebe zamewawem postoje}ih administrativnih procedura, upita i izve{taja).

S obzirom na brojnost i raznovrsnost zahteva pri deklarisawugranularnosti, realno je o~ekivati da }e u nekom momentu dizajna qudi iz DWtima uvideti potrebu za promenom detaqnosti ~iwenica. Ukoliko transakcioni


sistem korektno vodi podatke na nekom detaqnijem nivou, dodavawe detaqa }eimati zna~ajan efekat na izbor dimenzija i ~iwenica u slede}e dve faze. Ovoukazuje da se uvek mora imati ~ista slika o izabranoj granularnosti ciqne tabelefakata.

Osnovni tipovi ~iwenica

Transakcione ~iwenice су zasnovane na jednoj pojavi poslovnog doga|aja. ipredstavqaju najniì mogu}i nivo granularnosti. Transakcione ~iwenice imajuveoma jednostavnu strukturu, obi~no sa samo jednom merom - iznosom transakcije.Kontekst sledi iz forme kqu~a transakcije.

Transakcione ~iwenice su najprisutniji tip u praksi, na primer:● individualni telefonski poziv,● pojedina~na prodaja,● otplata rate kredita.

Snapshot (fotografske, prese~ne) ~iwenice absorbuju stawe biznisa uodre|enoj ta~ki vremena, kao {to je kraj smene, dana, meseca itd. Ove ~iwenice sune{to sloènije strukture. Sadrè sume ili ve{ta~ke vrednosti mera i ne morajuse odnositi na sve dimenzije (na primer, kada nisu svi proizvodi prodavani svakogdana). Tako|e, ovde se mogu na}i i semiaditivne ~iwenice.

Snapshot ~iwenice prakti~no nastaju od operativnih transakcija. Me|utim,u nekim slu~ajevima nije re~ samo o prostoj agregaciji - za kalkulaciju prihoda jevrlo bitna struktura transakcija depozita i naplate.

U op{tem slu~aju, postoji istovremena potreba i za ovim i zatransakcionim tipom ~iwenica (ali da se ne nalaze u istoj tabeli). Tipi~niprimeri snapshot ~iwenica su dnevno proveravawe ravnoteè ra~una ili mese~naprodaja proizvoda.

Stavke su ~iwenice koje se koriste za sme{tawe detaqnih informacija oelementima poslovnog dokumenta. One reprezentuju individualne stavke koje seodnose na poslovne doga|aje i sadrè sve mere te stavke (koli~inu, prodajnu cenu,tro{kove i druge). Odgovaraju}a tabela ~iwenica ima vi{e datumskih kqu~evakoji predstavqaju rali~ite faze kroz koje prolazi stavka. Tako|e, u tabeli je~esto potrebno postojawe dimenzije statusa za stavke. Kona~no, ~iwenice stavkise aùriraju ~e{}e nego ostali tipovi, zato {to u principu imaju dugu istoriju.

Primeri su stavke poruxbenica, otpremnica i polisa osigurawa.

îwenice doga|aja ili stawa - to su specijalizovani tipovi ~iwenica kojireprezentuju pojavu doga|aja, ali ne i detaqe doga|aja. One tako|e reprezentujupromene stawa i upotrebqive su pri analizama koje ukqu~uju i aktivnost ineaktivnost za odre|ene dimenzije. Na primer: „Proizvodi koji su bili napromociji, ali nisu bili prodavani danas”. îwenice doga|aja ili stawa suoskudne (factless) jer nemaju meru. Me|utim, vrednost 1 se ~esto koristi zaolak{avawe upita.

Ne treba kombinovati granularnost ili periodi~nost individualnihatributa tabele ~iwenica. Izme{anost granulacija u tabeli fakata moèdovesti do nekonzistentnih odgovora.


Pretpostavimo da tabela ~iwenica sadrì i dnevne i mese~ne vrednosti, ada upit ekstrahuje dnevne totale. U zavisnosti od odabranog atributa, bi}eizra~unate razli~ite sume. Ako su kori{}eni samo dnevni atributi dobi}e sekorektna suma, a ako su kori{}eni jedan ili vi{e mese~nih atributa bi}eizra~unata pove}ana suma. Granula tabele treba da pripada iskqu~ivo jednom odpobrojana ~etiri tipa!

3.4.3 Izbor dimenzija koje }e biti primewene na svaki zapistabele ~iwenica

Izbor dimenzija je kqu~ni korak u dizajnu. Za vreme odre|ivawa identitetadimenzija zanemaruje se eventualni problem obezbe|ivawa dimenzionih atributa.

Kada je utvr|ena granularnost ~iwenica, izbor dimenzija je dosta logi~an iprirodan. Na primer, minimalni set dimenzija za stavku pla}awa sadrì datumpla}awa, kupca, robu i specijalnu degenerisanu dimenziju koja se sastoji samo odbroja naloga. Granulacija je ~esto formulisana u terminima primarnih dimenzija,a ostale dimenzije se mogu lako proveriti u odnosu na granularnost, ~ime se dautvrditi wihova smislenost. Ukoliko ne postoji poklapawe dimenzije igranularnosti, mogu}a su dva glavna izbora: eliminisawe dimenzije iz razmatrawaili promena deklarisane granularnosti.

Postoje dodatne dimenzije koje nisu striktno uzrokovane odlukom ogranularnosti tabele ~iwenica. Te dimenzije (kao datum isporuke, uslovi ugovorai status) dodaje dizajner ako postoje odgovaraju}i izvori. Dodavawe dimenzija nemewa broj slogova u tabeli fakata i ono nije potrebno za definisawe primarnogkqu~a, ali veoma doprinose mo}i date tabele fakata. Dodavawe dodatnihdimenzija je lako i zato {to ne mewa prethodno utvr|enu granulaciju tabele~iwenica.

Najboqe dimenzije su one koje imaju jednu vrednost u kontekstu datog skupamera. U tom kontekstu, najboqe je pridruìti najniì nivo te dimenzije koji jo{uvek ima osobinu o jedinstvenoj meri. Merama na nivou dana je mogu}e pridruìtigodinu kao dimenziju, ali nije smisleno.

Pridruìvawe vi{evrednosnih dimenzija je mogu}e, ali tada je te{korealizovati korisne izve{taje i upite du` M:N relacija. Potrebno je kreiraweM:N tabela mostova izme|u dimenzione tabele i tabele ~iwenica, uzodgovaraju}e alociraju}e ili teìnske ~iwenice.

Ovakav pristup dimenzionom modelovawu, uslovqen merama, olak{avaodlu~ivawe ako nov deskriptivni podatak postane dostupan. Ako je taj podatakjednovrednosan (u navedenom smislu), potrebno ga je samo pridruìtiodgovaraju}im merama. Na primer, ako postoje dnevni podaci o nekom geografskompodru~ju, veoma je jednostavno dodati vremenske podatke (pridruìvawem kqu~aovih podataka u listu kqu~eva u tabeli ~iwenica). Nije potrebno redefinisaweili mewawe bilo koje tabele ili aplikacije.

Svaka dimenzija ima svoju granularnost. Granularnost individualnedimenzije ne moè biti nià od granularnosti tabele ~iwenica. Mogu}a jeprimena „grubqe” dimenzije. Na primer, na~in isporuke robe moè biti vazdu{niili kopneni, iako se odgovaraju}e ~iwenice odnose na odre|eno prevozno sredstvo.Analogno tome, dimenzija proizvoda se moè voditi po grupama proizvoda, dok se~iwenice odnose na pojedina~ne proizvode. U oba slu~aja dolazi do gubitka


korisnih informacija za krajwe korisnike, ali sam dizajn ne sadrì logi~kukontradikciju.

Sve re~eno o konformnim dimenzijama vaì i na ovom mestu. Tako, mesecnaplate nije isto {to i kalendarski mesec, pa ih separatne tabele ~iwenica kojekoriste te dve interpretacije vremena moraju ozna~iti kao razli~ite dimenzije.Ako jedna dimenzija, kao poslovni entitet, egzistira na dva ili vi{e mesta,verovatno je u pitawu slu~aj sa vi{estrukim ulogama (rolama). Te uloge trebajedinstveno imenovati i tretirati ih kao odvojene dimenzije.

Kada se jednom izabere dimenzija, mogu}e je postojawe velikog brojadeskriptivnih atributa koji mogu biti kori{}eni za izgra|ivawe dimenzije. Ovideskriptivni atributi mogu dolaziti iz razli~itih izvornih sistema. Na tommestu, u ovoj fazi dizajna, korisno je napraviti dugu linearnu listu svih znanihdeskriptivnih atributa raspoloìvih za opisivawe dimenzije (roba, usluga,zemqa, ili dan).

Ciqevi ove faze dizajna su obuhvatnost, iscrpnost i op{irnost. Detaqioko preuzimawa i kvaliteta podataka se re{avaju tokom dizajna implementacionefaze.

3.4.4 Izbor ~iwenica koje }e biti primewene u svakom zapisutabele ~iwenica

Posledwi korak je dodavawe {to je vi{e mogu}e ~iwenica u kontekstudeklarisane granulacije poslovnog procesa. Naime, kao {to odre|uje izborprimewenih dimenzija, izbor detaqnosti omogu}ava izbor individualnih fakatakao i opseg (scope) tih fakata. U slu~aju transakcione tabele ~iwenica, ve} jespomenuto da obi~no postoji samo jedna ~iwenica, nazvana iznos transakcije.Snapshot tabele ~iwenica imaju otvoren broj ~iwenica, jer bilo koja sumaaktivnosti tokom datog perioda dolazi u obzir i moè se dodati u skup ~iwenica(ako se pokaè korisnom). Tabele ~iwenica stavki tako|e moè imati nekoliko~iwenica jer, na primer, individualna stavka moè biti razloèna na koli~ine,bruto vrednosti, razlike, popuste, neto iznose i poreze.

Ukoliko se, za potrebe lak{eg izra~unavawa, pojave ~iwenice iz drugihvremenskih perioda ili agregacija, neophodno je da ostanu u izdvojenim slogovimau izdvojenim tabelama ~iwenica. U ovoj fazi dizajna treba odloìti detaqnorazmatrawe administracije kqu~a (kqu~ }e, naravno, biti ve{ta~ki).

Dok jedan atribut moè postojati u iskqu~ivo jednoj dimenziji, ~iwenica semoè ponavqati u nekoliko tabela ~iwenica. Svaka ~iwenica uglavnom imaodre|ena pravila agregacije (suma, minimum, maksimum, semiaditivna, specijalanalgoritam i neagregibilna). Ne}e svaki alat za upite i izve{taje biti umogu}nosti da vr{i pozive kompletne liste tehnika agregirawa, ali navedenomoè posluìti kao lista zahteva pri evaluaciji alata.

U slu~aju problema sa ~iwenicama razli~ite granularnosti, jedan odpostupaka je i tzv. procedura alocirawa ~iwenica sa vi{eg nivoa na niì nivo.Tipi~an primer je alocirawe tro{kova, gde se recimo ulaè napor da setro{kovi prevoza alociraju do nivoa stavke, iako ovaj proces ukqu~uje odre|eni


stepen kompromisa i protivre~nosti. Ukoliko se u dizajnu alokacija tro{kova neizvr{i uspe{no, javqaju se slede}e pote{ko}e:

● Dizajn {eme izve{taja profitabilnosti, koji kombinuje prihode itro{kove, bi}e komplikovaniji zbog prisustva vi{estrukih tabela~iwenica na razli~itim nivoima granulacije.

● Situacija moè biti dodatno oteàna ako su mere tro{kova prevoza prostostandardi i koeficijenti koji se ne odnose ni na specifi~nu otpremnicu,nego postoje na regionalnom ili dràvnom nivou.

● Jo{ ve}i problem se javqa ako su tro{kovi alocirani na poruxbenici,~ime je nemogu}e izvr{iti analizu profita i gubitaka (P&L analiza).

Idealno je da se kompletna alokacija izvr{i od strane finansijskogdepartmenta, a ne od strane DW tima. DW tim ne bi trebao da gubi vreme i energijuna ove aktivnosti, jer je u ve}ini organizacija uvelike utvr|ena potreba zaracionalnim alocirawem tro{kova. Ova funkcija je kompletno nezavisna od DWtima i ponegde se sre}e pod imenom „Pra}ewe tro{kova zasnovano naaktivnostima“.

Ukoliko je alokacija nemogu}a, tada je obavezno ve} spomenuto izdvajawe~iwenica na vi{em nivou detaqnosti, naj~e{}e u vidu agregata (samostalno iliukqu~ivawem u postoje}e).

êst je slu~aj poslovnog pra}ewa procesa sa vi{estrukim jedinicama mere.Tada izvesna koli~ina moè imati nekoliko mogu}ih ekonomskih vrednosti(valuacija). Ovu situaciju ~ioni sloènijom eventualno postojawe vi{efundamentalnih koli~inskih fakata u svakom slogu fakata.

Zamislimo da postoji jedanaest fundamentalnih koli~inskih fakata, devetjedinica mere i tri vrednosne {eme [1]. U tom slu~aju, pogre{no je smestiti 11fakata u tabelu ~iwenica i prepustiti korisnicima ili aplikacijama da traèodgovaraju}i konverzioni faktor u odvojenim dimenzionim tabelama (naro~itoako upit sam po sebi ne nalaè spojawe ovih tabela). Tako|e je pogre{nosme{tawe sve 132 o~ekivane kombinacije ~iwenica (11*9 + 11*3) u svaki slogglavne tabele ~iwenica. Korektan kompromis je kreirawe odgovaraju}eg fizi~kogsloga sa 11 koli~inskih ~iwenica, 8 konverzionih faktora jedinice mere (po{tosu osnovne ~iwenice ve} predstavqene u jednoj od jedinica mere) i 3 valuacionafaktora - ukupno 22 ~iwenice.

Kona~no, sme{tawe ovih faktora u tabelu fakata reducira pritisak saodgovaraju}e dimnzione tabele za kreirawe novih slogova koji }e reflektovatiminorne promene u faktorima. Ovi faktori (posebno ako se rutinski mewaju uvremenu) vi{e spadaju u ~iwenice nego u dimenzione atribute.

Data tabela ~iwenica se prezentuje korisnicima u vidu jednog ili vi{epogleda. Najobuhvatniji pogled }e prikazivati sve 132 kombinacije, ali jeo~igledno mogu}e pojednostaviti korisni~ki interfejs za proizvoqnu korisni~kugrupu, tako {to bi se samo zahtevani faktori (mera i valuacija) prikazali tojkorisni~koj grupi.


3.5 AGREGIRAWE

U prethodnim glavama implicitno podrazumeva da su atomarni podacidobri, uz aproksimaciju da su sva poqa {irine 4 bajta. Atomarnost zna~ikori{}ewe najmawih mogu}ih nivoa granulacije (transakcija u produkciji ilistavka kontrolnog dokumenta). Sa predloènim nivoima granulacije, relativnoslobodniji upit nad jednom ili vi{e dimenzija }e obuhvatiti veoma veliki brojslogova, {to moè imati odre|ene negativne konsekvence.

3.5.1 Pojam i svrha agregirawa

Agregirawe pripada domenu tehni~kog dizajna, gde su bitna pitawaveli~ina rezultuju}e BP i performanse rada. Naime, zbog velikog brojatransakcija na najnièm nivou u arhitekturi DW, za podatke kojima se ~estopristupa je preporu~qiva presumarizacija. Agregirawe je proces u kome se podacinièg nivoa sumiraju i sme{taju u posredne (agregatne) tabele. Agregatni slog jeuvek povezan sa jednim ili vi{e slogova agregatne dimenzione tabele.

Primeri agregata:

agregat roba na nivou grupe proizvoda po zemqi po danu (jednosmerniagregat)

agregat zemaqa na nivou regiona po robi po danu (jednosmerni agregat) mese~ni agregat po robi po danu (jednosmerni agregat) agregat roba na nivou grupe proizvoda po regionu zemaqa po danu

(dvosmerni agregat) agregat roba na nivou grupe proizvoda po regionu zemaqa po mesecu

(trosmerni agregat).

Agregati su jedno od najefektivnijih sredstava za kontrolu performansiDW. Agregatne tabele omogu}avaju anticipaciju korisni~kih upita i ukidajupotrebu za ponavqawem obimnih ra~una. Ukoliko se du` neke od dimenzija nezahtevaju veoma detaqni podaci, tj. ukoliko se zbrajaju ili jednostavnoizostavqaju, primena agregata moè dovesti izme|u deset do sto (pa i hiqadu) putapoboq{anih performansi.

Slede}a pogodnost koju donose agregati je ta, da se za wih moè garantovatikorektnost. Samo odre|eni korisnici i ~lanovi DW tima mogu kreirati iaùrirati agregate i/ili definisati grupe u okviru agregata. Na primer,definicija likvidne banke moè biti o~igledna svim analiti~arima, ali jerizi~no da svaki korisnik kreira tu grupu svaki put kada se radi analiza.

Agregati i indeksi

Po mnogo ~emu, kreirawe i kori{}ewe agregata je u sli~no sa kreirawem ikori{}ewem indeksa. Kao i indeks, agregat je struktura podataka koja poboq{ava


performanse i zahteva administraciju. Dodatna sli~nost je u tome {to se obakoriste ukoliko su raspoloìvi, ali i ako ne postoje sistem opet funkcioni{e.

Agregati imaju vrlo interesantan uticaj na indekse. Mudar odabir agregataznatno smawuje pritisak za indeksirawe tabele fakata. Pretpostavimo postojawekompozitnog indeksa, koji se sastoji od kqu~eva tri tabele dimenzije. Taj indeksse uobi~ajeno koristi od strane SUBP u slu~aju ograni~ewa po sve trikomponente. U slu~aju ograni~ewa po prve dve komponente, ve}ina SUBP radikorektno.

Me|utim, u slu~aju da se izostavi druga ili prva komponenta dolazi doklasi~nog konflikta. U prvom slu~aju se koristi samo prva komponenta indeksa, au drugom je neophodno pretraìvawe kroz celu tabelu (SUBP nije u stawu dakoristi indeks). Tada se uglavnom ide na kreirawe drugog indeksa. Problem je {tosu u DW kompozitni indeksi nad tabelama fakata veliki balast. U tipi~nomslu~aju sa 4 ili mawe fakata, kompozitni indeks moè iznositi 80% veli~inetabele fakata. Slede}i indeks bi zauzeo jo{ toliko, {to povla~i zahtevnoadministrirawe.

Agregati u principu re{avaju taj problem. Treba imati u vidu da upit kojinema ograni~ewe nad nekom dimenzijom u su{tini vr{i sumirawe du` cele tedimenzije. Tako|e, prakti~no svaki upit nad tabelom fakata u DW je traèwesume, minimuma, maksimuma, proseka i sl. Za sumirawe du` cele dimenzije trebakoristiti agregat. Tako da vaì slede}e: labavo ograni~ewe (ili nepostoje}e) u osnovnoj tabeli fakata je u stvari

rigorozno ograni~ewe u agregatnoj tabeli fakata, i dovoqno je kreirati samo jedan kompozitni indeks nad tabelom fakata, dok

sortirawa koja iskqu~uju neka dimenziona ograni~ewa se reguli{u separatnimagregatnim tabelama.

3.5.2 Kreirawe agregata

Odabir agregata

Odre|ivawe {ta }e se agregirati se zasniva na slede}im aktivnostima:

• uvid u poslovne zahteve

• uvid u statisti~ku distribuciju podataka (gustinu podataka)

• revizija svake dimenzije radi utvr|ivawa koji atributi se mahom koriste zagrupisawe

• uvid u kori{}ewe kombinacija tih atributa

• broj vrednosti atributa koji su kandidati za agregaciju.

Ako dati dimenzioni element predstavqa veliki broj redova u odnosu nadruge elemente hijerarhije, agregacija po tom elementu je jako poèqna, i obrnuto.Ako se dimenzije kombinuju ova analiza postaje sve komplikovanija, ali i svezna~ajnija. Definisawe zahteva za podacima apomo}u vi{estrukih dimenzijasmawuje obim i gustinu podataka koji se angaùju. Inicijalna lista agregata kojebi trebalo kreirati se formira neposredno po zavr{etku modelovawe podataka,dok su korisni~ki zahtevi jo{ sveì.


Razvijawe plana agregatnih tabela

Potrebno je ste}i uvid u stepen razre|enosti podataka. Razre|enost(raspr{enost) je fenomen, koji dovodi do toga da agregacija uzrokuje ~akdesetostruko ve}a uve}awa osnovne veli~ine BP od o~ekivanih. Tipi~an primer jeslu~aj da se samo 10% roba proda u odre|enoj dràvi odre|enog dana. U slu~aju dasvaka roba pojedina~no (ili dovoqno "raspr{eno") pripada razli~itoj grupiproizvoda, dolazi do faktora pove}awa koji su naro~ito dramati~ni za dvosmernei trosmerne agregate.

Sve se ovo dovodi da se BP pove}a npr. ne za 50% ve} 500%, iako se svedimenzije pove}aju sa mawe od 30%. Fenomen retkosti je te{ko ta~no predvideti,ali je sigurno da se (u odre|enom stepenu) uvek javqa pri agregirawu. O~iglednore{ewe je pa`qivo kreirawe agregata. Veoma je bitno obezbediti da prose~anagregat u svakoj dimenzionoj tabeli sumira bar 10%, a poèqno je 20% i vi{eslogova.

Procesirawe agregata

Izgradwa agregata se sastoji iz dva koraka koji bi mogli biti neefikasniako bi se odvijali unutar SUBP. Prvo, agregirawe uvek ukqu~uje operacijusortirawa. Sortirawe moè biti mnogo brè van SUBP pomo}u specijalizovanogpaketa za sortirawe, nego unutar SUBP kori{}ewem ORDER BY klauzule u SQL.Drugo, krucijalni korak u kreirawu agregata je traèwe odgovaraju}eg ve{ta~kogkqu~a agregata ili mo`da ~ak dodavawe novog ve{ta~kog kqu~a (ako se agregatnije pojavqivao ranije). Logika ovih operacija je jednostavna, ali spada usekvencijalnu obradu (a ne relacionu).

Kqu~evi agregata su po definiciji ve{ta~ki. Drugim re~ima, ne postojebar-kodovi za grupe proizvoda. Iz istih razloga iz kojih se ne koristeprodukcioni kqu~evi na granularnom nivou u DW, ne treba ih koristiti i priagregaciji. Pre ili kasnije, zahtevi koji se odnose na produkcione kqu~eve }epo~eti da divergiraju u odnosu na zahteve za DW kqu~eve.

Veoma je bitno da agregati budu sinhronizovani sa osnovnim podacima usvakom trenutku vremena. Ako se osnovni podaci aùriraju on-line, a pri tom sejavqa ka{wewe u aùrirawu agregata, onda se stari agregati moraju staviti vanupotrebe dok novi ne postanu spremni. Ina~e, agregati ne}e korektno odslikavatiosnovne podatke. Tada DBA bira izme|u odga|awa publikovawa podataka (dok se nekompletiraju i svi agregati) i privremeno degradiranih performansi (rad saosnovnim podacima dok agregati ne budu spremni).

Administracija

Kreirawe agregata iziskuje zna~ajne administrativne aktivnosti. Zarazliku od slogova na osnovnom nivou (gde uglavnom sistem administrirakqu~eve), obi~no DW tim samostalno kreira i odràva kqu~eve agragata.

Ove kqu~eve je potrebno kreirati samo za nove dimenzione elemente kao{to su grupe roba, regioni ili meseci. Tabela fakata, naravno, samo koristi te


kqu~eve (kao i kqu~eve na osnovnom nivou) u raznim varijantama, po{to je onaprirodno steci{te stranih kqu~eva.

Kqu~eve bi verovatno trebalo sekvencijalno generisati, po tipu. Tada bikqu~evi grupe roba pripadali intervalu 10000-19999, dok bi kqu~evi regionabili u 20000-29999, i tome sli~no. Kqu~evi bi bili jednokratno dodeqivani, {tobi ukupno omogu}ilo odvojenu administraciju.

Ova administracija je pojednostavqena ako je svaki tip agregata urazli~itoj tabeli fakata. âk i ako su bazni kqu~evi kompleksni i derivirani odnekog alfa koda sa 11 mesta, agregacioni kqu~evi su ~isti i celobrojni jer nemoraju da ostanu u istim tabelama kao bazni kqu~evi.

Agregati su dinami~ki resurs u okruèwu DW. Oni koji se ne koriste mogubiti brisani, ~ime se osloba|a prostor na disku i pojednostavquju prate}iprocesi.

U principu, treba planirati pove}awe sme{tajnog prostora za 100% usledagregirawa. Ako je suma agregatnih tabela mawa od 25% veli~ine osnovnih tabela,verovatno je da su performanse oborene. Ako je suma nekoliko puta ve}a odosnovnih tabela, verovatno se neke agregatne tabele ne koriste, a one najve}e suverovatno na nivou koji je suvi{e blizak osnovnom.

3.5.3 Tehnike skladi{tewa agregata

Postoje dve glavne tehnike skladi{tewa dodatnih fakata i slogovadimenzionih tabela za agregate. One imaju skoro identi~an uticaj na ukupnoskladi{tewe podataka i administrirawe kqu~eva, ali veoma razli~ito uti~u naaplikacije i povla~ewe podataka.

Postupak sa kreirawem novih tabela fakata

Svaki agregat ima svoju tabelu fakata. Te tabele fakata su izvedene izglavne tabele fakata. Svaka tabela fakata mora biti u spoju sa jednom ili vi{eizvedenih tabela dimenzija.

Izvedene tabele dimenzija su obi~no drasti~no reducirane u odnosu naoriginalnu. Izostavqaju se svi atributi nivoa koji se agregiraju. Tako|e, svidimenzioni atributi koji preostanu u agregatnim dimenzionim tabelama se moguefikasnije koristiti u agregacionoj {emi, nego u osnovnoj {emi. Kreiraweagregatnog sloga tabele fakata iziskuje kreirawe novog ve{ta~kog kqu~a (koji nepostoji u osnovnoj tabeli fakata), za svaku dimenziju koja se agregira. Ina~e jeslog agregatne tabele fakata istovetne strukture kao slog osnovne table fakata.Obi~no je DW tim odgovoran da, tokom ekstrakcionih procesa, izvr{i kreiraweve{ta~kih kqu~eva.

Iako se moè pojaviti veliki broj agregatnih tabela fakata, ipak je dobrorazdeliti agregate u separatne iz slede}ih va`nih razloga:

● ne postoji mogu}nost duplog ra~unawa od strane aplikacije ({to je mogu}e udrugoj tehnici), jer se svaki upit izvr{ava nad podacima uniformnegranularnosti


● u dobro dizajniranom DW, krajwi korisnici i kreatori aplikacija ne}e videtite agregatne tabele; oni ne}e biti optere}eni odre|ivawem da li }e i koje }eagregatne tabele biti kori{}ene za izvr{ewe upita

● odvojeni tipovi agregata mogu biti kreirani, obarani, puweni i indeksiraniodvojeno kad su u odvojenim tabelama, {to pru`a inkrementalni stilupravqawa; agregati su modularni, segmentirani i mogu se odvojenoizgra|ivati

● kori{}ewe separatnih tabela ne iziskuje vi{e kategorija agregata nego {toiziskuje alternativni pristup (isti je broj agregatnih slogova, agregatnihtipova i novih agregatnih kqu~eva)

● metatabele koje opisuju agregate su jednostavnije nego u drugom pristupu● izbor agregatnih dimenzionih kqu~eva je ne{to jednostavniji u ovom pristupu● maksimalna {irina poqa za brojeve je lak{a za upravqawe, odnosno izbegava

se potreba da se veli~ina poqa svih fakata prilago|ava izuzetno velikimagregiranim vrednostima (npr. na nivou nacionalne ekonomije), ~ime se {tedina prostoru

● jednostavnost reduciranih dimenzija, koje se kreiraju za potrebe odre|enihagregata (i tabele ~iwenica mogu biti reducirane).

Postupak sa poqima koja ukazuju na nivo

Drugi pristup je kori{}ewe poqa za nivo u odgovaraju}oj dimenzionojtabeli, {to omogu}ava da agregatni slogovi ostanu u originalnoj tabeli fakata.Ovaj pristup kreira isti broj agregatnih slogova kao prvi pristup, i zahtevagenerisawe istog broja agregatnih kqu~eva u dimenzionim tabelama i tabelamafakata. Jedina razlika je mesto sme{tawa slogova fakata, koji kao i odgovaraju}islogovi dimenzija ostaju u originalnoj tabeli. Ovaj pristup je {irokokomercijalno zastupqen u softverima za analizu maloprodaje.

Dodatno poqe nivoa opisuje agregatni nivo svakog sloga u tabeli dimenzije.Originalni slogovi imaju Nivo = Bazni, a novi agregatni slogovi npr. Nivo =Region. Agregatni slogovi treba da imaju kqu~eve koji su kompatibilni saoriginalnim kqu~evima. Poqa koja nemaju smisla za agregatne slogove imaju nullvrednost, odnosno „NA“ ili „Total“.

Najozbiqniji aplikacioni problem je mogu}nost duplog brojawa, koji sejavqa u slu~aju izostavqawa ograni~ewa na odre|enu vrednost poqa Nivo. Ako seovo poqe koristi u vi{e od jedne dimenzije, ograni~ewe je potrebno u svakojtakvoj dimenziji. S toga se preporu~uje prvi pristup.

3.5.4 Agregaciona navigacija

Do skoro, prisustvo agregata je komplikovalo rad programera iadministratora. Iako je bilo o~igledno ubrzawe upita, SQL je morao da „zna“ zaprisustvo agregata i da ih specifi~no referencira. To je iziskivalo mewawekoda upita (naj~e{}e uz FROM i WHERE klauzulu) - tzv. diskontinuitetaplikacija. Tako|e, i pri promeni strukture agregata, svi alati krajwihkorisnika, generatori izve{taja i aplikacije su morali biti revidirani. To jebio jedan od uzroka „agregacionih eksplozija“ u prvim danima DW.


Navedena dva fenomena su uzrokovala razvoj novog sloja softvera izme|uaplikacija krajwih korisnika i SUBP. Taj novi softver je nazvan agregacioninavigator, a imao je ulogu da presretne SQL krajweg korisnika i transformi{e gatako da optimalno iskoristi raspoloìve agregate. Pri tome, alati krajwihkorisnika, generatori izve{taja i aplikacije su zadràvali svoj izvorni SQL.DBA je u stawu da dinami~ki prilago|ava agregate, bez da mora da pretraùjeaplikacionu bazu. Arhitektura agregacionog navigatora je prikazana na slede}ojslici:

Slika 3.5 Архитектура агрегационог навигатора

Svi korisni~ki klijenti upravqaju komunikaciju ka navigatoru. Sa ta~kegledi{ta krajwih korisnika, navigator je mre`ni server. Wima se ne dozvoqavadirektan pogled na stvarni SUBP. Agregacioni navigator sa~iwava specijalnemetapodatke sa opisom trenutnog profila agregatnih tabela. Tako|e, pratistatistiku upita krajwih korisnika i pokazuje koji agregati se koriste, a koje bitrebalo napraviti sa ciqem ubrzawa uo~enih dugotrajnih upita.

Funkcija agregatnog navigatora je da transformi{e korisni~ki SQL u SQLkoji je „svestan“ agregata. Potom navigator komunicira sa stvarnim SUBP, kojimu vra}a rezultat upita spreman za prosle|ivawe krajwem korisniku.

Agregacioni navigator pripada mreì, a moè biti poseban ~vor ili senalaziti na istoj ma{ini sa SUBP. Verovatno }e iz komercijalnih razloga drugavarijanta preovladati u praksi. Bitno je da se navigator ne nalazi na ra~unarukrajweg korisnika. Svi alati krajwih korisnika, generatori izve{taja iaplikacije treba da transparentno „profitiraju“. Ipak, spomenuto lo{ijere{ewe se moè ponegde na}i u prakti~noj primeni.

прерађени SQL

агрегирани резултати

агрегациониметаподаци

& корисничкастатистика

рачунар крајњег корисника+

клијент апликација+

мрежни драјвер

мрежни сервер+

агрегациони навигатор+

мрежни драјвер

мрежни сервер+

СУБПподаци

+агрегати

oсновни SQL

агрегирани резултати


Inkrementalno razvijawe agregata

Osnovna tabela fakata i sve odnosne agregatne tabele fakata se grupi{u ujednu familiju {ema, tako da navigator zna koje su tabele u relaciji. Svaka {emau familiji predstavqa jedan zvezdasti spoj. Ovo su ujedno i jedini metapodaci uovom dizajnu, tako da treba eliminisati proizvode koji iziskuju komplikovanijuadministraciju za te svrhe.

Agregacioni navigator sa svojom statistikom upita omogu}ava da DBAperiodi~no pode{ava portfolio agregata. Agregacije se mogu dodavati ioduzimati. Tako|e, mogu se mewati granice agregirawa.

Agregati angaùju resurse za svoju rekalkulaciju. Jednostavno reagregirawesumirawem po tabeli fakata nije uvek opcija. Mogu}e je aùrirawe agregatazasnovano na dolaze}im atomarnim podacima - inkrementalno aùrirawe.

Navigaciona strategija

Sledi jednostavan algoritam za odabir najboqih agergacionih tabelafakata i dimenzija:

1. poredaj sve agregatne tabele fakata po veli~ini u neopadaju}em redu (baziranona broju redova)

2. za prvu (najmawu), proveri u sistemskom katalogu poklapawe poqa koja zahtevaupit i poqa u tabeli fakata i u odgovaraju}oj dimenzionoj tabeli; ako se svapoqa mogu na}i, postupak je uspe{no okon~an i samo treba zamenitioriginalna imena tabela sa agregatnim

3. izbaci tabelu fakata iz spiska i ponovi korak 2; ako je lista iscrpqena, nakraju ostaju osnovne tabele koje }e uvek zadovoqiti upit - algoritam jekona~an.

Ovaj algoritam ne zahteva posebno komplikovane metapodatke za opis samihagregata. Nije potrebna kompleksna logika modelovawa, jer lista tabela fakatatreba da sadrì samo jo{ i imena kqu~nih poqa, odnosno informaciju da postojereducirane tabele.

Mogu}a je modifikacija algoritma za alternativni postupak skladi{tewaagregata. Potrebno je proveravati vednosti odgovaraju}ih poqa u dimenzionojtabeli i videti da li su u wima stvarne ili agregirane vradnosti. Jedini na~in zaizbegavawe ovog zametnog traèwa u dimenzionoj tabeli bi bio izgradwasloènijih metatabela, koje bi sadràle tu informaciju. U velikim tabelama sa150 atributa, svih 150 atributa bi trebalo reprezentovati. Tu strukturu biaùrirao DBA ili „pametna“ aplikacija. To je jo{ jedan razlog favorizovawapristupa sa separatnim tabelama fakata, gde se traèwe obavqa direktno usistemskim tabelama i to samo egzistencijalno, a ne vrednosno.

Ukoliko se odgovaraju}i pozivi ka SUBP ne odvijaju dovoqno brzo (pardesetinki sekunde), algoritam moè postati neprihvatqiv. Tada se sistemsketabele drè u agregacionom navigatoru, izbegavaju se pozivi ka SUBP, ali samnavigator postaje sloèniji. Mora biti sposoban da ~ita i upisuje komplikovane


konfiguracije sistemskih tabela, kao i da povremeno proveri promewenost tihtabela u SUBP.

Alogritam ima i odre|ena ograni~ewa. Pretpostavqeno je da upit nadzvezdastim spojem referencira maksimalno jednu tabelu fakata. U slu~aju spajawavi{e tabela fakata, SUBP bi verovatno izgubio kontrolu nad performansama.Me|utim, gotovo da ne postoji korisni~ki alat koji omogu}ava zadavawe takosloènih upita, pa rizik u stvari ne postoji.

Drugo ograni~ewe je da agregacija mora biti „kompletna“. Opisanaarhitektura u ovoj glavi ne dozvoqava da se izgrade agregati samo za neke npr.grupe proizvoda. Agregacioni navigator odlu~uje da li agregatna tabela moèbiti upotrebqena, iskqu~ivo na osnovu postojawa atributa grupa proizvoda uagregatnoj dimenzionoj tabeli. Ako postoji, podrazumeva se da agregatnadimenziona tabela i odgovaraju}a tabela fakata podràvaју svaki upit nadvrednostima grupe proizvoda. Algoritam navigacije bi morao biti znatnoposlo`wen za slu~ajeve podskupova vrednosti.

Agregati i planirawe

Vrlo ~esto se na nivoima na kojima se odvija agregirawe, vr{i i planirawei prognozirawe. Jedan od ciqeva ve}ine DW je upore|ivawe planova i stawa.Veoma je pri tom efikasno ako su izra~unavawa u okviru jednog sloga. Pogodno jetada, da se uz „aktuelne“ agregatne podatke na|u i odgovaraju}i prognosti~ki iplanski podaci. To tehni~ki nije problem, a odgovaraju}a aplikacija bi vr{ilaodgovaraju}a upore|ewa podataka.

Za ove potrebe se agregacioni algoritam komplikuje jer se u koraku 2pojavquju poqa koja ne postoje na osnovnom nivou. Interfejsi krajwih korisnikamoraju „znati“ ta poqa, jer npr. ako korisnik poèli upore|ivawe podataka nanièm nivou (na kome nije izvr{eno planirawe), sistem }e odbiti zahtev.

Ukoliko planske i/ili agregatne tabele imaju dodatne dimenzijekombinovawe nije mogu}e, tj. potrebna je bijekcija odgovaraju}ih dimenzionihtabela.


3.6 IZGRA\IVAWE DATA WAREHOUSE

Na Slika 3.6 je prikazan pristup ìvotnog ciklusa (BDLC - BussinessDimensional Life Cycle) u izgradwi DW. Dijagram opisuje vi{enivoski procesdizajnirawa, implementacije i razvoja DW.

Slika 3.6 Dijagram poslovnog dimenzionog ìvotnog ciklusa

Ovaj dijagram ne pretenduje na apsolutnost. Svaki blok je iste {irine, alipotrebni resursi i vremena nisu jednaki; fokus je na sle|ewu i konkurentnosti.Tako|e, sama primena ciklusa }e verovatno biti iterativna (vi{estruka).

3.6.1 Projektovawe DW

Definisawe projekta

Ne postoji receptura za po~etni stadijum definisawa DW projekta iobezbe|ivawa sredstava. Veoma je mali stepen ponovqivosti u ovoj fazi ìvotnogciklusa, jer postoje znatne varijacije gledano po organizacijama. Ipak, uo~avaju setri glavna scenarija inicijative za DW:

● inicijativa izdvojenog poslovnog pobornika,● izuzetno velika potra`wa i● mawak zahteva za DW.

Nezavisno od scenarija, potrebno je odabrati momenat za odre|ivawespremnosti organizavije za DW projekat, jer je to faktor za koji se ne moèo~ekivati da }e se vremenom „spontano“ popravqati. Potrebno je razvijatistrategije smawewa rizika i planove kontingencije za jedan ovako skup projekat, ieliminisati hazarderstva i potencijalne pote{ko}e.

Planiraweprojekta

Defini-cija

zahtevabiznisa

Dimen-ziono

modelovanje

Fizi~kidizajn

Prire-|ivawe

podataka

Posta-vqawe

Odràv.i rast

Dizajntehni~ke

arhitekture

Izbor pro-izvoda i

instalacija

Razvoj E/Uaplikacija

Specifikaci-ja E/U

aplikacija

Upravqawe projektom


Postojawe sna`nog i uticajnog poslovno-upravqa~kog sponzora (ili vi{ewih) je od kriti~ne va`nosti za kompletan projekat. Sponzor ima viziju dejstvaDW i veliku samouverenost po pitawu te vizije, ali i neophodan nivo uvida urealne mogu}nosti. Prevazilaèwe kratkoro~nih problema pomo}u fokusa nadugi rok, prihvatawe kompromisa, kao i odgovornost za dono{ewe te{kih odlukasu neophodni kvaliteti sponzora.

Zajedni~ke karakteristike organizacija koje su se upustile u DW projekatsu ose}aj urgentnosti i (prakti~no prisilna) poslovna motivacija. Motivatorimogu biti: konkurencija, okruèwe, interne krize, ali i pogodnosti na trì{tu.Organizacije kod kojih su u toku velike strukturalne promene (ukidawe nekihdelova biznisa ili fuzionisawe), su verovatno slabiji kandidati za DWinicijativu.

Dobri odnosi poslovnih i informati~kih delova organizacije su bitanfaktor, ali on se u principu popravqa tokom rada na DW projektu. Analiti~kakultura, odnosno odlu~ivawe zasnovano na ~iwenicama, a mawe na intuiciji iose}aju, }e dati dobar podstrek za DW. Ina~e, izvesni su napori na mewawunepovoqne klime odlu~ivawa u organizaciji. Izvodqivost se odnosi prvenstvenona raspoloìvost i korektnost postoje}ih podataka, ali i na tehni~ku dimenziju.

Primer za „lakmus test” spremnosti organizacije se moè na}i u [1]. Prvifaktor ima va`nost oko 60%, motivacija i izvodqivost po 15%, a preostala dvafaktora dele stepen va`nosti od preostalih 10%. Jak sponzor moè nadomestitimawkavosti po pitawu ostalih faktora spremnosti, a tako|e moè i obezvreditidobro izdizajniranu DW.

Me|u prihva}enim tehnikama za poboq{awe spremnosti moèmo na}islede}e:● analiza poslovnih zahteva visokog nivoa (analiza pomenutih scenarija

zahteva)● odre|ivawe prioriteta poslovnih zahteva (s obzirom na potencijalni uticaj

na biznis i izvodqivost/spremnost - matrica odlu~ivawa)● dokazivawe koncepta (~esto se koristi u sprezi sa ostalim tehnikama).

Naredni korak je definisawe opsega projekta. Ovaj korak je u simbioti~kojvezi sa odre|ivawem opravdanosti projekta. [to je ve}i vremenski period koji seposmatra, ove dve aktivnosti su zametnije i vi{e zahtevaju reviziju prethodnihkoraka. Pravilo je da se opseg projekta defini{e na osnovu poslovnih zahteva, ane na osnovu kalendarskih rokova. Inicijalni projekat treba da bude skromnihdimenzija po pitawu izvornih sistema i broja korisnika. Definisawe opsegaprojekta obi~no prati i po~etno odre|ivawe kriterijuma uspe{nosti projekta.Opseg nije rigidna kategorija, jer se povremeno revidira, prilago|ava i kao takvaponovo publikuje.

Izgradwa opravdanosti projekta je jo{ jedno poqe saradwe poslovnog iinformati~kog osobqa. U principu je potrebno uporediti anticipiranetro{kove i koristi povezane sa DW projektom. Ne{to jednostavnije je odreditifinansijske investicije i tro{kove: hardver, softver, izgradwa, resursi (internii eksterni), edukacija i prate}a podr{ka, i postepeni rast. Odre|ivawefinansijskih prihoda i dobiti je komplikovano, jer je o~igledno (dodirqivo) ovdemnogo mawe od sakrivenog; pridobijawe novih kupaca, poboq{an kvalitet usluga iservisa, mo}nije predvi|awe i odlu~ivawe su prednosti koje nesumwivo dajufinansijske efekte na duì rok. Iz aspekta oportunitetnih tro{kova, svako


zna~ajnije ka{wewe projekta je znatan gubitak. Jak sponzor je velika pomo} kodfinansijskog opravdavawa projekta.

Planirawe projekta

U literaturi [1]se moè na}i interesantna analogija sastavqawasportskog i DW tima. Podrazumeva se da jedna osoba moè preuzeti vi{e uloga nasebe, tako da se veli~ina tima kre}e od 2-25 osoba. „Upravu” ~ine sponzori(poslovni i IS) i poslovni pokreta~i projekta - tim ima retko priliku da sedirektno susre}e s wima; „stru~ni {tab” su rukovodioci projekta - obi~nonajkvalitetniji qudi, koji ~esto deluju i kao „igra~i”; „igra~i prvog tima” ~ineosnovu DW tima - neki su sve vreme u igri, a neki povremeno: analiti~arposlovnih sistema, dizajner modela podataka, DW DBA, dizajner prire|ivawapodataka, programeri korisni~kih aplikacija, DW edukator; „specijalni timovi”se sastoje od: tehni~ko/bezbednosnog arhitekte, specijaliste za tehni~ku podr{ku,programera prire|ivawa podataka, posluìteqa podataka, analiti~ara zakvalitet podataka.

Razvijawe plana projekta ima dve glavne karakteristike: integrisanost idetaqnost. U literaturi postoji ekscerpt plana projekta, sa preporu~eniminformacijama koje treba pribaviti o svakom projektnom zadatku [1] (resursi,o~ekivano trajawe izvr{ewa, zavisnost od drugih zadataka, oznaka ka{wewa, ...).Broj poslovnih korisnika i uskla|ivawe sa organizacionom kulturom bitno uti~una o~ekivano vreme zavr{etka projekta.

Planom projekta se utvr|uju definicija i delokrug DW projekta,ukqu~uju}i postoje}e stawe i opravdanost uvo|ewa (iz perspektive biznisa). Ovizadaci su kriti~ni, sa stanovi{ta uglavnom velikih tro{kova DW. Planirawefokusira resurse i odgovaraju}e qudstvo, trajawe i redosled aktivnosti; zavisnoje od zahteva biznisa, {to je ilustrovano dvostrukom strelicom na dijagramu. Onoje osnova za daqe upravqawe projektom.

Upravqawe projektom

Upravqawe obezbe|uje sinhrono odvijawe aktivnosti u ìvotnom ciklusu is toga, {to se vidi na prikazanom dijagramu, prati ceo ciklus. Aktivnostiupravqawa su fokusirane na status projekta, pra}ewe rezultata i kontrolupromena. Stalna komunikacija je kqu~na za upravqawe o~ekivawima, a ono jekqu~no za ostvarivawe zadataka DW.

Jedinstvene karakteristike DW projekata su: vi{efunkcionalniimplementacioni timovi, iterativni razvojni ciklus svakog zahteva,kombinovani podaci i vizija. Postoji pet glavnih tehnika za uspe{nu kontrolu iusmeravawe projekta DW :● Sastanak za zvani~no ozna~avawe po~etka;● Pra}ewe statusa projekta (sastanci i izve{tavawa);● Odràvawe projektnog plana (promena opsega projekta, pomerawe dana

zavr{etka, angaòvawe dodatnih resursa i istraìvawa) i projektnedokumentacije;


● Upravqawe opsegom projekta - uvek }e biti korisni~kih zahteva koji nisuprvobitno re~eni ili su vremenom dodatno formirani. Razlog tome su prirodaDW projekta, kao i integrisawe raznolikih platformi, podataka i tehnika.Tada je mogu}e je odbiti korisni~ki zahtev, promeniti strukturu opsega ilipro{iriti opseg;

● Komunikacioni plan za upravqawe o~ekivawima (eliminisawe black-boxsindroma) - obuhvata projektni tim, sponzore, poslovne korisnike i ostalezainteresovane u~esnike (izvr{ni menaxment, sektor za IS, pa i organizacijuu celosti).

Menaxer projekta je glavni akter i odgovorno lice za ovu fazu ìvotnogciklusa izgradwe DW. Saglasno jedinstvenim potrebama organizacije, menaxertreba da prilago|ava prikazanu metodologiju. Ne}e se svaki detaq ìvotnogciklusa na}i u svakom projektu - razvoj sistema se zasniva na kompromisima.

3.6.2 Odre|ivawe korisni~kih zahteva

Uspe{nost DW je pove}ana razumevawem krajwih poslovnih korisnika iwihovih zahteva. Prilaz koji prihvata zahteve analiti~ara se su{tinskirazlikuje od podacima-vo|enog pristupa. DW dizajneri moraju razumeti kqu~nefaktore biznisa, da bi mogli dobro da utvrde zahteve i prevedu ih u stavke dizajna.Zahtevi biznisa daju osnov za tri paralelna toka fokusirana na tehnologiju,podatke i aplikacije krajwih korisnika.

Intervjuisawe krajwih korisnika je najva`niji po~etni korak u dizajnuDW. Intervjuisawe ima dve svrhe. Prvo, daje dizajnerima uvid u potrebe io~ekivawa korisnika. Svih devet kqu~nih ta~aka odlu~ivawa (iz 3.4) se izvode izevidencija tokom intervjuisawa. Intervjuisawe je bitan korak u povezivawu DWtima sa poslovawem. Pogodno je ako je ova veza ostvarena davno pre DWinicijative.

Druga namena intervjua je da se dozvoli dizajnerima da podignu nivoobave{tenosti krajwih korisnika o budu}oj DW. Intervjuisawe krajwihkorisnika je dvosekla akcija, jer neposredno posle intervjua po~iwe da rastepritisak istih tih korisnika po pitawu DW. Ukoliko su intervjui ~esti, avidqivih rezultata nema, nezadovoqstvo korisnika }e rasti.

Proces intervjuisawa treba da se odvija naizmeni~no sa grupama krajwihkorisnika i DBA transakcionih sistema. Kako se pojedine teme budu otvarale uintervjuima krajwih korisnika, pojavqiva}e se pitawa tipa da li postoje}ipodaci mogu da podrè analizu tih tema. U ranoj fazi procesa intervjuisawa, DWdizajneri bi trebali da istraè (u saradwi sa grupama krajwih korisnika) da lineka delimi~na ograni~ewa u podacima mogu biti prihvatqiva.

Na primer, tro{kovi distribucije mogu biti zavisni od proizvoda izavisni od skladi{ta, ali mogu biti i neka prose~na vrednost (koju logisti~ariutvr|uju na svakih {est meseci). Potrebno je ispitati korisnike i videti da li jeovaj nivo pra}ewa tro{kova prihvatqiv.

Optimalno intervjui traju sat vremena, gde se dva ili tri ~lana DW timasre}u sa odgovaraju}im menaxerom i nekoliko wegovih direktno podre|enih.


Veoma veliki sastanci su gubqewe vremena, jer }e par qudi u~estvovati ukonverzaciji, a ostali }e biti pasivni.

Veoma je bitno imati i strate{ke i takti~ke perspektive u prvimintervjuima. Tako|e je bitno obuhvatiti i marketin{ku, prodajnu, finansijsku,logisti~ku i menaxersku perspektivu. Tipi~an raspored intervjua u velikoj,milijarderskoj organizaciji bi trajao jednu ili dve nedeqe, sa 20 do 30 grupa.Najboqe je intervjuisati sve marketin{ke timove jedne za drugim, pa zatim sveprodukcione timove i potom sve operativne timove. Razumevawe poslovawa odstrane dizajnera }e narastati tokom intervjua i pogodno je da se neka po~etnapitawa ponovno sagledaju u novom svetlu. Posledica toga je da }e na krajuintervjuisawa dizajneri u~iti sve mawe novog i da }e sadràj intervjua postajatipredvidiv.

Ponekad intervju mora biti obavqen sa jednom osobom. Tada tim ne smepreopteretiti saradnika, te ne sme imati vi{e od dva ~lana. Ova individua,pogotovo ako je mla|a, ne}e uvek mo}i da odgovori na visoko strate{ka pitawatipa „Koja je misija va{eg departmenta?”. S druge strane, intervjui sarukovodiovcima se ~esto odvijaju u wihovim kancelarijama (bez prisustvapodre|enih) i ~esto su slobodniji. Ponovo, tim bi trebao biti ograni~en na dva dotri ~oveka, ali pitawa bi trebala biti vi{e strate{ka.

Sadràj intervjua krajwih korisnika

Kvalitetan intervju ima za ciq da navede krajweg korisnika da opisuje svojeaktivnosti u svojim terminima. Ne treba da govori o potrebnom sadràju DW, jerje to odgovornost informati~ara. êsto pitawa mogu biti postavqana kaoliteralne ~ek-liste, ali treba biti fleksibilan i za odgovore do par re~enica.Tada je mogu}e ne{to kra}e trajawe sesije.

Preporu~ene su slede}e celine sesije intervjua:

● Predstavqawe participijenata - kratak pregled delokruga rada i nadle`nostikrajwih korisnika, kao i predstavqawe ~lanova tima.

● Misija tima/grupe/departmenta/sektora - pogodan po~etak intervjuisawa jesticawe perspektive o misiji. Mogu}e je da grupa nema jasan uvid o misiji. Tadadizajnerski tim (kao i u svim drugim pitawima) treba da proceni da li suodgovori idealizovani ili stvarni, odnosno da li radi o normativnom ilideskriptivnom modelu organizacije. Oba modela su validna, ali treba utvrditikoji od wih trenutno izlaè intervjuisani. Deskriptivni modeli ~esto ukazujuna potencijalne izvore podataka za budu}u DW, kao i na poèqan izgledizve{taja.

● Promene u na~inu rada - ovi odgovori imaju znatan uticaj na dizajn DW, jer }eDW biti primarno oru|e za sprovo|ewe tih promena. Pitawa koja se izlu~ujuiz ovoga su slede}a:

o fokus prema klijentimao broj klijenatao grupisawe i dinamika grupisawa klijenatao delovi poslovawa za koje se odre|uje profit (i struktura profita)o pra}ewe kvaliteta (vremenske serije).

● Odnos sa konkurencijom.


● Merewe uspe{nosti - ukazuje na potencijalne mere tabele ~iwenica i potrebeza izvorima podataka.

● Lanac vrednosti (ukoliko postoji).● Granulacija - pitawa granulacije se postavqaju direktno, a ti~u se slede}eg:

o dnevni pregled podataka (vremenska dimenzija)o razdvajawe dana u nedeqi (vremenska dimenzija)o dovoqnost mese~nih preseka (vremenska dimenzija)o nivo pra}ewa proizvoda (dimenzija Proizvod), i drugo.

Intervjuisawe DBA

DBA su ~esto glavni eksperti izvornih sistema. Ovi intervjui sluè zaproveru realnosti pokrenutih tema. Metod otkrivawa spornih pitawa je pa`qivaanaliza izvornih BP, te DBA treba da priloì kompletnu dokumentaciju.

Pitawa su slede}a:

● Odnos produkcionih sistema i odakle poti~u podaci - klasi~na gre{ka je kadaDW zavisi od skupa podataka koji je nekoliko koraka (nizvodno) udaqen odoriginalnih podataka. DW }e mawe zavisiti od serije grupnih obrada iuvezanih produkcionih aplikacija, ukoliko uplivi{e bliè izvoru.

● Odgovorna lica za izgra|ivawe podataka koji }e ~initi budu}e dimenzije -nepovoqno je kada postoji rasplinutost, sa vi{e verzija podataka.

● Opis svake bitne tabele, opis svakog poqa u tim tabelama, broj slogova usvakoj tabeli BP - ova pitawa treba postaviti par nedeqa unapred, po{toiziskuju obiman rad.

● Popuwenost i kvalitet poqa u bitnim tabelama, validacija i obaveznost ovihpoqa, kardinalitet (broj razli~itih vrednosti) ovih poqa, primerivrednosti.

● Zna~ewe kodova - u DW se ne dozvoqavaju nejasni i nerastuma~eni kodovi.● Administrirawe kqu~eva u izvornim sistemima - ima}e bitan uticaj na

administrirawe kqu~eva u DW.● Direktan uvid u originalnu transakcionalnu istoriju.● Poqa sa vi{estrukim ulogama (zavisno od konteksta).

3.6.3 Oblikovawe podataka DW

Logi~ki dizajn

Logi~ki dizajn DW se konstitui{e dimenzionim modelovawem. Dimenzionomodelovawe podràva zahteve analize, uz druk~iji prilaz nego dizajn OTS(operativni transakcioni sistemi).

Identifikaciji dimenzionih modela pomaè metod (s vrha na dole) koji sezasniva na Matrici DW Bus arhitekture. Matrica predstavqa kqu~ne procesebiznisa (redovi) i wihovu dimenzionalnost (kolone). Povezivawem sa detaqnijomanalizom relevantnog OTS, razvija se dimenzioni model (fakti, dimenzije,atributi, hijerarhije). Matrica je veoma pogodna za predstavqawe dizajna navisokom nivou.


Prvi korak je izlistavawe svih uo~enih Data Marts. Jedna od prednostimatri~ne metode je da se uvek mogu kombinovati jednostavni (jednoizvorni) DataMart u kompleksni (vi{eizvorni) Data Mart.

Na dugi rok, ve{tinu u izgra|ivawu DW predstavqa postizawe najboqegbalansa izme|u zadovoqavawa urgentnih pitawa organizacije i prihvatawanajdostupnijih podataka u organizaciji. Preporuka je da se po~ne sa nekimjednostavnijim poslovnim procesom, odnosno DataMart-om.

Drugi korak je iscrpqivawe liste dimenzija (kolona) u matrici. Potom seutvr|uju prese~ne ta~ke, odnosno pripadnost dimenzija odre|enim Data Marts.Matrica je u principu dosta gusta i svaka dimenzija koja prolazi kroz vi{epreseka mora za te Data Marts biti konformna.

Potom se prelazi na ~etvorofazni postupak kreirawa tabela ~iwenica,opisan u 3.4.

Posle pripreme matrice treba pristupiti izradi logi~kog dijagrama svakekompletirane tabele ~iwenica. Ovi dijagrami pokazuju specifi~ni kontekstdate tabele u okviru Data Mart. Tako|e, treba prikazati sve povezane i nepovezanedimenzione tabele (imena i opise).

Ovi dijagrami su veoma bitni za uvo|ewe i obuku krajwih korisnika. S togaje bitno da su na svakom dijagramu dimenzione tabele pore|ane na isti na~in pova`nosti, po~ev od vremenske dimenzije. Dodatne informacije treba da obuhvatajuimena atributa, opise atributa, primere vrednosti atributa i kardinalnost.

Napredni koncepti dimenzionog modelovawa obuhvataju M:N relacije,lagano mewawe dimenzija (1 - prepisivawe, 2 - kreirawe novog sloga, 3 - ~uvawe inove i stare vrednosti, 0 - nema aùrirawa) i ve{ta~ke atribute.

Inicijalno modelovawe treba ~initi sa jezgrom tima od tri do {est qudi,koga ~ine modelatori podataka, DBA i eksperti izvornih sistema. U po~etku setreba orjentisati na ideje, a eventualna pitawa notirati i re{iti ih kasnije. Upo~etku je te{ko re}i koja su pitawa trivijalna, a koja su bitna.

Tako|e je bitno evidentirati potrebu za deriviranim ~iwenicama, jer se nenalaze svi fakti u izvornim sistemima. Postoje dve vrste deriviranih ~iwenica.Prve su aditivne, mogu biti izra~unate iz ~iwenica u istom slogu tabele~iwenica, predstavaqaju se u korisni~kim pogledima (gde korisnici ne uo~avajurazliku) i predstavqaju virtuelnu ekstenziju tabele ~iwenica. Druge sunezbrojive, poput odnosa ili kumulativnih ~iwenica na drugom nivougranularnosti. One se ne mogu nalaziti u istoj tabeli i izra~unavaju se u momentuupita.

Kompletirana lista izvedenih ~iwenica moè posluìti za izgradwumetapodataka (za alate za pristup podacima), kada se za to ukaè potreba. Logi~kidizajn je kompletiran odgovaraju}im strukturama tabela i primarni/strani kqu~relacijama, kao i preliminarnim planom agregirawa.

Fizi~ki dizajn

Po{to su identifikovana sva poqa u tabelama ~iwenica i dimenzija,ve}ina u~esnika velikih sastanaka po pitawu dizajna vi{e nisu neophodni. Mawi


tim moè izvr{iti inicijalni dizajn laganog mewawa dimenzija i agregata, kao iu kasnijim fazama dizajn heterogenih dimenzija, minidimenzija i modova upita.

Fizi~ki dizajn, kao postupak definisawa fizi~ke strukture za podr{kulogi~kog dizajna, tako|e ukqu~uje:

● standarde razvoja i imenovawa● BP okruèwe, ukqu~uju}i memorijske zahteve i veli~inu blokova● preliminarno indeksirawe (inicijalni plan indeksirawa)● strategije particionirawa (odnosno fizi~ke strukture)● implementaciju monitoringa kori{}ewa, tj. performansi.

Trebalo bi koristiti alat za modelovawe podataka pri razvoju fizi~kogmodela podataka. Poèqno je imati takav alat koji sme{ta strukturu modela urelacionu BP. Prednosti kori{}ewa alata za modelovawe podataka su slede}e:

● integracija DW modela sa drugim korporativnim modelima podataka● konzistentnost u naimenovawima● dokumentovanost u razli~itim korisnim formatima● generisawe DDL za sve popularne RSUBP● intuitivan korisni~ki intefejs za unos komentara.

Dizajn i razvoj prire|ivawa podataka

Prire|ivawe podataka (staging) ima tri glavna koraka: ekstrakciju,transformaciju i puwewe. Potrebno je dizajnirati dva procesa - jedan inicijalni,a drugi za redovno (inkrementalno) puwewe DW.

Najve}i zadatak u konstruisawu DW je dizajnirawe ekstrakcionog sistema.Potencijalni izvori podataka su oni koji se nalaze u dokumentaciji korisni~kihzahteva i drugi koji su mo`da potrebni kao podr{ka. Tabele dimenzija, naro~itokonformne, mogu iziskivati vi{e izvora podataka, dok se tabele ~iwenicanaj~e{}e popuwavaju iz jednog izvora.

Poces prikupqawa korisni~kih zahteva identifikuje kako formalne, takoi neformalne izvore podataka. Formalni izvori su podràni od strane IS ipostoji odre|eni stepen strogosti za izgradwu i integritet tih podataka.Neformalni podaci dolaze direktno od biznisa i koriste se u procesu dono{ewaodluka. Obi~no postoji odgovorno lice za prikupqawe i distribucijuneformalnih podataka. Korisnici trebaju neformalne podatke u konjunkciji saformalnim izvorima podataka.

Pri izboru lokacije iz koje }e se vr{iti ekstrakcija podataka, treba imatiu vidu slede}e kriterije:

● dostupnost podataka● trajawe puwewa● ta~nost podataka● vremenske rokove projekata● informacione prioritete.


Potrebno je analizirati sve dostupne modele podataka, izglede fajlova ikorporativne metapodatke. Informacije koje su potrebne o svakom izvorupodataka su slede}e:

poslovni vlasnik podataka IS vlasnik podataka sistemska platforma (UNIX, MVS) struktura fajlova (flat fajlovi, Oracle, DB2, FoxPro, Progress) fizi~ka lokacija sistema obim podataka (broj transakcija po danu, prose~an broj transakcija mese~no) identifikacija kqu~eva integritet podataka poku{aji integracije pravac razvoja.

Osnova za kvalitetan proces prire|ivawa podataka je izvor-ciq mapapodataka, koja ujedno sluì i za potrebe identifikacije razlika izme|u izvornihi ciqnih podataka.

3.6.4 Arhitektura DW

Arhitektura DW poseduje vrednosnu strukturu koja se ogleda u slede}ih petcelina:

● Komunikacija: arhitekturalni plan je odli~no komunikaciono sredstvo, kojeomogu}uje da menaxment shvati magnitudu i kompleksnost projekta.Arhitekturalne funkcije su sredstvo komunikacije u okviru tima i sa ostalimIS grupama.

● Planirawe: mnogi detaqi uo~eni u toku planirawa bivaju objediweni istrukturisani u okviru arhitekture. Arhitekturalni plan ~esto otkrivatehni~ke zahteve i zahteve koji se ne uo~avaju u procesu planirawa.

● Fleksibilnost i razvoj: arhitektura treba da se zasniva na modelima, alatimai metapodacima. To donosi tzv. semanti~ki sloàj u DW. Ovaj sloàj opisujeDW sadràje i procese, kao god {to se u tim procesima koristi za kreirawe,navigaciju i izgradwu DW - prakti~no, DW je fleksibilnija i lak{a zarazvijawe.

● Olak{ano u~ewe: arhitektura ima va`nu ulogu kao dokumentacija. Precizna iprofesionalna dokumentacija olak{ava ukqu~ivawe novih ~lanova u tim ipove}ava produktivnost rada.

● Produktivnost i vi{ekratna upotrebqivost: produktivnost je obezbe|enatime {to arhitektura olak{ava odabir alata koji automatizuju delove DWprocesa. Poboq{ano razumevawe omogu}ava mogu}nost ponovne upotrebepostoje}ih procesa i eliminisawe izgradwe uvek ispo~etka.

Postoje mnogi izdiferencirani pristupi definisawa i razvoja sistemskearhitekture. Usvojen je pojednostavqen pristup Xona A. Zahmana, prilago|enpotrebama DW [1]. Pojednostavqewe je u~iweno zbog toga {to DW nije odgovornaza kompletnu sistemsku arhitekturu. Detaqan prikaz pristupa prevazilazi okvireovog rada i bi}e samo napomenuto da se dati arhitekturalni okvir u najkra}em


sastoji od slede}ih oblasti: podaci ({ta), tehni~ka arhitektura (kako) iinfrastruktura (gde). U nastavku }e ukratko biti opisana pitawa odabiraproizvoda i odgovaraju}ih instalacija.

Izbor proizvoda i instalacija

Sa razvojem logi~kog i fizi~kog modela, raste potreba za specificirawempotrebnog hardvera i softvera. To je dosta sloèno pitawe, zbog rasplinutostikriterijuma i trì{nih trvewa.

Veoma je pogodno ako ponu|a~ ve} poseduje svoje instalacije uorganizacijama sli~nim datoj. Ina~e je potrebno sprovesti testirawe koje bi unajkra}em obuhvatilo slede}a pitawa, primera radi:

● moè li sistem efektivno da manipuli{e (upit, sme{tawe, puwewe,indeksirawe) sa tabelom ~iwenica od milijardu slogova i 12 dimenzija

● moè li sistem brzo da prelistava dimenzionu tabelu od 100000 slogova.

Ukoliko kandidat pro|e ovu fazu, moè se pristupiti testirawu koje biobuhvatilo:

1. Puwewe tabele ~iwenica - pretpostavqa se da tabela ima jedan glavni indeksnad kompozitnim kqu~em i eventualno sekundarni indeks;

2. Puwewe dimenzione tabele - relativno mali broj slogova (1000) se dodaje uveliku tabelu i relativno mali broj slogova se aùrira u tabeli;

3. Vi{ekorisni~ki upit - nekoliko ra~unara su preko mreè povezani na ciqniserver i svaki autonomno izvr{ava seriju upita; realna simulacija upita ima80% prelistavawa nad jednom tabelom i 20% vi{etabelarnih. Broj upita trebada je velik (preko 50), da se BP ne bi mogla podesiti specijalno za odre|eneupite.

3.6.5 Implementacija DW

Iplementacija u {irem smislu obuhvata slede}e teme:

● administracija agregata● kompletirawe fizi~kog dizajna● prire|ivawe podataka● razvoj aplikacija za krajwe korisnike.

Po{to su prva tri pitawa obra|ena u ta~kama 3.5 i 3.6.3, ovde }e se pa`waposvetiti aplikacijama krajwih korisnika. Prethodno }e biti napomenuto dapostoji specijalna klasa aplikacija, koje sem ~itawa zahtevaju i upisivawe u bazu(planirawe, buxetirawe, predvi|awe i {ta-ako modelovawe) - korisnici vr{eupis verzija u DW. To dovodi do potrebe za upravqanim aùrirawem BP,ukqu~uju}i pitawa bezbednosti i neku vrstu monitoringa transakcija. Me|utim,volumen ovih aktivnosti je generalno mnogo mawi od ve}ine produkcionihoperacionalnih sistema.


Tako|e, izlagawe u ovoj ta~ki }e biti pomalo diskontinuirano jer seprocesi povezani sa aplikacijama javqaju na dva mesta u ìvotnom ciklusu. S toga}e se odvojeno posmatrati specifikacija aplikacija i sam razvoj aplikacija.

Specifikacija aplikacija krajwih korisnika

Specifikacija aplikacija utvr|uje razumevawe izme|u tima i poslovnihkorisnika. Specifikacija aplikacija je priprema za „meko spu{tawe” nakorisni~ki desktop [1].

Parametrizovani (konzervirani - canned) izve{taji se nazivaju {abloni(uzorci - templates). [abloni bi trebali biti specificirani neposredno pokompletirawu zahteva. Naime, ~ak i u slu~aju obimne dokumentacije okorisni~kim zahtevima, zna~ajan deo informacija koje se odnose na aplikacije nebude izloèn. S toga, ove informacije je potrebno prikupiti momentalno, jermogu biti delimi~no ili ~ak kompletno izgubqene (zaboravqene).

Postoje ~etiri glavna koraka u specifikacionom procesu: odre|ivaweinicijalnog skupa {ablona, razvoj navigacione strategije, odre|ivawe standardaza {ablone i razvoj detaqnih specifikacija za {ablone. Naravno, obavezno jeukqu~iti korisnike u ovaj proces.

Odre|ivawe inicijalnog skupa {ablona - treba pribaviti 10-20 vrednih{ablona. Svaki intervju treba zavr{iti za evidentirawem potencijalnihizve{taja, koriste}i recimo brainstorming. Konsolidovawe liste kandidata jenajboqe izvr{iti primenom analiti~kog cikli~nog koncepta, koji ukqu~ujeslede}a pitawa: stawe biznisa, trendovi, neuobi~ajeni slu~ajevi (i uzroci), what-if, odlu~ivawe i implementacija odluke.

Kona~no, treba odrediti prioritet {ablona (u saradwi sa korisnicima) istartovati sa odre|enim malim brojem {ablona.

Dizajn navigacionog pristupa - mogu}e je imati do 100 {ablona godi{we.Potrebno je posedovati metodologiju grupisawa i organizovawa objekata i{ablona. Od velike pomo}i su metapodaci {ablona.

Odre|ivawe standarda za {ablone: imenovawe objekata, sme{taweobjekata, ekranski izgled. Standardi }e se mo`da mewati sa pribliàvawem fazeizgradwe.

Specifikacija detaqnih {ablona - format specifikacije se sastoji oddefinicionog dela i od izgleda {ablona. Definicija ukqu~uje ime, opis ilinamenu, frekvenciju, parametre, ograni~ewa i neuobi~ajene zahteve.

Iskqu~ivo poslovne mere definisane kao deo dimenzionog modela mogubiti ukqu~ene u {ablon. Ako se uo~e nove mere u {ablonima, potrebno ih jedodati u dijagram tabele ~iwenica.

Na kraju se {abloni mogu prezentovati korisnicima. Prethodno jepotrebno upore|ewe specificiranih {ablona sa kona~nim dimenzionim modelom.Elementi specikacija moraju pripadati inicijalnom Data Mart-u.


Razvoj korisni~kih aplikacija

Koraci ove faze ìvotnog ciklusa su veoma zavisni od tipa konkretneorganizacije i alata za pristup podacima koji je odabran. Na osnovuspecifikacija se konfiguri{u odgovaraju}i metapodaci i izra|ujuspecifikovani izve{taji. Poèqno je da se koriste napredni alati za pristuppodacima, koji obezbe|uju produktivnost tima i jednostavno mewawe izve{taja,~ak i od strane korisnika.

Sam proces prati standardni tok izrade softvera: odabirimplementacionog pristupa, programirawe, testirawe i verifikacija podataka,dokumentovawe, odràvawe. Instalaciju je najboqe realizovati preko , , teprodukcione verzije.

Implementacioni pristup moè biti jedan od slede}ih:

● Web - pristup, gde je celokupna navigaciona struktura ugra|ena u metapodatke● pristup potpuno zasnovan na alatu● pristup sa izvr{nim interfejsom zasnovanim na alatu● pristup sa korisni~ki kodiranim interfejsom.

Programirawe se sastoji iz slede}ih aktivnosti:

● definicija metapodataka za alat za pristupawe podacima● razvoj {ablona i navigacije krajwih korisnika (neophodno postojawe test

podataka)● selekcija izve{taja koji }e biti unapred startovani.

Testirawe logike i verifikacija samih podataka, ukqu~uje traèwe (ikasnije eliminisawe) slede}ih fenomena:

● opisa koji nemaju smisla● dupliciranih dimenzionih informacija● nekorektnih dimenzionih relacija● neizbalansiranih podataka.

Kqu~nu ulogu u ovoj fazi ima kreator aplikacija. Analiti~ar poslovnogsistema u~estvuje u razvoju specifikacija i testirawu aplikacija, a ~esto seukqu~uje i analiti~ar kvaliteta podataka. Razvoj korisni~kih aplikacija bitrebao biti zavr{en otprilike u isto vreme kada i dimenzioni model.

Glava 3 - Теоријско-методолошке основе DW 71.

3.7 DATA MINING

3.7.1 Definicija, evolucija i namena rudarewa podataka

Po{to i podaci predstavqaju resurse u proizvodnim sistemima, kao {to suoprema, qudi, prostor i sl., oni vremenom gube svoju vrednost (po stopi od 2,5-3,5%mese~no). Generi{u}i informacije, menaxeri poslovnih sistema konstantnopove}avaju vrednost podataka. Iz tih informacija treba da proistekne odre|enoznawe neophodno za kvalitetnije i brè dono{ewe odluka. Donesene odluke uti~una pove}awe vrednosti samog sistema, a time i na kvalitet novih podataka koji sepovratno slivaju u IS.

Qudske mogu}nosti neposrednog doku~ivawa zna~ajnih informacija izvelike koli~ine podataka su ograni~ene, ~ak, male. [tavi{e, veliki skupovisakupqenih i uskladi{tenih podataka su nepodlo`ni analizi pomo}utradicionalnih sredstava i postupaka. Kombinacije statisti~kih postupaka iprocedura upravqawa podacima su kako neefektivne, tako i neefikasne za datusvrhu. Mogu}i razlozi su: mala glavna memorija, udaqenost podataka, disparatnostpodataka. U tu svrhu se uspe{no mogu koristiti metodi, tehnike i sistemiautomatizovane analize podataka koji se nazivaju rudarewe podataka (Data Mining)i otkrivawe znawa (Knowledge Discovery).

Rudarewe podataka je automatizovani analiti~ki proces oblikovan zaeksploraciju u velikim zbirkama podataka, sa ciqem efikasnog otkrivawa,vrednovawa i crpqewa (vrednih, skrivenih) informacija. Ove informacije seti~u novih (neznanih) ~iwenica i modela, i kao takve se mogu koristiti zadono{ewe strate{kih poslovnih odluka. Sa tehnolo{kog nivoa, rudarewepodataka primewuje napredne tehnike i tehnologije sa namerom da identifikujezakonitosti u podacima. Rudarewe podataka nije isto {to i otkrivawe znawa; onoje faza u procesu otkrivawa znawa. Rudarewe podataka se sastoji iz slede}ihsubprocesa: priprema podataka (selekcija, ~i{}ewe, preprocesirawe iprezentacija), upotreba algoritma i analiza.

Otkrivawe (strukturisawe) znawa u BP predstavqa netrivijalni,iterativni i interaktivni proces identifikovawa (novih, validnih,potencijalno upotrebqivih i razumqivih) sloàjeva u podacima. Osnovne odlikeznawa su strukturisanost, koherentnost i relativna trajnost, za razliku odinformacije ~ije su odlike delimi~nost, fragmentarnost, izrazita privremenosti kratkotrajnost.

Znawe nije strogo „objektivno“, saznavalac i saznavano nisu prirodno ijasno razdvojeni, ve} su u interakciji - tradicionalno vi|ewe znawa kao stati~kogi pasivnog se primetno pomera ka vi|ewu znawa kao aktivnog. Pitawa saznavaocaodre|uju odgovore, odnosno prirodu i koli~inu informacija i podataka koji suzna~ajni i koje bi odgovori trebalo da sadrè. Tako, podaci su svrhoviti plod~ovekove intencije. Saznavalac tuma~ewem podataka u odre|enom (vremenskom,kulturnom, socijalnom, kao i teorijskom, logi~kom, metodolo{kom) kontekstudoku~uje informacije, te su i one wegova kreacija. Ovo jo{ izraènije vaì i zaznawa.

72. Dejan ûki}/Magistarska teza

Istorija rudarewa podataka

Iako trì{te isti~e mno{tvo novih produkata i kompanija, Data Miningposeduje bogatu tradiciju istraìvawa i primene koja obuhvata zadwih 30 godina.Prvi naziv za Data Mining, u 70-im godinama, je bio statisti~ka analiza. Izvorno,statisti~ka analiza se sastojala od klasi~nih statisti~kih rutina kao {to sukorelacija i regresija. Vode}e kompanije jo{ uvek imaju te rutine u svojoj ponudi,ali unapre|ene u mnogo dubqe pristupe za tuma~ewe i predvi|awe.

Tokom 80-ih se razvija niz analiti~kih alata. Ve}ina tih alata dozvoqavapodr{ku pristupu zasnovanom na verifikaciji, u kojem korisnici pretpostavqajuspecifi~ne me|uzavisnosti podataka, a zatim koriste alate da bi proverili svojepretpostavke. Takav pristup se zasniva na intuiciji analiti~ara da postavioriginalno pitawe i analizira rezultate potencijalnih kompleksnih upita u BP.Efikasnost analiza zasnovanih na verifikaciji je ograni~ena brojnimfaktorima, ukqu~uju}i i sposobnosti analiti~ara.

U kasnim 90-im, klasi~na statisti~ka analiza je pro{irena vi{eeklekti~kim setom tehnika, ukqu~uju}i rasplinutu logiku, heuristi~korezonovawe, ekspertne sisteme (ES) i neuronske mreè. To je predstavqalovrhunac ve{ta~ke inteligencije (VI). Ipak, VI nije ispunila sva o~ekivawa -bila je domenski ograni~ena, kodirawe ekspertskog znawa je poprili~nokomplikovano i samo funkcionisawe VI je ostalo black-box, obavijeno velomprobu|ene tehnolo{ke misterije.

Danas, krajem veka, se pristupa efektivnoj kombinaciji najboqih tehnika.Pojava DW daje rudarewu podataka realnost i aktuelnost, te predstavqa idealnookruèwe za taj proces. Analiti~ke metode za crpqewe (modeli) se sme{taju ubazu modela; one su pogodne za re{avawe problema strukturisanog ipolustrukturisanog odlu~ivawa.

Inteligentni agenti (IA) su informati~ka tehnologija koja se sve vi{ekoristi u simbiozi sa rudarewem podataka. ES moè fleksibilno da dodaje znaweu inteligentni agent, a moè se ukombinovati i u fazi sisteme. Rudareweusmeravano pomo}u IA moè da koristi trigere u BP, da bi se ozna~io po~etakprocesa rudarewa podataka.

Metodi prezentovawa rezultata rudarewa podataka, odnosno „nau~enog“, suslede}e:

1. vizuelizacija2. generisawe pravila3. analiza osetqivosti4. predvi|awe modela.

Slede}a generacija sistema za rudarewe podataka }e kombinovati operacijevo|ene verifikacijom sa onima vo|enim pronalaèwem. Verifikacijski vo|enisistemi }e omogu}iti iskazivawe i verifikovawe organizacionih i personalnihiskustava i hipoteza, dok }e pronalaèwem vo|eni sistemi biti iskori{}eni zapro~i{}avawe tih hipoteza i isto tako da identifikuju i ponude informacijekoje nisu prethodno hipotezirane od korisnika.


Metode i tehnike rudarewa podataka

Osnovne metode i tehnike su: neuronske mreè, stablo odlu~ivawa,bejzijanske mreè (mreè verovawa), grubi skupovi, geneti~ki algoritmi igeneti~ko programirawe, asocijativna pravila, rasplinuta logika, metodnajblièg suseda, K-najbliì par i statisti~ki metodi.

U slede}oj tabeli je dat najosnovniji pregled primene nekih tehnika:

Data Mining tehnologija Poslovna upotrebaneuronske mreè predikcija

algoritmi stabla odluke razumevawegeneti~ki algoritmi kategorizacija

fazi logika opcijeasocijativna pravila asocijacije

K-najbliì par klasterovawe

Tabela 3.6 Data Mining tehnologija i wena upotreba

Pored navedenog, rudarewe podataka se koristi za: klasifikovawe,procewivawe, regresiju, asocijacije, sekvencirawe, vizualizaciju, detekcijupromena i odstupawa, predikciju, modelovawe zavisnosti itd.

Tako|e, rudarewe podataka se moè koristiti i za razvoj aplikacija kao{to su automatizacija konstruisawa transakcionih sistema i modela predvi|awa[2].

Statisti~ke metode se naj~e{}e koriste za testirawe hipoteza. Metodese ukqu~uju u DSS u vidu statisti~kih paketa. êsto se koriste tzv. modeliizgra|enih blokova i subrutina.

Najpoznatije statisti~ke metode su:

predskazivawe vremenskih serija generator slu~ajnih brojeva trend regresiona analiza simulacija faktorska analiza nelinearna regresija linearna regresija atavisti~ki ARMA modeli.

Samo neki od primera za upotrebu statisti~kih metoda su:

analiza potro{a~ke korpe, segmentacija trì{ta (klasterovawe), modeli cena i kontrola procesa (regresija), predvi|awe prodaje i kamatnih stopa, kontrola investicija (vremenske serije).


Namena rudarewa podataka

Rudarewe podataka se moè podeliti u ~etiri glavne kategorije:

- Klasterovawe je tipi~an primer neusmerenog rudarewa podataka, gde korisniknema specificiran plan rada i nada se da }e alat sam otkriti neku vrednustrukturu. Nije ~ak neophodno ni identifikovati ulaze i izlaze na po~etkuizvr{avawa. Obi~no jedina odluka koju korisnik mora doneti je broj klastera koji}e se zahtevati. Algoritam klasterizacije }e na}i najboqe particioniraweslogova i obezbediti opise centroida svakog klastera u terminima originalnihpodataka. U mnogim slu~ajevima klasteri imaju o~itu interpretaciju. Specifi~netehnike kori{}ene u klasterizaciju ukqu~uju statistiku, memorijsko rezonovawe,neuronske mreè i stabla odlu~ivawa.

- Klasifikovawe predstavqa svrstavawe date pojave entiteta u odre|eni klasterili klasifikaciju. Detaqni opisi se pohrawuju u klasifikacioni algoritam, aklasifikator odre|uje kojem klasterskom centroidu je entitet najbliì ilinajsli~niji. Klasterovawe prirodno prethodi klasifikovawu. U najgeneralnijemsmislu, klasifikovawe je veoma primewivo u mnogim DW okruèwima -klasifikovawe je odluka. Tehnike koje mogu biti kori{}ene ukqu~uju standardnustatistiku, memorijsko rezonovawe, geneti~ke algoritme, analizu veza, neuronskemreè i stabla odlu~ivawa.

- Procewivawe i predvi|awe su dve sli~ne aktivnosti koje obi~no izlu~ujunumeri~ku meru kao rezultat. Na primer, iz skupa kupaca moè se procenitiukupna zaduènost kupca kandidata. Predvi|awe je sli~no, jedino {to se poku{avaodrediti rezultat koji }e se dogoditi u budu}nosti. Procewivawe i predvi|awetako|e mogu pokrenuti klasifikaciju. Vaàn kvalitet numeri~kog procewivaweje mogu}nost rangirawa. Specifi~ne tehnike ukqu~uju standardnu statistiku ineuronske mreè za numeri~ke varijable, kao i sve tehnike klasifikacije kada sepredvi|a samo diskretan ishod.

- Grupisawe srodnosti (afiniteta) je specijalna vrsta klasterovawa kojaidentifikuje doga|aje i transakcije koje se de{avaju simultano - ponegde se nazivatraèwe zajedni{tva. Najpoznatiji je primer analize potro{a~ke korpe, gde seotkriva koji proizvodi se prodaju zajedno. Primewuju se tehnike standardnestatistike, memorijskog rezonovawa, analize veza i specijalni alati za analizupotro{a~ke korpe.

Rudarewe podataka, poput standardnog izve{tavawa, je tipi~no separatansistem (ili sistemi) sa separatnim alatima. To je jo{ jedan klijent DW, ali bezuobi~ajenih zahteva izve{tajnog sistema. Iako interakcija sa DW nema izraènuzavisnost, ve}ina Data Mining sistema moè da radi samo sa podacima sme{tenim uravnim fajlovima ili operativnim BP. Servisi koje treba Data Mining aplikacijasu vi{e poput servisa prire|ivawa podataka za neki Data Mart, ukqu~uju}i:

● podr{ku za periodi~no povla~ewe velikih fajlova● servisi za transformaciju podataka● pristup koji omogu}ava aùrirawe.


3.7.2 Sistemi za upravqawe znawem

Istorijski, znawe u organizaciji je bilo sme{tano na papirima ilipam}eno od strane najzna~ajnijih eksperata. Ove forme ne pruàju adekvatneodgovore na rastu}e zahteve za prikupqawem i obradom znawa, te se organizacijeokre}u ka sistemima za upravqawe znawem (knowledge management - KM). Sistem zaupravqawe znawem formalno upravqa svim resursima znawa kako bi se omogu}iobrì pristup znawu i wegovo vi{estruko kori{}ewe, obi~no koriste}i napredneinformacione tehnologije.

Upravqawe znawem je formalno u smislu da se znawe klasifikuje ikategorizuje prema unapred odre|enom modelu za opis znawa (ontologiji) za datuorganizaciju, {to omogu}ava da se uskladi{teno znawe iskoristi na najboqimogu}i na~in. Izvori znawa variraju u zavisnosti od konkretne organizacije, aliuglavnom obuhvataju razne priru~nike za rad, pisma, izve{taje servisa, odgovoreklijenata, novosti, kao i znawe dobijeno u radnim procesima.

Okruèwa za eksploataciju podataka

Okruèwe za upravqawe izve{tajima (Managed Reporting Environment -MRE) ukazuje na softverske alate koji su razvijeni za generisawe i distribucijuizve{taja ka onim korisnicima, koji zahtevaju predefinisane informacije uunapred definisanim trenucima vremena. Korisnicima nije neophodno specijalnoznawe o podacima.

Okruèwe za upravqawe upitima (Managed Query Environment - MQE) ukazujena softverske alate koji su razvijeni za obezbe|ivawe fleksibilnih ad hoc upita.Potrebna je intenzivnija obuka i familijarnost korisnika u odnosu na pasivnoMRE okruèwe. Uz znatne prednosti i preglednost, ipak postoji mogu}nost dakorisnik ne ume da interpretira podatke ili ignori{e kvalitet podataka. Ovookruèwe ukqu~uje OLAP i SQL alate.

Otkrivawe znawa u podacima (Knowledge Discovery in Data - KDD)podrazumeva revidirane i pro{irene tehnologije kao {to su: statistika, VI,vizualizacija, specijalizovani algoritmi, ekspertski sistemi i sl.

MRE MQE KDDInformacije su gurane Informacije su vu~ene Pronalaèwe informa-

cijaNefleksibilnost, krutost Fleksibilnost Nerazvijenost

Kontrolno orijentisano Navigacijski orijenti-sano

Orijentisano ka modelu

Unapred definisanizahtevi

Ad hoc Nepoznati zahtevi

Raspoloìva distribucija Raspoloìvi metapodaci Raspoloìvost algoritama

Serverska baziranost Klijentska baziranost Serverska baziranost

Tabela 3.7 Osnovna eksploataciona okruèwa u kojima se koristi DW


Ove tehnologije evoluiraju i time uslovqavaju evoluciju pojedinih alata.Svako okruèwe ima specifi~ne korisnike ~iji su zahtevi stalno u porastu, takoda razvoj alata prati wihove zahteve, ali dolazi i do suprotnog dejstva jer se tiisti alati uslo`wavaju. Postaje bitno pitawe korisni~ke obuke.

Potrebe za upravqawe znawem

Pritisci iz okruèwa - rastu}a konkurentnost, globalizacija igeografska razu|enost zahtevaju minimizovawe verovatno}e pojave ponovqenihistraìvawa (ili ponovqenih istih gre{aka) u organizaciji. KM je komplikovan~ak i u situaciji da su u~esnici na istoj lokaciji. Informacioni i saznajnitokovi se uglavnom odvijaju na neformalnim sastancima i ne podleùformalizaciji, te ih je te{ko pravilno iskoristiti.

Tehnolo{ki napredak - gotovo svi sistemi vezani za KM koriste neke vrsteInternet browser-a. Tako|e, mnogi alati koji su nezavisno razvijeni imaju veoma{iroku primenu u Internet okruèwu, poput inteligentnih agenata.

Kreirawe korisnih informacija - KM sistemi daju dodatnu vrednostkonvertovawem znawa i informacija dostupnog pojedincima u grupno iliorganizacijski dostupno znawe.

Osnove KM sistema

Ontologija za klasifikovawe i klasterizovawe znawa u strukturne isemistrukturne podatke i baze znawa je prespecificirana, ali i u stalnomrazvoju.

Slika 3.7 Osnovni koraci u procesu upravqawa znawem

Istorijski se KM javio kao EIS, koji je sadrào portfolio alata poput onihza brz pristup BP i vestima. Vremenom su se KM sistemi pro{irili na domenorganizacije. Naime, velika je verovatno}a da su informacije i znawa potrebnidirektorima, korisni za jo{ neke od zaposlenih. Tako|e, KM sistemi su izuzetnopogodni za menaxerske grupe (npr. customer support), gde se npr. sve reklamacijekupaca sme{taju u centralizovanu BP.

Klasi~an pristup podrazumeva prikupqawe znawa i ~iwewe da ono budedostupno; me|utim, ignori{e znawe koje se gomila u generisanim podacima itekstualnim informacijama. Ovaj pristup tako|e omogu}ava povezivawe znawa i

Socio-kulturolo{ki aspekt

Primenaznawa

Tehnolo{ki aspekt

Kreirawe znawa/Akvizicija

Sme{tawe znawa/Organizacija

Distribucijaznawa


qudi, ali ne vezuje znawe sa ostalim znawem, niti usmerava znawa. Potrebno jedelewe i konvertovawe znawa.

Knowledge harvesting (ètva znawa) identifikuje znawe koje mogu}epodvrgnuti tom procesu. Zaposleni doprinose generi~kim znawem, ali su odzna~aja i istorije slu~ajeva.

Najve}i izvor znawa su qudi, pri ~emu se saradwa izme}u qudinajefikasnije obavqa preko mreà. Pored navedenog, KM sistemi su imali fokusna dokumentima, ali dokumenta sama po sebi ne defini{u svoj sadràj ili temu zakoju su vezani. Potrebno je urediti odnos izme|u dokumenata, na primer pomo}uhipertekst linkova.

Implementacija KM-a

Jedan od prvih alata su DW. Veli~ina DW moè biti ogromna. Mogu}a jedopuna sa procesom otkrivawa znawa.

Umesto skladi{tewa kvantitativnih podataka, Knowledge Warehouses (KW)su orijentisane ka kvalitativnim podacima. KW su neka vrsta virtuelnihskladi{ta u kojima je znawe podeqeno izme|u razli~itih servera.

Baze znawa i baze podataka: lesson learned, best practices (znawe o najboqimiskustvima, obi~no kreirano kori{}ewem benchmarking-a), Price Warehouses i sl.

Otkrivawe znawa - termin KDD je uveden 1989. godine da bi se potvrdilo daje znawe krajwi produkt istraìvawa zasnovanog na podacima. KDD proces, osimData Mining-a, sadrì i ugradwu odgovaraju}eg znawa iz domena i interpretacijurezultata analize.

KDD ukqu~uje rezultate razli~itih oblasti poput ma{inskog u~ewa,prepoznavawa uzoraka, akvizicije znawa za ES, izra~unavawa visokog nivoa i sl.Krajwi ciq je ekstrakcija znawa visokog nivoa iz podataka niskog nivoa uvelikim BP.

Slika 3.8 Arhitektura sistema za KM

Spoqni izvoriznawa:

WWWistraìva~ke grupebiblioteke ...

Latentnoznawe

Nasle|eno znawestare BP, neintegrabilne BP

Baza znawaobjekt znawa (tekst, multimedija)metapodaci (metrika, klase)

DataMining

DW

IR

Zaposleni

znawe,deqeni pogledi

upit

Prirodnaselekcijaznawa:

visoko rangiranoznawe

nisko rangiranoznawe

obrasci,trendovi~i{}ewe,

filtrirawe

PRODOR ZNAWA IKULTURA DELEWA


Predstavqawe znawa

Znawe razumqivo za ~oveka se predstavqa kori{}ewem razli~itihpristupa. Qudi obi~no pristupaju informacijama preko browser-a ili nekog IA.Uglavnom je znawe predstavqeno u vidu mno{tva slu~ajeva, koji se pravilnomanalizom mogu iskoristiti za re{avawe novih slu~ajeva i to predstavqa domenCBR sistema (sistemi zasnovani na slu~ajevima - Case Based Reasoninig).

U situacijama u kojima su informacije predstavqene u vidu velikihkoli~ina deklarativnog znawa, tekstovi ili odgovaraju}a pravila se morajukoristiti za predstavqawe znawa. Na primer, priru~nici, radna uputstva isli~na dokumenta koja se koriste u organizacijama su u formi implicitnihpravila: „Ako je izvr{eno A, tada treba uraditi B ...“.

Vi{estruko filtrirane informacije se pojavquju u obliku skupadeklarativnih izraza. Tehni~ki izve{taji opisuju znawa i situacije koje su odop{teg interesovawa i nisu specijalno usmereni ni ka jednom segmentuorganizacije. Ove forme imaju veliki zna~aj za politiku organizacije, ali ne itako kreativne mogu}nosti, kao kod nefiltriranih informacija.

Ma{inski razumqivo znawe je dostupno samo u ma{inskoj formi, u viduekspertnih ili KB (Knowledge Base - baza znawa) sistema. Ekspertni sistemi mogubiti sastavni deo KM sistema, ali ipak, ve}ina KM sistema prvenstveno koristerazne inteligentne agente za pretraìvawe druge forme znawa. Ovo je jo{ uveknedovoqano istraèna oblast.

Bez obzira koja se forma znawa koristi, potrebna je eksplicitnataksonomija zadataka koje sistem poseduje, tzv. ontologija.

Filtrirawe i pretraìvawe znawa

Kvalitet znawa varira u zavisnosti od mnogih faktora (izvor znawa i sl.).Tipi~an slu~aj su diskusione grupe na Internetu, u kojima nepostojawefiltrirawa informacija moè da prouzrokuje totalnu konfuziju. Sistemi zafiltrirawe obezbe|uju kompletnost i korektnost znawa.

Filtrirawe moè raditi ~ovek ili automatizovan sistem (pre svegaelektronske po{te). Sistemi za nadgledawe kvalitativnih BP na osnovukorisni~kih profila izvla~e zanimqive informacije iz mase podataka.Informacije se prenose kroz rukovodstvenu hijerarhiju - kolaborativni sistemi.Me}utim, zna~ajno ograni~ewe je korisni~ka semantika klasifikacije.

Pretraìvawe znawa je izuzetno sloèn zadatak, zbog mogu}e veli~ine bazeznawa i raznorodnosti sme{tenih informacija. Najzna~ajniji pristupi su:

● ma{ine za pretraìvawe - koriste se za usmeravawe informacija kakorisnicima (Alta Vista, Excite, Infoseek, Lycos, WebCrawler, Yahoo)

● inteligentni agenti - mogu da koriste i odre|enu heuristiku da do|u doskrivenih interesovawa korisnika, gde se na osnovu sintakse poruka nalazezna~ajne fraze vezane za korisni~ke karakteristike (InfoFinder)

● vizuelizacioni modeli - jedan od novijih trendova, gde se kori{}ewemstruktuiranih informacija ili nestrukturisanih tekstova (lingvisti~kianalizatori) prave odre|eni superkonteksti; tako|e, ~est je slu~ajvizuelizacije velikih hijerarhijskih struktura.


3.7.3. Neuronske mreè

Potreba za neuronskim mreàma se javqa zbog te{ko}e pra}ewa izrazitonelinernih krivih pona{awa sistema. Mogle bi se definisati kao matemati~kimodeli, koji opona{aju strukturu i aktivnosti mozga.

Neuronske mreè i geneti~ki algoritmi su oblast nauke i tehnike za kojevaì da su primarno inspirisani biologijom. Prema klasi~nom stanovi{tu mozakje kompjuter (VI = pravila + simboli). Alternativno stanovi{te nagla{avasimbiozu paralelizma (masivnog) i PR (pattern recognition - prepoznavawe prizora)qudskog mozga.

Osnovne karakteristike neuronskih mreà su:

robusnost (distribuiranost informacija - mreà nastavqa da funkcioni{e ikada su neki delovi o{te}eni, odnosno kao kad u mozgu neke }elije preuzmufunkcije o{te}enih)

paralelna arhitektura (svaki neuron je procesor, ~ime se teì postizawunekih prednosti qudskog mozga u odnosu na klasi~ne ra~unarske sisteme)

u~ewe novih koncepata sa starom arhitekturom jednom obu~ena mreà moè da na|e re{ewe, iako je deo ulazne informacije

o{te}en ili nedostaje.

Model mreè

Mreà se sastoji iz skupa ~vorova - procesnih elemenata (jedinica). Svaki~vor prima neki ulaz, obra|uje ga aktivacionom funkcijom F i prosle|uje izlaz.^vorovi su organizovani po slojevima: ulazni, skriveni i izlazni - ulazni supasivni, a skriveni i izlazni aktivni; postoje jo{: inhibiraju}i - bez pobude(spu{ta signal) i ekscitiraju}i - daju pobudu. Perceptron je mreà sa ulaznim iizlaznim slojem, koja ne pravi ekskluzivnu disjunkciju.

Propagaciona funkcija kombinuje inpute iz emituju}ih neurona teìnskimsumirawem na osnovu sinapti~ke snage (> 0 za ekscitiraju}e i < 0 za inhibiraju}esinapse). Za izraàvawe pozadinskog aktivacionog nivoa dodaje se neka konstanta.Skriveni slojevi su „oborili“ tvrdwe Miskog o besperspektivnosti neuronskihmreà.

Svaki neuron ima aktivacioni nivo koji se nalazi izme|u minimuma imaksimuma. Stoga, suprotno Bulovoj logici, postoji vi{e nego dve aktivacionevrednosti - koje odre|uje aktivaciona funkcija.

Sli~nosti neuronskih mreà i qudskog mozga su slede}e:

1. klasifikacija2. klasterovawe3. asocijativna memorija (omogu}uje PR)4. modelovawe (na osnovu primera)5. predvi|awe (vremenskih serija)6. zadovoqavawe ograni~ewa.


Obu~avawe mreè

Karakteristi~no za proces obu~avawa neuronskih mreà je da se ne znajuaktivacione funkcije. U pripremi se formira obu~avaju}i skup nad kojim seprimewuje algoritam obu~avawa, gde su mogu}a i razna matemati~ka izvo|ewa.Aktivaciona funkcija je deterministi~ka funkcija, nije funkcija vremena (npr.step funkcija, semilinearna, ...).

Postupak obu~avawa se sastoji iz slede}ih koraka:

1. bira se slede}i par iz obu~avaju}eg skupa (dovodi se ulazni vektor)2. ra~un izlaznog vektora3. ra~un gre{ke4. pode{avawe teìnskog faktora da se minimizira gre{ka5. ponavqawe koraka za svaki vektor iz obu~avaju}eg skupa, dok gre{ka ne postane

dovoqno mala.

Tada se mreà smatra obu~enom i koristi se, a teìnski faktori se ne mewaju. Uslu~aju da su teìnski faktori isti, a zahtevane vrednosti nisu, mreà ne}eu~iti. Obu~avawe dosta dugo traje (kod problema vizije ~ak mesecima), a ne moraobavezno uspe{no da se zavr{i. Me|utim, neki problemi poput govora i slike suizuzetno efikasno re{eni. Ste~eno znawe mreè je skriveno u strukturi i uteìnskim faktorima.

Standardan je back propagation algorythm - algoritam prostirawa gre{ke. Onse sastoji iz kombinacije olan~avawa unazad i nadgledawa (feedforward +supervising). Tako|e su poznati i Kohonenov algoritam, kao i hibridni recurent backpropagation algoritam. Jedna od specifi~nih, ali i opasnih degenerativnih pojavaje overtraining neuronske mreè.

Po zavr{etku faze u~ewa nastupa radna faza. Neuronska mreà }e davatirezultate sli~ne onima u uzorku kada ulazne vrednosti zadovoqavaju obu~avaju}eprimere. Za ulazne podatke izme|u tih vrednosti, aproksimira se izlaznavrednost. Pona{awe je deterministi~ko - za jednake kombinacije ulaza, izlaz jeuvek isti. U radnoj fazi nema u~ewa.

Podela i primena neuronskih mreà

Neuronske mreè se mogu razvrstati prema slede}im kriterijima:

● obu~avawe● topologija - napredne, ograni~eno i totalno povratne (koje su nestabilne)● paradigma treninga - bez nadgledawa (segmentacija i klaster), sa nadgledawem

i sa poja~awem (reinforced).

Kada za dati slu~aj dono{ewa odluka postoje podaci, a ne postoji algoritam,neuronske mreè predstavqaju mo`da jedino re{ewe. Neuronske mreè se koristenaro~ito za klasifikaciju, modelovawe i predvi|awe, a mawe za klasterovawe isegmentaciju. Najpoznatiji komercijalni alat za Data Mining je IBM NNU (NeuralNetwork Utility).


Razvoj mreè je sli~an razvoju standardnih programa, s tim da 50-75%razvojnog vremena odlazi na rad s podacima, pre nego {to oni uop{te ugledajuneuronsku mreù. Ponovno trenirawe mreè s najnovijim podacima }e dovesti doaùrirawa aplikacije koja je razvijana uz pomo} mreè.

ê{}e je mreà subrutina, uz preskalirawe ulaznih podataka ipostskalirawe simboli~kog u numeri~ki format. Da bi se izbegao sindrom crnekutije, koristi se vizuelizacija (recimo Hintonovi dijagrami).

Hibridni sistemi - zna~ajan nedostatak neuronskih mreà je {to neobrazlaù re{ewa. Stoga se kombinuju s ekspertnim sistemima ES (kodsimboli~kog modelovawa), pa i sa klasi~nim programima.

Problem je {to mreà daje rezultat, ~ak i kada ulaz nije dobar. Ukoliko jebaza znawa mala, neuronska mreà preuzima zadatke ES (kada se ustanovi da mreàdobro radi). Ovo se ipak de{ava re|e (samo za perceptore), a ~e{}e je obrnuto.

3.7.4 Fazi logika i neuro-fazi aplikacije

Upotreba fazi skupova u logi~kim izrazima se naziva fazi logika. Faziskupovi predstavqaju generalizaciju konvencionalnih skupova, a defini{u sefunkcijom pripadnosti (MBF - membership function). Tada, stepen pripadnostiskupu postaje stepen istinitosti izraza. Na primer, iskaz: „pacijent ima visokutemperaturu“ bi mogao biti istinit sa stepenom 0,65 za temperaturu od 39C.

Za razvoj sistema koji simuliraju ~ovekovo odlu~ivawe, klasi~nimatemati~ki modeli nisu dobri. Qudsko prosu|ivawe i vrednovawe ne sledeBulovu logiku niti bilo koju konvencionalnu matemati~ku disciplinu. Stoga,standardni programski jezici, tesno povezani sa matemati~kom logikom, su dalekood efikasnosti i nisu dovoqni za implementaciju procesa dono{ewa odluka.

Primer 1: odre|ivawe ciqne grupe „o~evi u najboqim godinama saprose~nim primawima“

Kriterijum selekcije: 1) godine izme|u 40 i 552) broj dece bar jedno3) prihod izme|u $40.000 i $55.000,

daje lo{ rezultat u slu~aju osobe (38, 3, $48.000), koja zapravo ima boqekarakteristike od osobe (41, 1, $41.500). Da bi se i takve osobe ukqu~ile u izbor,mogu}e je pro{iriti (liberalizovati) kriterijume. Me|utim, tada }e se ukqu~itii osobe koje ne bi trebale da su u ciqnoj grupi. Re{ewe koje ukqu~uje fazikriterijume ne primewuje striktne granice, nego intuiciju i iskustvo izpro{losti - daje realnu relaciju izme|u uslova i aktuelnog ciqa. Tada ~iwenicada neko ima 38 godina nije dovoqna da bude iskqu~en iz selekcije.

Tako|e, ~esto je u upotrebi i fazi klasterovawe. Tada se koristisofisticiranije zna~ewe „sli~nosti“ - sli~nost dve ta~ke se odre|ujekori{}ewem MBF.


Tipovi neizvesnosti

Mnoge matemati~ke discipline koriste termin neizvesnosti, npr. teorijaverovatno}e, teorija informacija i teorija fazi skupova. Me|utim, tretirajurazli~ite tipove neizvesnosti.

Stohasti~ka neizvesnost - bavi se neizvesno{}u de{avawa konkretnogdoga|aja; npr. iskaz: „Verovatno}a pogotka mete je 0,8“. Teorija verovatno}eomogu}ava modelovawe ovog tipa neizvesnosti nekom klasi~nom metodom kao {toje Bayes-ov ra~un i sl.

Leksi~ka neizvesnost - nalazi se u svakodnevnom jeziku. Nauka koja se bavi~ovekovim na~inom vrednovawa koncepata i dono{ewa odluka jepsiholingvistika. Re~i imaju ulogu subjektivnih kategorija koje klasifikujupojmove kao {to su „visina“, „temperatura“ ili „inflacija“. Kori{}ewem tihsubjektivnih kategorija, pojmovi u realnom svetu se vrednuju pomo}u stepena pokojem zadovoqavaju kriterijum. Iskaz: „Berovatno }emo imati uspe{nufinansijsku godinu“, je pogodniji za predstavqawe verovatno}e nego neki iskaz sastohasti~kom neizvesno{}u.

Leksi~ka neizvesnost barata sa neizvesno{}u definicije samog doga|aja.Kombinacija subjektivnih kategorija, u procesu qudskog dono{ewa odluka, nezadovoqava aksiome teorije verovatno}e - ne moè biti kori{}ena za modelovawe.

3.7.4.1 Lingvisti~ke varijable i funkcije pripadawa

Osnovni element sistema sa fazi logikom je tzv. linvisti~ka varijabla.Vi{estruke subjektivne kategorije se koriste da opi{u isti kontekst. One senazivaju „lingvisti~ki uslovi“ (terms odn. labels) i reprezentuju mogu}e vrednostilingvisti~ke varijable. Na primer „temperatura tela“ moè biti „visoka“,„normalna“ i „niska“.

Lingvisti~ke varijable su re~nik fazi sistema. Pravila koja opisujuodre|enu politiku odlu~ivawa izvode zakqu~ke na osnovu tog re~nika i zatomoraju blisko opisivati na~in na koji qudi izra~unavaju numeri~ke podatke.

Metodologija dizajna linvisti~kih varijabli

Mnoge aplikacije koriste 3-7 lingvisti~kih uslova (vrednosti) za jednuvarijablu. Mawe od tri se retko koristi, jer gotovo svi qudski koncepti se sastojeod bar dva ekstrema i sredine. Tako|e, qudi interpretiraju tehni~ke pokazateqekori{}ewem svoje kratkotrajne memorije, koja moè da barata sa do sedam simbolaistovremeno. ôvekova prirodna skala osetqivosti je sedmostepena (otudasedmostepena muzi~ka skala i sedam osnovnih boja u spektru). Za kodirawe sedamalternativa potrebno je 2,81 bit {to ukazuje na nisku granicu osetqivosti kanalapercepcije (psiholozi smatraju da se moè pove}ati efektivni kapacitet qudskogkanala percepcije).

Dodatno, broj vrednosti je neparan, jer su obi~no lingvisti~ke varijabledefinisane simetri~no, a jedna vrednost opisuje sredinu. Tako da je broj obi~notri, pet ili sedam.


Oblici MBF

U literaturi postoje mnoge MBF. Me|utim, u praksi se koriste samostandardne: Z-tip, -tip, -tip i S-tip. Standardne MBF su normalizovane, nalazese izme|u 0 i 1.

Psiholingvisti~ke studije su pokazale da bi MBF teoretski trebala dazadovoqi odre|ena ~etiri uslova. Te uslove zadovoqava kubna funkcija, ~ija jeupotreba ista kao i standardnih MBF.

Od ostalih MBF je najinteresantnija empirijska funkcija - definisanakori{}ewem empirijskog pristupa na osnovu simuliranog procesa odlu~ivawa.Ipak, za ve}inu aplikacija je ovo suvi{e zahtevno.

Sve navedeno vaì samo za ulazne varijable fazi sistema. Za izlaznevarijable se koristi uglavnom -tip MBF.

3.7.4.2 Algoritam fazi logike

U su{tini, fazi logika je tehnologija koja translira opise politikeodlu~ivawa (u prirodnom jeziku) u algoritam (koriste}i matemati~ki model).Fazi logika obezbe|uje lak i transparentan metod za sjediwavawe zdravorazumskogrezonovawa.

Ve}ina fazi aplikacija koristi AKO-ONDA pravila, ali potpunodruga~ije od ekspertnih sistema - koriste se meki podaci. Na primer: IF A velikoAND B sredwe THEN C veliko.

Fazi izra~unavawe se sastoji iz tri koraka:

fazifikacija - translirawe ulaznih numeri~kih varijabli u lingvisti~kevrednosti, kori{}ewem fazi skupova,

fazi zakqu~ivawe - po{to je izvr{ena fazifikacija svih potrebnihvarijabli, pristupa se izra~unavawu AKO-ONDA pravila; rezultat jelingvisti~ka vrednost za lingvisti~ku varijablu i

defazifikacija - izlazna varijabla je pogodnija u numeri~koj formi, te jepotreban i ovaj translacioni korak.

Translacije su cena za pravila bliska qudskom rezonovawu. One zahtevajuvezu izme|u numeri~ke i lingvisti~ke reprezentacije varijable - to je MBFsadràna u definiciji lingvisti~ke varijable.

3.7.4.3 Fazifikacija

Vrednost lingvisti~ke varijable se moè izraziti na dva na~ina. Jedan jevektor stepena pripadnosti fazi skupovima koji defini{u vrednosti varijable.Drugi koristi samo re~i za predstavu tih vrednosti.

Varijable mogu biti izvorno lingvisti~ke. Tada su one ve} fazifikovane itranslacija nije potrebna.


3.7.4.4 Fazi zakqu~ivawe

U fazi logici se moraju definisati novi operatori analogni AND, OR iNOT. Uglavnom se koriste slede}e definicije:

AND: AB = min{A; A} OR: AB = max{A; A} NOT: A = 1 - A

Fazi zakqu~ivawe se sastoji od dve komponente:

agregacija premisa (kra}e agregacija) - kombinacija ulaznih varijabli upravilo, da se formuli{e stepen odgovarawa pravila datoj situaciji; tajstepen se odre|uje pomo}u DoS (Degree-of-Support) i

agregacija rezultata - rezultati pravila sa istim zakqu~kom se kombinuju,agregiraju u jednu vrednost.

Agregacija premisa operatorima fazi logike

MIN i MAX operatori nisu bili jedini, ali su postali naj~e{}e kori{}enioperatori. Me|u razlozima se isti~u prirodnost i jednostavnost, kao i brzina(bitno kod npr. kontrolisawa u procesnoj tehnici) i matemati~ke osobine.

Postoje odre|ena ograni~ewa u izraàjnosti ovih operatora. Zato sepribegava ekpanziji pravila ({to moè odvesti u „eksploziju“ - prekobrojnost)ili kori{}ewu nekih drugih operatora. Tipi~an primer su kompenzacionioperatori poput Gama operatora koji je generalizacija Bulovog AND (sli~no kaoMIN), ali omogu}ava kompenzaciju.

Naime, kada ~ovek povezuje dva kriterija sa lingvisti~kim „i“, obi~nopodrazumeva da oba moraju biti zadovoqena. [to su vi{e kriterijumi ispuweni,tim je boqe. Tako|e, kao na primeru kupovine automobila - mawu brzinu kolamoè da kompenzuje ekonomi~nija potro{wa goriva. Dolazi se do pojma „stepenkompenzacije“, koji nije konstanta u razmi{qawu ve} zavisi od konteksta. Postojeslu~ajevi u kojima se ne moè govoriti o kompenzaciji.

U qudskom prosu|ivawu, postoji ~itav spektar agregirawa. Me|utim,svakodnevni jezik daje samo dve re~i za agregaciju: „i“ i „ili“. Minimumpredstavqa ekstremno „i“ tako {to posmatra samo mawe zadovoqen kriterijum, amaksimum predstavqa ekstremno „ili“ i posmatra samo vi{e zadovoqenkriterijum. Agregacije koje koristimo su locirane izme|u ovih ekstrema - onebliè minimumu zovemo „i“, a one bliè maksimumu „ili“. Ponekad je agregacijata~no izme|u ekstrema i tada je te{ko odrediti pravu re~.

Ipak, komunikacija obi~no nije tako te{ka. Moè se predpostaviti stepenkompenzacije (iz konteksta iskaza) ili se moè postaviti dodatno pitawe. Fazisistem nema tu mogu}nost - ne moè da zna {ta smo mislili i ne moè dodatno dapita. Stoga, za takve slu~ajeve treba definisati stepen kompenzacije.


Agregacija rezultata

U praksi se koriste dva matemati~ka modela:

maksimalna operacija (MAX) - podrazumeva se da su u fazi sistemima svapravila formulisana alternativno i ~esto reprezentuje logi~ko ILI.Maksima „Pobedniku sve“ ilustruje MAX - samo }e tvr|ewe iz najja~eg pravilabiti defazifikovano. Ako jedno pravilo tvrdi istinu sa stepenom 0,5 i 20pravila tvrdi la` sa stepenom 0,5 , onda su istina i la` ravnopravni. Ovo setraì u ve}ini aplikacija - vi{e pravila sa istim tvr|ewem ne zna~i da je totvr|ewe vi{e istinito;

ograni~ena suma (BSUM - bounded sum) - pre defazifikacije se izvr{avasumirawe stepena. Ovaj model se koristi u aplikacijama u kojima nije poèqnoda se posmatra samo najvi{e dostignuti stepen za vrednost izlazne varijable,ve} stepeni svih pravila za tu vrednost. Ako je suma ve}a od 1, onda se uzima daje jednaka 1 i tada se kaè da je tvr|ewe potpuno istinito. „Jedan ~ovek, jedanglas“ najboqe ilustruje BSUM.

3.7.4.5 Defazifikacija

Postoje razne metode defazifikacije. Da bi se odabrala prava, potrebno jerazumeti razli~ita (iskustvena) lingvisti~ka zna~ewa defazifikacije:

odre|ivawe „kompromisnog re{ewa“ (best compromise) - najadekvatnijegrezultata

odre|ivawe „najprimenqivijeg (najverodostojnijeg) rezultata“.

Metoda „Teì{te (centar) maksimuma“ (CoM - Center of Maximum) prvoodre|uje najtipi~niju vrednost i zatim izra~unava kompromisno re{ewe. MetodaCoM je u stvari metoda „Teì{na ta~ka“ (CoG - Center of Gravity) koja koristi samojednu MBF. Metoda CoG se sre}e i kao „Teì{te povr{ine“ (CoA - Center of Area).Ove tri metode su se nekada koristile u ve}ini implementacija fazi logike. Sadasu metode CaA/CoG va`ne vi{e iz istorijskih razloga, dok je prisutnijeupro{}ewe CoA - fast CoA.

Me|utim, ove metode su ponekad neprimenqive, ~ak besmislene. Pogodanprimer je automobil kome se na putu nalazi prepreka. Tada je potrebannajprimenqiviji rezultat, a metoda koja daje taj rezultat je „Sredwa vrednostmaksimuma“ (MoM - Mean of maximum). Umesto balansirawa razli~itih rezultata,MoM selektuje tipi~nu vrednost najvalidnijeg lingvisti~kog uslova. U primeru}e automobil skrenuti ili levo, ili desno. Postoje i vi{e teorijske varijanteMoM - LoM (Left of maximum) i RoM (Right of maximum).

Kod DSS izbor metode zavisi od konteksta odluke - CoM je pogodan zakvantitativne (plan buxeta, kreditna podobnost ili prioritet projekata), a MoMza kvalitativne (ilegalnosti kod kreditnih kartica ili segmentacija trì{ta)odluke.

U nekim aplikacijama, lingvisti~ka interpretacija je dovoqna (nijepotrebna defazifikacija). Naredna tabela daje saèt uvid u komparaciju metodadefazifikacije:


CoA/CoG CoM MoM

Lingvisti~kekarakteristike

„Kompromis“ „Kompromis“ „Najprimenqivijere{ewe“

Prilago|enostintuiciji

Neizvodqiva zbog raznolikihoblika i velikog preklapawaMBF

Dobra Dobra

Neprekidnost * Da Da Ne

Efikasnostizra~unavawa

Veoma niska Visoka Veoma visoka

AplikacijeKontrola, DS, analizapodataka

Kontrola, DS,analiza podataka

Prepoznavawe oblika, DS,analiza podataka

Tabela 3.8 Komparacija metoda defazifikacije

*Neprekidnost - infitezimalno mala promena ulazne varijable ne izazivanaglu promenu izlazne varijable.

Redukcija informacija usled defazifikacije nastaje zato {to jematemati~ki defazifikacija mapirawe vektora u realni broj. Mapirawe nijejedinstveno, te razli~iti vektori mogu dati isti rezultat defazifikacije.

Za ve}inu tehni~kih fazi aplikacija, informacija o dvosmislenoj prirodidefazifikovanog rezultata ne predstavqa problem. U DSS aplikacijama jedruga~ije - koriste se napredne metode, npr. rangirawe MBF.

3.7.4.5 Osnove neurofazi dizajna

Fazi logika opona{a proces dono{ewa odluka kod qudi, na veoma visokomnivou apstrakcije prirodnog jezika. Suprotno, neuronske mreè poku{avaju dakopiraju na~in rada qudskog mozga na najnièm nivou - „hardver“ nivou. Ovo ipaknisu suprostavqene tehnike. Kombinacija eksplicitne reprezentacije znawa fazilogike sa mo}i u~ewa neuronskih mreà daje NeuroFazi.

Neuronske mreè Fazi logika

Reprezentacijaznawa

Implicitna, sistem se ne moè lakointerpretirati ili modifikovati (-)

Eksplicitna, laka i efikasna veri-fikacija i optimizacija (+++)

Mogu}nost zaobu~avawe

Samostalna obuka - u~ewe iz skupovauzoraka (+++)

Ne postoji, sve se mora eksplicitnodefinisati (-)

Tabela 3.9 Prednosti i mane neuronskih mreà i fazi logike

Nasuprot ostalim adaptivnim tehnologijama, mogu}e je iskqu~iti nekedelove iz obuke. Uvek se moè interpretirati rezultat trenutnog stawa sistema,jer poseduje samoobrazlaù}a fazi pravila i lingvisti~ke varijable.

Nepogodno je {to je NeuroFazi mlada tehnologija, koju su razvijali vi{equdi iz prakse nego istraìva~i. Drugo, smawen je stepen slobode algoritma zaobu~avawe u odnosu na neuronske mreè. U ve}ini slu~ajeva je ovo pre prednostnego mana, ali ako postoje velike koli~ine podataka i nikakvo predznawe -neurofazi ne}e na}i re{ewe.


Primer 2: procena podobnosti za kreditirawe

Angaòvani su eksperti iz oblasti kredita. Eksperti su svoje znawepredstavili pravilima koja su direktno uneta - ru~no definisawe pravila.Tako|e su dostavili i primere odlu~ivawa, na osnovu kojih je vr{eno obu~avawemodula za produkovawe pravila. Oba skupa pravila su davala jednake izlaznerezultate (odluke).

Me|utim, pravila koja daje modul nisu ista ru~no definisanim, iz mnogihrazloga:

obu~avaju}i skup nije ta~na reprezentacija ekspertovog znawa u obu~avaju}im BP postoji odre|ena nekonzistentnost podataka modul ne kombinuje pravila, ve} samo modifikuje postoje}a modul produkuje male, postojane gre{ke (eventualno se uklawaju pravila

sa malim DoS koji indicira, ali ne i dokazuje minornost pravila).

Integracija fazi logike i standardnih softvera

Integracija u Excel je relativno jednostavna. Mogu}e je kreirati faziradnu tabelu, uz mnoge primene. Na primer, pra}ewe zaliha sa identifikacijomtrendova i kupi/prodaj/~ekaj odlu~ivawem.

Primer 3: procewivawe zaliha

Glavni ciq i izazov za DSS leì u otkrivawu kontinualnih trendova iwihovom razdvajawu od trenutnih (u automatizovanoj formi), iako ~esto nisuo~igledno razli~iti. Potrebno je npr. otkriti trenutno pozitivno kretawetrenda koji je generalno negativan. Raspoloìve tehnike za analizu se zasnivaju napretpostavci da se prognoza moè odrediti pra}ewem i analizirawem kretawazaliha. Nema poverewa u vrednost ovog pristupa.

Suprotan metod se zasniva na rundom-walk teoriji, koja tretira kretawe kaoslu~ajan proces - zavisi od prethodnog stawa, ali ne i od trenda. Ova ideja zahtevafleksibilnu integraciju i objektno-orjentisane strategije, koje se obi~nozasnivaju na intuitivnim pravilima.

Integracija u Visual Basic zahteva DLL interfejs.

Primer 4: kontrola kvaliteta

U aplikacijama za kontrolu kvaliteta su ~esto prisutni raznolikikriterijumi koji se kombinuju. Tako|e je tipi~no da se ti kriterijumi ne mogudirektno prikazati matemati~kim relacijama. I u takvim slu~ajevima, fazilogika obi~no nudi brza i prakti~na re{ewa. U pitawu je proizvo|a~ auto guma,koji je primenio optimizaciju proizvoda (evaluaciju odlika guma).

Integracija u MS-Access zahteva postojawe modula u ciqu obezbe|ewa triosnovne integracione funkcije: pristup, izra~unavawe i odjavu.


Primer 5: investiciona banka

Fazi klasifikacija (izra~unavawe demografskih klasa samo preko jednogbroja) ima za ciq da smawi kompleksnost sistema. Originalna aplikacija imadeset ulaznih klasa (lingvisti~kih uslova). U fazi klasifikaciji okruèwe nemora biti sme{teno u ta~no jednu klasu. Na primer, „uglavnom Klasa3, pomaloKlasa5“, daje vrednost lingvisti~ke varijable Gclass:= {Class1, Class2, Class3, Class4,Class5, Class6, Class7, Class8, Class9, Class10} = {0; 0; 0,2; 0; 0,8; 0; 0; 0; 0; 0} .Originalna aplikacija ima 170 pravila i 9 ulaznih varijabli.

Upotreba fazi logike u investicionom bankarstvu je relativno nova u SAD,dok mnoge evropske i azijske banke imaju dugotrajno iskustvo (postoje primeri zainvesticione fondove i menice, u Japanu).

Primeri iz poslovne prakse

Primer 6: fazi ra~un u aplikacijama za hipoteke

Reprezentovawe bankovne politike pomo}u fazi pravila je brè itransparentnije u pore|ewu sa merama u klasi~nim bodovnim karticama. Tako|e,svaka promena politike kompanije se moè implementirati brzo i lako i nezahteva mu~na kreirawa novih parametara.

Razmatrano je i re{ewe pomo}u neuronskih mreà. Me|utim, ~ak i kadaneuronska mreà funkcioni{e idealno, ona samo podraàva podatke izpro{losti. Problemi su isti kao kod statisti~ki pode{enih bodovnih kartica.

Primer 7: odre|ivawe finansijske likvidnosti za kreditirawe

Predstavqen je ASK firme INFORM. Prva instalacija datira iz 1986., {toga verovatno ~ini prvim komercijalnim fazi DSS-om. Zasniva se napsiholingvisti~kim empirijskim istraìvawima u ranim devedesetim. Umestokori{}ewa neuronskih mreà za obu~avawe fazi sistema, ASK koristiodgovaraju}e statisti~ke algoritme. Predstavqen je slu~aj pilot korisnika ASK,anonimne {vajcarske banke.

U malim mestima u Alpima, dalekose`ne odluke se donose vi{e na bazifamilijarnih veza nego na prora~unima. âk i u ve}im mestima, slu`beniciinterpretiraju kriterijume na toliko razli~itih na~ina, da osobe koje su bileodbijene na jednom mestu treba samo da posete neko drugo i da mo`da dobiju kredit.Zato se banka odlu~ila za automatizovano re{ewe koje daje konzistentnuproceduru dono{ewa odluka. Tako|e, kreditna politika se moè mewaticentralno iz Ciriha.

U pojednostavqenoj strukturi sistema postoji osam ulaznih (~etiri „tvrde“i ~etiri „meke“) varijabli. Struktura je hijerarhijska: na svakom ~voru, dvaelementa se agregiraju u jedan, novi ~vor. Tako nastaju tri sloja apstrakcije, kojikomprimuju (kondenzuju) dobijene informacije. Sli~no qudima, koji uzimaju mnogeulazne varijable u obzir da daju jedan apstraktni sud, agregaciona hijerarhija senastavqa do izlaznog ~vora (varijabla Pogodnost_za_kredit) - informacije sanajvi{im stepenom apstrakcije u hijerarhiji.


Primer 8: detekcija krivotvorewa kartica

êkovne i telefonske kartice se mogu na sli~ne na~ine zloupotrebqavati.Kompanije skrivaju svoje metode detekcije. Opravdano strahuju da sama ~iwenicada primewuju fazi logiku moè pomo}i delikventima.

U pitawu je organizacija koja nudi bankarske i osiguravaju}e usluge. Poredstepena verovatno}e zloupotrebe, fazi sistem daje indikaciju za{to klijentasmatra potencijalnim prevarantom. Neophodna je kombinacija sedam ulaznihvarijabli - ni jedna ne moè samostalno identifikovati kriminalno pona{awe.

Pored tri navedena, u praksi su poznati slede}i primeri primene ufinansijskim aplikacijama: odre|ivawe rizika zakupa, klasifikacijainvestitora, analiza dobavqa~a, odre|ivawe ciqnih grupa, sekvencirawe iterminirawe, optimizaciona istraìvawa i razvojni projekti, na znawuzasnovano prognozirawe. U oblasti analize podataka razvijene su aplikacije za:

● fazi analizu podataka u kozmetici,● prepoznavawe adresa stranaka u bazama podataka i● predvi|awe trajawa hospitalizacije.

4. Glava

Rezultati empirijskih istraìvawa

Postoje}e stawe u NBJ podrazumeva kvalitetno (metodolo{ki podràno)funkcionisawe OLTP. Moè se re}i da je uspe{no izvr{en prelazak sa host basedarhitekture (Honeywell, mre`na BP, COBOL) na klijent/server okruèwe irelacione BP. U novosadskoj Filijali se koristi RDBMS Progress 9, dok, poredtoga, u sistemu NBJ funkcioni{u ORACLE i SQL Server.

Od ~itavog spektra pogodnosti i mogu}nosti koje daje DW, procena je da suosnovne motivacione ta~ke za uvo|ewe DW arhitekture u sistem NBJ:

spoznaja ograni~enosti primene i mo}i relacionog i ER modela u oblastimai aplikacijama koje analiziraju poslovawe i okruèwe,

rezultati teorije kognitivne disonance (Leon Fistinger) i postojawestrategijskog paradoksa,

potreba za savremenim DSS i odgovaraju}om arhitekturom zafunkcionisawe tih sistema,

pogodnosti dimenzionog modelovawa i {iroka ponuda, primena i mo} alata za Data Mining kao i Text Mining.

U protekloj deceniji u svetu nije razvijena neke stroga i op{te prihva}enametodologija projektovawa i izgradwe DW. Pored toga, nema smisla govoriti okonceptualnom, ve} samo o (logi~kom) implementacionom projektovawu DW bazepodataka [5]. Me}utim, veli~ina baze i sloènost upita akcentuju pode{avaweperformansi ove BP.


4.1 PRIKAZ POSLOVNOG SISTEMA

Ustav SR Jugoslavije utvr|uje Narodnu banku Jugoslavije kao samostalnu ijedinstvenu emisionu ustanovu monetarnog sistema SR Jugoslavije, koja jeodgovorna za monetarnu politiku, za stabilnost doma}e valute i finansijskudisciplinu i za obavqawe drugih poslova odre|enih saveznim zakonom. Narodnabanka Jugoslavije (NBJ) prati i prou~ava pojave i kretawa u oblasti odnosa kojisu predmet zajedni~ke emisione, nov~ane i devizne politike i zajedni~kih osnovakreditne politike, kao i pojave i kretawa u kreditnim odnosima sainostranstvom.

Osnovnu koncepciju, na~in funkcionisawa i nosioce monetarno-kreditnogi deviznog sistema u nas defini{u:

Ustav SR Jugoslavije (~lan 114), Zakon o Narodnoj banci Jugoslavije, Zakon o bankama i drugi sistemski zakoni i odluke.

Monetarno-kreditni i devizni sistemi se mogu najpre definisati kaodelovi ukupnog finansijskog sistema. Pri tome se uzima da finansijski sistemobuhvata sve pojave, tokove, odnose i subjekte koji su u vezi sa stvarawem,raspodelom, tro{ewem i upravqawem nov~anim sredstvima. U okviru ovogsistema, kao poseban deo se mogu izdvojiti podsistemi koji ~ine osnovne funkcijeNarodne banke i koji se odnose na monetarne finansije i devizno poslovawe, akoji se u najve}oj meri ostvaruju preko poslovnih banaka.

Prema tome, Narodna banka Jugoslavije je osnovni nosilac i odgovorna je zafunkcionisawe monetarno-kreditnog i (u najve}oj meri) deviznog sistema, i u tomsmislu ona:

● reguli{e koli~inu novca i na~in odr`avawa likvidnosti u zamqi i premainostranstvu;

● obavqa i vr{i kontrolu obavqawa platnog prometa;● odgovorna je za stabilnost doma}e valute i u tom smislu zajedno sa

Saveznom vladom vodi politiku kursa dinara;● radi obezbe|ewa finansijske discipline vr{i kontrolu banaka i drugih

finansijskih organizacija;● obavqa druge poslove koji su u vezi sa izvr{avawem wene osnovne funkcije.

4.1.1 Zadaci NBJ

Izvr{avawe poslova za potrebe monetarno-kreditnog regulisawa(ukqu~uju}i i devizne transakcije) se odvija povezano, sa izra`enom me|usobnominterakcijom na relaciji NBJ - poslovno bankarstvo. Pri tome treba imati u viduvi{estruke zahteve koji proisti~u, pre svega, iz posebne uloge i zna~ajnihzadataka koje Narodna banka ima u ovoj oblasti. U tu svrhu se zadaci Narodne

Глава 4 – Резултати емпиријских истраживања 93.

banke iz domena monetarno-kreditnog i deviznog sistema i politike mogugrupisati u tri osnovne celine:

1. zadaci koji imaju upravqa~ko-regulativni karakter,2. zadaci iz domena izvr{avawa wene kontrolne funkcije i3. zadaci koji se odnose na formirawe informaciono-dokumentacione

osnove za planirawe i statisti~ko informisawe.

Va`niji zadaci Narodne banke Jugoslavije koji imaju upravqa~ko-regulativni karakter su:

-regulisawe obima i strukture nov~ane mase, {to se postiè primenomodgovaraju}ih mera i instrumenata monetarno-kreditnog regulisawa,

-odràvawe potrebnog obima deviznih rezervi zemqe,-odràvawe likvidnosti banaka, {to se ostvaruje stalnom kontrolom

wihovog stawa sredstava primarne likvidnosti i kori{}ewa sekundarnih izvoralikvidnosti,

-odràvawe likvidnosti u pla}awima prema inostranstvu,-pra}ewe i uskla|ivawe kretawa obima primarnog novca NBJ i kontrola

procesa multiplikacije,-regulisawe obima kreditnog potencijala banaka sa ciqem da se pove}a ili

smawi mogu}nost bankarskog sistema u domenu kreirawa novca, zavisno odkonkretnih potreba i zadataka monetarno-kreditne politike,

-ostvarivawe ciqeva i zadataka monetarno-kreditne politike kontrolomobima i strukture plasmana centralne banke, prvenstveno bankama, kao ineposrednim korisnicima (buxeti i dr.).

Zadaci iz domena kontrolne funkcije Narodne banke u najve}oj meri seodnose na:

-kontrolu primene odre|enih mera emisione, nov~ane, kreditne i deviznepolitike,

-stalnu kontrolu dinarske i devizne likvidnosti i pra}ewa kreditnogpotencijala banaka i drugih finansijskih organizacija (radi kontrole kreditnemultiplikacije itd.),

-kontrolu kori{}ewa kredita iz primarne emisije i ostalih dinarskihplasmana Narodne banke.

Svoju kontrolnu funkciju NBJ obavqa na osnovu dokumentacije i podataka koje jojdostavqaju banke, kao i na osnovu podataka kojima raspolaè Narodna banka.Naknadnu kontrolu NBJ obavqa uvidom u dokumentaciju i evidencije i ona seodvija neposredno u bankama. Poseban vid kontrole je tzv. bonitetna kontrola,odnosno kontrola kvaliteta poslovawa banaka.

Iz specifi~ne i zna~ajne uloge u monetarno-kreditnom i deviznom sistemuzemqe, a zatim i wene kontrolne funkcije u odnosu na mreù poslovnih banaka,moè se re}i da je Narodna banka sloèn dinami~ki organizacioni sistem.Imaju}i u vidu navedene oblasti koje ~ine osnovnu funkciju Narodne banke, kao iwenu upravqa~ko-kontrolnu ulogu u domenu poslovawa banaka, mogu}e je utvrditislede}e delove (podsisteme) NBJ:

1. Podsistem monetarno-kreditnog poslovawa,2. Podsistem pra}ewa poslovawa banaka i drugih finansijskih

organizacija,


3. Podsistem o ekonomskim odnosima sa inostranstvom (u okviru koga de-vizno poslovawe ~ini najzna~ajniji deo).

4.1.2 Podsistem monetarno-kreditnog regulisawa

S obzirom na izra`enu funkcionalnu povezanost i intenzivnu i dinami~nuinterakciju izme|u prva dva podsistema, oni se mogu posmatrati integralno kaoPodsistem monetarno-kreditnog regulisawa.

NBJ sprovodi monetarno-kreditno regulisawe u najve}oj meri prekoposlovnog bankarstva. Sli~no je, mada u mawoj meri, i u slu~aju sa sistemomekonomskih odnosa sa inostranstvom odnosno deviznim sistemom. Mogli bi sedefinisati slede}i podsistemi i moduli Podsistema monetarno-kreditnogregulisawa:

1. Podsistem: Krediti i ostali plasmani NBJ1.1 Dinarski plasmani,1.2 Devizni plasmani,1.3 Aktivne kamate i naknade NBJ;

2. Podsistem: Primarni novac i ostala pasiva NBJ2.1 Primarni novac (depoziti kod NB, gotov novac u opticaju, i dr.),2.2 Devizna pasiva i ostala pasiva,2.3 Ostala pasiva;

3. Modul: Nov~ana masa3.1 Depozitni novac,3.2 Gotov novac u opticaju;

4. Podsistem: Krediti i ostali plasmani banaka4.1 Dinarski plasmani,4.2 Devizni plasmani,4.3 Aktivne kamate i naknade;

5. Podsistem: Kreditni potencijal banaka5.1 Depoziti,5.2 Primarna emisija,5.3 Fondovi i dr;

6. Podsistem: Likvidnost banaka6.1 Primarna likvidnost,6.2 Sekundarni izvori likvidnosti (obavezna rezerva, krediti NB,

pozajmice na tr`i{tu novca i dr.),6.3 Hartije od vrednosti (od zna~aja za likvidnost);

7. Modul: Devizne transakcije sa inostranstvom7.1. Kreirawe i povla~ewe primarne emisije po ovom osnovu,7.2. Teku}e i kapitalne devizne transakcije;

8. Podsistem: Kontrola monetarno-kreditnog poslovawa8.1 Kontrola primene mera i instrumenata monetarno-kreditne po-

litike,


8.2 Kontrola nov~anih tokova;

9. Podsistem: Pra}ewe i ocena kvaliteta poslovawa banaka.Posebno zna~ajan podsistem NBJ se odnosi na podatke za pra}ewe kvaliteta

ukupnog (i po pojedinim segmentima) poslovawa banaka. Ukqu~ivawem na{e zemqeu me|unarodne finansijske organizacije i tokove ovaj podsistem }e jo{ vi{edobiti na zna~aju. U zemqama sa razvijenim finansijskim trì{tima supropisani posebni standardi za ocenu kvaliteta poslovawa banaka koji su obi~nogrupisani u {est kategorija:

- pokazateqi likvidnosti,- pokazateqi kamatne aktive,- pokazateqi finansijske strukture,- pokazateqi operativnih rashoda,- pokazateqi neto kamatne marè i- pokazateqi profitabilnosti.

Postoje}a zakonska regulativa u nas predvi|a da banke moraju u svomposlovawu da se pridràvaju odre|enih kriterijuma vezanih za visinu kapitala iobavezu da vr{e limitirawe i raspored plasmana na ve}i broj korisnika. Ovimre{ewem zakonodavac je nameravao da za{titi deponente banke, kao i da do najve}emogu}e mere smawi sistemski rizik od kraha finansijskog sistema.Tako supropisani minimum kapitala, u~e{}e kapitala i u~e{}e sredstava stanovni{tva uukupnoj pasivi banke.

Drugu veoma va`nu oblast nadzora nad poslovawem banaka koja je regulisanazakonom predstavqa kontrola kreditnog rizika. Naime, banke su u obavezi daizvr{e limitirawe visine svojih plasmana pojedinim korisnicima, kao i daizvr{e wihovu diverzifikaciju kako bi se izbegli rizici velikih gubitaka.Takoje predvi|eno da banka mora da se pridràva odredbi o velikom i najve}emkreditu, o procentu ulagawa kapitala banke u akcije preduze}a i drugih banaka.Banke moraju da kratkoro~nim plasmanima i nov~anim sredstvima pokriju upotpunosti kratkoro~ne izvore. Tako|e, propisan je i odnos devizne aktive idevizne pasive banaka.

Drugi institucionalni osnov za pra}ewe finansijskih pokazateqa banakapredstavqaju odredbe Pravilnika o uslovima za u~e{}e banaka na finansijskomtrì{tu1, koga je propisala Savezna komisija za hartije od vrednosti ifinansijsko trì{te. Pored ostalog, ovim Pravilnikom je predvi|en obim isadràj informacija koje su banke du`ne da dostave Komisiji prilikompodno{ewa zahteva za odobrewe emisije hartija od vrednosti (HOV). Poredosnovnih statusnih informacija, vezanih za sedi{te banke, organizacionu mreù,dozvolu za rad NBJ i dr., banke dostavqaju i podatke o svom imovinskom stawu iposlovawu, o ukupnom platnom prometu sa inostranstvom i druge va`nije podatkeo deviznom poslovawu, zatim podatke o emisiji HOV i sl.

Kona~no, polazni osnov za pra}ewe performansi banaka predstavqa iOdluka o minimumu sadràja ekonomsko-finansijske revizije2, kojom je propisansadràj revizije i oblik izve{taja revizora koga banke moraju da dostavqajuNarodnoj banci Jugoslavije. Pored ostalog, revizija sadrì i analizuperformansi (boniteta) banaka.

1 Slu`beni list SRJ broj 2/96.2 Slu`beni list SRJ broj 15/95.


Bonitet banke se posmatra sa vi{e aspekata. Prva tri aspekta (analizakapitala, kvaliteta aktive i pokazateqa poslovawa) se u najve}oj meri oslawajuna ~lanove 26. i 27. Zakona o bankama i predvi|aju ocenu boniteta banke sa aspektasolventnosti i za{tite od kreditnog rizika. Slede}i analiziran aspektposlovawa banke je produktivnost, koja se ocewuje na osnovu kamata, kamatonosneaktive, nenapla}enih plasmana, kao i propisanih odnosa, kao {to su: odnos dobitiprema aktivi, prihoda od kamata prema aktivi, kamatnih rashoda prema pasivi,ostalih prihoda prema aktivi i ostalih rashoda prema pasivi. Likvidnost bankese analizira sa aspekta ro~ne uskla|enosti aktive i pasive, odnosno uzroka koji suproizveli fakti~ko stawe. Na kraju analize boniteta banaka posebno se razmatrakadrovska, tehni~ka i organizaciona osposobqenost banke i daje ocena o wenominformacionom sistemu.

Sledi pregled najva`nijih indikatora za potrebe kontinuiranog pra}ewa iocenu kvaliteta poslovawa banaka:

indikatori teku}e likvidnosti banaka:a) Primarna likvidnost (dnevno pra}ewe),b) Sekundarni izvori likvidnosti (dnevno),c) Izvr{avawe obaveza banke (dnevno);

kreditna aktivnost i kreditni potencijal banke:a) Stawe dinarskih plasmana (dnevno),b) Kreditni potencijal banke (dekadno),c) Stawe obaveza po osnovu primarne emisije (dnevno),d) Trajni kapital (mese~no);

osnovni indikatori deviznog poslovawa (dekadno i mese~no) i indikatori o kvalitetu bilansa banaka (mese~no).

Navedeni su samo osnovni indikatori koji se prate za svaku banku u navedenimrokovima (periodici). Detaqniji prikaz postoji u Zborniku radova sa savetovawa„Banke i preduze}a u tranziciji“, Ni{, maj 1996. godine.

4.1.3 Podsistem o ekonomskim odnosima sa inostranstvom

Obim i raznovrsnost ekonomskih odnosa sa inostranstvom (i deviznihtransakcija po tom osnovu) mo`e se ilustrovati klasifikacijom tokova iaktivnosti u ovoj oblasti. Sa stanovi{ta obuhvatnosti sistema ekonomskih odnosasa inostranstvom (EOI) mogu se razlikovati:

robni tokovi (izvoz i uvoz roba) tokovi usluga (izvoz i uvoz usluga) kreditni odnosi sa inostranstvom izvoz i uvoz tehnologije i znawa finansijski tokovi (platni promet sa inostranstvom) kretawe qudi preko granice zemqe (u oba pravca) sa razli~itim

ekonomskim motivima.

U odvijawu pomenutih tokova EOI razlikuju se slede}e osnovne faze i to:


1. faza izrade devizne politike i platnog bilansa,2. faza zakqu~ivawa ugovora i prijavqivawa zakqu~enih poslova, odnosno

wihova registracija kod nadle`nih organa,3. faza realizacije izvozno-uvoznih poslova (prelazak robe preko carinske

granice, cariwewe i dr.)4. faza naplate izvezene odnosno pla}awa uvezene robe, usluga i ostalo,5. faza obra~una podsticaja,6. faza zakqu~ivawa, kori{}ewa i otplate kreditnih zaduèwa u

inostranstvu,7. ostali tokovi u EOI.

Нosiоci odnosa u oblasti EOI су tako|e brojni i raznovrsni:

- preduze}a, preduzetnici i druga pravna lica,- poslovna udruèwa i drugi oblici organizovawa privrede,- poslovne banke i druge finansijske organizacije (DFO), NBJ i druge

finansijske institucije,- fondovi, organizacije za osigurawa i reosigurawe imovine i lica i dr.,- federacija i republike i wihovi organi i organizacije,- ostale dru{tveno-politi~ke zajednice i wihovi organi i organizacije,- udruèwa gra|ana i sami gra|ani kao privatna lica i dr.

Obim, sloènost i raznovrsnost ovih odnosa upu}uje na zakqu~ak da je oEOI potrebno blagovremeno obezbe|ivati zna~ajan obim raznorodnih podataka. Utom smislu su se na nivou zemqe u proteklom periodu razvijali odgovaraju}ipodsistemi u okviru kojih se obavqa prikupqawe, obrada, prenos i iskazivawepotrebnih podataka. Ovde se navode samo najva`niji organi i organizacije kojiimaju odre|ene nadle`nosti u domenu funkcionisawa sistema EOI:

1. Savezna vlada (nadle`no ministarstvo),2. Savezna uprava carina - SUC,3. Narodna banka Jugoslavije,4. Savezni zavod za statistiku,5. Savezni devizni inspektorat i druge.

Osnovne smernice i ciqeve, kao i najva`nije kvantifikacije i pokazateqeEOI za naredni period utvr|uje Savezna vlada, a detaqniju projekciju Platnogbilansa Jugoslavije i deviznih transakcija izra|uje NBJ. Platni bilans obuhvatafinansijske i druge ekonomske transakcije izme|u doma}ih i stranih lica, anaro~ito: vrednost i naplata izvoza robe i usluga i ostalog nerobnog priliva;vrednost i pla}awa uvoza robe i usluga i ostalog nerobnog odliva, finansijsketransakcije sa inostranstvom; odgovaraju}a salda teku}ih i finansijskihtransakcija sa inostranstvom, kao i promene u deviznim rezervama.

Devizne rezerve Jugoslavije sluè za odràvawe op{te likvidnosti zemqe upla}awima inostranstvu i intervencije na deviznom trì{tu. Sastoje se odstalnih deviznih rezervi i teku}ih deviznih rezervi.

Prijavqivawe izvoznih i uvoznih poslova je zakonska obavezaspoqnotrgovinskih organizacija. Prema vaè}em Zakonu o spoqnotrgovinskomposlovawu, nadle`na filijala NBJ, na ~ijem se podru~ju nalazi preduze}eproizvo|a~ odnosno korisnik robe ili usluge, vr{i evidentirawe podnete prijaveo zakqu~enom poslu izvoza odnosno uvoza kao i dokumentacije koja se uz prijavu


prilaè. Nadle`na filijala NBJ vr{i pra}ewe realizacije prijavqenih poslovai wihovo napla}ivawe odnosno pla}awe u zakonskom roku - u vidu vo|ewa devizno-dokumentacionog lista.

Realizacija izvoza odnosno uvoza prijavquje se u skladu sa Carinskimzakonom i Pravilnikom o kori{}ewu isprava u carinskom postupku - napropisanim obrascima: jedinstvena carinska isprava, carinska isprava zaprijavqivawe robe i dr. Spoqnotrgovinske organizacije podnose carinskimorganima propisane obrasce i predvi|enu prate}u dokumentaciju, radi regulisawaprelaska robe i usluga preko carinske granice. Na osnovu prikupqenogmaterijala statisti~ki zavod u saradwi sa NBJ vr{i obradu i iskazivawepodataka o uvozu i izvozu roba i usluga, neophodnih za informisawe relevantnihkorisnika odnosno u~esnika u EOI.

Tokovima platnog prometa sa inostranstvom su obuhva}ena sva pla}awa inaplate koje se vr{e izme|u na{ih ovla{}enih banaka i inostranih partnera.Ova oblast je regulisana Zakonom o deviznom poslovawu, Odlukom i Uputstvom ijedinstvenom vr{ewu platnog prometa sa inostranstvom i dr.

Ovla{}ene banke u ime i za ra~un pravnih i fizi~kih lica vr{e naplatuili pla}awe i o tim transakcijama na propisanim obrascima izve{tavajunadle`nu filijalu NBJ. Organizacije koje izvoze robu i pruàju usluge stranim idoma}im licima u me|unarodnom saobra}aju ostvaruju pravo na stimulacije -povra}aj da`bina i podsticawe izvoza.

Zna~aj kreditnih poslova sa inostranstvom, sa gledi{ta obezbe|ewadopunskih izvora za finansirawe ekonomskog razvoja zemqe, je uslovio da se celaoblast reguli{e posebnim zakonom (Zakon o kreditnim poslovima sainostranstvom). Nakon zakqu~ewa ugovora o kreditnom poslu, preduze}e prekoposlovne banke podnosi prijavu o zakqu~ewu kredita teritorijalno nadle`nojfilijali NBJ, radi kontrole, registracije prijave i evidentirawa planovakori{}ewa i otplate kredita.

Na osnovu datog prikaza osnovnog sadràja sistema EOI mogu}e jeidentifikovati osnovne funkcije koje se ostvaruju u sistemu, te identifikovatislede}e module:

1. modul spoqnotrgovinskog poslovawa,2. modul podsticaja izvoza roba i usluga,3. modul platnog prometa sa inostranstvom,4. modul kreditnih odnosa sa inostranstvom i5. modul ostalih tokova i poslova u EOI.

Polaze}i od raznovrsnosti odnosa koje sistem EOI obuhvata kao i nivoa ipotreba za informacijama, posebno treba ukazati na dvostruki aspekt izgradwe ifunkcionisawa wegovog informacionog sistema. Jednom ga posmatramo kaopodsistem informacionog sistema EOI, a drugi put kao podsisteminformacionog sistema NBJ.

4.1.4 Informacioni sistem NBJ

Da bi ostvarila svoju funkciju i izvr{ila navedene i ostale zadatke, NBJ jedu`na da obezbedi funkcionisawe odgovaraju}eg informacionog sistema (IS).Institucionalnu osnovu za funkcionisawe IS NBJ ~ine odredbe Zakona o


Narodnoj banci Jugoslavije3. Regulisani su i na~in i uslovi ukqu~ivawa banaka idrugih finansijskih organizacija (daqe: banke) u taj sistem.

U tom smislu, ovim zakonom je propisano da je NBJ ovla{}ena da radiizvr{avawa svojih funkcija, utvrdi obavezu banaka da evidentiraju, prikupqaju,obra|uju i obezbe|uju NBJ podatake koji se odnose na monetarna i devizna kretawai kreditne odnose sa inostranstvom. Isto tako, radi efikasnog izvr{avawazadataka iz svojih osnovnih funkcija, Narodna banka Jugoslavije razvija svojeinformacione sisteme u domenu monetarno-kreditne i devizne oblasti ikreditnih odnosa sa inostranstvom i propisuje na~in i uslove ukqu~ivawa banakau te sisteme.

Slede}a slika prikazuje trenutno stawe strukture IS NBJ:

ПОДСИСТЕМ МОНЕТАРНО-КРЕДИТНИХ ПОСЛОВА

1. ПЛАСМАНИ НБЈ1.1. КРЕДИТИ НБ

- контрола и одобравање- књижење промена- извештавање

1.2. ПОСЛОВАЊЕ СА ХОВ- контрола ХОВ- праћење портфеља ХОВ- остали послови са ХОВ- извештавање

1.3. ОБРАЧУН И НАПЛАТА КАМАТЕ НА ПЛАСМАНЕ

3 Zakon o NBJ (Slu`beni list SRJ broj 32/93.) ~lanovi 62. i 63.

СТАТИЧКА СТРУКТУРА ИИС

4. ПРАЋЕЊЕ ПОКАЗАТЕЉАЗА МОНЕТАРНО КРЕДИТНО

РЕГУЛИСАЊЕ

3.ПРАЋЕЊЕ СТАЊА ИТОКОВА ГОТОВОГ

НОВЦА

2. ОБРАЧУН И ПРАЋЕЊЕОБАВЕЗНЕ РЕЗЕРВЕ И

КАМАТЕ

1.ПЛАСМАНИ НБ

подсистемМОНЕТАРНОКРЕДИТНО

ПОСЛОВАЊЕ

4.ОСТАЛО ДЕВИЗНО ПОСЛОВАЊЕ

3.ПЛАТНИ ПРОМЕТ САИНОСТРАНСТВОМ

2.КРЕДИТНИ ОДНОСИСА ИНОСТРАНСТВОМ

1.СПОЉНОТРГОВИНСКОПОСЛОВАЊЕ

ДДК

подсистемЕКОНОМСКИОДНОСИ СА

ИНОСТРАНСТВОМ

5.ДЕВИЗНО ПОСЛОВАЊЕБАНАКА И

КОИ

4.ПРАЋЕЊЕ КВАЛИТЕТА(БОНИТЕТА) БАНАКА

3.ЛИКВИДНОСТ БАНАКА(примарна и секундарна)

2.ПОСЛОВНИ ПОТЕНЦИЈАЛИ ПЛАСНАНИ БАНАКА

1.СТАТУСНО СТАЊЕ ИОСНОВНИ ПОДАЦИ

О БАНЦИ

подсистемПОСЛОВАЊЕ

БАНАКАИ ДФО

4.ПРАЋЕЊЕ И ЕВИДЕНЦИЈАОСТАЛИХ ПОСЛОВА

3. ПРАЋЕЊЕ ОСНОВНИХСРЕДСТАВА

2.КАДРОВИ И ЗАРАДЕ

1.РАЧУНОВОДСТВЕНО- ФИНАНСИЈСКИ

ПОСЛОВИ

подсистемИНТЕРНО

ПОСЛОВАЊЕФИЛИЈАЛЕ

ИИС НБЈ


- обрачун и наплата камате на кредите- обрачун и наплата камате на ХОВ- извештавање

2. ОБРАЧУН И ПРАЋЕЊЕ ОБАВЕЗНЕ РЕЗЕРВЕ И КАМАТЕ- обрачун обавезне резерве- контрола и обрачун благајничких записа- обрачун и праћењe активних камата- обрачун и праћења пасивних камата- извештавање

3. ПРАЋЕЊЕ СТАЊА И ТОКОВА ГОТОВОГ НОВЦА- праћење и књижење трезорског пословања- праћење готовине у ЗОП-у (Завод ѕа обрачун и плаћање)- праћење готовине у банкама и ДФО- извештавање

4. ПРАЋЕЊЕ ПОКАЗАТЕЉА ЗА МОНЕТАРНО-КРЕДИТНО РЕГУЛИСАЊЕ4.1. НОВЧАНА МАСА

- депозитни новац- готов новац у оптицају- извештавање

4.2. ПОКАЗАТЕЉИ ПОСЛОВАЊА БАНАКА - пласмани банака (кредити и ХОВ)- депозити банака- капитал банака- камате банака…….

4.3 ПОКAЗАТЕЉИ ДЕВИЗНОГ И КРЕДИТНОГ ПОСЛОВАЊА С ИНОСТРАНСТВОМ- праћење девизних резерви НБ и банака- прилив и одлив девиза- стање узетих и датих кредита…...

ППООДДССИИССТТЕЕММ ЕЕККООННООММССККИИ ООДДННООССИИ ССАА ИИННООССТТРРААННССТТВВООММ

1. ПРАЋЕЊЕ СПОЉНОТРГОВИНСКОГ ПОСЛОВАЊА - ДДК1.1. ПРИЈАВЉИВАЊЕ СПОЉНОТРГОВИНСКИХ ПОСЛОВА1.2. ПРАЋЕЊЕ РЕАЛИЗАЦИЈЕ (ФИЗИЧКЕ И ФИНАНСИЈСКЕ)1.3. ПРОДУЖЕЊЕ РОКА УНОСА ДЕВИЗА1.4. ПРЕБИЈАЊЕ ДУГОВАЊА И ПОТРАЖИВАЊА1.5. ОБРАЧУНАВАЊЕ СТИМУЛАЦИЈА1.6. ИЗВЕШТАВАЊЕ

2. КРЕДИТНИ ОДНОСИ СА ИНОСТРАНСТВОМ2.1. КРЕДИТНА ЗАДУЖЕЊА У ИНОСТРАНСТВУ

- регистровање обавештења, пријаве и планова- праћење реализације кредитног задужења

2.2. КРЕДИТИ ДАТИ ИНОСТРАНСТВУ- регистровање пријаве и планова- праћење реализације кредитног одобрења

3. ПЛАТНИ ПРОМЕТ СА ИНОСТРАНСТВОМ3.1. ПРИХВАТАЊЕ И КОНТРОЛА НАЛОГА ПЛАТНОГ ПРОМЕТА СА

ИНОСТРАНСТВОМ3.2. ИЗВЕШТАВАЊЕ

4. ОСТАЛО ДЕВИЗНО ПОСЛОВАЊЕ


4.1. ДЕВИЗНА ШТЕДЊА ГРАЂАНА4.2. МЕЊАЧКИ ПОСЛОВИ4.3. ОСТАЛИ ПОСЛОВИ (ИЗДВАЈАЊЕ ДЕВИЗА, ПРОДАЈА ДАВИЗА И ДР.)4.4. ИЗВЕШТАВАЊЕ


4.2 ISTRA@IVAWE INFORMACIONIH ZAHTEVAKORISNIKA

Poslovni korisnici i wihovi zahtevi imaju uticaj na gotovo svaku odluku uimplementaciji DW. Korisni~ki zahtevi se nalaze u centru „DW univerzuma“,Slika 4.2.

Slika 4.2 Poslovni zahtevi imaju uticaj na gotovo svaki aspekt DW projekta

Zahtevi odre|uju koji podaci moraju biti dostupni u DW, kako suorganizovani i koliko ~esto se aùriraju. Odgovori na sva pitawa u ìvotnomciklusu su zasnovani na razumevawu korisni~kih potreba. Pored toga, broj DWkorisnika i lokacije korisnika imaju veliki uticaj na arhitekturu DW. Kona~no,planovi razvoja, odràvawa i rasta su u funkciji korisnika i korisni~kihzahteva.

Istraìvawe korisni~kih zahteva u ovom istraìvawu sastojalo se odslede}ih osnovnih koraka:

1. Izbor metoda odre|ivawa informacionih zahteva2. Odre|ivawe i priprema tima za ispitivawe3. Odabirawe i priprema respondenata4. Raspored ispitivawa respondenata5. Sprovo|ewe ispitivawa6. Analiza podataka dobivenih ispitivawem7. Pripremawe izve{taja o nalazima ste~enim ispitivawem8. Odre|ivawe prioriteta i revidirawe obima projekta.

Upravqaweprojektom

Dimenzionomodelovawe

Tehni~kaarhitektura

Fizi~kidizajn

Prire|ivawepodataka

Specifikovaweaplikacija

Postavqawe

Rast i razvoj

Poslovni

zahtevi


4.2.1 Izbor metoda odre|ivawa informacionih zahteva

Odabran je „hibrid“ tri osnovne metode prikupqawa zahteva i istraìvawaodgovaraju}ih operacionalnih podataka:

● ankete,● intervjua i● namenskih sesija (sednica).

Nacrt i upitnik za anketu su predtavqale osnovu prikupqawa korisni~kihzahteva. Intervjui su sprovo|eni individualno ili sa veoma malim grupama.Prednost ovog pristupa je {to je potrebno planirati relativno ograni~en iznosraspoloìvog vremena respondenata. Nije potrebno koordinirati desetak qudi zasastanak na nekom posebnom mestu. Intervjui tako|e podsti~u visok stepenparticipacije od strane respondenata, {to daje veoma detaqne podatke.

Alternativni pristup se moè koristiti za podsticawe kreativnogbrainstorming-a, sa ograni~enim brojem participijenata. Mada zahtevaju ve}e vremeu~e{}a svakog participijenta, sednice ~ak mogu da reduciraju o~ekivano vremepotrebno za prikupqawe informacija, uz pretpostavku da je mogu}e organizovatipogodan termin za sastanak sa 10-12 qudi u razumnom vremenskom periodu. Ovajpristup se primewuje po{to se prikupi dovoqno osnovnih informacija, odnosnokada se usvoje osnovne crte poslovawa i poslovni re~nik.

Treba napomenuti da nijedna metoda nije povla{}ena, odnosno nijeapsolutno boqa. U specifi~nom slu~aju se i{lo na blagu dominaciju metodeintervjuisawa.

4.2.2 Odre|ivawe i priprema tima za ispitivawe

Na ovom mestu }e biti ukazano niz aktivnosti za koje se ~ini da pripadajuzdravom razumu, ali se u praksi ~esto previ|aju, zaboravqaju ili preska~u.

Odre|ivawe tima za ispitivawe

Principijelno je zahtevati da isti tim istraùje zahteve biznisa isprovodi ispitivawe operacionalnih podataka. Ovaj tim se naj~e{}e struktuiraod slede}ih participijenata:

● Vo|a tima ima osnovni zadatak da usmerava ispitivawa. On vodi bele{ke,primarno kao osnov za slede}a pitawa koja }e biti postavqena. Uglavnom seova uloga poverava analiti~aru poslovnog sistema. Uloga vo|e tima jerelativno rizi~na, jer se suo~ava sa stanovitim opasnostima. Stoga trebaizbegavati pritisak na potencijalne kandidate da rade preko svojih li~nihnivoa kompetencije. Potrebno je uzeti u obzir odnose vo|e tima sarespondentima i korisnicima.

● ^lanovi tima su naj~e{}e menaxer projekta, poslovni vo|a projekta,modelatori podataka i programeri aplikacija krajwih korisnika DW.


● Zapisni~ar treba da evidentira {to je vi{e detaqa mogu}e, nezavisno od togada li su wemu li~no novi. Evidentirane bele{ke su dokumentaciona osnova zaceo DW tim, u kome mnogi ~lanovi nisu familijarni sa predmetnom materijom.Zapisni~ar tako|e zahteva odre|ena obja{wewa, ukoliko do|e do nejasno}a inerazumevawa. On predstavqa sigurnosni faktor, koji ukazuje na propu{teno iinterveni{e u slu~aju sukoba ili zamora grupe. Tako|e, po{to dajepreliminarne zapise o zahtevima, potrebno je da ima solidne spisateqskesposobnosti i da je uigran sa vo|om tima.

● Posmatra~i su opcionalni deo tima, mada se gotovo uvek pojavquju. Wih ~inedrugi ~lanovi DW tima, koji nemaju direktno zaduèwe u procesuintervjuisawa. Posmatra~i ne bi trebalo da zloupotrebe svoju ulogu i daometaju i ugroàvaju sam proces, nego da ostanu posmatra~i.

Priprema tima za ispitivawe

Pod pripremom tima se misli na istraìvawe koje prethodi samomintervjuu. Ovo istraìvawe je veoma bitno, a ve}im delom je zapo~eto analizomgodi{weg izve{taja NBJ - tu se dobio uvid u strategijske okvire, opise poslovawai organizacionu strukturu. Detaqni finansijski podaci nisu toliko bitni.

Potrebno je bilo upoznati se i sa pojedinim prospektima i publikacijama,kao i sa WEB prezentacijama (na Internetu odn. Intranetu). Principijelno, uvidu kqu~ne konkurente moè dati korisne informacije o samoj organizaciji. U ovomslu~aju je bilo prigodno posedovati informacije o odnosu NBJ i nekih oblikavlasti, kao i bankarskog, monetarnog i trì{nog sistema.

Veoma je bitno razumeti eventualne ranije poku{aje uvo|ewa DW uorganizaciju. Mogu}e je da tada nije kori{}en termin DW, nego „upravqa~kisistem izve{tavawa“ ili „marketing IS“ ili neki neki akronim za poslovnoizve{tavawe i sisteme analize. Pri tome je va`no saznati ko je bio ukqu~en u teinicijative, jer ti ~lanovi zahtevaju poseban pristup.

Potrebno je da vo|a tima pripremi spisak pitawa u duìni do jednestranice teksta. Ovaj spisak je obi~no detaqniji za podru~je IS, ali ga se ne trebakruto pridràvati - poèqno je da intervjuer bude mentalno pripremqen dapostavqa pitawa koja slede iz konteksta razgovora.

4.2.3 Odabirawe i priprema respondenata

Analizovawem mape organizacije, u saradwi sa sponzorima, izvr{ene su oveprve aktivnosti neposredno vezane za same respondente u procesu intervjuisawa.Pri tome je izuzetno bitno razumeti kako formalne, tako i neformalne(nedokumentovane) elemente organizacije.

Trebalo je otkriti ko je u organizaciji uticajan, ko je vizionar (vidovit),koji qudi su alfa i omega organizacije, ko podràva, a ko nipoda{tava nainformacijama zasnovano odlu~ivawe. Uz pomo} sponzora je odre|en i prioritetrespondenata.


Odabir poslovnih respondenata

âk i kada je re~ o ekstremnom slu~aju da je fokus istraìvawa usmeren najedan primarni deo poslovawa, potrebno je izvr{iti intervjuisawe horizontalnodu` organizacije (van granica inicijalne grupe). S toga se podrazumevaneophodnost ovakvog pristupa i u slu~aju konkretnog istraìvawa u okviru NBJ.Tako se dobija obuhvatnost i pro{irivost DW. Za razvoj DW BUS matrice jekriti~no da se poseduje razumevawe celokupnog lanca vrednosti.

Pri odabiru poslovnih respondenata bitan segment je bilo obezbe|ewevertikalne reprezentacije, odnosno razumevawa celokupne strategije i vizijeorganizacije. Pored toga, bitno je obuhvatiti i sredwi nivo menaxmenta, ~ime sedobija bliì kontakt sa realnom svakodnevicom, odnosno kako se strategijapreta~e u poslovnu taktiku. Podjednak naglasak je dat intervjuisawu anliti~araiz ciqnih oblasti, koji imaju odli~an pregled postoje}e upotrebe informacija.

Za kqu~ni poslovne respondente su odabrani:

● iz upravqa~ke strukture:

1. generalni direktor Filijale2. zamenik generalnog direktora3. pomo}nik generalnog direktora za monetarno-kreditni (dinarski) sistem4. direktor direkcije za devizne poslove5. direktor direkcije za istraìvawa, informatiku i statistiku6. direktor direkcije za monetarno-kreditne poslove7. direktor odeqewa za statistiku i analize8. direktor odeqewa dokumentarne kontrole spoqnotrgovinskih poslova9. direktor odeqewa kreditnih i specifi~nih poslova sa inostranstvom10. {ef odseka za poslove trezora

● analiti~ari:

1. vi{i stru~ni saradnici odeqewa za monetarno-kreditne poslove2. vi{i stru~ni saradnici odeqewa za statistiku i analize3. vi{i stru~ni saradnik odeqewa za devizne poslove.

Odabir respondenata iz IS

Respondenti iz IS izuzetno dobro poznaju podatke i uglavnom su odgovorniza kqu~ne operacionalne sisteme. Izvr{eni su i preliminarni intervjui saprogramerima, kao i sa ABP i modelatorima podataka. Ovi intervjui imajudruga~iju atmosferu nego intervjui sa poslovnim respondentima.

Istraìvawe podataka je sistemati~na eksploracija izvornih sistema. To jejedna poludirigovana (neslobodna) diskusija o pravcima poslovawa. Tako|e,sastanak sa IS menaxmentom daje vizije o potencijalnom kori{}ewu informacija.

Respondenti iz ovog domena su bili:


1. direktor odeqewa za razvoj informacionog sistema2. specijalni savetnik u odeqewu za razvoj IS3. vi{i savetnici odeqewa za razvoj IS4. savetnik odeqewa za razvoj IS5. vi{i stru~ni saradnici odeqewa za razvoj IS.

4.2.4 Raspored ispitivawa respondenata

Terminirawe intervjuisawa se pokazalo kao vrlo zametno, ~ak i uz primenuelektronskih kalendara. Terminirawe se sastoji iz odre|ivawa redosledaintervjua (uz pomo} odre|enih prioriteta) i potoweg utvr|ivawa mesta i vremenasesije.

Odre|ivawe redosleda intervjuisawa

U odre|ivawu redosleda intervjuisawa prioritet su imali poslovnisponzori odnosno razumevawe wihove perspektive. Potom se pristupa srediniorganizacione hijerarhije. Pristup sa vrha je suvi{e zahtevan, a pristup sa dnanije pogodan. Potrebno je kombinovati departmente (organizacione jedinice -direkcije i odeqewa) i razne perspektive.

Utvr|ivawe mesta i vremena

Respondenti su intervjuisani na svom „terenu“ - u svojim kancelarijama.Udaqene prostorije su nepogodne, naro~ito zbog nedostupnosti odgovaraju}ihizve{taja i bro{ura. Prostorije za intervjuisawe treba da su konforne iodgovaraju}e veli~ine. Pored toga treba eliminisati bilo koji vid ometawa,poput ~estih telefonskih poziva.

Grupa treba da bude mala i homogena. Na primer, marketing bi bio isuvi{e{iroko poqe. Odabirane su grupe iz iste funkcije poslovawa i/ili istogposlovnog fokusa. Tako se ispostavilo da grupa jedne sesije intervjua nijeprelazila veli~inu od ~etiri ~lana i dva organizaciona nivoa. Ve}i brojorganizacionih nivoa obuhva}en u jednoj sesiji bi uticao na smawewe entuzijazmarespondenata.

Intervjui su iscrquju}i. Potrebna je velika koli~ina energije ikoncentracije za slu{awe, beleèwe i upitivawe. Maksimalno se i{lo na triintervjua dnevno. Preporuke dozvoqavaju i ~etiri intervjua, ali u konkretnomslu~aju teku}i dnevni poslovi i obaveze to nisu dozvoqavali.

Ipitivawe izvr{ilaca treba da je kra}e od 30 minuta. Intervju sa malomgrupom analiti~ara ne treba da je duì od 1,5-2 sata. Minimalna duìna pauze jepola sata (treba voditi ra~una i o biolo{kim potrebama respondenata, a i~lanova tima). U su{tini, sve treba obaviti relativno hitro i organizovano.


4.2.5 Sprovo|ewe ispitivawa

Za svrhu pripreme respondenata za intervjuisawe potrebno je sprovestikick-off. Ova akcija prenosi osnovne poruke respondentima i sli~na je ve}pomenutom sastanku kick-off. Moè se obaviti i pomo}u po{te (najboqeelektronske).

Tako|e, sama pitawa intervjua je potrebno neposredno predati, a nebezli~no slati. Tokom intervjua, treba izbegavati defetisti~ko tehnicizirawe.Ne treba prisiqavati respondente da donesu odgovaraju}e izve{taje na sesiju.Neophodna je kvalitetna komunikacija, a u tu svrhu i definisana terminologija,odnosno standardizovan re~nik (naro~ito za horizontalni presek). Bitna jeravnopravna osnova u razgovoru, te se uglavnom primewivao re~nik korisnika.Nedozvoqena je iskqu~ivost, preteranost (ekstremizam), odnosno zahteva se visokstepen fleksibilnosti.

Potrebno je posve}eno slu{ati korisni~ka o~ekivawa, uz izbegavawezamrzavawa specifikacija i drugih ortodoksnih zahteva. Ovo sledi iz toga {to jeizgradwa DW iterativni proces, otvoren prema kasnijim novim zahtevima.

Intervjui su po~iwali kratkim uvodnim izlagawem. Zavisno od sastavatima, menaxer, poslovni vo|a projekta ili pak glavni intervjuer je saop{tavaopar informacija visokog nivoa. Te informacije su se ticale najop{tijih ciqevaprojekta i samog intervjuisawa, kao i ~lanova tima sa svojim primarnimodgovornostima. Korisnicima je saop{tavan na~in na koji }e im bitipredstavqeni revidirani rezultati intervjua.

Posle konciznih i jasnih uvodnih pitawa o prirodi poslovawa, imaju sesmernice za daqi tok intervjua. Principijelno treba krenuti od pitawa vi{egnivoa i potom po}i u konkretizacije.

Intervjuisawe izvr{nog tela (kolegijuma Generalnog direktora) dajeop{te razumevawe organizacije. Pitawa o ciqevima koji se èle posti}i ifaktorima uspeha daju uvid u kqu~ne poslovne procese koji se prate i ~iwenicekoje }e se morati na}i u DW. Periodi~nost merewa uspeha }e odrediti budu}ustrategiju aùrirawa DW. Pitawa koja se ti~u potencijalnih problema ipogodnosti imaju naro~it zna~aj kada je potrebno dokazati finansijskuopravdanost uvo|ewa DW. Veoma je bitno sagovornicima dati mogu}nost da iskaùsvoje vizije, èqe i o~ekivawa o kori{}ewu informacija u budu}nosti.

Intervjuisawe poslovnih menaxera i analiti~ara je sli~no intervjuisawunajvi{ih rukovodilaca. U pitawu je samo detaqniji uvid u odgovaraju}e oblastiposlovawa. Upitivawe se ti~e analiza i potencijalnih poboq{awa analiza, kao ineophodnih informacija i istorijskog dohvata podataka. Jasno je da analiti~ari uspreadsheet programima ve} grade svoje „personalne“ DW. Potrebno je imati uvid upostoje}i sistem izve{tavawa i traìti mogu}nosti za poboq{awa.

Prevo|ewe intervjua u dimenzione modele se pokazalo kao „vi{e umetnost(ume{nost) nego nauka“. U literaturi postoji nekakav skup heuristi~kihpreporuka za taj zametan i komplikovan posao. Detaqan prikaz intervjuarukovodilaca, menaxera i analiti~ara je dat u Prilog .

Intervjuisawe IS osobqa je imalo za krajwi ciq da utvrdi da li postoje}iIS garantuje sve podatke koji su se pokazali neophodni za traène analize. Posleuvodnog upoznavawa sa osnovnim crtama posla, postavqana su pitawa tipa:


● Prikaz kqu~nih operacionalnih sistema (frekventnost aùrirawai istorijski opseg podataka);

● Koji se procesi i alati koriste se za prosle|ivawe informacijakorisnicima, i za koje analize (standardne, ad hoc, ...)?

● Problemi, uska grla i kriti~na mesta u trenutnom pristupawupodacima.

● Vizije i zahtevi po pitawu budu}eg DW.Interesantno je da se i tokom ovih intervjua sti~e dubqi uvid u sam procesposlovawa. Mogu}e je spoznati nerealnost i nelogi~nost nekih korisni~kihzahteva. Naravno, ~esto se pokaè i da postoje}i operacionalni sistemi nepruàju sve potrebne podatke u egzistencijalnom smislu ili u smislu kvaliteta(ta~nosti, granularanosti i sl.).

Finalni korak jednog intervjua je wegovo zatvarawe, svo|ewe. Vo|aintervjua odre|uje po~etak zavr{nih minuta, u kojima se vr{i osvrt nadiskutovane teme. Pored toga, pogodno je tada odrediti kriterijum uspe{nostiprojekta, koji bi trebao da je dovoqno konkretan i da obuhvata:

● implementacione mere (potrebni volumeni diska, broj korisnika, ...)● mere aktivnosti i kori{}ewa (broj upita, logovanih korisnika, ...)● mere uslu`nosti (dostupnost, kvalitet podataka, vremena odgovora)● mere uticaja na poslovawe (najbitnije, ali i najteè odredive)● analiza „pre i posle“ DW.

U literaturi se moè na}i interesantna tipologija respondenata koji sunepogodni za saradwu i kod kojih je mo`da boqe odgoditi ili ~ak kanceliratiintervjuisawe [1]. Pomenuta tipologija }e se ovde dati samo punktualno:

nezadovoqni korisnici (razo~arani u prethodne poku{aje uvo|ewa) prebukirani korisnici (naj~e{}e nezainteresovani za dodatnu edukaciju) zbuweni korisnici (daju „jednobitne“ odgovore, ali se retko sre}u) prerevnosni i eufori~ni korisnici „nepostoje}i“ korisnici (eliminisani od strane IS tima).

4.2.6 Analiza podataka dobivenih ispitivawem

Potrebna je identifikacija podru~ja u kojima postoji ikakvih nejasno}a,kao priprema za eventualne slede}e (naknadne) intervjue. Za tu svrhu je vo|aintervju tima vodio listu otvorenih pitawa i tema. Svakako, korisni~ki zahteviodre|uju modele podataka, podatke, analize, edukaciju i obuku, kao i tehnike itehnologije koji }e biti projektovane ili kupovane (softveri). Uvidi ukorisni~ke zahteve su podeqeni sa ostalim ~lanovima DW tima.

Sumarizacija i sre|ivawe zabele{ki sa intervjua se sprovode nekolikosati posle intervjua, u toku istog dana, a najkasnije pre po~etka slede}e sesije saistom ili sli~nom grupom respondenata. Tako|e, potrebno je pregledati postoje}eizve{taje i analize, jer oni grade dimenzione modele skoro direktnomtranslacijom. Tu se uvi|aju atributi, kolone (i superkolone), nivoi granulacijekoji nisu ni spomiwani tokom intervjua i na wih se obra}a posebna pa`wa. Stoga


je preporuka da se uvek na zavr{etku intervjua zatraì skup izve{taja koji setrenutno koriste.

Pripremawe izve{taja o nalazima ste~enim ispitivawem

Kao {to je poznato, vo|ewe evidencije i dokumentacije je jedan odnajzna~ajnijih, ali i jedan od naj~e{}e izbegavanih, odlaganih i preskakanihzadataka u informati~kom svetu. Dokumentacija ima enciklopedijsku iedukativnu ulogu. Ona sadrì kriti~ne informacije, koje bivaju izgubqene ako sunezavedene i ako lice koje ih poseduje napusti organizaciju. Pored toga,dokumentacija pomaè kristalizaciji saznawa i boqem razumevawu sadràjaintervjua. Dokumentovawe intervjua je dinami~ki proces i ono nagla{ava aktivnuulogu korisnika.

Zapisnik intervjua, zavisno od situacije, moè ukqu~ivati poslovnookruèwe i ciqeve, analiti~ke i informacione zahteve (ukqu~uju}ipotencijalni uticaj na poslovawe) i kriterij uspeha. Mogu}e je angaòvatirespondente da pregledaju i odobre ove zapisnike.

Dokumenti korisni~kih zahteva se mogu dodatno obrazovati, kao vidkonsolidovanih i sintetizovanih podataka iz pomenutih zapisnika. Oni imajusli~nu strukturu kao sami zapisnici. Mogu}e je kori{}ewe elektronskih radnihtabela, koje omogu}uju odre|eni nivo matemati~ke obrade zahteva. Ovi dokumentiizgra|uju va`nost i kredibilitet DW.

Rezultati ispitivawa su dobrim delom za{ti}eni i poverqivi (kaoposlovna i dràvna tajna), a svakako su preto~eni u budu}i DW i ne}e bitiposebno izlagani.

4.2.7 Odre|ivawe prioriteta i revidirawe obima projekta

Po{to su utvr|eni korisni~ki zahtevi i istraèni izvorni operacionalnisistemi, pogodno je da se izvr{e odre|ene aktivnosti. Potrebno je da korisnicipotvrde ta~nost utvr|enih zahteva. Pored toga, jedna iteracija DW procesa ne}emo}i da ispuni sve zahteve, te je potrebno u saradwi sa poslovnim korisnicimautvrditi konsenzus o prioritetima i obimu projekta.

Potvr|ivawe, prioritetizacija i konsenzus su utvr|eni tokommodifikovanih sesija. Mada nije moralo tako da se uradi, sesije garantujuukqu~enost svih aktera u donesene odluke i samim tim ose}aj vlasni{tva izainteresovanosti. Kao priprema za sesiju, korisnicima je prosle|enadokumentacija, a sve utvr|ene promene su ponovno dokumentovane. Ove sesije suneophodne ~ak i u slu~aju relativno stabilno prethodno utvr|enih zahteva.

Ovaj pristup se moè u~initi kao dramati~no razli~it u odnosu naintervjue. Me|utim, iz zadataka prilago|enih sesija se moè utvrditi da su ta dvapristupa veoma srodna:

● identifikacija tima i uloga● priprema tima● odre|ivawe participijenata● priprema participijenata


● odràvawe sastanaka● dokumentovawe● validacija od strane participijenata.

Ve}ina opisanih tehnika su primenqive i u ovom pristupu, uz minornaprilago|ewa.

Kao DM (poslovne oblasti) sa najve}im prioritetom su izdvojeni Pra}ewespoqnotrgovinskog poslovawa i Pra}ewe poslovawa banaka, te }e oni bitidetaqnije projektovani.

Vremensko trajawe

Potreban napor o~igledno zavisi od magnitude i opsega projekta.Generalno, prikupqawe korisni~kih zahteva traje od ~etiri do {est nedeqa.Uticajne veli~ine su slede}e:

● broj respondenata● mogu}nost prisustva● broj izvornih sistema● nivo dokumentovanosti● mogu}nost prisustva sesijama prioritizacije i konsenzusa● srodnost zahteva i potreba.

Prikupqawe korisni~kih zahteva za potrebe ovog istraìvawa je trajalooko sedam nedeqa. Na ne{to ve}u duìnu procesa je uticalo doba kalendarskegodine u kome su zahtevi prikupqani (leto - godi{wi odmori i druga odsustva) izauzetost DW tima i respondenata drugim (operativnim) pitawima i obavezama.


4.3 KONCEPT I STRUKTURA DW U PODR[CIODLUÎVAWA U OKVIRU NBJ

4.3.1 Data Marts (modeli)

Poslovni procesi (budu}i Data Marts) slede skoro neposredno iz modulastrukture IS NBJ. Pri tome, modul Pokazateqi za monetarno-kreditnoregulisawe ne}e imati odgovaraju}i poslovni proces zbog toga {to je on delomsadràn u drugim modulima odgovaraju}ih podsistema, a i zbog toga {to su wegovarazrada i stavqawe u punu funkciju predvi|eni za budu}i period. Poslovniproces Pra}ewe finansijskih rezultata banaka je nov, ali on se i tako nalazi unajnovijim prikazima strukture IS NBJ. Proces Trezorsko poslovawe uglavnompripada modulu Stawa i tokovi gotovog novca, dok proces Interno poslovawetreba uzeti vi{e uslovno - predvi|eno je da se wime pokriju eventualne potrebecelog jednosg podsistema. Prema tome, kona~an spisak DM }e izgledati na slede}ina~in:

1. Plasmani Narodne banke2. Obavezna rezerva i kamata3. Stawa i tokovi gotovog novca4. Spoqnotrgovinsko poslovawe - DDK5. Kreditni odnosi sa inostranstvom6. Platni promet sa inostranstvom7. Ostalo devizno poslovawe8. Statusna stawa banaka9. Poslovni potencijal i stawe banaka10. Likvidnost banaka11. Bonitet (kvalitet) banaka12. Devizno poslovawe banaka i KOI13. Pra}ewe finansijskih rezultata banaka14. Trezorsko poslovawe15. Interno poslovawe.

Posle nabrajawa poslovnih procesa se pristupilo uo~avawu, analizi igrupisawu dimenzija poslovawa. Sledi kratak komentar nekih osnovnih dimenzija:

Preduze}a - Podaci o preduze}ima i drugim organizacijama koji su dobilijedinstven mati~ni broj od Saveznog zavoda za statistiku (SZS). Deo ovog registratreba da budu i podaci iz Registra imalaca ra~una koji se vode u ZOP i to poìro-ra~unima.Banke - Poseban deo registra preduze}a treba da budu podaci o bankama i DFO.Naseqe - Podaci o naseqima kako se vode u SZS.Op{tina - Podaci o op{tinama kako se vode u SZS.Klasifikacija delatnosti - utvr|ena je Zakonom o klasifikaciji delatnosti io registru jedinica razvrstavawa; to je op{ti standard prema kojem se vr{irazvrstavawe u delatnosti.


Roba - podaci o robi prema „Carinskoj tarifi“ i po „Standardnoj me|unarodnojtrgovinskoj klasifikaciji“ (SMTK). Spisak robe prema „Carinskoj tarifi“ saoblicima izvoza i uvoza objavquje se u „Slu`benom listu SRJ“ u okviru Odluke orazvrstavawu robe na oblike izvoza i uvoza, koju donosi Savezna vlada. Podaci orobi po SMTK dobijaju se od SZS.Zemqa - {ifarnik zemaqa po me|unarodnom standardu. Objavqen je kao sastavnideo raznih uputstava o dokumentaciji koja se koristi u odvijawu ekonomskihodnosa sa inostranstvom.Valuta - {ifarnik valuta po me|unarodnom standardu. Objavqen je kao sastavnideo raznih uputstava o dokumentaciji koja se koristi u odvijawu EOI.Kurnsa lista - podaci koji odràvaju inter-valutarne odnose dinara premadrugim valutama. Podaci se dobijaju od Udruжewa banaka Jugoslavije i na osnovuspiska kurseva valuta koje se ne kotiraju na deviznom trì{tu, a koji dostavqaNBJ tromese~no.Kontni plan (NBJ, ZOP i banke) - analiti~ki kontni plan za NBJ i za banke iDFO. Od 1.01.1999. godine kontni okvir NBJ donosi Guverner NBJ, a kontni okvirza banke i DFO donosi Ministarstvo finansija.Kamate - podaci o vrstama kamata, stopama i ostalim elementima potrebnim zaobra~un kamate NBJ. Promene se dobijaju u vidu mese~nog izve{taja od NBJSedi{te i to Sektora za poslove monetarnog sistema i politike.Tro{kovna mesta (kancelarije - prostorije) - podaci o prostorijama(kancelarije i druge prostorije) u NBJ Filijali u Novom Sadu. Koriste seprvenstveno za popis i evidenciju osnovnih sredstava.Radnici - podaci o radnicima NBJ Filijale u Novom Sadu. Koristi se u popisu ievidenciji osnovnih sredstava, drugim poslovima u Sektoru ra~unovodstva,trezora i dr.Sedi{ta ZOP-a - podaci o filijalama i drugim organizacionim delovima ZOP-a(Zavoda za obra~un i pla}awa).Apoeni - podaci o apoenima gotovog novca i HOV ukqu~uju}i ESN.Kodeks {ifara - razni {ifarnici koji se koriste u pojedinim podsistemima, adeo su uputstva koje propisuje sadràj dokumentacije vezane za odre|eni podsistem.

Zajedni~ke ~inioce poslovawa predstavqaju oni za koje je karakteristi~no:

- kori{}ewe u vi{e sistema ili modula,- dug ìvotni vek podataka sa vi{ekratnom upotrebom i- relativno retko aùrirawe.

Sledi matrica poslovni procesi/dimenzije, koja je prvi grafi~ki alat zaizgradwu konzistentnog DW bus-a. Naravno, otvorenost za ou~avawe potrebe kanekim novim dimenzijama (ili modifikovawe postoje}ih) se podrazumeva - ~ak jepoèqna. Preporuka je da se matrica proprati sa onoliko dijagrama tabelafakata koliko ima poslovnih procesa. Pri tome se prikazuju sve dimenzije,ukqu~uju}i i one koje nisu povezane sa konkretnom tabelom fakata. Ovi dijagramisu dobro informativno i komunikaciono sredstvo ka neinformati~kom osobqukoje treba da apsolvira {eme budu}eg DW. U tu svrhu se dimenzije u svakomdijagramu prikazuju na istim geometrijskim mestima, kako bi se olak{alomemorisawe. Ova grafi~ka tehnika zauzima dosta prostora, te bi naru{ila ritamteksta i zbog toga je data u Prilog 4. Wu potom slede detaqni prikazi tabela~iwenica i dimenzija.


Servisi zaupravqawe

podacima

- ekstrakcija- transformacija

- puwewe- kontrola

Izvornisistemi

Prire-|ivawe

podataka

dimenzioni DataMarts saatomarnim podacima

DWbus

konformnedimenzije i

fakti

dimenzioni DataMartssamo sa agregiranim

podacima

Katalogmetapodataka

prezentacioni serveriPristupniservisi

- upravqaweupitima

- DW browsing- za{tita- izve{tavawe- monitoring

izve{tajnialati

desktopalati

aplikacionimodeli

operacio-nalni

sistemiZa{tita- backup- arhiva

4.3.2 Shema DW

Izloèna teoretska gra|a i dosegnuti stepen dubine u analizi iprojektovawu konkretnog sistema, dovoqan su preduslov za kroki budu}e celine,odnosno za preliminarnu predstavu sheme DW. U tu svrhu sledi prikaz tehni~kearhitekture budu}eg DW (prikazan na slede}oj slici).

Slika 4.3. Tehni~ka arhitektura budu}eg DW

Na slici su uo~qivi pripremni (back room) i javni deo (front room). Izme|uwih se nalazi „srce“ DW, koje je ìvotno zavisno od detaqnosti i kavalitetaodgovaraju}ih metapodataka. Tako|e, ova slika govori da je odabran postupakkreiarawa agregata sa separatnim tabelama fakata. Detaqnija vizura tehni~kogaspekta funkcionisawa ove arhitekture je data u ta~ki 4.5.

DW arhitektura neminovno evoluira, {to nagla{ava va`nostfleksibilnosti date arhitekture. Fleksibilnost je u kauzalnom odnosu saslede}im bitnim kategorijama:

1. Nizak, {to niì, nivo granulacije ~iwenica (performansi u~e{}adimenzija u poslovnoj aktivnosti). Naime, preurawena-prevremena agregacija jejedan od najve}ih „neprijateqa“ fleksibilnosti.

2. Simetri~nost dimenzionog modelovawa.

U nastavku sledi detaqniji prikaz projektovawa odabranih poslovnihoblasti.


4.4 LOGI^KI NIVO MODELOVAWA - DIMENZIONIMODELI

Formirawe DW Bus matrice, kao po~etni korak dimenzionog modelovawa jeprikazano u prethodnoj ta~ki. Vaqa napomenuti da po nekim autorima, taj korakdolazi kasnije - nakon takozvane integracije zvezdastih {ema. Utisak je da se uintelektu projektanata ove aktivnosti odvijaju sa odre|enom dozom paralelizma,tako da izmena u redosledu na linearnoj vremenskoj osi ne nosi su{tinske izmene.

4.6.1 Dijagrami tabela fakata

Kako je ve} elaborirano u tre}oj glavi, slede}i prirodan korak je izradadijagrama tabela fakata. Na narednim stranama slede dijagrami tabela fakata zadva odabrana poslovna procesa, dok se ostali dijagrami nalaze u Prilog 4.

Model za poslovni proces Pra}ewe spoqnotrgovinskog poslovawa - DDK jetipa snapshot (ne nedeqnom nivou preseka), dok poslovni proces Plasmani Narodnebanke - KREDITI je transakcionog tipa i odgovaraju}e granularnosti.

Detaq tabele fakata

Dijagram tabele fakata je propra}en detaqnijim prikazom tabele fakata.Ovaj prikaz podrazumeva spisak stranih kqu~eva - dimenzija (koje su unefunkcionalnom odnosu) i ~iwenice.

Sledi lista za tabelu fakata DDK (derivirani fakti su ozna~enizvezdicom):

● kljuc_dimenzije_Vreme ● kljuc_dimenzije_Izvoz-Uvoz● kljuc_dimenzije_VrstaPosla ● kljuc_dimenzije_NacinNaplate● kljuc_dimenzije_Zemlja ● kljuc_dimenzije_Valuta● kljuc_dimenzije_Namena

● APR_Prijavljeno ● APR_Izvezeno-Uvezeno● APR_Naplaceno-Placeno ● APR_Nenaplaceno-Neplaceno● APR_NerealizovanoUroku ● AFZ_Vrednost● AFZ_Naplaceno ● AFZ_Nenaplaceno● AFZ_ProsaoRok ● AFI_Vrednost● Nenaplaceno-RokNijeProtekao* ● Nenaplaceno-ProtekaoRok*● PlacenoNeuvezeno*

îwenice predstavqa kompletna lista svih atributa raspoloìvih krozdatu tabelu fakata. Ona sadrì aktuelne fakte u fizi~koj tabeli, izvedene~iwenice koje se prezentuju kroz poglede SUBP, i ostale fakte koji se mogu


izra~unati iz prve dve grupe. Detaqna dokumentacija }e sadràti i agregacionapravila, u svrhu podsetnika na aditivnost ~iwenica. U listi se mogu na}i i~iwenice koje se ne mogu izra~unati, ali za koje postoji potraìvawe od straneposlovnih korisnika.

Slika 4.4 Dijagram tabele fakata DDK

Vreme Preduze}a(ROJ)

Banke Naseqa Op{tine

Klasifikaci-ja delatnosti

Tarifnibrojevi

Zemqe

Рa~uni

Namenaplasmana

Carinskeispostave

Instru-menti

Namenauvoza

Reìm

Izvoz-uvoz

Vrste devi-znih uloga

Oblici kre-ditnog posla

Vrste posla Namenekredita

Vrstekredita

Apoeni nov-ca i HOV

Valute

Inokredi-tori

Konta

Kamate

Tro{kovnamesta

Radnici

Sedi{taZOP

Spoqnotrgovinsko

poslovawe - DDK


Slika 4.5 Dijagram tabele fakata Plasmani NB

4.6.2 Dijagrami tabela dimenzija

Dijagrami tabela dimenzija eksplicitno prikazuju zrnatost svakedimenzije, pribli`an kardinalitet, hijerarhije, relacije izme|u atributa odn.




Tarifnibrojevi

Zemqe

Рa~uni

Namenaplasmana

Carinskeispostave

Instru-menti

Namenauvoza

Re`im

Izvoz-uvoz




Vrstekredita

Apoeni nov-ca i HOV

Valute

Inokredi-tori

Konta

Kamate

Tro{kovnamesta

Radnici

Sedi{taZOP

Plasmani Narodne

banke


mogu}e putawe za drill. Naravno, opet se ukqu~uju i atributi koji su poslovnopotrebni, ali jo{ uvek nisu ukqu~eni u dizajn.

Na Slika 4.6 je prikazana zvezdasta struktura dimenzije Vreme.

Slika 4.6 Detaqni dijagram dimenzije Vreme

Smatram da bi bilo interesantno prikazati jedan druga~iji modelvremenske dimenzije koji bi mogao biti pogodan za odre|ene analize. Ovaj modelne mora biti u koliziji sa sa prvom varijantom, odnosno mogu}a je nekakvaintegracija.

Slika 4.7 predstavqa, zna~i, jo{ jedan detaqni dijagram dimenzije Vreme.Osen~eni objekti predstavqaju atribute, a brojevi u zagradama su relativnikardinaliteti. Potom sledi tabela sa detaqnim opisom atributa dimenzijeVreme.

dan_sifra

dan_datumdan_naziv

dan_naziv_skrdan_u_nedeljidan_u_mesecudan_u_godini

ned_sifra

ned_nazivned_u_kva

ned_kvaned_u_godini

ned_god

Vreme

dan_sifraned_siframes_sifrakva_sifraGodina

kva_sifra

kva_nazivkva_u_god

kva_god

mes_sifra

mes_nazivmes_naziv_skr

mes_u_godmes_god

NEDELJA

ned_nazivned_u_godini

DAN


KVARTAL


MESEC


VREME



Slika 4.7

Tabela 4.2 Detaqni opis atributa dimenzije

Atribut Opis atributa Kardina-litet

Laganomewawe

dimenzije

Primervrednosti

Dan Predstavqaodre|eni datum 365 nema

a`urirawa 14/01/2001

PraznikPredstavqakalendarski

praznik14 prepisivawe Nova godina

Dan unedeqi

Ime dana unedeqi 7 nema

a`urirawa Petak

Fiskalna Godina

VišestrukeHijerarhije


(1)

ned_nazivned_u_godin

i

Fiskalni Kvartal(4)

ned_nazivned_u_godin

i

Fiskalni Mesec(12)


Fiskalna Nedelja(52)


Kalendarska Godina (1)


Kalendarski Kvartal (4)


Kalendarski Mesec (12)


Kalendarska Nedelja (52)


DanPraznik Dan u Nedelji (7)


Sat

(10)


(8760)

ned_naziv

ned_u_godi

ni

(365)

ned_naziv

ned_u_godi

ni Dimenziona GranulaBudući Atribut

Potencijalna Dimenziona Granula


Atribut Opis atributa Kardina-litet

Laganomewawe

dimenzije

Primervrednosti

Kalendarskimesec

Predstavqakalendarski

mesec12 nema

aùrirawa 2001/01

Kalendarskikvartal

Predstavqakalendarski

kvartal4 nema

aùrirawa 2001 Q1

Kalendarskagodina

Kalendarskagodina 1 nema

aùrirawa 2001

Fiskalnanedeqa

Sedmica danadefinisana

kalendarom NBJ53 nema

aùrirawa F 14/04/2001

Fiskalnimesec

Kolekcija fis-kalnih sedmica,po obrascu 4-4-5

12 nemaaùrirawa F 2001/01

Fiskalnikvartal

Kolekcija trifiskalna meseca

4 nemaaùrirawa F 2001 Q1

Fiskalnagodina

Kolekcijafiskalnihkvartala

1 nemaaùrirawa F 2001

Tabela 4.2 nastavak

4.6.3 Dimenzioni modeli

Slede konkretni dimenzioni modeli za odabrana dva Data Marts. U dizajnu jekori{}en deo paketa Platinum pod nazivom ERwin verzija 3.5.2, sa aktiviranomopcijom za dimenziono modelovawe.

Dijagrami su propra}eni ilustracijama detaqnih prikaza:

● ~iwenica - Tabela 4.3● izvora podataka - Tabela 4.4● na~inom ekstrakcije podataka iz izvora - Tabela 4.5.


Slika 4.8 Logi~ki model procesa DKL


Slika 4.9 Logi~ki model procesa Krediti


Tabela 4.3 Detaqni opis deriviranih fakata


Kolona Change Flag pokazuje koji opisi su mewani od posledwe verzijedokumenta. Ovo je naro~ito va`no kada postoje brojna izra~unavawa.

Kolona Type (Tip) razvrstava ~iwenice prema slede}em kriterijumu:

● column - aktuelna ~iwenica● constraint - ~iwenica sa predefinisanim ograni~ewem● transformation - postoji translacija specifi~nih vrednosti● calculation - postoji nekakvo izra~unavawe● column with limits - semiaditivna fakta, koja zahtevaju specifikaciju limita.

Zna~ewe ostalih kolona je samo po sebi razumqivo.

Tabela 4.4 Definicije izvora podataka

Poslovna odgovornost se odnosi na same podatke, a IS odgovornost seodnosi na kompletan izvor podataka.

IZVORPOSLOVNA

ODGO-VORNOST

IS ODGO-VORNOST

PLATFORMA LOKA-CIJA

OPIS

NBJ-GRFspecijalnisavetnik

administra-tor BP

JYCOSHoneywell 8

BGD-Brankova

glavnarepubl.Filijala

Centralaspecijalnisavetnik

administra-tor BP

JYCOSHoneywell 8

BGD-Bulevar

sedi{teNBJ

DM KOI specijalnisavetnik

administra-tor BP WIN NT BGD-

Skadarskaura|enData Mart

Bonitet - - Internet EUNET servis

Bankestru~nisaradnik

sistemin`ewer WIN sedi{ta

banaka

dostavaelektron.putem

HONEY vi{isavetnik

vi{isavetnik

JYCOS,Honeywell 7000,WIN NT

Novi Sad

Carina NNvi{istru~nisaradnik

UNIX SUCdostavaelektron.putem

Statistikaspecijalnisavetnik

specijalnisavetnik WIN 95 SZS

dostavaelektron.putem


Tra

nsf

orm

acij

a

New

New

Dire

ct

Subs

tr

Dire

ct

Txfm

Txfm

Txfm

Txfm

Tab

ela

4.5

Pri

mer

map

iraw

a iz

vor-

ciq

Izv

orna

kolo

na/p

oqe

New

New

Sifr

a2

Naz

iv2

Kod

1

M-1

5-1

M-1

5-2

M-1

5-3

M-1

6

Izv

orna

tab

ela/

faj

l

New

New

SF00

3

SF00

3

SF00

3

M M M M

Opi

s ko

lone

jedi

nstv

eni

prim

arni

kq

u~

zavr

emen

sku

dim

enzi

ju

datu

m u

sta

ndar

dnom

obl

iku

jedi

nstv

eni

prim

arni

kq

u~

zadi

men

ziju

Ban

ka

nazi

v ba

nke

ozna

ka

o vr

sti

ovla

{}e

wa

(doz

vole

)

kam

atna

sto

pa

fik

sna

kam

ata

inte

rkal

arna

kam

ata

tro{

kovi

kre

dita

Du`

ina

6 - 8 40 1 2,4

2,4

2,4

11,2

Tip

Num

Dat

e

Num

Cha

r

Log

Num

Num

Num

Num

Kol

ona

Vre

me

Dat

um

Sifr

aBan

ke

Naz

ivB

anke

Stat

usB

anke

KA

M_R

ED

KA

M_F

IK

KA

M_I

NT

TRO

SKO

VI

Tab

ela

dim

enzi

jaV

rem

e

dim

enzi

jaV

rem

e

dim

enzi

jaB

anka

dim

enzi

jaB

anka

dim

enzi

jaB

anka

KO

If

akti

KO

If

akti

KO

If

akti

KO

If

akti

...

ChgFlag

Grupafakata

Nazivmere Opis mere Tip

Agregacionopravilo Formula Ograni~ewe

Transfor-macija

DKLAPR

PrijavqenoIznos

prijavqenihposlova

Calc Suma sum(PRJ_FakturnaVrednost) nema nema

DKLAPR

Izvezeno-Uvezeno

Fizi~karealizacijaprijavqenih

poslova

Calc Suma sum(PRJ_FizickaRealizacija) nema nema

DKLAPR

Napla}eno-Pla}eno

Finansijskarealizacijaprijavqenih

poslova

Calc Suma sum(PRJ_ FinansijskaRealizacija) nema nema

DKLAPR

Nenapla}eno-Nepla}eno

NerealizovaneFR prijavqenih

poslovaTxfm Suma

sum( “...razlika fizi~kih ifinansijskih realizacija po

prijavqenom poslu...”)nema kursirawe

DKLAPR

Nerealizovanou roku

Pro{ao rokrealizacijeprijavqenih

poslova

TxfmCnstr

Suma sum(“... za prijavqene poslovegde je pro{ao rok ...”)

Rok kursirawe

DKL AFZVrednost

Ukupne fizi~kerealizacije

Calc Suma sum(JCD_Vrednost) ANDsum(FAK_Vrednost)

nema nema

DKL AFZNapla}eno

Finansijskarealizacija

fizi~kihrealizacija

Calc Suma sum(FIN_Vrednost) vezanih zaodre|enu fizi~ku realizaciju

Izvoz nema

DKLAFZ

Nenapla}enoNerealizovaneFR fizi~kihrealizacija

Txfm Sumasum( “... razlika fizi~kih i

finansijskih realizacija ...”) Izvoz kursirawe

DKL AFZPro{ao rok

Pro{ao roknaplate

fizi~kihrealizacija

TxfmCnstr

Suma sum(“... za fizi~ke realizacijegde je pro{ao rok ...”)

Rok kursirawe

DKLAFI

VrednostUkupne

finansijskerealizacije

Calc Suma sum(FIN_Vrednost)nema nema


4.5 DIZAJN FIZI^KE STRUKTURE

Aktivnosti u ovoj fazi izgradwe DW ovaplo}uju logi~ki dizajn u fizi~kuBP. Po~etni korak je planirawe standarda i za{tite. Odre|ivawe preliminarneveli~ine i intenziteta rasta BP se odvija paralelno sa agregacionim planom(jednim od kqu~nih delova fizi~kog modelovawa). Poznavawe identiteta svihtabela otvara prostor za preliminarnu viziju indeksirawa. Tada se prelazi narealizaciju fizi~ke strukture u pravom smislu re~i - dizajn i postavka BP sastrukturom odgovaraju}ih objekata u BP. Slika 4.10 prikazuje dizajn fizi~kestrukture DW na visokom nivou apstrakcije.

Slika 4.10 Proces fizi~kog dizajna

Detaqi fizi~kog modela podataka i implementacije BP su vrlo zavisni odindividualnih odlika projekta, tako da naredna izlagawa imaju mawi stepenop{tosti.

Standardizovawenaziva

Fizi~kimodel

Revizijaplana

agregirawa

Inicijalnastrategija

indeksirawa

Kreirawebaze podataka

Implementacijafizi~ke

strukture

Monitoringkori{}ewa


Uz ve} uo~enu deskriptivnost, odlu~eno je da logi~ka i fizi~ka imena buduidenti~na u maksimalnoj mogu}oj meri. Usvojeni standardi su imperativ, ali nisui dogma. Velika i mala slova u nazivima (case sensitivity) se koriste iz ~istoestetskih razloga - nije prime}en pad performansi zbog toga.

Prava pristupa su re{ena preko sinonima i pogleda (synonyms and views).Pogled se javqa u vidu tabele, ali u su{tini moè biti veoma kompleksan. Pomo}upogleda je mogu}e kreirati ugodniji interfejs (collapsed star) nad normalizovanomfizi~kom strukturom. Teorija kaè da pogledi ne bi smeli da ugroàvajuperformanse, ali praksa ovo osporava. S toga se ide na kontrolisanu i opreznuprimenu pogleda.

4.5.1 Fizi~ki modeli

Polazi{te fizi~kog modela podataka je logi~ki model. Logi~ki modeltreba preslikati koliko god je mogu}e, mada su neizbe`ne izmene uslovqenetipi~no{}u konkretnog RSUBP. Tako|e, fizi~ki model ukqu~uje neke dodatnetabele kao {to su tabele vezane za prire|ivawe podataka i sl. Ipak, osnovnarazlika ova dva modela je {to fizi~ki model sadrì detaqne i iscrpne opisekarakteristike fizi~ke BP.

Kao {to je re~eno, kqu~evi su uglavnom ve{ta~ki i celobrojni. Zanimqivoje napomenuti da je za kqu~eve sa relativno niskom kardinalno{}u ponekadpovoqnije da budu tipa CHAR fiksne duìne. Pored toga, kolone sa dozvoqenimnula vrednostima ne treba da budu deo primarnog kqu~a (~ak i kada je toizvodqivo).

S obzirom da je proces puwewa strogo kontrolisan i ~ist, nije obaveznoforsirawe referencijalnih integriteta u BP, jer oni vr{e dodatni pitisak naperformanse. Neki optimizatori upita, ipak, boqe rade sa definisanimreferencijalnim integritetima.

Tabele prire|ivawa podataka, kao god i agregatne tabele, ~ine poseban deou dokumentaciji modela podataka. Tako|e, fizi~ki model sadrì i tabele indeksa.Tabela 4.6 sadrì ilustraciju fizi~ke specifikacije tabela.

Tabela 4.7 predstavqa preliminarni prora~un fizi~ke veli~ine jednog DataMart-a. Kona~na veli~ina se dobija sabirawem vrednosti u posledwe dve kolone.Vidi se da je veli~ina dimenzionih tabela relativno zanemarqiva. Broj slogovatabele fakata (i odgovaraju}ih agregacionih i indeksnih tabela) je odre|en uzpretpostavku uvo|ewa nove dimenzije Preduzece. Za tabele indeksa trebapredvideti temp space od jo{ 80% ukupnog zauze}a tabela indeksa.

Tabela 4.8 je plan indeksirawa. U tabeli se nalaze svi primeriindeksirawa: indeksirawe dimenzija, indeksirawe tabela ~iwenica, kao iindeksirawe za potrebe prire|ivawa podataka. Prire|ivawe podataka }e seobavqati uz pomo} nekog ETL alata (extraction, transformation, load - ekstrakcija,transformacija, puwewe), koji moè biti kupqen ili interno razvijansoftverski paket.


Tabela/Kolona Tippodatka

nullable Prim.kqu~

Komentar

Vreme Kalendarska dimenziona tabelaVreme_kljuc integer n 1 Ve{ta~ki kqu~Datum date n Datum, mogu}e aritmeti~ke operacijeDekada integer n Uzima vrednosti 1..3Mesec integer n Uzima vrednosti 1..12Kvartal integer n Uzima vrednosti 1..4FiskalniPeriod integer n Godina u vidu brojaSat Dimenzija satSat_kljuc integer n 1 Uzima vrednosti 1..23Sat_time time n Mogu}e aritmeti~ke operacijeam_pm_ind char(2) n Uzima vrednosti am/pmpeak_period_ind char(8) n Uzima vrednosti peak/off-peakBanke Dimenzija bankeSifraBanke integer n 1 Direktno preuzet kqu~SifraBankeROJ integer n [ifra banke u registru ROJNazivBanke char(40) n Naziv bankeZiroRacun char(35) @iro ra~unRedosledBanke integer n Redosled u ve}ini najva`nijih izve{tajaStatusBanke logical n Status bankeSkr_NazivBanke char(8) Naziv banke za hedere kolonaMesto char(20) n Naziv mestaRepublika integer n Uzima vrednosti 1..9Rep_Naziv char(8) n Naziv republikeUlica_I_Broj char(35) n AdresaOdgovornoLice char(30) n Odgovorno liceTelefon char(20) n TelefonOznTekRac integer n Oznaka teku}eg ra~unaOznStednja integer n Oznaka {tedweSWIFT char(28) SWIFT adresaDatDozv date n Datum dozvoleUgasena logical n Uzima vrednosti Da/NeOstecena logical n Uzima vrednosti Da/NeVlasnistvo logical n Uzima vrednosti Da/NeDKL Tabela fakata, po vrsti posla, na~inu,

zemqi, valuti i nameniVreme integer n 1 Strani kqu~Izvoz-Uvoz integer n 2 Strani kqu~VrstaPosla integer n 3 Strani kqu~NacinNaplate integer n 4 Strani kqu~Zemlja integer n 5 Strani kqu~Valuta integer n 6 Strani kqu~Namena integer n 7 Strani kqu~APR_Prijavljeno decimal n Iznos prijavqenih poslovaAPR_Izvezeno-Uvezeno

decimal n Fizi~ka realizacija prijavqenih poslova

APR_Naplaceno-Placeno

decimal n Finansijska realizacijaprijavqenih poslova

APR_Nenaplaceno-Neplaceno

decimal n Nerealizovane finansijske realizacijeprijavqenih poslova

APR_NerealizovanoURoku

decimal n Pro{ao rok realizacije prijavqenihposlova

AFZ_Vrednost decimal n Ukupne fizi~ke realizacijeAFZ_Naplaceno decimal n Finansij. realizac. fizi~kih realizacijaAFZ_Nenaplaceno decimal n Nerealizovane FR fizi~kih realizacijaAFZ_ProsaoRok decimal n Pro{ao rok naplate fizi~kih realizacijaAFI_Vrednost decimal n Ukupne finansijske realizacije

Tabela 4.6 Ilustracija fizi~kog modela


Tabela Brojslogova

Du`inasloga

O~ekivanirast

Inicijalnaveli~ina

Veli~inaza 6 meseci

Vreme 1825 55 0 0,1 MB 0,1 MBIzvoz-Uvoz 2 10 0 - -VrstaPosla 27 74 0 - -NacinNaplate 6 20 0 - -Namena 6 35 0 - -Zemlja 248 50 0 0,01MB 0,01MBValuta 201 54 0 0,01MB 0,01MBPreduzece 5791 133 0,1 % 0,77 MB 0,77 MBKursnaLista 125361 40 0,1 % 5 MB 5 MBDKL 9.500.000 211 3 % 2 GB 2,4 GBDKL-GRZ 957.000 200 2 % 200 MB 240 MB...

Indeks tabelefakata

Broj polja

primarni_inx 7 1 GB 1,2 GBinx2 4 500 MB 600 MBinx3 3 400 MB 480 MBagg_inx 3 300 MB 360 MB...

Tabela 4.7 Inicijalni prora~un veli~ine jednog Data Mart

Pitawa postavqawa konkretne BP, a koja se ti~u:

● memorije● veli~ine bloka● na~ina pristupa diskovima● skriptova BP i● parametarskih fajlova;

strukture fizi~kog sme{tawa:

● particionirawe● RAID - fault tolerance computing (Prof dr A. Avizienis), konfigurisawe volumena

i drajvova, kao i privremene (temp) BP;

kao i razlozi za implementaciju monitoringa kori{}ewa:

● performanse● korisni~ka podr{ka● marketing● planirawe● alati;

su strogo tehni~ka i previ{e obimna za izlagawe na ovom mestu.


Ta-bela

Indeks Tip Jedin-stven

Kolone Lokacija Argumen-tacija

DKL

DKL_pkey B-stablo * Vreme,Izvoz-Uvoz,VrstaPosla,NacinNaplate,Zemlja, Valuta,Namena

TSDKL_indexes

primarnikqu~

DKL_datum bitmap Vreme DKL_indexeskori{}eweu ve}inizvezdastihkorisni-~kih upita

DKL_VRP B-stablo VrstaPosla DKL_indexesDKL_NAC B-stablo NacinNaplate DKL_indexesDKL_ZEM bitmap Zemlja DKL_indexesDKL_VAL bitmap Valuta DKL_indexesDKL_NAM bitmap Namena DKL_indexesDKL_batch bitmap * Row_batch_key DKL_indexes rapidna

ekstrakcija

VremeVreme_pkey B-stablo * Vreme dim_indexes prim. kqu~Vreme_mes bitmap Mesec dim_indexes browse, filter,

group-byVreme_god bitmap Godina dim_indexes

BankeBanke_ pkey B-stablo * SifraBanke dim_indexes prim. kqu~Banke_rep bitmap Republika dim_indexes browse, filter,

group-byBanke_ red bitmap Redosled dim_indexes

ValutaValuta_pkey B-stablo * SifraNum dim_indexes prim. kqu~Valuta_alf bitmap * SifraAlfa dim_indexes browse, filter,

group-byValuta_podr bitmap Podrucje dim_indexes...

Tabela 4.8 Plan indeksirawa

Osnovni u~esnik u fizi~kom modelovawu je DBA, dok su mawe ili vi{eukqu~eni: analiti~ar poslovnog sistema, modelator podataka, menaxer projekta iostali. Projektovawe fizi~ke strukture je trajalo oko mesec dana.


4.6 NAÎN REALIZACIJE KORISNI^KIH ZAHTEVA

Realizacija korisni~kih zahteva je vezana za prezentacioni deo arhitektureDW.

Slika 4.11 Prezentacioni deo DW

Kqu~na pitawa se lociraju u oblastima izgradwe aplikacija za krajwekorisnike, dizajnu grafi~kih korisni~kih interfejsa, obuci korisnika i udomenu kontinuiranog obezbe|ivawa performantnosti mreè.

Obuka korisnika (training) je potrebna kako po pitawu aplikacija, tako i popitawu strukture i sadrìne podataka. Gro zahteva se svodi na obuku velike grupeanaliti~ara, koji startuju i modifikuju izve{taje - za ve}inu je dovoqancelodnevni kurs (prvi deo je upoznavawe sa DW, a drugu polovinu kursa ~ini obukaza rad sa alatom).

Ostala kqu~na pitawa se obra|uju u nastavku.

dimenzioni DataMartssa atomarnim

podacima

DWbus

konformnedimenzije i

fakti

dimenzioni DataMartssamo sa agregiranim

podacima

Katalogmetapodataka

prezentacioni serveriPristupniservisi

- upravqaweupitima

- DW browsing- za{tita- izve{tavawe- monitoring

izve{tajnialati

desktopalati

aplikacionimodeli

operacio-nalni

sistemi

servisipodaciLegenda


4.6.1 Bazi~ne korisni~ke aktivnosti

Vaqanost dizajna DW i implementacije odgovaraju}eg SUBP ~ine 60%kvaliteta DW re{ewa. Preostali veliki udeo u kvalitetu donosi na~inprezentacije podataka na ekranu ili na papiru.

Su{tina je u tome da korisnik nije sveden samo na prikaz podataka i shodnotome, danas postoje tri kategorije korisni~kih aktivnosti:

1. upore|ivawe2. prezentacija3. traèwe uzroka.

Ove aktivnosti su kompleksne, ali jednostavnost upotrebe odre|enog alata je uvekza malo va`niji faktor od wegove mo}i - osnovno je da alat uop{te bude kori{}en.Glavni moto je „jedan klik mi{em“, odnosno „pritisni dugme - vidi izve{taj“.Klik na dugme i kontekstno povezivawe se po pitawu komfora kori{}ewa, kaokriterijuma vaqanosti, mogu uporediti sa kori{}ewem telefona.

Komparacija (upore|ivawe)

Numeri~ke mere nemaju velik spoznajni potencijal dok se ne uporede uodnosu na ne{to. Komparacija se moè svesti na puko prikazivawe dva uporedivabroja jedan do drugog, ali se ti brojevi mogu iskombinovati u jedan u vidu odnosa,indeksa, razlike, procentne razlike, raspodele i sli~no. SQL (sintaksno) iziskujeizra~unavawe takvih pore|ewa u okviru reda izve{taja, ali ne pruà mogu}nostdirektnih komparacija izme|u redova - pore|ewa (kao osnov poslovnih analiza) suproblem za „nativni“ SQL!

Potrebno je odabrati takav alat koji omogu}ava:

● komparacije du` vremenskih intervala razli~ite granulacije● komparacije du` ostalih dimenzija● kompozitna pore|ewa du` dve ili vi{e dimenzija.

Korisnik treba lako da dolazi do ovih mogu}nosti i da ne bude optere}enizgledom generisanog SQL-a. Posledwih godina se radi na razvoju SQL -a koji }eomogu}iti neke od navedenih operacija.

Prezentovawe

Prezentacija moè biti tekstualna ili grafi~ka. Tekstualnoprezentovawe ukqu~uje:

1) klasi~ne formatirane izve{taje2) transformacije numeri~kih vrednosti u tertile (visoka, sredwa, niska ili

sl.), kvartile, zone, pokretne proseke i sume, totale, ...3) radne tabele sa dinami~kim }elijama4) specijalno ozna~avawe izuzetaka (exceptions)


5) specifi~nosti vezane za ekranski prikaz (touch screens, pivot, ...).

Grafika je, naravno, raznovrsnija:

1) grafikoni (re{etkasti, „pite“, ta~kasti)2) mape3) dinami~ki grafovi (prikazivawe promena tj. kretawa i korisni~ka

navigacija).

Podaci ne smeju biti zarobqeni u nekom prezentacionom alatu - obezbe|enaje laka transformacija u razli~ita prezentaciona okruèwa, za razli~itepotrebe.

Traèwe uzroka

U davawu odgovora na pitawe „Za{to?“ od velike pomo}i su alati koji:

● prikazuju izuzetke● upravqani su doga|ajima (a ne procedurama)● poseduju aktivne agente● omogu}uju drill up i drill down du` dimenzija● omogu}uju drill across du` tabela fakata● omogu}uju dinami~ko dodavawe mera.

4.6.2 Korisni~ke aplikacije

Svrha DW nije da samo par naprednih korisnika uz pomo} ad hoc alata radisa bazom - teì se masovnoj upotrebi. S toga je oformqen mali tim za produkcijukorisni~kih aplikacija (End User Aplications - EUA). ^lanovi ovog tima suodabirani prema kriterijumu da detaqno poznaju zahteve krajwih korisnika i da uistoj meri poseduju odgovaraju}a informati~ka znawa. Osnovni zadaci tima su:

● razvoj op{teg plana aplikacionih templejta ({ablona - templates)● izgradwa funkcionalnih i fleksibilnih aplikacionih templejta● izgradwa mo}nijih aplikacija● obezbe|ewe interaktivnog monitoringa izvr{ewa aplikacija.

Na slede}oj slici je pozicionirana uloga EUA u budu}em DW. Vertikalnestrelice (od desktop alata ka EUA i od EUA ka izve{tajnom okruèwu) ozna~avajumigracione puteve.


Slika 4.12 Uloga aplikacija za krajwe korisnike

U ve}ini slu~ajeva, individualni skup podataka ne ~ini potpun odgovor naposlovno pitawe. Kompletan odgovor na poslovno pitawe zahteva poslovniizve{taj, koji simultano prezentuje informacije u raznim oblicima (na~inima)i koji se naj~e{}e sastavqa iz vi{e skupova odgovora. Po{to ranije nabrojaniprezentacioni modovi (ukqu~uju}i i neprikazivawe odre|enih redova) uglavnomnisu podràni SQL-om, potrebna je naknadna obrada (postprocesirawe)rezultuju}ih skupova.

Prvi korak u naknadnoj obradi je usagla{avawe skupova odgovora sa ciqemvr{ewa komparacija. Pri tome je va`no ukazati na hijerarhiju (po sloènosti)vidova pore|ewa:

1. prosta pore|ewa2. vi{estruka pore|ewa3. vi{edimenzionalna pore|ewa4. pore|ewa sa raznolikom granulacijom5. break rows - zahtevaju group by i order by klauzule.

Detaqna razrada ovih pitawa se moè na}i u [1], str. 245.

Za dodavawe kolone pore|ewa i break rows postoje ~etiri raspoloìvetehnike:

1. self join - uvo|ewe novog logi~kog imena za tabelu daje poprili~no „ruàn“SQL kod, koji se pri tome mora ru~no pisati i koji je nepogodan zaizvr{avawe i optimizaciju

2. povezani podupiti - ni{ta kvalitetnije re{ewe, te ni ono nije odabrano

PRIRODAKORI[]EWA

TIPUPOTREBE

INFORMACIJSKIINTERFEJS

VREDNOST

Strate{ko

Operacionalno

mo}ni(ad hoc)

korisnici

(push-button)menaxeri

znawa

„potro{a~i“standardnih

izve{taja

десктоп алати za„уради сам “ upite

aplikacijeza krajwekorisnike

operacionalnoizve{tajnookruèwe

Izve{tavawe//analizePrimeriPouzdane refe-rentne ta~ke

Mali naporUvid u teku}eposlovaweFleksibilnost


3. CASE naredba - daje kompaktniji i ~itkiji SQL, koji i daqe nije realnoupotrebqiv (iz mnogih razloga)

4. odvojeni upiti - jedina upotrebqiva tehnika koja svakoj komponentikomparacije pridodaje poseban upit; mnogobrojne su prednosti (kompaktanSQL, lak za kontrolu, koristi agregacioni navigator, re{eno je deqewenulom, lak{e dinami~ko mewawe izve{taja), ali postoji i nekolikonedostataka (upravqawe odvojenim upitima i sort-merge odn. outer-joinskupova).

Zahtevi za korisni~ki intefejs

Osnovni princip glasi: „prepoznavawe i ozna~avawe, umesto pam}ewa ipisawa“.

Vidqivost (visibility) - pogotovo najbitnijih elemenata: dimenzija,ograni~ewa nad dimenzijama, osnovnih tabela ~iwenica, trenutnog statusaizve{taja (kao i informacija o potrebi osveàvawa izve{taja). Ne trebaprikazivati svaki detaq tabele ako nije zahtevan, ve} samo informaciju da tabelapostoji.

Modifikovawe kolona izve{taja - direktno mewawe (ponu|enih)ograni~ewa i moda kolone (komparacioni ili prezentacioni), koje }e iziskivatiponovni upit samo za modifikovanu kolonu.

Zaustavqawe upita - postojawe trenutne STOP komande, koja zahvaquju}imultitasking operativnim sistemima ne}e „zarobiti“ ra~unare korisnika.

Prilago|enost korisniku je artikulisana kroz razli~ite tipoveinterfejsa:

● interfejs za rukovodioce - ozna~avawe izuzetaka uz mogu}nost traèwarazloga (uzroka), bez konstrukcija i modifikacija

● interfejs za analiti~are - mewawe ograni~ewa, specifikacija iprezentacionih modova izve{taja (kolona)

● razvojni interfejs - izgradwa izve{taja koji omogu}uju pristup svimdimenzijama i faktima, sa kompletnim HELP sistemom.

4.6.3 Upitni alat

Upitni alat se tetira kao bilo koji softverski klijent nekog SUBP, koji:

1) {aqe SQL zahtev (obi~no male duìne) i2) prima odgovor u vidu skupa podataka (potencijalno veoma velike duìne), u

nastavku - rezultuju}i skup.

Upitni alat moè biti: samostalni softverski paket, standardna radnatabela (sa ugra|enim SQL naredbama), generator izve{taja ili DS aplikacija (sa


specifi~nim korisni~kim interfejsom). Velika organizacija obi~no ima vi{ealata za upite, koji treba da se uklapaju u odabranu arhitekturu, {to zna~i:

● kori{}ewe SQL-a kao medijuma, {to omogu}ava zamenqivost alata i SUBP-abez velikih tro{kova (uz o~evidnost nesavr{enosti SQL-a)

● nezavisnost povezivawa BP (pomo}u protokola ODBC ili EDASQL)● postojawe mre`nog agregacionog navigatora (obja{weno u 3.5)● minimizovawe (optimizovawe) komunikacije sa SUBP.

Osobine upitnih alata

Upitni alat, kao okruèwe za kreirawe i prezentovawe parametrizovanihizve{taja, treba da poseduje ~itav niz osobina koje }e u nastavku biti saètodefinisane.

Browsing - dobar browser omogu}ava razumevawe velikih dimenzija od stranekorisnika. Pri tome, outer joins su uvek dvosmerni (simetri~ni).

HELP interfejs - postoje slede}e vrste interfejsa vezanih za pomo}nefunkcije:

1. dokumentacija (hipertekst, ...)2. HELP na komande3. HELP za uobi~ajene aktivnosti4. obja{wewa podataka (information dictionary) - poslovna i tehni~ka.

Distribuirane kalkulacije - prikaz nezbrojivih mera treba da ima svepovoqnosti koje se javqaju i kod zbrojivih mera. Da bi se to obezbedilo, neophodnoje da izra~unavawe nezbrojivih pokazateqa bude posledwi korak upitnog alata(pre prezentacije) nad aditivnim komponentama iz SUBP. Matemati~ki re~eno -izra~unavawa se distribuiraju du` suma i nikako nekim drugim putem.

Drilling down u su{tini daje odgovor na pitawe za{to, te je direktnopovezano sa upravqawem izuzecima odn. traèwem uzroka. Drill down nije prostokretawe du` predeterminisane hijerarhije. Naime, bilo koji atribut bilo kojedimenzije moè biti pogodan put za davawe detaqnijeg prikaza. Kontekstni drilldown objekti omogu}uju skok na potpuno novi izve{taj sa brojnim varijacijama.

Drill across - potpuno druga~iji koncept, koji se tako|e izvr{ava uz outer join,a zahteva podudarnost zaglavqa kolona i „inteligentno“ upozorava korisnika opotencijalnim neslagawima i nelogi~nostima.

Napredno rukovawe izuzecima:

● crveno/zeleno ili fle{● prikaz/izbacivawe samo izuzetaka● prikaz/izbacivawe samo null vrednosti● ozna~avawe prvih/posledwih N vrednosti u izve{taju● ozna~avawe prvih/posledwih N procentualnih vrednosti u izve{taju● ozna~avawe prvih/posledwih N procentualnih vrednosti sume


● ozna~avawe prvih/posledwih N vrednosti u odnosu na zadate granice● agenti (napredna mogu}nost) - izuzetnost u odnosu na nevidqive mere (trendove

i sl.)● trigeri (napredna mogu}nost) - aktivirawe u odnosu na datum, dostizawe neke

grani~ne vrednosti i sl.

Pro{irene SQL agregacione operacije - uz postoje}e SUM, MIN, MAX, AVG,COUNT, pojavquju se PERIODAVG (vra}a periodni prosek) i PERIODCOUNT (vra}akardinalitet), uz generalizovane oblike DIMENSIONAVG i DIMENSIONCOUNT -ove operacije vr{e deqewe mera brojem vremenskih intervala, te su mogu}e jedinoza potpuno aditivne ~iwenice koje su u obliku vremenskih serija.

Bihejvioralna ograni~ewa - pra}ewe pona{awa je interesantna i te{kaoblast. Mogu}e su razne forme i poslo`wewa, a najprihvatqivije re{ewe jeformirawe grupa i tabela pripadnosti.

Pruàwe (isporuka, handing off) podataka je fundamentalna mogu}nost,koja je u stvari kombinacija prezentacije i komunikacije. Elektronska po{ta jestoèr odlu~ivawa kooperativnih grupa. Osnovno je da sve komponente upitnogalata (upiti, komparacija, prezentacija i traèwe uzroka) budu transferabilneizme|u korisnika, putem elektronske po{te. [tampawe predstavqa jedan vidpruàwa podataka.

Postoji jo{ ~itav niz poèqnih osobina vezanih za: batch operacije,komparacije (obja{weno ranije), interakciju sa agregatima, break rows (nijetotalno nov koncept, javqao se i ranije kao ideja), pivoting, ...

Svaki upitni alat aktivira mnogobrojne administrativne zadatke. U [1] str. 247.nalazi se kompletna lista ovih zadataka.

4.6.4 Performantnost mreè

Statisti~ki, 100 korisnika po{aqe dnevno 3000 upita, od ~ega 80%jednostavnih (jednotabelarnih) i 20% sloènih. Vremenom, ukoliko porasteinteres za podacima u DW, dostiè se broj i od 8000 upita (pri ~emu udeojednostavnih bude 90%). Jednostavan upit bi trebao da se prikaè u sekundi, doksloèniji moè zahtevati angaòvawe svih procesora i svih diskova na serveru.Preporuka je da se korisni~ki zahtevi zadovoqavaju uz pomo} vi{e jednostavnihupita, namesto maweg broja kompleksnih upita (nastalih spajawem vi{e tabela).Tada se naknadno vr{i sortirawe i kombinovawe separatnih rezultuju}ih skupova(podataka).

Okruèwe DW je napravqeno na razra|enim tehnolo{kim osnovama, tako daobezbe|uje visoke performanse kroz paralelizam SQL upita. Objektno-relacioniprilaz moè biti iskori{}en u svrhu prilago|avawa BP poslovnom okruèwu.Implementacija poslovnih tipova podataka pojednostavquje formulaciju upita,zbog rada na vi{em novou apstrakcije. Tako|e, aplikacije koje rade sa ovimtipovima su stabilnije, jer rade na poslovnom nivou. Kori{}ewe stabilnoginterfejsa ka poslovnim objektima {titi aplikacije od revizija u poslovnim


pravilima. Objekti bazirani na serveru obezbe|uju dodatnu performantnost,preko kompiliranih funkcija i redukcije u razmeni podataka izme|u servera BP iaplikacionog programa.

Lete}e (on-the-fly) DBMS tabele se mogu kreirati u svrhu izvr{ewa outer-joinna SUBP. Odre|eni problemi ostaju:

● veliki deo obrada na rezultuju}em podacima su sekvencijalne(numerisawe redova, kategorizacija, sumacije, ...)

● moè se pojaviti veliki broj (~ak 50) posrednih tabela; ovaproliferacija pomo}nih tabela moè izazvati dodatne probleme

● pojavquju se odre|eni „transakcioni“ problemi i problemi prilikompogre{nih zahteva.

Poèqno je da upitni alat funkcioni{e ~ak i na udaqenoj mreì koja nijefizi~ki povezana sa SUBP. Pri svemu tome je bitno obezbediti brz rad mreè, jerje neprihvatqivo izlistavawe (browsing) neke standardne dimanzije u vremenu 5-10sekundi. Naime, produàvawe izlistavawa sa 1s na 5s predstavaqa degradaciju od500%, {to }e se u nekoj kriti~noj aktivnosti svakako primetiti, ali i negativnoodraziti.

Na kraju, ilustracije radi, sledi prikaz DW servera ~ija realizacija seostavqa za neku udaqenu ta~ku na vremenskom horizontu (te ne}e biti detaqnijerazmatrana), ali koju treba imati u vidu prilikom daqeg rada jer je u svetuvrhunskih tehnologija ona ve} realnost.


Slika 4.13 Arhitektura modernog DW servera

nepouzdana mre`a

enkriptovana komunikacija preko VPN protokola

interfejs pristupnih tokena, lista radnihtabela i Cookies

klijent

enkriptovana komunikacija preko VPN protokolaserver

internikorisnici

WEB serverdinami~ke HTML stranice i aplet kod

serverHTML stranice koje referenciraju Java aplete,

ActiveX kontrole

Firewall; server LDAP direktorijamre`na autentifikacija i kontrola pristupa

OLAP i ROLAP aplikacioni server

serverCGI & ISAP/NSAPI omogu}uju CORBA & COM

SUBP agregaciona navigacija

serverSQL

5. Zakqu~ci

ER modelovawe zapravo ne modeluje biznis, ono modeluje mikrorelacijeizme|u podataka. Drugim re~ima, ER modelovawe ne poseduje poslovna pravila, ve}poseduje pravila o podacima. ER modeli su izuzetno promenqive strukture ipode{ena {ema je veoma osetqiva u slu~aju promene upita (zbog svojeasimetri~nosti). Tehnike dimenzionog modelovawa primarno modeluju semantiku,a ne strukturu podataka.

Pojava SQL-a je imala daleko ve}i uticaj na DSS nego same relacione BP.SQL je neproceduralni DML jezik relacione BP, nepogodan za kreiraweaplikacija, ali veoma upotrebqiv za pretragu BP. Iako u principu mali deokorisnika mo`e da nau~i SQL, wegove velike prednosti su produktivnost,konzistentnost i transparentnost za same dizajnere DSS.

Ipak, bez obzira {to je danas mogu}e skenirawe tabele od milijardu slogova(primenom paralelnih procesora), moderno okru`ewe je nezadovoqanonepostojawem STOP komande. Pored toga, iako SQL poseduje sofisticiranelogi~ke komande, ne postoje komande i alati za efikasno pore|ewe dva broja.

Postoje tri na~ina uskla|ivawa DSS sa postoje}om kulturom odlu~ivawa:

1. direktno preuzimawe postoje}eg modela odlu~ivawa i, ukoliko je ondisfunkcionalan, bi}e takav i odgovaraju}i DSS - period automatizovanoghaosa, pra}en pojavom „paralize odlu~ivawa“

2. ignorisawe postoje}eg i konstrukcija DSS pomo}u generi~kog modelaodlu~ivawa - uglavnom ve{ta~ki pristup koji daje neprihvatqiva re{ewa


3. kriti~ko istraìvawe postoje}eg procesa odlu~ivawa, ~ime konstrukcija DSSpostaje katalizator za redizajn okruèwa u kome se donose odluke.

Fleksibilno uskla|ivawe sa postoje}om kulturom i klimom organizacije,odn. potowi na~in, se name}e kao jedini logi~an izbor - koji nije lako ostvariti.Ne uspeva svako preduze}e da izgradi efektivan DW - u stvari, vi{e je neuspe{nihnego uspe{nih projekata. Gra|ewe DW je mawe klasi~an problem kompjuterskenauke, a vi{e problem koordinacije. Pri tome se, u inèwerstvu DW, konkretanDW (informaciono skladi{te podataka) posmatra analogno fizi~kimskladi{tima (magacinima).

Poznato je da se za OLTP zahteva ACID test (atomicity-atomarnost, consistency-konzistentnost, isolation-izolovanost i durability-trajawe). Za uspe{nost DW osnovupredstavqaju mo}an re~nik podataka (repozitorij metapodataka) i skupdizajnerskih principa. Kriti~ni faktori uspe{nosti u izgra|ivawu DW su:

Sponzorstvo od strane menaxera - neophodne interne (kulturalne) promenezahtevaju: saglasnost menaxmenta da promene postaju kako strategija, tako i ciqcelokupne organizacije, obavezivawe svih zaposlenih na aktivno ukqu~ivawe upromene, jer „qudi vole da mewaju, a ne vole da se mewaju“ i kona~no, odgovaraju}isistem kriterijuma za nagra|ivawe.

Ukqu~enost svih potencijalnih korisnika - jer su korisnici DW istovremeno ivlasnici operacionalnih podataka.

Poslovni zahtevi - najboqi izvor ovih zahteva su: strategijski plan organizacije(koji prikazuje svrhu, misiju i ciqeve organizacije) i mere performansi (kojeslede iz strategijskog plana i koje su kqu~ za uspe{no upravqawe organizacijom,po{to su unakrsne i povezane sa odgovaraju}im strategijskim kriterijumima).

Informaciona arhitektura organizacije - nastaje kombinovawem strategijskogplana i:

● arhitekture podataka organizacije - normalizovan model podataka koji opisujesve potrebne podatke i relacije

● arhitekture informacionih sistema - opisuje sve IS koji se koriste(potrebno je da ovi IS budu povezani sa elementima preostale dvepodarhitekture)

● tehni~ke arhitekture organizacije - hardverske platforme, operativnisistemi i telekomunikaciona infrastruktura.

DW arhitektura i dizajn - 60% gre{aka u izgradwi DW je posledica planirawa,analize i dizajna (ne odabira hardvera i softvera); arhitektura i dizajn DW bitrebali biti zasnivani na internim informacionim zahtevima (a ne naspecifi~nim tehnologijama) i sastoje se od:

● modela podataka - defini{e izvore podataka, na~ine transformacije podatakai obezbe|uje kvalitet podataka

● metapodataka - esencijalni deo DW, naj~e{}e odvojen od ostalih podataka udigitalni repozitorijum; osnovna dva tipa su:

Закључци 141.

o strukturalni metapodaci - slede iz modela podataka, a opisuju sadràji strukturu DW, kao i poslovne mere i mere performansi (programa iupita)

o metapodaci pristupa - sadrè lokacije i opise DW servera, BP,tabela, podataka, suma, pravila (transformacija i drill-ovawa) ibezbednosti

● komponenata DW - detaqni podaci, delimi~no sumirani podaci, visokosumirani podaci, arhive (naj~e{}e sadrè podatke starije od dve do pet godina,obi~no sumirane - koji se koriste za analizu trendova i predvi|awa, kao iodgovaraju}e metapodatke), sistemi slogova i programi zaintegraciju/transformaciju podataka

● strukture DW - neka od najva`nijih pitawa su distribucija podataka (naudaqene ra~unare ili klastere), replikacija podataka (jednosmerna ilidvosmerna, sinhrona ili asinhrona) i wihov uticaj na DW aplikacije i ukupnoupravqawe DW; osnovne strukture su:

o fizi~ki DW - fizi~ka BP sa podacima, metapodacima i proceduramao logi~ki DW - sadrì i metapodatke, ali ne sadrì aktuelne podatkeo Data Marts - uz eventualne Data Mart servere.

DW tehnologija - neposredno po definisawu DW arhitekture potrebno jerazmatrati raspoloìve tehnologije, grupisane u slede}e celine:

● korisni~ki interfejsi - sami korisnici bi trebali biti ukqu~eni u odabirinterfejsa, pri ~emu su glavni kriterijumi jednostavnost kori{}ewa iperformantnost, uz dostupnost metapodataka; èlim da naglasim da nijedovoqno da interfejs bude grafi~ki (GUI) da bi automatski bio dobar;korisnici se mogu podeliti i prema informati~koj pismenosti i potrebama:

o informati~ki „turisti“ - relativno zapla{eni pojavominformacionih sistema i ukoliko su rukovodioci, potpuno seoslawaju na rad svojih sekretarica i asistenata

o po~etnici - zadovoqavaju se setom standardnih izve{tajao analiti~ari - korisnici koji ve{to rukuju brojevima i odgovaraju}im

alatima (radnim listovima); oni raspoloìve podatke filtriraju ikategorizuju i potom deriviraju nove podatke

o tehni~ki orijentisani - èle da imaju kompletnu kontrolu nadna~inom na koji dobijaju i formatiraju podatke, kao i sveraspoloìve DW alate

● DW „pogon“ - struktura softvera BP i mreè koji omogu}uju rad DW● hardverske platforme - po{to je eksponencijalni rast broja korisnika i

kompleksnosti upita neizbeàn, ali i teàk za prora~un, preporu~uje sestepen sigurnosti bar dva i skalabilnost sistema; postoje ~etiri tipskaslu~aja:

o mala baza, bez ekstremno kompleksnih upita (vaì u NBJ) - LANserveri, sa jednim I/O bus-om

o sredwa do velika baza, kompleksniji upiti - SMP ma{ine sa bar dvaI/O kanala

o veoma velike baze, veoma kompleksni upiti - klasteri SMP ili MPPservera, sa ve}im brojem I/O kanala

o baze preko 10 TB, ekstremno kompleksni upiti - mainframe sistemi● sistemski softver● bezbednost - fault-tolerant i/ili redundantan hardver.


Kvalitet informacija - pravovremenost, aktuelnost i ta~nost su najva`nijifaktori uspeha DW; ako DW sadrì lo{e podatke korisnici ga ne}e koristitiili, {to je jo{ gore, koristi}e DW na {tetu preduze}a.

Infrastruktura razvoja - ovaj vrlo bitan faktor se naj~e{}e zanemaruje; u ciqukonzistentnog dizajna, razvoja i implementacije DW preduze}e mora imatirazvojnu infrastrukturu koja koristi najboqe metode i tehnike i koja ukqu~uje:

● projektne timove - jo{ jedan od kriti~nih kulturalnih elemenata● razvojnu metodologiju - metodologija potpunog ìvotnog ciklusa (koja mora

biti strategijski vo|ena, fokusirana na korisnike, zasnovana nainformacijama i modelima, disciplinovana, rigorozna i ponovqiva) jenesumwivo conditio sine qua non uspe{nog inèwerstva DW

● razvojne alate - CASE alati, jezici ~etvrte (i pete sic!) generacije, EIS i DSSalati, alati za integraciju/transformaciju i razni specijalni DW alati

● ve{tine i znawa - iskustvo sa OLAP alatima i sistem integracijom, tehni~kakultura (sa akcentom na operativnim sistemima, bazama podataka, DSS alatima,korisni~kim interfejsom i klijent-server konceptom), visok nivo poznavawarelacionih koncepata, komunikativnost i mnogi drugi kvaliteti su prakti~noobavezni i po potrebi ukqu~uju angaòvawe iskusnih konsultanata i/ili obukuinternog osobqa; znawa iz oblasti organizacionog inèwerstva,reinèwerstva poslovnih procesa (BPR - Business Process Reingeneering),upravqawa kvalitetom (TQM - Total Quality Management) i informacionoginèwerstva (IE - Information Engineering), svakako su dobrodo{la.

Za izgradwu efektivnog DSS okruèwa podaci moraju biti integrisani,oboga}eni i dostupni. To implicira da organizacija mora odvojiti posebnu(hardversku i softversku) platformu i ta dva sistema su simbioti~ki povezana -uzajamni reinèwering. Budu}nost DW je u softverskim prednostima idisciplini u dizajnu. U Prilog 6 je data kontrolna lista za kvalitet DW.

Data Warehousing je danas jedan od najaktuelnijih informati~kih (iindustrijskih) trendova, ne bez razloga. Me|utim, pogre{no je misliti da ova novafaza ukida prethodnu. Prakti~no je neostvarivo da se realizuje DW sistem, a daorganizacija nije prethodno razvila i implementirala kvalitetan OLTP.

Smatram da su uvr|eni metodolo{ki i tehnolo{ki aspekti izgradwe DWpostignuti rezultati teorijskog dela istraìvawa. Doprinos empirijskogistraìvawa je prototip DW, koji je realizovan na nivou dva segmenta (procesa),{to }e biti od velike analiti~ke koristi menaxerima u NBJ - pri tome jeuo~qivo do{ao do izraàja idiografski pristup. Uzorak u ovom istraìvawuzadovoqava kriterijum ekonomi~nosti za ocenu vaqanosti plana uzorkovawa -teìlo se izboru uzorka koji uz {to mawe angaòvawe vremena, energije i novcaomogu}ava {to ve}u (optimalnu) preciznost i ta~nost zakqu~aka.

Kqu~na pitawa, pobrojana u Glavi 2, su podrobno obra|ena, sa izuzetkomData Mining-a, koji je dominantno obra|en teorijski, a nedostatak prostora nijedozvolio detaqan prikaz konkretnih rezultata. Razvoj u NBJ treba da budecentralizovan i sinhronizovan, jer je guverner jama~no sna`niji sponzor odzamenika generalnog direktora Filijale. Neostvarewe ovog zahteva je sigurno nejedini, ali najve}i nedostatak ovog rada i istraìvawa.

P r i l o z i


P.1 BAZE PODATAKA

Uvod

Poqe je najmawa imenovana jedinica podataka sme{tena u bazi podataka(BP); slog je imenovani skup poqa; datoteka je imenovana kolekcija svih pojavajednog tipa sloga, dok je BP struktura nad skupom datoteka.

BP je u isto vreme integrisana i deqena: Integrisana zna~i da BP predstavqa strukturu nad skupom datoteka. Skup

datoteka je takav da u BP ne postoje dve iste datoteke, ~ak ni delovi tihdatoteka. Dakle, integrisano{}u se nastoji smawiti redudantnost (vi{estrukozapisivawe istih podataka) na minimum.

Deqena zna~i da pojedini delovi podataka iz BP mogu biti deqeni izme|uvi{e sli~nih korisnika BP. Dakle, za korisnike koji koriste iste podatke izBP, podaci ne}e biti vi{estruko zapisivani.

êsto, pojedini korisnici èle samo pojedine delove BP, a obi~no ikorisnicima istih delova BP trebaju ti podaci na razli~ite na~ine (~ak i kadadva korisnika dele isti podskup BP pogledi na te poskupove podataka ~esto semnogo razlikuju). Stoga sistem BP mora obezbediti razli~ite na~ine pristupaistim podacima.

BP i klasi~na organizacija podataka

Kod klasi~ne organizacije podataka svaka aplikacija ima svoje vlastitedatoteke, koje samo ona koristi. U odnosu na wu, BP nisu nastale kao rezultatnapretka tehnologije, nego kao rezultat primene novog koncepta u organizovawupodataka. U obja{wenim pojmovima integrisanosti i deqenosti leì su{tina togpristupa organizovawu podataka.

Razlike izme|u BP i klasi~ne organizacije podataka

Redudantnost. U klasi~noj organizaciji podataka svaka aplikacija ima svojevlastite datoteke. To dovodi do redudantnosti podataka i rasipawa prostora.Primer P.1. Datoteka aplikacije za prijavu ispita studenta sadrì osnovnepodatke o studentu. Te iste podatke sadrì i datoteka aplikacije za overusemestra. Obe datoteke }e sadràti podatke o imenu i prezimenu studenta, brojuindeksa itd. Ove dve datoteke (koje su gotovo jednake) mogu biti integrisane, {to}e dovesti do smawewa redudantnosti podataka.

Redudantnost podataka ne moè biti ukinuta, ali se moè svesti naminimum, tj. moè se kontrolisati. Dakle, sistem je „svestan“ redudantnosti ibrine se o konzistentnosti podataka.

Konzistentnost. Konzistentnost ozna~ava usagla{enost podataka u sistemu (svakedve datoteke u sistemu koje kao svoj podskup imaju podatke o istim objektimarealnog sistema, ne smeju sadràvati razli~ite podatke o tim istim objektima).

Прилози 145.

Primer P.2. Zaposleni Z1 radi u odeqewu O1. U klasi~nom sistemu ovaj podatak}e sadràvati i datoteka svih zaposlenih i datoteka platnog spiska. O~igledno daako je radnik otpu{ten (ne radi ni u jednom odeqewu), treba ga izbaciti i saplatnog spiska. Me|utim, kako se ovde radi o dve datoteke koje koriste razli~itiprogrami, to podaci u wima ne}e biti usagla{eni. Drugim re~ima, sistem }e sena}i u nekonzistentnom stawu (sadrà}e konfliktne ili nekorektne podatke).

Naravno, sve konfliktne situacije nemogu}e je prevazi}i konceptom BP(uvek pro|e neko vreme dok se baza usaglasi sa stawem realnog sistema), ali BPomogu}avaju kontrolisanu redudantnost (samim tim i kontrolisanunekonzistentnost).

Delewe podataka. Podrazumeva delewe istih podataka izme|u vi{e aplikacija.Me|utim, podrazumeva i mogu}nost razvijawa novih aplikacija koje }e operisatisa istim podacima. Drugim re~ima, da bi se udovoqili neki novi zahtevikorisnika nema potrebe kreirati nove datoteke.

Po{tovawe standarda u pohrawivawu podataka. S obzirom da je BP centralizovansistem (u slu~aju nedistribuiranih BP), mogu}e je lako proveravati po{tovawestandarda u reprezentaciji podataka. Ovo je zna~ajno zbog mogu}nosti razmenepodataka izme|u vi{e sli~nih sistema.

Za{tita podataka. Pedstavqa jednu od najva`nijih karakteristika BP.Administrator BP moè definisati pravo pristupa za bilo koji deo BP(definisawem provera za pristup). Bez ovoga, sistem BP bi bio opasniji odklasi~nog necentralizovanog sistema, jer bi neovla{}eni korisnik lak{e mogaopristupiti nedozvoqenim podacima (posledica centralizovanosti).

Odràvawe integriteta BP. Problem integriteta posmatra se u odnosu nadefinisani skup ograni~ewa. To je problem ta~nosti podataka u BP.Nekonzistentnost izme|u podataka o istom objektu je primer naru{avawaintegriteta BP. Naru{avawe integriteta BP moè se desiti samo u slu~ajuredudantnosti podataka. S obzirom da se i u BP javqa redudantnost podataka,moè do}i do naru{avawa integriteta BP. Upravo osobina centralizovanostiomogu}ava o~uvawe integriteta BP. Jedno brisawe ili modifikacija u BPpovla~i izvr{avawe dodatnih operacija da bi se o~uvao integritet. Naru{avaweintegriteta BP bilo bi opasnije nego naru{avawe integriteta klasi~nog sistema,upravo zbog deqewa istih podataka. Bez odgovaraju}ih validacionih procedura,jedan program moè generisati nekorektne podatke i „inficirati“ drugeprograme koji koriste iste podatke (ovo je opet posledica centralizovanosti).

Prevazilaèwe konfliktnih zahteva. Administrator BP treba da struktuirasistem BP onako kako to odgovara najve}em broju korisnika. Naravno, mora sevoditi ra~una i o va`nijim i ~e{}e kori{}enim aplikacijama, tj. nastojati da imse prilagodi struktura.

Nezavisnost podataka. Ovaj pojam je lak{e objasniti preko wemu suprotnog pojma.Intuitivno, {ema BP je zavisna ako u woj postoje dva puta za pristup istomobele`ju. Aplikacija zavisna od podataka je takva aplikacija koja u sebi sadrìinformacije o fizi~koj organizaciji podataka i tehnikama pristupa BP. Vremejednog aùrirawa relacije BP nad zavisnom {emom, u grani~nom slu~aju, moèzavisiti od broja torki (slogova) u celoj BP, {to je posledica potrebe provere i


eventualnog mewawa sadràja drugih relacija. Ako se te provere ne sprovedu, BPmoè ostati u nekonzistentnom stawu.Primer P.3. Neka je datoteka koju koristi aplikacija, indeks-sekvencijalneorganizacije. Ako je u logici aplikacije sadràna informacija o organizacijidatoteke, tada takvu aplikaciju nazivamo zavisnom od podataka (od wihovefizi~ke reprezentacije). U ovom slu~aju nemogu}e je promeniti fizi~kustrukturu podataka ili strategiju pristupa bez promene same aplikacije.

U radovima posve}enim ovom problemu, postavqa se pitawe da linezavisnost predstavqa samo teoretski kompleksnu estetsku osobinu {eme BP,ili ima i prakti~nog zna~aja. Zbog kompleksnosti samog pojma se o nezavisnosti,pri projektovawu {eme BP u praksi, retko vodi ra~una. Me|utim, nezavisnostpredstavqa jedan od kriterijuma za ocenu kvaliteta projekta {eme BP i sigurno jejedna od va`nijih karakteristika. U sistemu BP ne sme se dozvoliti zavisnostpodataka zbog najmawe slede}a dva razloga:

1. Razli~ite aplikacije mogu zahtevati razli~ite poglede nad istim podacima.Primer P.4. Neka postoje dve aplikacije u sistemu A i B , i neka svaka

sadrì datoteku koja sadrì poqe plata. Neka aplikacija A operi{e sa ovimpoqem u decimalnom obliku, a aplikacija B u binarnom. Klasi~ni na~inorganizacije podataka bi podrazumevao formirawe dve datoteke o istim podacima.

Me|utim, u slu~aju BP mogu}e je integrisati ove dve datoteke i na taj na~ineliminisati redudantnost. To zna~i da }e se odabrati jedna reprezentacijapodataka (decimalna, binarna, ili neka tre}a), a sistem BP }e se brinuti okonverziji te reprezentacije u formu koju zahteva aplikacija. Ako u gorwemprimeru, odlu~imo da ~uvamo podatke u decimalnom obliku, tada svaki pristupaplikacije B }e zahtevati i konverziju traènog podatka u binarni oblik.

Dakle, nezavisnost podataka obi~no podrazumeva razliku izme|u oblikapodatka kako ga vidi aplikacija, i oblika kako je taj podatak fizi~ki pohrawen.

2. Administrator BP moè mewati na~in unutra{we (fizi~ke) reprezentacijepodataka ili moè mewati strategiju pristupa.

Ove promene se prave da bi se udovoqilo novim zahtevima ili poboq{aleperformanse sistema. U klasi~noj organizaciji, ovakve izmene obavezno povla~e imodifikacije aplikacija. Me|utim, ako su aplikacije nezavisne od podataka, tadasve ove promene ne uzrokuju intervencije u ve} postoje}im aplikacijama. Jo{ nekepromene koje se mogu desiti, a koje ne smeju izazvati promene aplikacije su:promena prioriteta aplikacija, novi tip spoqne memorije... U slu~aju aplikacijazavisnih od podataka ovakve izmene zahtevaju promene i u wihovom kodu, {to ~estoiziskuje vi{e programerskog napora od pravqewa potpuno nove aplikacijeprilago|ene novonastaloj situaciji.

Ako je {ema BP nezavisna, tada je dovoqno, nakon pojedina~nog aùrirawasvake relacije, proveriti da li je ona lokalno konzistentna, pa da BP bude iglobalno konzistentna. Baze podataka nad nezavisnim {emama pripadaju klasi BPsa konstantnim vremenom aùrirawa.

Arhitektura BP

Arhitektura BP se moè posmatrati na tri op{ta nivoa: interni

Прилози 147.

konceptualni eksterni.

Interni nivo je najbliì fizi~koj reprezentaciji podataka (odnosi se nana~in kako su podaci zaista pohraweni u BP). Eksterni nivo je najbliìkorisniku (odnosi se na na~in kako podatke iz BP vidi pojedina~ni korisnik),dok se konceptualni nivo nalazi izme|u ta dva nivoa.

Na slici P.1. je prikazan odnos ova tri nivoa.

Slika P.1. Nivoi u arhitekturi BP

Eksterni nivo se odnosi na individualni pogled korisnika. Postoji vi{eeksternih pogleda istog dela BP. Konceptualni pogled je, za razliku od eksternog,samo jedan i predstavqa apstrakciju fizi~ke reprezentacije BP u celini. Tako|e,postoja}e samo jedan interni pogled, koji predstavqa celokupnu BP onako kako jeona zaista (fizi~ki) memorisana.

Svaki korisnik BP ima jezik preko kog komunicira sa BP. Za programereaplikacija to }e biti neki od konvencionalnih programskih jezika (tzv. hostjezici kao {to su: C, COBOL,..), to moè biti i neki upitni jezik. Vaàn deokorisni~kih jezika ~ini i podjezik za podatke (DSL od engl. Data SubLanguage).

Podjezik za podatke se sastoji od dva jezika: jezika za definiciju podataka (DDL od engl. Data Definition Language), koji

omogu}ava definiciju ili opis objekata BP jezika za manipulaciju podacima (DML od engl. Data Manipulation Language),

koji podràva operacije sa objektima BP.

Jedan korisnik, u najve}em broju slu~ajeva, je zainteresovan za samo jedan deoBP. Korisni~ki pogledi }e biti prili~no apstraktni u pore|ewu sa na~inom nakoji su ti podaci fizi~ki sme{teni u BP. Eksterni pogled je, stoga, sadràj BPvi|en od strane korisnika. (tj. za korisnika, eksterni pogled je BP). Eksternipogled je definisan eksternom {emom. Eksterna {ema je napisana kori{}ewemjezika za definisawe podataka.

Konceptualni pogled je reprezentacija celokupnog informacionogsadràja BP, ali na vi{em nivou apstrakcije nego {to je fizi~ka reprezentacijapodataka. Tako|e, moè biti znatno razli~ita i od eksternog pogleda bilo kog

INTERNINIVO

KONCEPTUALNINIVO

EKSTERNINIVO

pogledi korisnika


korisnika. Konceptualni pogled je definisan konceptualnom {emom (ova {ema jetako|e napisana jezikom za definiciju podataka). S obzirom na nezavisnostpodataka ova definicija ne sme ukqu~ivati informacije o fizi~koj strukturipodataka ili strategiji pristupa - ona mora biti definicija sadràja. Dakle, ukonceptualnoj {emi ne smeju postojati nikakve reference na fizi~kureprezentaciju poqa, indeksirawe, he{-adresirawe ili drugi detaq internognivoa.

Konceptualni pogled predstavqa pogled sadràja celokupne BP, akonceptualna {ema je definicija ovoga pogleda. Me|utim, definicije ukonceptualnoj {emi ukqu~uju i mnoge dodatne karakteristike, kao {to su proveraprava pristupa.

Interni pogled je veoma nizak nivo reprezentacije cele BP. Ovaj pogled jenajbliì fizi~koj predstavi podataka. Interni pogled pretpostavqa beskona~anlinearni adresni prostor. Detaqi o tome kako je adresni prostor preslikan ufizi~ku reprezentaciju nisu eksplicitno navedeni u internom pogledu.

Na slici P.2. su prikazani obja{weni pojmovi:

Slika P.2.Preslikavawa u arhitekturi BP

Na slici se mogu uo~iti dva nivoa preslikavawa, jedan izme|u eksternog ikonceptualnog nivoa, a drugi izme|u konceptualnog i internog.Konceptualno/interno preslikavawe defini{e vezu izme|u konceptualnog iinternog pogleda. Ako se struktura BP promeni, konceptualna {ema mora ostatinepromewena. Drugim re~ima, efekti takvih promena mogu uticati na nivoe ispodkonceptualnog nivoa.

Eksterno/konceptualno preslikavawe defini{e vezu izme|u vi{eeksternih pogleda i konceptualnog pogleda. Moè postojati proizvoqan broj

Korisnik A1

host jezik +DSL

host jezik +DSL

host jezik +DSL

host jezik +DSL

host jezik +DSL

Eksternipogled A

Eksternipogled B

Konceptualnipogled

Interni pogled

Eksterno/Konceptualnopreslikavawe B

Eksterna{ema A

Eksterna{ema B

SUBP

Interna{ema

Korisnik A2 Korisnik B1 Korisnik B2 Korisnik B3

Eksterno/Konceptualnopreslikavawe A

Konceptualno/internopreslikavanje

Прилози 149.

eksternih pogleda, a tako|e proizvoqan broj korisnika moè deliti istieksterni pogled. Promene u konceptualnom pogledu ne smeju se odraziti naeksterne poglede (utica}e na promenu eksterno/konceptualnog preslikavawa).

Na slici je jo{ prikazan i sistem za upravqawe bazom podataka (SUBP). Toje softver koji rukuje svim pristupima BP i mora da obezbedi slede}e funkcije: specifikacija modela podataka na kom je zasnovana BP, pohrawivawe

specifikacije i mogu}nost pristupa specifikaciji pohrawivawe podataka u BP u skladu sa modelom podataka, pristup podacima

(na osnovu razvijenog upitnog jezika) i aùrirawe podataka specifikacija uslova integriteta BP i prihvatawe samo onih zahteva

korisnika koje ne naru{avaju uslove integriteta BP mogu}nost interaktivnog konkurentnog rada vi{e korisnika (uz o~uvawe

uslova integriteta) specifikacija ovla{}ewa korisnika i obezbe|ivawe mehanizama za

realizaciju tih ovla{}ewa.

Kada korisnik izda zahtev za pristup, koriste}i neki jezik za manipulacijupodacima, tada ga najpre SUBP prihvata i interpretira. SUBP prolazi redomeksternu {emu, eksterno/konceptualno preslikavawe, konceptualnu {emu,konceptualno/interno preslikavawe, definiciju fizi~ke strukture. SUBPizvr{ava sve neophodne operacije nad BP, realizuje pristup i vra}a rezultatprolaze}i sve {eme i preslikavawa u obrnutom redosledu (pri prelasku iz jednogu drugi nivo obavqaju se neophodne konverzije).

Za korisnika BP (izuzev administratora) bitni su samo podaci o realnomsistemu. Me|utim, to nisu jedini podaci koji se nalaze u BP. Neophodno je negde~uvati informacije o preslikavawima, o izgledima eksternih i konceptualnih{ema itd. Te vrlo bitne informacije sme{tamo u tzv. re~nik podataka. Re~nikpodataka sadrì informacije kao {to su koji programi koriste koje delove BP,koja odeqewa zahtevaju koje izve{taje i sli~no. Re~nik podataka se po svojojfizi~koj interpretaciji ne razlikuje od preostalog dela BP. Re~niku podataka sepristupa na isti na~in kao i drugim podacima, koriste se iste metode pristupa,isti upitni jezici i sli~no. Naravno, neophodno je za{tititi re~nik podataka odneovla{}enog pristupa (obi~no re~niku podataka moè da pristupi samoadministrator BP).

Relacione baze podataka

Relacioni model podataka poseduje slede}e osobine: jasno razgrani~ewe logi~kih i fizi~kih aspekata upravqawa podacima strukturalna jednostavnost upitni jezici (SQL, QUEL, QBF) veoma razvijena formalna, matemati~ka teorija.

Relacione BP se zasnivaju na relacionom modelu podataka. Osnovnaosobina strukturalnog dela relacionog modela je da se skupovi objekata (entiteta)istog tipa predstavqaju relacijama - tabelama. Kolone tabele odgovarajuatributima (obele`jima) entiteta, a vrste (torke) pojedina~nim pojavama tipaentiteta. Redosled kolona i vrsta je nebitan, ali se ne mogu pojaviti dve potpunoiste vrste. Upitni i manipulativni deo relacionog modela sastoje se od skupa


operatora koji transformi{u tabele u stawa. Relacioni model posedujeformalni, matemati~ki jezik zasnovan na algebri i logici.

Slika P.3. Arhitektura relacone BP

Osnovna tabela ima nezavisnu egzistenciju (nije izvedena iz drugih) iodgovara joj datototeka. Tabela koju vidi korisnik moè biti osnovna ili pogled.Pogled ne postoji kao nezavisna tabela (pa samim tim nema ni svoju datoteku).Pogled je izveden iz jedne ili vi{e osnovnih tabela. Pogled moè imati i poqakoja ne postoje ni u jednoj tabeli. Jednoj vrsti tabele odgovara jedan slog datoteke.Tabeli moè biti pridruèn proizvoqan broj indeksa. Korisnik moè bitisvestan ovih indeksa, ali ne mora im se direktno obra}ati da bi pristupiopodacima. Indeksi mogu biti kreirani ili uni{teni u bilo kom trenutku bezikakve {tete po korisnika (osim u performansama).

SQL je podjezik za podatke. Sadrì jezik za definiciju podataka (DDL) ijezik za manipulaciju podacima (DML). DDL funkcioni{e i na eksternom i nakonceptualnom nivou. SQL se pojavquje u jo{ jednom obliku (tzv. ugwe`deni SQL).SQL je isprepleten sa naredbama osnovnog jezika RSUBP-a (relacioni SUBP).

CASE alati

CASE ozna~ava po~etna slova od Computer Aided Software Engineering(ra~unarom podràno projektovawe softvera). Kao definicija CASE alata obi~nose navodi slede}a formulacija: CASE alat je svaki onaj alat koji u fazama analizezahteva i izrade projektnih specifikacija obezbe|uje skup efikasnih mehanizama,a ukqu~uje i one alate koji imaju mogu}nost automatizovanog generisawa koda izprogramskih specifikacija.

Zbog nesavr{enosti strukturnih metodologija, prouzrokovanih uglavnomneodgovaraju}om i nedoslednom primenom, nastali su CASE alati kao poku{aj da seautomatizuju principi strukturnih metodologija i organizacionih tehnika.Ve}ina CASE alata svoju koncepciju bazira na strukturnim metodologijama koje surazvijene 60-tih i 70-tih godina. U to vreme primena strukturnih metodologija jebila podstaknuta potrebom da se smawi razvojni rizik. Sprovo|ene su na papiru.One omogu}uju projektantima programskog proizvoda da grade veoma sloène

DATOTEKA#1

DATOTEKA#2

DATOTEKA#3

DATOTEKA#4

OSNOVNATABELA#1

OSNOVNATABELA#2

OSNOVNATABELA#3

OSNOVNATABELA#4

POGLED #1 POGLED #2

SQL

Interninivo

Konceptu-alni nivo

Eksterninivo

Korisnik

Прилози 151.

sisteme. Pojavom PC ra~unara i grafi~kih radnih stanica (80-tih godina) te sumetodologije prerasle u CASE alate.

Upotrebom odgovaraju}eg CASE alata se re{ava, ili makar ublaàva,problem izrade kvalitetne {eme BP i aplikacija informacionog sistema (IS),uz pribli`no optimalno angaòvawe materijalnih, qudskih i vremenskih resursa.

Namena CASE alata je da smawe ili u potpunosti otklone probleme kojinastaju u fazama projektovawa i implementacije sloènih programskih proizvoda,putem automatizovanog generisawa ve}ine programskog koda, na osnovuspecifikacija koje zadaje projektant. CASE odvaja fazu projektovawa programskogproizvoda od implementacije programskog koda.

U osnovama metodologija leì princip funkcionalne dekompozicijevelikih sistema na skup mawih (na module) kojima se kasnije lak{e rukuje. Time jeomogu}en nezavisan razvoj i testirawe svakog od modula. Integracija modula nepredstavqa veliku pote{ko}u.

U fazama analize zahteva i izrade projektnih specifikacija CASE alatiomogu}avaju interaktivno projektovawe programskih {ema pomo}u ra~unarompodràne grafike (grafi~ki interfejs). Rad u takvom okruèwu je brì ijednostavniji. Postoji ~itav niz ugra|enih mehanizama za proverukonzistentnosti programskih {ema, koji usmeravaju projektanta da na ispravanna~in defini{e programske module i odgovaraju}e strukture podataka. Namenadrugih CASE alata je sasvim specifi~na. Razvijeni su sa ciqem da zadovoqe klasufunkcija.

CASE alati upotpuwuju „rukom“ programirane module. Omogu}avajuprojektantu ili programeru da provode vi{e vremena u osmi{qavawu proizvoda.CASE alati osloba|aju sistem analiti~ara i programera rutinskih detaqa ipomaù u velikom broju situacija, ali su jo{ prili~no daleko od mogu}nostigenerisawa celovitog koda programskog proizvoda. Potreba za „ru~no“ kodiranimmodulima jo{ uvek postoji.

Tipovi CASE alata

Jezici 4. generacije. Bi}e kasnije obja{weni.Alati za modelirawe strukture podataka. Ogromna ve}ina programskih proizvodana trì{tu spada u grupu onih koji koriste BP. Kao pomo} projektantimarazvijene su tehnike za modelirawe strukture podataka. CASE alati zamodelirawe strukture podataka pomaù projektantu da, u sistemu za koji se razvijaIS, uo~i informacione tokove i razli~ite poglede na wih. Kao rezultat primeneovih alata dobija se ispravno projektovana struktura podataka.Alati za analizu funkcionalnih zahteva i izradu projektnih specifikacija.Koriste metodologije strukturne analize, tehnike dijagrama toka podataka imetodologije strukturnih dijagrama. Imaju izvrsne grafi~ke mogu}nosti za prikazinformacionih tokova izme|u procesa.Alati za izradu prototipa korisni~kog interfejsa. Korisni~ki interfejszasluùje veliku pa`wu jer u ve}ini komercijalnih programskih proizvodapredstavqa najve}i pojedina~ni modul. CASE alati za izradu prototipakorisni~kog interfejsa daju grafi~ku prezentaciju modela izgleda ekrana.Generatori koda. Ovi alati podrazumevaju automatizovanu izradu izvr{ivog iliprevodivog programskog koda iz projektnih specifikacija. Sluè za generisawe


prototipa aplikacije, odnosno 4GL specifikacija. Generatori koda su uglavnommenu orijentisani. Putem menija, jednostavnih upita i formi defini{e se izgledbudu}e aplikacije. Razvijawem prilago|enih template datoteka mogu}e je,koriste}i generator koda, izgenerisati i sloènije aplikacije, bez potrebepreprogramirawa u 4GL-u ili 3GL-u (jezici ~etvrte odn. tre}e generacije). Te`waje da se granica upotrebqivosti generatora koda {to vi{e pomeri. Jo{ uvek nepostoje alati koji mogu da generi{u celokupan programski kod za programskiproizvod op{teg tipa.

Karakteristike CASE alata

CASE alati treba da zadovoqe slede}e zahteve: sniàvawe sloènosti: najva`niji ciq CASE tehnologija je da izvr{e

dekompoziciju postupka projektovawa i razdvoji sloène funkcionalnezahteve na celine

obezbe|ewe razumqivosti projektnih specifikacija: rezultati CASE alatamoraju da budu razumqivi i krajwim korisnicima i upravqa~kim strukturama

smawewe tro{kova: visoko kvalitetne specifikacije i dizajn kao rezultatupotrebe CASE alata zna~ajno umawuju napore implementacije i odràvawa

produktivnost: CASE alati zna~ajno pove}avaju produktivnost i projektanta iprogramera, te je wihova primena postala obavezna

konzistentnost: predstavqa jedan od najteè ostvarivih zadataka u realizacijiCASE alata

pogodnost za odràvawe: projektne specifikacije nastale putem CASE alatamoraju da budu prilagodqive promenama u funkcionalnim zahtevima i dizajnu

grafi~ka orijentisanost: slika predstavqa mnogo pogodnije sredstvo zaprezentaciju i razumevawe projektne dokumentacije nego {to je opisni tekst.

Jezici ~etvrte generacije

To su jezici veoma visokog nivoa, nameweni rukovawu bazama podataka.Wihova je primena, u postupcima programirawa pristupa podacima, mnogojednostavnija nego kod nekih od karakteristi~nih predstavnika niìhprogramskih jezika. Ve}ina jezika ~etvrte generacije ima neke od mogu}nostigrafi~kog projektovawa (forme, izgledi ekrana, ...). Ciqevi i motivacija zarazvoj su omogu}avawe prototipskog razvoja aplikacija i ubrzavawe i olak{avaweprocesa izrade aplikacija, odnosno smawivawe tro{kova odràvawa (lak{eotkrivawe i ispravqawe gre{aka).

Ono {to su kvalitativno novo doneli jezici ~etvrte generacije (4GL) sudeklarativnost (potpuna ili bar delimi~na), preglednije specifikacije i mnogolak{e programirawe. Sa 4GL se navodi {ta se èli uraditi, a ne kako to trebauraditi. Tako|e, 4GL se koristi i kada treba izvr{iti neke specifi~neoperacije. 4GL aplikacija zahteva mnogo mawe koda nego konvencionalni programii stoga je lak{a za razumevawe.

Na slici P.4. je prikazan odnos performansi i produktivnosti generatorakoda, 4GL-a, 3GL-a, asemblera i ma{inskog jezika. Ipak, 4GL (generisana)aplikacija je sporija od iste 3GL aplikacije i smawena je funkcionalnost alata zarazvoj aplikacija (4GL je, a posebno generator koda, razvijen za re{avawe malogskupa problema). Pojavom sve brìh ra~unara je postalo opravdano razvijati takve

Прилози 153.

proizvode koji }e biti ne{to sporiji, ali }e omogu}iti brè i lak{eprogramirawe (naravno, i odràvawe programa).

Slika P.4. Programski jezici

Iako 4GL obezbe|uje ve}u produktivnost u razvoju programa, postojeslu~ajevi kada ga ne treba koristiti (generisawe neefikasnog koda koji nezadovoqava zahteve krajweg korisnika). Moè se definisati osnovno pravilo: 4GLse upotrebqava u najve}em broju slu~ajeva, a samo kada je to neophodno koristi se3GL. Na slici P.5. je prikazan napor u zavisnosti od sloènosti aplikacije uslu~ajevima kori{}ewa samo 3GL-a, samo 4GL-a, i slu~aj kada se oboje koristi.

Slika P.5 Upotreba 3GL i 4GL

Tipovi jezika ~etvrte generacije su: Razvojno orijentisani 4GL: namewen programerima za lak{i razvoj aplikacija.

Jednu programsku celinu (programski modul) ~ini meni, 4GL kod kojidefini{e meni i operacije koje se wime mogu izvr{avati. Poseduju elementeproceduralnosti i elemente deklarativnosti (trigeri, meni aktivacije,SQL...).

Informaciono orijentisani 4GL: nameweni su krajwim korisnicima zapristup podacima i navikavawe na logiku funkcionisawa budu}ih aplikacija.Prili~no su ograni~enih mogu}nosti. Primer je interaktivni SQL.

Performanse ifunkcionalost

Produktivnost(kvalitet i brzina)

Generatorkoda

Jezik IVgeneracije

Ma{inskijezik

Jezik IIIgeneracije

Asembler

4GL

3GL

4GL&3GL

sloènost aplikacije

Napor

granica funkcionalnosti4GL-a


Primeri jezika ~etvrte generacije: alati za razvoj aplikacija: ORACLE/SQL*Forms, INGRES/4GL generatori/editori formi: ORACLE/SQL*Forms, INGRES/VIFRED (VIsual FoRms

EDitor) generatori izve{taja: ORACLE/SQL*Report-Writer, INGRES/RBF, INGRES/Report-

Writer generatori menija: ORACLE/SQL*Menu, INGRES/4GL generatori upita: ORACLE/SQL*Plus, INGRES/ISQL, INGRES/QBF, INGRES/QUEL.

Slika P.7.

Slika P.6 Standardno okru`ewe jezika ~etvrte generacije

Osvrt na sada{we stawe

Korisnik je mnogo vi{e zavisan od proizvo|a~a SUBP-a, nego odproizvo|a~a hardvera. Korisnik ponekad dogra|uje i prekonfiguri{e hardverskuarhitekturu u ciqu poboq{awa performasi sistema. Zahvaquju}iCLIENT/SERVER arhitekturi obezbe|eno je anga`ovawe relativno jeftine PCtehnologije u radu sa velikim BP.

Slika P.7. Otvorena arhitektura

RE^NIK

PODATAKA3GL

SQL

GENERATOR/EDITORFORMI

GENERATOR

IZVE[TAJA

GENERATORUPITA

ALAT ZAIZRADU

APLIKACIJEMENIJA

GENERATOR

HARDVER

OS nezavisnost od hardvera

RDBMS - nezavisnost od OS

SQL nezavisnost od RDBMS

4GL & 3GL

GENERATOR KODA

UPPER CASE

OTVORENA ARHITEKTURA

Прилози 155.

P. 2 UPITNIK ZA POSLOVNE MENAXERE I ANALITI^ARE

A. ODGOVORNOSTI

1. Opi{ite svoju Filijalu i wene odnose sa ostatkom Narodne banke.

2. Koje su Va{e primarne odgovornosti?

3. Koja se vrsta odluka o~ekuje od Vas?

4. Koje se glavne promene o~ekuju u oblasti rada kojom Vi rukovodite u narednih:

(a) godinu dana:

(b) dve godine:

(v) pet godina:


B. POSLOVNI CIQEVI I PROBLEMI

1a. Koji su ciqevi Va{e organizacione jedinice?

1b. [ta poku{avate da postignete?

1v. Koji su Va{i najprioritetniji poslovni ciqevi?

1g. Rangujte po zna~aju navedene ciqeve

1d. Kako Vi poku{avate da postignete te ciqeve?

2a. Koja su Va{a merila uspe{nosti?

2b. Kako znate da ne{to radite dobro?

Прилози 157.

2v. Koliko ~esto merite kqu~ne faktore uspe{nosti?

3a. Koja su kqu~na poslovna pitawa sa kojima se su~eqavate danas?

3b. [ta Vas ometa u postizawu postavqenih poslovnih ciqeva?

3v. Navedite najvi{e po tri problema koja ometaju postizawe svakog od navedenih ciqeva

3g. Rangujte po zna~aju navedene probleme.

3d. [ta spre~ava re{avawe svakog od navedenih problema?

3|. [ta je neophodno za re{avawe svakog od navedenih problema?


3e. Koje su informacije neophodne za uspe{no re{avawe svakog od navedenih problema?

4. Kako identifikujete probleme/izuzetke?

C. KRITI^NI FAKTORI USPE[NOSTI

1. Ako biste iz nekih razloga izostali sa posla dve sedmice bez ikakvih komunikacijasa organizaciom u kojoj radite, {ta bi ste prvo `eleli da saznate o poslu u oblastikojom Vi rukovodite, kada se vratite?

2. Navedite tri podru~ja u oblasti kojom Vi rukovodite u kojima bi Vas neuspe{an radnajvi{e pogodio:

(a) ……………………………………………………………………………………(b) ……………………………………………………………………………………(v) ……………………………………………………………………………………

3. Navedite najvi{e pet kqu~nih faktora uspe{nosti u oblasti rada kojom rukovodite:

(a) …………………………………………………………………………………….(b) …………………………………………………………………………………….(v) …………………………………………………………………………………….(g) …………………………………………………………………………………….(d) …………………………………………………………………………………….

Прилози 159.

4. Rangujte navedene kriti~ne faktore uspe{nosti prema relativnom zna~aju:

5. Navedite kriti~ne odluke koje donosite u radu, a koje presudno uti~u na uspe{noili neuspe{no funkcionisawe oblasti kojom rukovodite:

(a) ……………………………………………………………………………………(b) ……………………………………………………………………………………(v) ……………………………………………………………………………………(g) ……………………………………………………………………………………(d) ……………………………………………………………………………………(|) ……………………………………………………………………………………(`) ……………………………………………………………………………………(z) ……………………………………………………………………………………

6. Navedite kriti~ne informacije ~ije posedovawe ili neposedovawe presudno uti~e nauspe{nost u kqu~nim podru~jima rada kojim rukovodite:

(a) ……………………………………………………………………………………(b) ……………………………………………………………………………………(v) ……………………………………………………………………………………(g) ……………………………………………………………………………………(d) ……………………………………………………………………………………(|) ……………………………………………………………………………………(`) ……………………………………………………………………………………(z) ……………………………………………………………………………………(i) …………………………………………………………………………………….(j) …………………………………………………………………………………….(k) ...............................................................................................................................(l) ...............................................................................................................................(m) ............................................................................................................................(n) .............................................................................................................................(w) ...............................................................................................................................

7. Za koje od kriti~nih odluka bi trebalo izgraditi sisteme za podr{ku odlu~ivawu?


D. ZAHTEVI ZA ANALIZOM

1a. Koji tip rutinske teku}e analize Vi obavqate?

1b. Koje podatke koristite?

1v. Kako dolazite do tih podataka?

1g. [ta radite sa informacijom po{to je dobijete?

2a. Koje analize biste `eleli da obavite?

2b. Postoje li potencijalna poboq{awa za va{ sada{wi metod/proces?

3a. Koji tip analize „u letu” tipi~no obavqate?

Прилози 161.

3b. Ko tra`i ad hoc analize?

3v. [ta oni ~ine sa tom analizom?

3g. Koliko vremena tipi~no zahteva ta analiza?

4a. Koje teku}e izve{taje vi koristite?

4b. Koji podaci u izve{taju su zna~ajni?

4v. Kako koristite informaciju?

4g. Ako je izve{taj dinami~an, promenqiv, {ta ga ~ini druga~ijim?

5. Kako procewujete sada{wu informacionu podr{ku u pogledu:(0 ozna~ava najgoru a 3 najboqu ocenu.)

Pravovremenosti informacije 0 1 2 3 Zna~ajnosti informacije 0 1 2 3 Pouzdanosti informacije 0 1 2 3 Jasno}e prezentacije informacije 0 1 2 3 Lako}e kori{}enja informacije 0 1 2 3 Ko{tawa informacije 0 1 2 3 Koli~ine informacije 0 1 2 36. Kakve su posledice jedno~asovnog prekida rada postoje}eg informacionog sistema za

uspe{nost funkcionisawa Va{e organizacione jedinice?

Potpun prekid rada Bilo bi nezgoda ali kqu~ne poslovne aktivnosti bile bi nastavqene Zanemarqiv uticaj na funkcionisawe

-----------------------------------------------------------------------------------

-----------------------------------------------------------------------------------7. Kakve su posledice dvonedeqnog prekida rada postoje}eg informacionog sistema?

Skoro fatalne Vrlo skupe Minimalne


8. Postoje li specifi~na uska grla u dolaèwu do informacija?

9. Koliko su traène istorijske informacije?

10. Koje analiti~ke mo}i biste èleli da imate?

11a. Koje povoqnosti postoje da dramati~no unaprede va{e poslovawe, zasnovane napoboq{anom pristupu informacijama?

11b. Koji bi to finansijski doprinos bio?

11v. Kada biste imali analiti~ke mo}i o kojima je bilo re~i, {ta bi to zna~ilo za va{eposlovawe?

POTPIS:_________________________________________

Прилози 163.

P.3 REZIME OBAVQENIH INTERVJUA

Odgovornosti

saradwa u izradi sistemskih re{ewa i mera za sprovo|ewe politika (politikakursa, monetarno-kreditna politika, pla}awe/naplata u poslovima sainostranstvom, KOI)

sara|ivawe u formirawu predloga mera i propisa u oblasti deviznog idinarskog poslovawa

obezbe|ivawe jedinstva u radu sistema NBJ tuma~ewe propisa i savetovawe u~esnika devizni sistem: kontrola i sprovo|ewe mera devizne politike, pra}ewe

efekata od uticaja na ostvarivawe devizne politike, sprovo|ewe operativnihposlova

izrada i pra}ewe svih podzakonskih akata u oblasti EOI planirawe, izrada i pra}ewe izvr{avawa platnog bilansa (gotovinskih)

deviznih tokova kontrolisawe poslovawa (devizna kontrola i sl.) poslovnih banaka kontrola deviznog poslovawa STP pra}ewe fiksnih i garantovanih obaveza poseban na~in pla}awa prema inostranstvu pra}ewe kursa dinara re{avawe spornih slu~ajeva u STP, produ`ewa roka naplate ...

Predikcija budu}ih promena od uticaja na poslovawe

ne predvi|aju se su{tinske promene planirawe i pra}ewe platnog bilansa i bilansa gotovinskih deviznih

tokova na nivou kra}ih vremenskih perioda pra}ewe dugoro~nih programa i sredworo~nih i drugih planova poboq{awe kvaliteta i pouzdanosti informacija u odgovaraju}oj

oblasti kontinuirano (promptno) pra}ewe efekata mera politika, kao i druge

~inioce na razli~itim nivoima agregirawa prelazak na interaktivni rad gde god je to mogu}e liberalizacija uvoza, smawewe normativizma i administracije na svim

nivoima, te ja~awe ekonomskih zakonitosti u svim podru~jima delovawa.

Poslovni ciqevi

obezbe|ewe primene zakonskih propisa i uputstava realnost planirawa i projekcije platnog bilansa zemqe


uvid u stawe odnosa sa inostranstvom (prihodi i rashodi, priliv i odliv,kupovina i prodaja, promet)

unapre|ewe deviznog poslovawa banaka i drugih u~esnika u EOI, kao i davaweodgovaraju}ih instrukcija i pruàwe pomo}i radi pravilnog sprovo|ewazakonskih odredbi

kvalitet i sigurnost poslovawa banaka i bezbednost finansijskog sistema SRJ obezbe|enost uslova za pra}ewe platnog bilansa sa podbilansima i rezultata

izvr{ewa odgovaraju}e mera za planirawe, izvr{ewe, merewe uspe{nosti i upravqawe u

ciqu ostvarewa projekcije platnog bilansa zemqe uvid u stawe i odràvawe nivoa (eventualno pove}awe) deviznih rezervi stimulisawe izvoza poboq{awe likvidnosti zemqe smawewe stepena zaduènosti.

Grupe problema

1. Neusagla{enost i me|usobna nepovezanost informacionih tokova o stawu ipromenama u sistemu u integralni automatizovani informacioni sistemNBJ. Postojawe dvojnosti podataka iz istog ili razli~itih izvora.Nepostojawe veznih elemenata koji povezuju sve faze odvijawa (nedovoqnakohezivnost - funkcionalna nepovezanost).

Indikatori: nemogu}nost sistematskog, efikasnog i kontinuiranogpra}ewa relevantnih kretawa; velika angaòvawa materijalnih i qudskihresursa.

2. êste sistemske promene koje za posledicu imaju potrebu stalnog inovirawaIS - ~este promene propisa, politike i regulative dovode do brzogzastarevawa IS.

u oblasti EOI: problemi refinansirawa, reprogramirawa i odlagawadovode do nagomilavawa nerealizovanih planova {to umawujeefikasnost i aùrnost; PPI je osnov za platni bilans zemqe koji je uìì dru{tvenog i politi~kog interesa, {to nagla{ava va`nost ovogproblema

3. Nedostatak jedinstvene metodologije (obrade podataka), standardizacijepodataka, kao i jedinstvenog {ifarskog sistema.

U oblasti EOI: poslovne banke primewuju interne {ifarnike;dokumenti-nosioci transkcija nisu isti sa dokumentima-nosiocimainformacija ({to nije u skladu sa principima savremenih IS)

U oblasti MKR (monetarno-kreditnog regulisawa): velike dileme umetodologiji pra}ewa stawa i promena, ~ak se primewuju razli~itemetodologije pra}ewa i obra~unavawa unutar NBJ

4. êste promene u sadràju i obimu identifikovanih informacionih zahtevai nemogu}nosti IS da zadovoqi sve informacione potrebe.

Прилози 165.

Nefleksibilnost IS, odnosno neobezbe|ivawe dovoqne koli~ineinformacija - na~in i metod nisu u skladu sa informacionim zahtevima.Neodgovaraju}a tehni~ka i softverska podr{ka za statisti~ka pra}ewa.

U oblasti EOI: nemogu}nost pra}ewa izvr{ewa platnog bilansa iizvr{ewa planova naplate/pla}awa, naro~ito na odgovaraju}im nivoimaagregirawa, vremenskih serija i indeksa za sloène analize koje sezahtevaju.

U oblasti MKR: nemogu}nost pra}ewa likvidnosti banaka i nepotpunodefinisani informacioni zahtevi.

5. Metodolo{ke neuskla|enost odluka, propisa i uputstava koja reguli{uorganizaciju i funkcionisawe IS NBJ. Postojawe razli~itih evidencijakoje su metodolo{ki neuskla|ene.

U oblasti EOI: nemogu}nost povezivawa svih vidova odvijawa PPI saostalim oblicima EOI.

U oblasti MKR: metodolo{ka neuskla|enost regulacije pra}ewamonetarno-kreditnih kretawa.

6. Neadekvatan sistem komunicirawa izme|u NB i ostalih subjekatarelevantnih za funkcionisawe IS NB (posebno sa sistemom poslovnihbanaka).

U oblasti MKR: neadekvatan sistem komunicirawa ukqu~uje i ZOP;poslovne banke koriste PTT iako sve imaju automatizovane resurse zakomunikaciju i razmenu.

7. Aùrnost i ta~nost podataka i evidencija ne odgovara zahtevima, jerneblagovremene i nepouzdane evidencije se ne mogu koristiti pri dono{ewuodluka i kontroli.

U oblasti EOI: nekorektna popuwenost osnovnih obrazaca (naro~ito{ifara); neblagovremenost i neta~nost podataka sa aspekta sadràja,rokova i odnosa.

U oblasti MKR: kvalitet i dinamika obrade nedovoqni; obrasci neodgovaraju po ta~nosti pouzdanosti.

8. Postoje}a organizacija pogodna nije pogodna osnova za savremenu iefikasnu obradu i prenos informacija. Obrasci se ~esto podnose posleroka ili nakon intervencije, a informacije su nepravovremene, nesadràjnei neta~ne.

Indikator: ka{wewe obrade i prenosa informacija (odstupawe odutvr|ene dinamike i rokova).

9. Klasi~na organizacija rada i reìm auomatske obrade ne odgovarazahtevima za aùrno{}u i pouzdano{}u funkcionisawa; neodgovaraju}ina~in struktuirawa i organizacije podataka.


10. Nemogu}nost direktnog pristupa podacima (krajwih korisnika) i uvida ustawe evidencija i rokovnike - ne postoji dostatna hardversko-softverskapodr{ka.

11. Nepotpuna obuhvatnost podataka u NBJ-FNS, te zavisnost od razmenepodataka u sistemu NBJ.

U oblasti EOI: obuhvataju se samo prijave STP iz Vojvodine, kao inalozi PPI koji idu preko poslovnih banaka iz Vojvodine.

12. Nije uspostavqen celovit, efikasan i pouzdan sistem razmene podatakaunutar sistema NB.

U oblasti EOI: NBJ-FNS ne raspolaè podacima za sve korisnike izVojvodine.

13. Neadekvatna tehni~ka i organizaciono-kadrovska podr{ka IS, neadekvatankomunikacioni sistem. Ka{wewe razmene podataka u sistemu NB ineefikasna i nesavremena razmena s bankama.

14. Stepen sigurnosti za{tite podataka od uni{tewa i neovla{}enogkori{}ewa ne odgovara zahtevima funkcionisawa savremenog IS, naro~itoimaju}i u vidu specifi~nosti IS NBJ (povi{en stepena tajnosti podatakai sl.).

15. Izve{tajni sistem zasnovan na klasi~nim osnovama - neblagovremenoinformisawe krajwih korisnika. Ne postoje uslovi za primenu savremenihmetoda i modela.

Uzroci problema

neusagla{enost metodologija platnog bilansa i bilansa gotovinskihdeviznih tokova

previ{e strogo poverqivih i nedore~enih propisa prevelik normativizam i administrativno regulisawe nedoslednost mera velik obim podataka koji su nepouzdani i ne pruàju mogu}nost

povezivawa podsistema u okviru integralnog IS obuhvat, kontrola i odgovornost nisu na mestu nastanka informacija nepovezanost sistema, nekoordiniran rad subjekata koji u~estvuju u

stvarawu podataka.

Preduslovi za prevazilaèwe problema

izmena dokumentacionih i informacionih tokova - racionalizacija iboqa povezanost

ostvarivawe direktnih veza u poslovnom bankarstvu sistemske i organizacione-tehnolo{ke promene boqa saradwa u pripremi predloga i nacrta sistemskih re{ewa

Прилози 167.

liberalizacija uvoza i smawewe administrativnog regulisawa EOI.

Efekti prevazilaèwa problema

ve}a efikasnost i kvalitet u obavqawu poslova izvr{ewa platnogbilansa sa podbilansima, na osnovu usvojene projekcije platnog bilansazemqe

blagovremeno i efikasno izve{tavawe korisnika (skup{tine,ministarstva, ...)

blagovremeno i efikasno izve{tavawe preduze}a radi spre~avawapovrede deviznih propisa

pove}awe ta~nosti i sadràjnosti izve{taja, koji bi rezultirao i upravqewu efikasnijih predloga za dono{ewe propisa

dolaèwe do zajedni~kih problema i wihovo jedinstveno re{avawe smawewe tro{kova poslovawa NBJ smawewe broja obrazaca i smawivawe tro{kova u organizacijama smawewe obima i frekventnosti rutinskih poslova racionalizacija posla, ukidawe postupaka i podataka koji se dupliraju i

prepli}u.

Kriti~ni faktori uspe{nosti

Kriti~ne informacije

informacije o pla}awima i naplatama (CASH FLOW) i DDK statisti~ke informacije u vezi sa su{tinom posla (bez obzira na

nadle`nost) kriti~ne informacije za neki posao u traènom trenutku (poslovi na

„granici“ zakona, prekr{aji, ...), jer su ina~e korisne samo za naknadneanalize

informacije o zakqu~enim i nerealizovanim poslovima, refinansirawu(zakqu~nicama), neusagla{enim kreditnim partijama, novozakqu~enimkreditima.

Kriti~ne odluke

odre|ivawe (re)eskontne stope oduzimawe postoje}eg ovla{}ewa od konkretne banke stopirawe kredita primarne emisije zabrana rada banke (ne)odobravawe produèwa roka unosa deviza (ne)odobravawe pravdawa razlike stimulacije izvoza podno{ewe prijave protiv spoqnotrgovinskog preduze}a odnosno

preduzetnika.


Kriti~ni faktori uspe{nosti

balans u strukturi nov~ane mase likvidnost, kredibilnost i bonitet poslovnih banaka stabilnost doma}e valute i trì{ta ostvarewe pokrivenosti izvoza uvozom izbalansirana struktura izvoza/uvoza nizak stepen nenapla}enih potraìvawa i pla}enog a nerealizovanog

uvoza.

Nalazi koji se ti~u kriti~nih faktora uspe{nosti su veoma kompleksni ipoverqivi – slu`bene i dràvne tajne; s toga je ovaj spisak {tur. Me|utim,evaluacija kriti~nih faktora uspe{nosti je ugra|ena u modele budu}eg DW –dodatna ilustracija (re{ewa) ispitivawa korisni~kih zahteva se moè na}i uPrilog 5.

Potrebe analize

Informaciona podr{ka

Uglavnom zadovoqavaju}a ta~nost informacija, ali se pojavquju stanovitepote{ko}e:

informacije nisu na zadovoqavaju}em nivou jer kvalitet i rokovi zaviseod poslovnih banaka i NB

deo informacija zahteva dodatnu ru~nu obradu nemogu}nost i sporost dobijawa informacija na zahtev nepovezanost aplikacija prevazi|eni na~ini obrade i neadekvatni izve{taji neblagovremeno izve{tavawe.

Povoqnosti unapre|enog poslovawa

uvid u likvidnost poslovnih banaka i zemqe celovite, brze i ta~ne informacije zasnovane na podacima, a ne na

izjavama i sl. izmena propisa u ciqu racionalizacije rada racionalizacija i unapre|ewe poslovawa unutar poslovnih sistema kvalitativno boqi rad ukidawe duplih tokova podataka i povezivawe podataka kontinuiet, pravovremenost i kvalitet informacija i brè i

efikasnije obavqawe kontrole, registracije i drugih poslova koji nisuu direktnoj vezi sa analizom.

Прилози 169.

P.4 ДИЈАГРАМИ ТАБЕЛА ФАКАТА




Tarifnibrojevi

Zemqe

Рa~uni

Namenaplasmana

Carinskeispostave

Instru-menti

Namena uvoza

Re`im

Izvoz-uvoz




Vrstekredita

Apoeni nov-ca i HOV

Valute

Inokredi-tori

Konta

Kamate

Tro{kovnamesta

Radnici

Sedi{taZOP

Obavezna rezerva

i kamata





Tarifnibrojevi

Zemqe

Рa~uni

Namenaplasmana

Carinskeispostave

Instru-menti

Namena uvoza

Re`im

Izvoz-uvoz




Vrstekredita

Apoeni nov-ca i HOV

Valute

Inokredi-tori

Konta

Kamate

Tro{kovnamesta

Radnici

Sedi{taZOP

Stawa i tokovi

gotovog novca

Прилози 171.




Tarifnibrojevi

Zemqe

Рa~uni

Namenaplasmana

Carinskeispostave

Instru-menti

Namena uvoza

Re`im

Izvoz-uvoz




Vrstekredita

Apoeni nov-ca i HOV

Valute

Inokredi-tori

Konta

Kamate

Tro{kovnamesta

Radnici

Sedi{taZOP

Kreditni odnosi sa

inostranstvom





Tarifnibrojevi

Zemqe

Рa~uni

Namenaplasmana

Carinskeispostave

Instru-menti

Namena uvoza

Re`im

Izvoz-uvoz




Vrstekredita

Apoeni nov-ca i HOV

Valute

Inokredi-tori

Konta

Kamate

Tro{kovnamesta

Radnici

Sedi{taZOP

Platni promet sa

inostranstvom

Прилози 173.




Tarifnibrojevi

Zemqe

Рa~uni

Namenaplasmana

Carinskeispostave

Instru-menti

Namena uvoza

Re`im

Izvoz-uvoz




Vrstekredita

Apoeni nov-ca i HOV

Valute

Inokredi-tori

Konta

Kamate

Tro{kovnamesta

Radnici

Sedi{taZOP

Ostalo devizno

poslovawe





Tarifnibrojevi

Zemqe

Рa~uni

Namenaplasmana

Carinskeispostave

Instru-menti

Namena uvoza

Re`im

Izvoz-uvoz




Vrstekredita

Apoeni nov-ca i HOV

Valute

Inokredi-tori

Konta

Kamate

Tro{kovnamesta

Radnici

Sedi{taZOP

Statusna stawa

banaka

Прилози 175.




Tarifnibrojevi

Zemqe

Рa~uni

Namenaplasmana

Carinskeispostave

Instru-menti

Namena uvoza

Re`im

Izvoz-uvoz




Vrstekredita

Apoeni nov-ca i HOV

Valute

Inokredi-tori

Konta

Kamate

Tro{kovnamesta

Radnici

Sedi{taZOP

Poslovni

potencijal i

stawe banaka





Tarifnibrojevi

Zemqe

Рa~uni

Namenaplasmana

Carinskeispostave

Instru-menti

Namena uvoza

Re`im

Izvoz-uvoz




Vrstekredita

Apoeni nov-ca i HOV

Valute

Inokredi-tori

Konta

Kamate

Tro{kovnamesta

Radnici

Sedi{taZOP

Likvidnost

banaka

Прилози 177.




Tarifnibrojevi

Zemqe

Рa~uni

Namenaplasmana

Carinskeispostave

Instru-menti

Namena uvoza

Re`im

Izvoz-uvoz




Vrstekredita

Apoeni nov-ca i HOV

Valute

Inokredi-tori

Konta

Kamate

Tro{kovnamesta

Radnici

Sedi{taZOP

Bonitet

(kvalitet)

banaka





Tarifnibrojevi

Zemqe

Рa~uni

Namenaplasmana

Carinskeispostave

Instru-menti

Namena uvoza

Re`im

Izvoz-uvoz




Vrstekredita

Apoeni nov-ca i HOV

Valute

Inokredi-tori

Konta

Kamate

Tro{kovnamesta

Radnici

Sedi{taZOP

Devizno poslovawe

banaka i

KOI

Прилози 179.




Tarifnibrojevi

Zemqe

Рa~uni

Namenaplasmana

Carinskeispostave

Instru-menti

Namena uvoza

Re`im

Izvoz-uvoz




Vrstekredita

Apoeni nov-ca i HOV

Valute

Inokredi-tori

Konta

Kamate

Tro{kovnamesta

Radnici

Sedi{taZOP

Pra}ewe

finansijskih

rezultata banaka





Tarifnibrojevi

Zemqe

Рa~uni

Namenaplasmana

Carinskeispostave

Instru-menti

Namena uvoza

Re`im

Izvoz-uvoz




Vrstekredita

Apoeni nov-ca i HOV

Valute

Inokredi-tori

Konta

Kamate

Tro{kovnamesta

Radnici

Sedi{taZOP

Trezorsko

poslovawe

Прилози 181.




Tarifnibrojevi

Zemqe

Рa~uni

Namenaplasmana

Carinskeispostave

Instru-menti

Namena uvoza

Re`im

Izvoz-uvoz




Vrstekredita

Apoeni nov-ca i HOV

Valute

Inokredi-tori

Konta

Kamate

Tro{kovnamesta

Radnici

Sedi{taZOP

Interno

poslovawe

Прилози 193.

P.6 KONTROLNA LISTA ZA KVALITET DW

Следи листа препоручених корака за изградњу DW. Презентирани кораци сеодносе углавном на техничке и архитектуралне аспекте изградње. Листа не претендује наапсолутну комплетност по питању интерних презентација, образлагања, буџетирања иобавезних корака за креирање DW.

Прелиминарно комплетирање листе подржаних корисничких група преинтервјуисања.Прелиминарно комплетирање листе извора података пре интервјуисања.Идентификован тим за имплементацију DW.

Идентификован менаџер DW.Идентификован вођа интервјуа.Идентификован менаџер екстракционог програмирања.Идентификован архитекта БП.

Идентификоване групе крајњих корисника за интервјуисање.DW почетни састанак са свим битним групама крајњих корисника.Интервјуи крајњих корисника.

Интервјуи у маркетингу.Интервјуи у финансијама.Логистички ин тервјуи.Интервјуи обласних менаџера.Интервјуи главних менаџера.Стек постојећих управљачких извештаја који репрезентује свеинтервјуисане групе.

Интервјуи системских DBA.Списак операционалних система.Речник података са објашњењем свих табела и поља.Опис табела и поља са подацима о квалитету.

Дистрибуиран извештај уо резултатима интервјуа.Приоритетне информационе потребе изражене од крајњих корисника.Извршена ревизија података да се укаже који су подаци расположиви да подржеинформационе потребе.

Састанак о дизајну DW.Идентификовани главни процеси и приказане табеле факата.Одабрана гранулација за сваку табелу факата.

Одабир трансакционе грануле vs. периодично акумулирана гранула.Идентификоване димензије за сваку табелу факата.Идентификовани димензиони атрибути са изворним пољима.Идентификоване основне и додатне хетерогене табеле продуката.Идентификовани димензиони атрибути који се лагано мењају (тип 2).Идентификоване демографске минидимензије.Идентификоване иицијално агрегиране димензије.Идентификовано трајање сваке табеле факата (потебно за екстракцију старихподатака).

Идентификована ургентност сваке табеле факата (тј. потреба за дневноекстраховање).

Режија имплементације (први процес за имплементацију ...).


Блок дијаграм за продукциону екстракцију података (како је сваки главни процесимплементиран).

Подсистем за читање изворних података.Подсистем за идентификовање промењених слогова.Подсистем за руковођење лагано променљивих димензија.Подсистем за припрему пуњења слогова.Миграциони систем (mainframe ка ДБМС серверу).Подсистем за креирање агрегата.Подсистем за пуњење података, управљање изузецима, гарантовањереференцијалних интегритета.

Подсистем за проверу квалитета података.Подсистем за заштиту и опоравак слика података.Подсистем за публиковање, обавештавање корисника о дневном статусуподатака.

Хардвер за DBMS сервер.Квалификовани тимови за продају и подршку.Релевантност продавца.Тест продавца.

Продавац демонстрира спремност за подршку стартовања, заштите иодржавања система.

Отворени системи и паралелна скалабилност.Потврђени елеметни уговора.

DBMS сотвер.Квалификовани тимови за продају и подршку.

Продавац је већ имплементирао сличну DW.Сагласност продавца са димензионалним приступом.Продавац показију компетентност у тесту прототипа.

Способност за пуњење, индексирање и одређивање квалитета података.Способност за листање великих димензионих табела.Способност за упит фамилије табела факата са 20 рачунара приликом пуњења.Високе перформансе и стабилност оптимизатора за упите са звездастим спојем.Проширена SQL синтакса за специјалне DW функције.Способност да тренутно и лако заустави упит са рачунара крајњег корисника.

Екстракциони алати.Специфичне потребе за особинама екстракционог алата, идентификоване саблок дијаграма екстракционог система.

Одбијена алтернатива писања сопствених екстракционих система.Референце за продавца.

Агрегациони навигатор.Верификовани приступ навигатора ка отвореним системима (послужује све SQLклијенте на мрежи).

Администрација табеле метаподатака упоређена са другим навигаторима.Статистика корисничких упита, препоруке за агрегацију, веза са алатом за

креирање агрегата.Перформансе за листање малих браузера (на нивоу субсекунде).

Алат за параметризоване извештаје.Записани извештаји који се могу послати mail-ом и стартовати.Записане дефиниције ограничења које се могу поново користити (јавне и

приватне).Записане дефиниције бихејвиоралних група које се могу поново користити(јавне и приватне).Браузер за димензионалну табелу са способношћу попречног претраживања.

Прилози 195.

Постојећи извештај се може отворити и стартовати помоћу једног клика мишем.Вишеструки скупови одговора се могу аутоматски уклопити у извештај саспољним спојем (outer join).Директна подршка једнодимензионих и вишедимензионих компарација.Директна подршка вишеструких компарација са различитим агрегацијама.Директна подршка израчунавања са просечним веменским периодима (тј.просечни дневни биланс).STOP QUERY команда.Проширив интерфејс за HELP, који омогућава DW табелама да буду описанекорисницима.Једноставна drill-down команда која подржава вишеструке хијерархије инехијерархије.Drill-across који омогућава да више табела факата буде у истом извештају.Коректно израчунавање break редова.Зелено-црвено означавање изузетака са интерфејсом за drill-down.Способност за коришћење мрежног агрегатног навигатора, са сваким упитомкоји алат излучи.Секвенцијалне операције на скупу одговора (пребројавање, првих N и rolling).Способност за проширивање синтаксе упита за специјалне DBMS функције.Способност за дефинисање врло великих бихејвиоралних група купаца ипроизвода.Способност за графичко представљање података или прослеђивање података унеки графички пакет.Способност за pivot података или прослеђивање података у неки pivot пакет.Способност за подржавање OLE веза са другим апликацијама.Способност за смештање одговора у clipboard или текстуални фајл у Lotus илиExcel формату.Способност за штампање хоризонтално и вертикално окренутих извештаја.Batch процесирање.Погодности за развој графичког корисничког интерфејса.

Способност за креирање стартног екрана за крајње кориснике.Способност за дефинисање pull-down менија.Способност за дефинисање дугмића за стартовање извештаја и позивањебраузера.

Консултанти.Квалификовани консултантски тим.

Консултантски тим је имплементирао сличну DW.Консултантски тим je сагласан са димензионалним приступом.Консултантски тим демонстрира компетентност у тесту прототипа.

Litetatura

[1] Kimball R. L., Reeves R. L., Ross M., and Thornthwaite W., "The Data WarehouseLifecycle Toolkit", John Wiley & Sons, Inc., New York, 1998.

[2] "Data Warehousing with INFORMIX: Best Practices", INFORMIX Press, Menlo ParkC.A., 1998.

[3] "INFORMIX MetaCube for Windows 95 and Windows NT" in: Warehouse Manager’sGuide Ver.3.1, INFORMIX Press, Menlo Park C.A., 1998.

[4] Balaban Ne|o, Risti} @ivan, "Sistemi podr{ke odlu~ivawa", Ekonomskifakultet Subotica, Subotica, 1998.

[5] Bigus Joseph, "Data Mining with Neural Networks: Solving Business Problems – fromAplication Development to Decision Support ", McGraw-Hill, New York, 1996.

[6] Chaudhuri A., Dayal S. U., "An Overwiew of Data Warehousing & OLAP Tehnology" in:SIGMOD Record, Vol. 26, No. 1, 1997. March, 65-74.

[7] Immon W. H., "Building the Data Warehouse" 2nd edition, John Wiley & Sons, Inc., NewYork, 1996.

[8] Immon W. H., Weleh J. D., Glassey K. L., "Managing the Data Warehouse", John Wiley &Sons, Inc., New York, 1997.


[9] Immon W. H., Hachathorn R. D., "Using the Data Warehouse", John Wiley & Sons, Inc.,New York, 1996.

[10] Kimball R. L., "The Data Warehouse Toolkit", John Wiley & Sons, New York, 1996.

[11] Mattison R., "Data Warehousing, Strategies, Technologies, and Techniques", McGraw-Hill, New York, 1996.

[12] Wu M. C., Buchmann A. P., "Research Issues in Data Warehousing" in: Proceedings of theBTW, Prentice Hall, 1996.

[13] Kachur R. J., "Data Warehouse Management Handbook", Prentice Hall, 1999.

[14] Groth R., "Data Mining: Building Competitive Advantage", Prentice Hall, 1999.

[15] Langenwalter G. A., "Enterprise Resource Planning and Beyond: intergrating Your EntireOrganization", McGraw-Hill, New York, 1999.

[16] Poe V., Klauer P., Brobst S., "Building a DW for DSS", Prentice Hall, 2000.

[17] Simchi-Levi D., Kaminsky P., Edith Simchi-Levi, "Designing and Managing the SupplyChain: Concepts, Strategies and Case Studies", International Thompson Publishing, 1999.

[18] Sperley E., "The Enterprise Data Warehouse: Planning, Building and Implementation",International Thompson Publishing, 1999.

[19] Rob Mattison, "Web Warehousing and Knowledge Management", International ThompsonPublishing, 1999.

[20] Dorian Pyle, "Data Preparation for Data Mining", Morgan Kaufman Publishers, 1999.

[21] Mogin P., Lukovi} I., "Principi baza podataka", Fakultet tehni~kih nauka,Novi Sad, 1996.

[22] Bernard H. Boar, "The Art of Strategic Planning for Information Technology: CraftingStrategy for the 90s", Chinese Mandarin Edition, 1995.

[23] Risti} @., "O istra`ivawu, metodu i znawu", Institut za pedago{kaistra`ivawa, Beograd, 1995.

[24] "Microsoft SQL Server 7.0 Data Warehousing Training", Microsoft Press Division,Washington, 1999.

[25] Constantin von Altrock, "Fuzzy Logic & NuroFuzzy Aplications In Bussiness & Finance",USA 1997.

[26] Kelly S., "Data Warehousing: The Route to Mass Customization", Dublin 1994.

[27] Mogin P., Lukovi} I., Govedarica M., "Principi projektovawa bazapodataka", Fakultet tehni~kih nauka, Novi Sad, 2000.

sistemi za podr{ku odlu~ivawa zasnovani na data warehouse...

Documents