ANALIZA MAGACINSKOG POSLOVANJA SA ASPEKTA PRIMENE SKLADIŠTA PODATAKA

VISOKA ŠKOLA TEHNIČKIH STRUKOVNIH STUDIJAČAČAK

ANALIZA MAGACINSKOG POSLOVANJA SA ASPEKTA PRIMENE SKLADIŠTA PODATAKA

Specijalistički rad

Student : 44/09-s Milica Jovičić

Čačak 2011.

VISOKA ŠKOLA TEHNIČKIH STRUKOVNIH STUDIJA ČAČAKSTUDIJSKI PROGRAM INDUSTRIJSKO INŽENJERSTVO

MODUL MAŠINSKO INŽENJERSTVO



Student: Mentor:44/09-s Milica Jovičić dr Nataša Gojgić, prof.

Čačak 2011.

2

VISOKA ŠKOLA TEHNIČKIH STRUKOVNIH STUDIJA ČAČAKSTUDIJSKI PROGRAM INDUSTRIJSKO INŽENJERSTVO

MODUL MAŠINSKO INŽENJERSTVO



Sastav Komisije za ocenu i odbranu rada:

Predsednik:

______________________________mr Branko Marković, predavač, VŠTSS Čačak

Član:

______________________________dr Danijela Milošević, docent TFČ

Mentor:

______________________________dr Nataša Gojgić, profesor, VŠTSS Čačak

3

SADRŽAJ1. UVOD...........................................................................................................................................52. POSLOVANJE U MAGACINSKOJ SLUŽBI U PD RB „KOLUBARA" D.O.O.....................63. MODELIRANJE PROCESA MAGACINSKOG POSLOVANJA...........................................13

3.1. Funkcionalno modeliranje...................................................................................................133.2. Grafički prikaz standarda IDEF0.........................................................................................143.3. Funkcionalna dekompozicija poslova magacina.................................................................15

4. INFORMACIONO MODELIRANJE........................................................................................194.1. Logički model podataka......................................................................................................19

4.1.1. Identifikujuća veza.......................................................................................................204.1.2. Neidentifikujuća veza...................................................................................................204.1.3.Veza kategorije..............................................................................................................204.1.4. Neodređujuća veza tipa više prema više......................................................................21

4.2. Fizički model podataka........................................................................................................215. APLIKATIVNO MODELIRANJE............................................................................................236. OBJEKTNO ORJENTISANO MODELIRANJE......................................................................29

6.1. Elementi (stvari)..................................................................................................................296.1.1. Strukturalni elementi....................................................................................................296.1.2. Elementi ponašanja.......................................................................................................30

6.2. Relacije................................................................................................................................316.3. Objektno modeliranje..........................................................................................................31

6.3.1. Dijagrami poslovnih slučajeva upotrebe......................................................................326.3.2. Izrada dijagrama poslovnih aktivnosti za poslovni slučaj magacinskog poslovanja. . .326.3.3. Model sistemskih slučajeva upotrebe...........................................................................33

6.4. Izrada modela sistemskih slučajeva upotrebe......................................................................336.5. Izrada konceptualnog modela..............................................................................................34

7. SKLADIŠTA PODATAKA.......................................................................................................357.1. Dimenziono modeliranje.....................................................................................................36

7.1.1. Denormalizacija podataka............................................................................................387.1.2. Definisanje hijerarhija..................................................................................................407.1.3. Kreiranje agregacije......................................................................................................407.1.4.Kreiranje fizičkog modela.............................................................................................407.1.5.Generisanje baze podataka............................................................................................417.1.6. Učitavanje podataka.....................................................................................................41

7.2. Analitički OLAP sistemi.....................................................................................................427.3. Arhitekture OLAP sistema..................................................................................................44

7.3.1 Višedimenzioni OLAP (MOLAP).................................................................................447.3.2. Relacini OLAP (ROLAP).............................................................................................447.3.3. Hibridni OLAP (HOLAP)............................................................................................45

7.4. Kreiranje OLAP kocki u Microsoft Query-ju.....................................................................458. ANALIZA PODATAKA MAGACINSKOG POSLOVANJA..................................................489. ZAKLJUČAK.............................................................................................................................5710. LITERATURA.........................................................................................................................58

4

1. UVOD

Činjenica je da za svaki ozbiljan sistem koji raspolaže velikim brojem mašina, alatki i materijala neophodna njihova evidencija i nomenklatura. To automatski omogućuje praćenje zaliha u realnom vremenu, a i njihovu promenu u zadatim vremenskim intervalima kako bi se mogla planirati njihova nabavka. Izvršavanje ovih radnih zadataka omogućuje MAGACINSKO POSLOVANJE.

Informacioni sistem predstavlja sređeni skup metoda, procesa i operacija za prikupljanje, čuvanje, obradu, prenošenje i distribuciju podataka u okviru jedne organizacije, uključujući i opremu koja se u te svrhe koristi i ljude koji se tim aktivnostima bave. Informacioni sistem delujući u okviru neke organizacije, omogućava joj da komunicira unutar sebe i sa svojim okruženjem. Prema tome, uslov opstanka bilo koje ogranizacije je da raspolaže adekvatnim informacionim sistemom, u kojem su razrađeni postupci informacionih aktivnosti.

U radu je korišćen MS Access za izradu aplikativnog modela kao podrška, alat poslovanja. Implementacija je realizovana izgradnjom skladišta podataka i kreiranjem višedimenzionalne kocke u MS Query, a grafički prikaz analize podataka je dat u MS Exccel-u.

Rad se sastoji od devet poglavlja.Prvo poglavlje opisuje sadržaj svakog poglavlja u radu, cilj ovog rada i njegov značaj.Drugo poglavlje opisuje dokumenta koja prate magacinsko poslovanje i poslove koje

obavlja magacinska služba.U trećem poglavlju prikazano je modeliranje procesa magacinskog poslovanja koje

obuhvata funkcionalno modeliranje korišćenjem grafičkog jezika IDEF0 (Integration Definition Functional Modeling), a realizovan softverom BPwin (Business Process for Windows) kojim je prikazana funkcionalna dekompozicija poslova magacinskog poslovanja.

Četvrto poglavlje obuhvata modeliranje podataka magacinskog poslovanja urađeno u okviru IDEF1X metodologije, na kome se bazira CASE alat ERwin (Entity Relitionships for Windows). U okviru modeliranja definisani su logički i fizički modeli magacinskog poslovanja.

U petom poglavlju opisano je generisanje baze podataka iz ERwin-a u SUBP MS Access i prikazano je aplikativno modeliranje.

Šesto poglavlje objašnjava objektno orjentisano modeliranje korišćenjem grafičkog jezika UML (Unified Modeling Language) koji je korišćen pri modeliranju. Opisano je objektno modeliranje, izrada modela sistemskih slučajeva upotrebe i izrada konceptualnog modela magacinskog poslovanja.

Sedmo poglavlje obuhvata teoriju skladišta podataka, dimenziono modeliranje, ETL procese koji omogućavaju prenos podataka u skladište, OLAP sisteme i postupak kreiranja OLAP kocke u MS Query.

U osmom poglavlju korišćenjem podataka iz kreirane OLAP kocke vrši se analiza podataka magacinskog poslovanja korišćenjem MS Excel.

Deveto poglavlje daje objašnjenje krajnih rezultata ovoga rada. Cilj rada je da prikaže izdvajanje podataka od relacionih baza podataka u skladište

podataka radi analize količine primljenih i trebovanih artikala po magacinima i vrsti promene za vremenske periode mesec, kvartal, polugodište i godinu.

Ovakav način analize omogućava visok nivo performansi za analizu podataka i prikaz po različitim nivoima detalja što pruža podršku rukovodstvu za poređenje podataka i donošenje odluka na osnovu činjenica.

5

2. POSLOVANJE U MAGACINSKOJ SLUŽBI U PD RB „KOLUBARA" D.O.O.

U sektoru za automatsku obradu podataka (AOP) neposredno se obavljaju: poslovi razvoja, projektovanja i uvođenja integralnog informacionog sistema za

potrebe Javnog preduzeća, poslovi uvođenja automatske obrade podataka u Javnom preduzeću sa obavezom

praćenja, održavanja i usaglašavanja obrade podataka u skladu sa zakonskim propisima,

poslovi automatske obrade podataka održavanje hardvera i sistemskog softvera.U okviru Sektora formirane su: Služba za razvoj i projektovanje informacionog sistema u okviru koje su:

1. Odeljenje za tehničke poslove2. Odeljenje za ekonomske poslove

Služba za automatsku obradu podataka1. Odeljenje Lazarevac2. Odeljenje Vreoci3. Odeljenje Lajkovac4. Odeljenje Rudovci5. Odeljenje za održavanje hardvera i sistemskog softvera.

Služba za razvoj i projektovanje informacionog sistema sagledava, projektuje i programira svaki zahtev koji se može obraditi na računarima a vezan je za poslovanje kombinata “Kolubara” u saradnji sa stručnim službama “Kolubare”.

Služba za automatsku obradu podataka (AOP) vrši pripremu (prijem i unos), predkontrolu, obradu, finalnu kontrolu i intervencije po zahtevu korisnika svih podataka koji se obrađuju, a takođe i održava sistemski softver i hardver.

U AOP-u se centralizovano obrađuju kadrovska evidencija, obračun ličnih dohodaka i kvalitet uglja koji se distribuiraju korisnicima.

Drugi poslovni moduli (magacinsko i materijalno poslovanje, sitan inventar, knjigovodstvo, finansije, osnovna sredstva...) se izvršavaju u ostalim delovima preduzeća (van AOP-a) i to je tzv. distribuirana obrada podataka.

Magacinsko poslovanje putem elektronskih maski predstavlja novi način unošenja podataka, pregleda i kontrolisanja stanja artikala, što omogućuje kvalitetno praćenje zaliha.

Sva magacinska dokumentacija ima svoj VK (AOP oznaka): VK 111 – prijemnica, VK 121 – prijem-ulaz od dobavljača iz inostranstva, VK 151 – prenosnica (interna prijemnica između magacina), VK 181 – prijem-donacija, VK 101 – prijemnica (zapisnik za investicioni materijal),

6

VK 211 – trebovanje (klasičnog i investicionog materijala), VK 221 – prodaja-izdavanje eksternom kupcu, VK 251 – prenosnica (interna prenosnica između magacina), VK 261 – otpremnica materijala na doraduU kombinatu Kolubara postoje dve važne vrste podela magacina. Prva i najvažnija je

podela prema podeli samog kombinata, a druga prema vrsti artikala koji se skladište u magacine.Podela po kombinatu je: 1. Direkcija2. Kopova 3. Prerada 4. Kopovi - investicije5. Prerada – investicije6. Kolubara Projekt.Po vrstama artikala koji se koriste postoje sledeći magacini: magacin sirovina, repromaterijala i rezervnih delova, magacin investicionog materijala, magacin ulja i goriva. magacin opasnih materija i eksploziva, magacin otpadnog materijala, magacin robe iz donacija, magacin sitnog inventara, magacin higijensko-tehničko-zaštite, magacin osnovnih sredstava.Prijemnica je osnovni dokument kojom se prima roba u magacine (slika 1). Ispunjava se

na osnovu otpremnice materijala koju zajedno sa robom donosi dobavljač.

Slika 1. Prijemnica

7

Pored prijemnice, magacin prima robu i preko interne prenosnice (slika 2), a u izuzetnim slučajevima zadužuje se reversom (slika 3) ako je u pitanju neka hitna pozajmica (revers nije zvanični dokument poslovanja).

Slika 2. Prenosnica (interna)

Prenosnica je dokument za međumagacinsko rukovanje zalihama i njena je oznaka VK 151 ako je ulaz u magacin, a VK 251 ako je izlaz.

Prilikom prenosa zaliha prvo se formira prenosnica - izlaz (VK 251) pa na osnovu nje prenosnica - ulaz (VK 151 ulaz).

8

Slika 3. Revers

Trebovanje je osnovni dokument za izdavanje robe iz magacina. Da bi se realizovalo trebovanje pre svega treba imati tri potpisa (trebovao, primio, odobrio), a četvrti potpis se realizuje posle izdavanja robe (magacioner - izdao).

Za izdavanje jednog artikla koristi se jedinično trebovanje formata B5 (slika 4). Ako je izdato više od jednog artikla koristi se trebovanje formata A4 (slika 5).

Slika 4. Jedinično trebovanje materijala

9

Slika 5. Trebovanje materijala

Kada je reč o trebovanju investicionog materijala i osnovnih sredstava koristi se poseban obrazac: trebovanje osnovnih sredstava i investicionog materijala (slika 6), ali se i ono obrađuje u istoj maski programa.

Slika 6. Trebovanje osnovnih sredstava i investicionog materijala

Ako je u pitanju investiciona nabavka i ulazak sredstava po nekom od donatorskih dokumenata koristi se zapisnik o prijemu robe VK - 101 (slika 7).

10

Slika 7. Zapisnik o prijemu robe

Za izdavanje robe iz magacina koristi se otpremnica (slika 8). Otpremnica se koristi i za izdavanje materijala na dalju obradu ili doradu u preduzeću.

Slika 8. Otpremnica materijala na obradu i doradu

Reversna knjižica sitnog inventara (slika 9) se koristi za tačnu evidenciju ličnog zaduženja radnika priborom, alatom i kancelarijskim materijalom. Ova evidencija se ažurira

11

svake godine sve do odlaska radnika u penziju, a tada je on obavezan da fizički vrati ili nadohnadi novčano svaku stavku da bi dobio potvrdu o razduženju. Karton zaduženja HTZ opreme sadrži šifru, naziv artikla i datuma zaduženja prema kome se „izračunava“ protok vremena trajanja za pojedinačni artikal i radnik se automatski razdužuje u skladu sa pravilnikom HTZ opreme.

Slika 9. Reversna knjižica sitnog inventara

Evidenciju svih navedenih magacinskih dokumenata sa datumom i količinama magacioner razvodi kroz magacinsku karticu (slika 10).

Ona je osnovni dokument za rad magacina i predstavlja ličnu kartu svakog artikla pojedinačno (koliko različitih artikala toliko kartica).

U svakoj situaciji kada je potrebno sravniti i proveriti podatke računopolagač se isključivo koristi magacinskom karticom jer on materijalno i krivično odgovara za zalihe.

Slika 10. Magacinska kartica

12

3. MODELIRANJE PROCESA MAGACINSKOG POSLOVANJA

Najvažnija korist u primeni modeliranja procesa je prototipski pristup gde se na brz i jednostavan način proveravaju alternativne ideje. Mnogo je jeftinije nacrtati model aktivnosti nego razviti novi informacioni sistem. Ovo je veoma bitna osobina jer brzi razvoj informacionih tehnologija i primena Internet servisa uslovljava potrebu za reinženjeringom koja zahteva radikalni redizajn aktivnosti, a koje je potrebno opisati i pre sprovođenja prototipski proveriti.

IDEF0 je tehnika modeliranja bazirana na kombinaciji grafike i teksta koji su predstavljeni na organizovan i sistematičan način da bi se povećala razumljivost i obezbedila logika za potencijalne izmene, specificirane zahteve, ili na drugi način rečeno podržala analizu sistema po nivoima u magacinskom poslovanju.

Standard IDEF0 omogućuje:1. Izvršenje sistema analize i dizajna na svim nivoima, za sistem sastavljen od ljudi,

mašina, materijala, računara i informacija;2. Stvaranje dokumentacije kao osnova za integraciju informacionih sistema i sistema

menadžment kvaliteta;3. Bolju komunikaciju između analitičara, dizajnera, korisnika i menadžera;4. Omogućuje diskusiju u radnom timu da bi se postiglo međusobno razumevanje;5. Omogućuje upravljanje velikim i složenim projektima, kao što je u radu prikazan

segment magacinskog poslovanja može se proširiti i na ostale.

3.1. Funkcionalno modeliranjeCilj modeliranja je da se razviju tehnologije koje će omogućiti logičku i fizičku

integraciju mreža hardverski i softverski veoma različitih konfiguracija. Tehnika IDEF0 modeliranja je prihvaćena kao osnova za sprovođenje postupka reinženjeringa poslovnih procesa.

Funkcionalno modeliranje IDEF0 omogućuje: izvršenje funkcionalne dekompozicije i dizajna na svim nivoima, za sistem sastavljen

od ljudi, mašina, materijala, računara i informacija; stvaranje dokumentacije, paralelno sa reinženjeringom poslovnih procesa; bolju komunikaciju između projektnog tima, korisnika i menadžera; diskusiju u projektnom timu da bi se postiglo međusobno razumevanje; upravljanje velikim i složenim projektima; obezbeđenje elemenata potrebnih za informaciono modeliranje (IDEF1X

metodologija).Softverski alat BPwin za modeliranje i analizu složenih poslovnih procesa je zasnovan na

konceptima standarda IDEF0. Zbog lakše identifikacije procesa i njihove optimizacije, kao i odbacivanja suvišnih procesa, nastala je metodologija modeliranja poslovnih procesa. Modeliranjem procesa se dobija uređena struktura sa jasno definisanim pravilima kojim se procesi odvijaju i na koji način.

13

Dinamički objekti koji vode kroz model sprečavaju greške koje najčešće nastaju pri kreiranju modela.

Kreiranje dokumentacije iz BPwin-ovih modela procesa daje potpunu slobodu u definisanju seta podataka iz modela aktivnosti, kao i u definisanju izgleda dokumentacije.

BPwin omogućava rad u grafičkom okruženju, tako da je editovanje modela podataka izuzetno lako; dijagrami koji se dobijaju daju potpuni prikaz modela. Dekompozicija procesa se vrši direktno na dijagramu, a kretanje po nivoima dekompozicije podrazumeva prebacivanje sa dijagrama na dijagram. Pri radu na jednom modelu otvoreni su svi dijagrami iz tog modela.

3.2. Grafički prikaz standarda IDEF0Grafički jezik IDEF0 opisuje metodu dekompozicije preko skupa dijagrama, od kojih

svaki predstavlja ograničenu količinu detalja definisanih odgovarajućom sintaksom i semantikom. Dijagrami su međusobno povezani tako da opisuju sistem, hijerarhijski, sa vrha naniže. Dijagrami se sastoje od pravougaonika koji predstavljaju neki deo celine. Povezani su međusobno usmerenim linijama koje predstavljaju veze između delova.

Postoje tri vrste IDEF0 prikaza: grafički, tekstualni i rečnik (glossary). Grafički prikaz definiše funkcije i veze funkcija preko pravougaonika i strelica i odgovarajuće sintakse i semantike. Tekst i rečnik pružaju dodatne informacije i podržavaju grafičke dijagrame.

Sintaksu grafičkog jezika IDEF0 čine pravougaonici (boxes), strelice (arrows) i pravila (rules).

Pravougaonici predstavljaju aktivnosti, definisane kao funkcije, procesi i transformacije. Svaki pravougaonik ima naziv i broj u okviru granica pravougaonika.

Za naziv aktivnosti se koristi aktivan glagol ili glagolska fraza koja opisuje funkciju. Broj se koristi da bi bio prepoznat predmet opisa pravougaonika u pridruženom tekstu.

Aktivnost definisana u okviru pravougaonika ima tri karakteristike: naziv – aktivnost mora imati naziv, tj. da ime aktivnosti ima, obično, strukturu

formata tipa glagol – subjekt; vremensku dimenziju – aktivnost ima vremensku dimenziju, tj. određeno vreme koje

mora proći između početka i kraja aktivnosti; rezultat rada – sve aktivnosti moraju dati rezultat, tj. odgovarajući izlaz. Sledeći element sintakse grafičkog jezika IDEF0 je strelica. Strelica se sastoji od jedne ili

više linija, sa vrhom strelice na jednom kraju. Strelice mogu biti pravolinijske ili savijene pod uglom od 90˚ i mogu se račvati ili spajati. Strelice predstavljaju podatke ili objekte vezane za aktivnost. One ne znače samo tok ili sekvencu, kao u tradicionalnom modelu dijagrama toka podataka, već prenose podatke ili objekte vezane za posmatranu aktivnost. Svaka strelica je definisana nazivom (imenicom). Za opis naziva strelice definiše se i odgovarajući tekstualni opis.

Semantika grafičkog jezika IDEF0 ukazuje na značenje sintaksne komponente jezika i olakšava korektnost interpretacije kojom se opisuje notacija za aktivnost i strelice. Odnos između aktivnosti i strelica je određen pomoću strane pravougaonika (aktivnosti) na koji je strelica naslonjena.

Imajući u vidu englesku notaciju, dijagrami se zovu i ICOM dijagrami, jer je to skraćenica od:

I – Input, nešto se upotrebljava u aktivnosti; C – Control, kontrole ili uslovi izvođenja aktivnosti; O – Output, rezultat izvođenja aktivnosti; M – Mehanizam, nešto što se koristi u aktivnosti ali se ne menja.

14

Ulazna (Input) strelica predstavlja materijal ili informaciju koja se koristi ili transformiše radi definisanja izlaza (Output). Dozvoljava se mogućnost da određene aktivnosti ne moraju imati ulazne strelice.

Kontrolne (Control) strelice regulišu, odnosno odgovorne su za to kako, kada i da li će se aktivnosti izvesti, odnosno kakvi će biti izlazi (Output). Svaka aktivnost mora imati najmanje jednu kontrolnu strelicu. Kontrole su često u obliku pravila, politika, procedura ili standarda. One utiču na aktivnost, ali ne mogu da budu transformisane ili upotrebljene. U slučaju da je cilj aktivnosti da promeni pravilo, politiku, proceduru ili standard, treba očekivati da će strelice koje sadrže tu informaciju, u stvari biti ulaz.

Izlazne (Output) strelice su materijali ili informacije stvorene aktivnošću. Svaka aktivnost mora imati najmanje jednu izlaznu strelicu. Ne treba modelirati aktivnost koja ne stvara izlaz.

Strelice mehanizma su izvori koji izvode aktivnosti, a sami se ne „troše“. Mehanizmi mogu biti ljudi, mašine i/ili oprema, tj. objekti koji obezbeđuju energiju potrebnu za izvođenje aktivnosti.

Strelica poziv (Call) specifični je slučaj strelice mehanizma i ona označava da pozivajući pravougaonik nema vlastiti detaljniji dijagram, već daje detaljniji prikaz izveden na nekom drugom pravougaoniku u istom ili nekom drugom modelu. Više pozivajućih pravougaonika mogu pozivati isti pravougaonik na nekom drugom ili istom modelu. Imenuju se brojem dekompozicionih dijagrama, koji sadrži pozvani pravougaonik zajedno sa brojem pozivnog pravougaonika.

3.3. Funkcionalna dekompozicija poslova magacinaFunkcionalnom dekompozicijom potrebno je identifikovati poslove magacina. Za

izvođenje ovih aktivnosti korišćen je standard IDEF0, softver CASE alat. Funkcionalnu dekompoziciju potrebno je izvoditi kroz tri podređene aktivnosti:

Definisanje granica sistema (kontekstni dijagram) - se definišu da bi se, pre svega, znalo gde treba stati sa modeliranjem.

Definisanje stabla aktivnosti - podrazumeva uspostavljanje vertikalne (hijerarhijske) veze između aktivnosti. Stablo aktivnosti se definiše primenom metode rešavanja problema odozgo nadole (top-down), kada se složena aktivnost rastavlja na više podređenih aktivnosti, a zatim se pristupa rešavanju jednostavnih podređenih aktivnosti.

Definisanje dekompozicionog dijagrama - je definisan jednim pravougaonikom koji predstavlja granicu modela koji se proučava. U tom sistemu i van njega teku informacije preko strelica. Kontekstni dijagram je najviši nivo apstrakcije koji se dekompozicionim dijagramima prevodi u niži nivo apstrakcije.

Kod standarda IDEF0 kao prvi korak definiše se odgovarajući dijagram konteksta tj. potrebno je postaviti granice sistema. Na slici 11 prikazan je dijagram konteksta gde se definiše neposredno okruženje.

15

Slika 11. Konteksni dijagram poslova magacina

Analizom aktivnosti poslova magacina uočeno je da se poslovi mogu podeliti u određene grupe poslova, odnosno tipizirati. Ovakav pristup obezbeđuje stabilnost informacionog sistema ukoliko bi došlo do organizacionih ili bilo kakvih drugih promena.Na slici 12 prikazano je stablo aktivnosti poslova magacina, na osnovu koga se jasno vidi hijerarhijska veza između procesa planiranja i magacinskog poslovanja.

Slika 12. Stablo aktivnosti poslova magacina

Na slici 13 prikazan je dijagram horizontalne dekompozicije procesa poslova magacina.

16

Slika 13. Dekompozicioni dijagram prvog nivoa

Po IDEFO standardu odgovarajuće strelice predstavljaju grupe dokumenata koje definišemo kao informacije. Na sledećem nivou svaka informacija se deli do nivoa aktivnosti gde se kao strelice definišu konkretna dokumenta.

Planiranje obuhvata sastavljanje plana, izbor odgovornih lica za izradu i izvršenje plana, sakupljanje potrebnih dokumenata i sredstava.

Magacinsko poslovanje obuhvata sve poslove vezane za magacine kao što su: označavanje i skladištenje artikala u magacine, spisak dokumenata koji prate artikle, potrebu za nabavkom artikala i ostalo. Na ovu aktivnost se odnosi i obrada podataka (prenos u elektronski oblik) prikupljenih po magacinskim službama.

Ovaj segment magacinskog poslovanja ima za cilj da: Omogući lakši uvid u zalihe po magacinima (prijemnica, interna prenosnica ulaz -

izlaz, prijem - donacija, trebovanje materijala i dr.) Gubljenje dokumenata, tj. da se sva dokumenta iz magacinskog poslovanja formiraju

u elektronskom obliku, a samim tim ograniči pristup tim podacima. Da se ograniče i smanje troškovi magacinskog poslovanja.

Na slici 14 prikazan je dekompozicioni dijagram drugog nivoa MAG poslovanje koje obuhvata označavanje MAG-a, izradu dokumenata i izradu izveštaja.

17

Slika 14. Dekompozicioni dijagram drugog nivoa

Označavanje MAG-a prati označavanje i skladištenje artikala u magacin sa pratecim dokumentima.

Izrada dokumenata obuhvata obradu svih dokumenata koji su potrebni za poslovanje magacina.

Izrada izveštaja na osnovu prikupljenih podataka o obradi dokumenata kreira izveštaje o zalihama u magacinima, o troškovima poslovanja i o realizaciji plana.

U radu je dalje posmatran samo proces poslova magacina kroz informaciono i aplikativno modeliranje.

18

4. INFORMACIONO MODELIRANJE

Pri informacionom modeliranju dolazi do izražaja sposobnosti i znanje visokostručnog kadra iz oblasti menadžmenta i informatike, gde se koriste tehnike za opisivanje strukture podataka i poslovnih pravila pod nazivom model podataka.

Modeliranje podataka je proces predstavljanja poslovnih koncepata u obliku dijagrama, koji se na jednostavan način može prevesti u fizičke strukture podataka, tj. šemu podataka.

Model podataka preko skupa podataka i njihovih međusobnih veza, predstavlja stanje sistema u jednom trenutku vremena i sadrži skup informacija o prošlosti i sadašnjosti sistema koja je potrebna da se pod dejstvom budućih poznatih ulaza mogu odrediti njegovi budući izlazi.

Model podataka za magacinsko poslovanje je urađen po standardu IDEF1X, na kome se bazira CASE alat ERwin.

Model podatka obuhvata definisanje: logičkog modela, tj. definisanje entiteta, atributa, relacija, kardinalnosti i ključeva, fizičkog modela , tj. definisanje tabela, domena, tipova i veličina kolona za izabrani

SUBP.Korišćenje ERwin-a podrazumeva istovremeni razvoj logičkog modela i fizičko

definisanje baze.

4.1. Logički model podatakaLogičkim modelom se definišu entiteti (entities). Svaki entitet ima svoje osobine, tj.

atribute (attributes), a sve je povezano vezama (relationships). Entitet se može posmatrati kao set ili kolekcija (skup) individualnih objekata. Koji se nazivaju primerci ili instance (instances). Jedan primerak predstavlja jedan pojavni oblik datog entiteta, svaki primerak mora imati različiti identitet od svih ostalih primeraka.

Postupak izvođenja odabira entiteta obuhvata nekoliko koraka: definisanje nezavisnih entiteta, tj. pronalaženje „roditelja“, definisanje zavisnih entiteta, definisanje veza.Nezavisni entitet je objekat koji ima jednu osobinu koja ga identifikuje jednoznačno. Oni

imaju svoju identifikaciju, ne zavise od drugih entiteta. Grafički se prikazuju pravougaonikom u koji se upisuje naziv tipa entiteta u jednini.

Zavisni entiteti su oni objekti čija egzistencija i identifikacija zavisi od drugog ili drugih entiteta.

Definisanje veza - veza je asocijacija dva ili više entiteta. Entitet od koga je uspostavljena veza zove se „roditelj“ (parent), a entitet ka kome je uspostavljena veza se zove „dete“.

Veza „roditelj-dete“ je asocijacija između entiteta gde su svi primerci entiteta „roditelj“ (entitet A) asocirani sa nula, jedan ili više primeraka entiteta „dete“ (entitet B), a svi primerci

19

entiteta „dete“ (entitet B) su asocirani sa nula ili jednim primerkom entiteta „roditelj“ (entitet B).

Postoje sledeći tipovi veza: Identifikujuće Neidentifikujuće Veza kategorije, tj. veza prema podtipovima Neodređujuća veza – više prema više.

4.1.1. Identifikujuća veza

Ključevi objekta „roditelj” predstavljaju deo identiteta objekta „dete”, tj. objekat „dete” zavisi od objekta „roditelj” preko identifikatora (slika 15).

Svaki primerak objekta “dete” mora biti povezan sa najmanje jednim primerkom objekta “roditelj”.

Pojavljivanje objekta „roditelj” se definiše nezavisno, a pojavljivanje objekta „dete” se ne može identifikovati bez identifikatora objekta „roditelj”.

Slika 15. Identifikujuća veza

4.1.2. Neidentifikujuća veza

Ako se svaki primerak objekta „dete” može jedinstveno identifikovati, bez znanja veze sa primerkom objekta „roditelj” onda je to neindentifikujuća veza (slika 16).

Slika 16. Neidentifikujuća veza

4.1.3.Veza kategorije

Veza kategorije je definisana za hijerarhijsku vezu između nadređenog generalizovanog objekta koji sadrži zajedničke osobine i podređenih objekata (slika 17).

Slika 17. Veza kategorije

20

4.1.4. Neodređujuća veza tipa više prema više

Primerak jednog objekta povezuje se sa nijednim, jednim ili više primeraka drugog objekta, a svaki primerak drugog objekta povezuje sa nijednim, jednim ili više primeraka prvog objekta (slika 18).

Slika 18. Neodređujuća veza tipa više prema više

Na osnovu analize dokumenata identifikovani su entiteti i atributi. Na slici 19 dat je prikaz logičkog modela magacinskog poslovanja.

Slika 19. Logički model magacinskog poslovanja u ERwin-u

4.2. Fizički model podatakaERwin nudi mogućnost istovremenog definisanja logičkog i fizičkog nivoa i jednostavno

prebacivanje sa logičkog na fizički pogled na model. Prevodi logički u fizički model, tj. entitet u tabele, atribute u kolone, kao i odgovarajuća ograničenja (slika 20).

Prilikom prevođenja logičkog modela u fizički model, dolazi do sledećih konvertovanja: Entiteta iz modela podataka u tabele fizičke baze podataka; Atributa u kolone u odgovarajućim tabelama; Kandidati za ključeve entiteta postaju primarni ključevi u tabelama; Veze između entiteta postižu da primarni ključevi u tabelama postaju spoljni ključevi

u povezanim tabelama.

21

ERwin definiše tabele i kolone automatski, tj. nazivi tabela se dobijaju na osnovu naziva entiteta, a nazivi atributa po default postaju nazivi kolona. I druge osobine se dodeljuju kao default setovane vrednosti (vrednosti koje će biti insertovane u kolonu).

Slika 20. Fizički model magacinskog poslovanja u ERwin-u

Šema baze podataka obuhvata poseban skup podataka sa odgovarajućom semantikom i vezama među elementima baze podataka. Fizički, ove veze su smeštene u bazi podataka za kasniju upotrebu. Na osnovu fizičkog modela podataka, izvodi se generisanje šeme baze podataka koju čine fizičke tabele, kolone i relacije, koje se u CASE alatu automatski generišu iz fizičkog modela. Dakle, da bi se generisala baza podataka potrebno je izabrati odgovarajuću ciljnu platformu (SUBP) i potom se logovati na nju. Kada se korisnik loguje na izabranu platformu, ERwin kreira aktivnu bidirekcionu vezu sa sistemskim katalogom izabranog servera koja omogućava direktno kreiranje baze podataka.

Proces generisanja šeme baze podataka može se izvesti na dva načina: Direktnim inženjerstvom (forward engineering); Inverznim inženjerstvom (reverse engineering).Proces generisanja šeme baze podataka iz logičkog modela, naziva se direktni inženjering.

Kada se generiše šema baze podataka, entiteti prelaze u tabele, atributi u kolone, a veze u relacije i definišu se referencijalni integritet, trigeri, procedure, indeksi i druge osobine koje podržava izabrani SUBP. Inverzni inženjering predstavlja proces dobijanja fizičkog i logičkog modela iz postojeće fizičke baze podataka. Definisanje fizičkog modela podataka, tj. implementacija entiteta i njihovih atributa u tabele i kolone nekog SUBP, korišćenjem ERwin, relativno je jednostavan proces.

22

5. APLIKATIVNO MODELIRANJE

Izrada aplikacije neposredno je vezana i za klijent/server arhitekturu. U klijent/server arhitekturi definiše se server u kom se nalaze baze podataka i SUBP i klijent - strana gde su definisane klijentove (korisničke) aplikacije, pa se izrada aplikacija izvodi na klijent - strani. Izradom aplikacija MS ACCESS treba da se realizuje korisnički pogled na podatke, tj. da se definišu meniji, forme, upiti i izveštaji.

U Accessu organizacija podataka definiše: Tabele koje su generisane iz ERwin-a kako je u prethodnom tekstu pokazano ili

koristeći osnovne funkcije Accessa za generisanje tabela. Forme koje omogućavaju korisniku predstavljanje podataka iz baze i unos podataka u

bazu. Forme u sebi mogu imati veliki broj drugih objekata (kontrola).Većina SUBP, koji za osnovu imaju MS WINDOWS, podržava tzv. Wizard metodologiju za kreiranje formi.

Upiti koji predstavljaju set zajedničkih komandi i funkcija definisanih ISO standardima za SQL.

Izveštaji koji su izgled postavljenih upita na papirnom mediju. Meniji koji treba da prate scenario odvijanja aktivnosti budućeg korisnika. Za

definisanje menija moraju se koristiti odgovarajuća pravila za strukturisanje kojima se definiše mogući redosled pozivanja operacija.

Access ima tri radna režima: Režim za pokretanje (Startup mode) omogućava da konvertujete, šifrujete, dešifrujete

i popravite podatke iz baze, izborom komandi iz podmenija Database Utilies i Security, menija Tools, pre otvaranja baze podataka. Ove komande su dostupne samo ako baza podataka nije otvorena.

Režim projektovanja (Design mode) omogućava da napravite i modifikujete strukturu tabela i upita, razvijete obrasce za prikaz i uređivanje podataka, kao i da formirate izveštaje za štampanje.

Režim izvršavanja (Run mode) prikazuje dizajn tabela, obrazaca i izveštaja u posebnim prozorima za dokument. Makroe izvršavate tako što jedan od njih izaberete, a zatim izaberete režim izvršavanja.

Na osnovu fizičkog modela podataka, izvodi se generisanje šeme baze podataka koju čine fizičke tabele, kolone i relacije, koje se u CASE alatu automatski generišu iz fizičkog modela.

Na slici 21 prikazana je baza podataka generisana iz ERwin-a u SUBP MS Access2003.

23

Slika 21. Model baze podataka magacinskog poslovanja realizovan u MS ACCESS-u

Kao platformu SUBP izabran je MS ACCESS. Izradom aplikacija MS ACCESS treba da se realizuje korisnički pogled na podatke, tj. da se definišu meniji, forme, upiti i izveštaji.

Na slici 22 je dat prikaz glavnog menija za aplikativni model. Na meniju su ponuđene sve kreirane forme koje omogućavaju lakši unos i pregled podataka u bazu.

Slika 22. Glavni meni transakcione baze podataka

U formi Artikal se vrši unos novog artikla u bazu podataka pri njegovom prijemu tj. unose se svi potrebni podaci za novi artikal (slika 23).

24

Slika 23. Forma Artikal

Radi preglednosti u slučaju više vrsta artikala po magacinima, artikle delimo po grupama i po vrsti jedinice kojom se meri. Na slikama 24 i 25 prikazane su forme grupa artikala i jedinica mera, u njima se vrši unos postojećih grupa artikala i vrsta jedinica mera.

Slika 24. Forma Grupa artikala

25

Slika 25. Forma Jedinica mere

Forma Magacin prikazana na slici 26 vrši unos svih magacina i njihov opis.

Slika 26. Forma Magacin

Na slici 27 prikazana je forma Vrsta promene preko koje se unose sve promene koje mogu da prate jedan artikal.

Slika 27. Forma Vrsta promene

Forma Prijem artikala korisniku omogućava lakši uvid i unos podataka prilikom prijema naručene robe tj. artikala (slika 28).

26

Slika 28. Forma Prijem artikala

Forma Trebovanje artikala omogućava uvid i unos podataka prenesenih i trebovanih artikala (slika 29).

Slika 29. Forma Trebovanje artikala

Stanje magacina predstavlja izveštaj za svaki artikal po magacinima. U njemu je dat prikaz primljene količine, trebovane količine i stanje svakog artikla po magacinima (slika 30).

27

Slika 30. Izveštaj Stanje magacina

28

6. OBJEKTNO ORJENTISANO MODELIRANJE

U zadnjih dvadeset godina, razvojem informatičke industrije, otvorilo se veliko tržište za sposobne i kvalitetne ljude. To je uticalo da se pojavi veliki broj firmi koje se bave izradom programske podrške. Na tržištu su mogle opstati samo one firme koje su se mogle nositi sa zahtevima tržišta. Svi su tražili najbrži i najlakši način da bi svoj proizvod izbacili na tržište pre konkurencije. Podela rada pri razvoju programa, kreiranje plana izrade softvera, zatim plana samog izlaska na tržište, dalo je najbolje rešenje za ostvarivanje cilja programerskih firmi.

UML ili Unified Modeling Language je grafički jezik za vizueliziranje, specificiranje, konstruisanje i dokumentovanje sistema programske podrške koji je postavljen kao standard od OMG-a. Ako malo fleksibilnije želimo to da objasnimo moramo naglasiti da UML nije programski jezik, to je grafički jezik. UML predstavlja kolekciju najboljih uspešnih inženjerskih metoda kojima je pojednostavljeno modelovanje velikih i složenih sistema.

UML je standardizovani jezik za izradu nacrta programa. Razvijen sa ciljem da pojednostavi veliki broj objektno orjentisanih razvojnih metoda.

UML dijagram je grafička prezentacija skupa elemenata. Dijagrami se crtaju kako bi se vizuelizirao sistem iz različitih perspektiva. Za gotovo sve sisteme, osim onih vrlo jednostavnih, dijagrami predstavljaju poboljšani prikaz elemenata koji čine sistem. Isti elementi mogu se pojaviti u svim dijagramima. Teoretski, dijagram može sadržati bilo koju kombinaciju stvari i relacija u modelu.

Međutim, da bi se razumeli za šta služe svi ovi dijagrami i šta oni znače mora se videti od čega se sastoje. UML se sastoji od dva tipa gradivnih blokova i samih dijagrama, elemenata i relacija.

6.1. Elementi (stvari)Elementima (stvarima) modela predstavljaju se standardni objektno orjentisani koncepti

(klase, objekti, poruke).UML ima četiri vrste elemenata: Strukturalne elemente (structural things), Elemente sa ponašanjem (behavioural things), Grupišuće elemente (grouping things), Označavajuće elemente (annotational things).

6.1.1. Strukturalni elementi

Struikturni elementi predstavljaju statičke delove modela i elemente koji su ili konceptualni ili fizički. Osnovni strkturni tipovi su: klasa, interfejs, učesnik, slučaj korišćenja, komponenta i čvor.

Klasa predstavlja skup objekata koji dele iste atribute, operacije, relacije i semantiku (slika 31).

29

Slika 31. Klasa

Interfejs (interface) je kolekcija operacija koja specifira usluge neke klase ili komponente (slika 32). To je skup poruka koji se može poslati klasi i ne uključuje implementaciju tih operacija. Interfejs se označava krugom i njegovim imenom, nikada neće biti sam već će biti vezan uz neku klasu ili komponentu koja ga realizuje.

Slika 32. Interfejs

Učesnik (actor) je spoljašnji krajnji korisnik (slika 33).

Slika 33. Učesnik

Slučaj korišćenja (use case) prikazuje jednu funkciju sistema kako je vidi spoljašnji učesnik (slika 34). To je skup sukcesivnih događaja koje sistem izvodi kako bi dobio neki rezultat.

Slika 34. Slučaj korišćenja

6.1.2. Elementi ponašanja

Ovaj skup elemenata predstavlja dinamički deo UML modela. Postoje samo dva primarna tipa stvari ponašanja. To su interakcija i automat stanja.

Interakcija (interaction) je ponašanje koje uključuje skup poruka koje se razmenjuju između objekata (slika 35). Interakcija uključuje i brojne druge elemente kao što su poruke, redosledi akcija (ponašanje pokrenuto porukom) i veze između objekata. Grafički, poruka je predstavljena kao linija sa strelicom u jednom smeru i najčešće uključuje i ime operacije.

Slika 35. Interakcija

30

Automat stanja (state machine) je ponašanje koje opisuje niz stanja kroz koja prolazi objekt ili interakcija u toku svog života (slika 36). Stanje se grafički predstavlja pravougaonikom zaobljenih temena.

Slika 36. Automat stanja

6.2. Relacije UML ima tri osnovne vrste relacija: Zavisnosti (dependency) Asocijacije (association) Generalizacije (generalization) Zavisnost je semantička relacija između dva elementa u kojoj promena jednog

(nezavisnog) elementa može da utiče na semantiku drugog (zavisnog) elementa (slika 37).

Slika 37. Zavisnost

Asocijacija je strukturalna veza koja opisuje vezu između objekata (slika 38). Poseban slučaj asocijacije je agregacija (slika 39), koja predstavlja strukturnu vezu celine i njenih delova.

Slika 38. Asocijacija

Slika 39. Agregacija

Generalizacija (generalization), je relacija specijalizacije/generalizacije u kojoj objekti specijalizovanih elemenata (deca) se mogu zameniti objektima generalizovanih elemenata (roditelja). Na ovaj način, deca dele strukturu ponašanja roditelja. Grafički, relacija generalizacije se prikazuje kao puna linija sa šupljom strelicom koja pokazuje prema roditelju (slika 40).

Slika 40. Generalizacija

6.3. Objektno modeliranjeU vreme kada poslovanje postaje sve više automatizovano – kada kompjuteri odrađuju

sve više posla, razumeti procese poslovanja, može biti ključ uspeha. Način poslovanja stalno se menja i evoluira i postaje sve kompleksniji. S informatičke tačke gledišta, primena objektnog modeliranja, odnosno vizuelno modeliranje procesa poslovanja predstavlja način da se stekne uvid u način poslovanja onakav kakav on jeste, sa ciljem njegovog daljeg unapređenja i poboljšanja. Vizuelno modeliranje povećava efikasnost rada i omogućuje brže i lakše shvatanje velikih procesa i struktura.

31

Za objektno modeliranje poslovnih procesa koristi se UML (Unified Modeling Language) standard, a cilj je napraviti dobar poslovni model koji će poslužiti kao osnova za razvoj softvera poslovne inteligencije. Ovakav pristup kao rezultat daje opšti model dizajna i nezavistan je od programskih jezika ili softverskih platformi na kojima će se informacioni sistem kasnije implementirati. Objektno orjentisani principi omogućuju da se implementacijom dodatnih funkcionalnosti dopunjuju, a ne značajno menjaju arhitektura i model softvera.

6.3.1. Dijagrami poslovnih slučajeva upotrebe

Dijagrami poslovnih slučajeva upotrebe su dijagrami koji po UML standardu sadrže: Objekte (poslovni učesnici i poslovni slučajevi upotrebe) i Veze.Poslovni učesnik (Bussiness Actor) pokreće poslovne slučajeve upotrebe (Bussiness Use -

Case) preko veze koja se prikazuje asocijacijom (koja može da se dodatno opiše asocijativnim nazivom) tipa "u interakciji je sa" ili "naređuje" (slika 41).

Poslovni ucesnik Poslovni skucaj upotrebe

Asocijativni naziv

Slika 41. Grafički prikaz poslovnih slučajeva upotrebe

Dijagram poslovnih aktivnosti definiše se za samo jednog poslovnog učesnika koji ima naredbodavnu ulogu.

U okviru dijagrama poslovnih aktivnosti izdvajaju se aktivnosti koje će biti opisane kroz sistemske slučajeve upotrebe i sistemske dijagrame aktivnosti.

Svrha opisa poslovnih slučajeva upotrebe je definisanje prioriteta za izvršavanje grupa logičkih zahteva i određivanje nivoa prioriteta baziranih na važnosti identifikovanog opsega projekta. Razmatraće se dijagram poslovnih slučajeva upotrebe za sledeće poslovne slučajeve upotrebe, nastale preslikavanjem poslovnih procesa definisanih u okviru funkcionalnog modela, i to za magacinsko poslovanje.

Poslovni učesnici koji su predmet modela poslovnih slučajeva upotrebe su: Šef magacinske službe i tim magacinske službe.

Poslovni slučaj upotrebe za magacinsko poslovanje u daljem tekstu opisaće se pomoću poslovnog dijagrama aktivnosti.

6.3.2. Izrada dijagrama poslovnih aktivnosti za poslovni slučaj magacinskog poslovanja

Na osnovu analize, mogu se definisati grupe aktivnosti poslova MAG poslovanja (slika 42). Te grupe poslova su:

Označavanje MAG-a Izrada dokumenata Izrada izveštaja.Na osnovu dobijenog plana šef magacinske službe izvodi aktivnost označavanja i

skladištenja artikala u magacin.Aktivnost izrada dokumenata obavlja tim magacinske službe koji prikuplja dokumenta iz

magacina.Prikupljena dokumenta šeg magacinske službe koristi za analizu i izveštaje.

32

Analiza stanja je predmet naših daljih razmatranja i izvodi se zbog potrebe analize zaliha po magacinima po vremenskim intervalima.

Slika 42. Dijagram poslovnih aktivnosti magacinskog poslovanja

6.3.3. Model sistemskih slučajeva upotrebe

Model sistemskih slučajeva upotrebe predstavlja: Atomsku transakciju, jer po njegovom završetku informacioni sistem ostaje u

konzistentnom stacionarnom stanju, i Logičku jedinicu posla u realnom vremenu, nešto što ima značenje za korisnika, bez

obzira na njegovu složenost.Dijagrami slučajeva (slika 43) upotrebe su dijagrami koji po UML standardu sadrže:

objekte (učesnici i slučajevi upotrebe), i veze.Učesnik (Actor) učestvuje u slučajevima upotrebe (Use-Case) preko veze koja se

prikazuje asocijacijom (koja može da se dodatno opiše asocijativnim nazivom) tipa "u interakciji je sa" ili "interakciji".

Slika 43. Dijagram sistemskih slučajeva upotrebe

6.4. Izrada modela sistemskih slučajeva upotrebeNa osnovu izrađenog modela poslovnih slučajeva upotrebe u kojima su specificirani u

dijagrami aktivnosti koji opisuju pojedine poslovne slučajeve upotrebe, sačinjen je model sistemskih slučajeva upotrebe uz ograničenja definisana predmetom ovog rada. Sistemski slučajevi upotrebe omogućavaju grubi opis dinamike aktivnosti budućeg rada rukovodstva, tj. šefa magacinske službe kao što se vidi na slici ispod (slika 44).

Slika 44. Sistemski slučaj upotrebe

33

Sistemski slučaj upotrebe sugeriše način na koji će se šef magacinske službe nalaziti u interakciji sa budućim softverskim rešenjem, tj. moraju se predvideti događaji koje će sistemski učesnik u liku šefa magacinske službe generisati.

Sistemski učesnik koji izvodi analize je šef magacinske službe. Identifikovan je kao korisnik funkcionalnosti sistema, koji će imati podršku sistema u obavljanju dnevnih zadataka i zainteresovan je za rezultate koje sistem proizvodi.

Sistemski učesnik šef magacinske službe komunicira sa sistemskim slučajevima upotrebe kao što je pokazano na prethodnoj slici.

6.5. Izrada konceptualnog modelaKonceptualni model definiše se za sistemske slučajeve upotrebe i predstavlja osnovu za

izvođenje sledećih koraka kako za izradu dijagrama interakcije tako i za pripremu podataka za analitičko procesiranje informacija i dimenziono modeliranje gde će pretrpeti korekcije i dopune.

Postavljen je koncept za sistemski slučaj upotrebe magacinskog poslovanja.Na osnovu prikupljenih izvornih zahteva definisanih, i na osnovu potreba za izradom

skladišta podataka, izdvojeni su koncepti kojima se definišu činjenice i koncepti kojima se definišu dimenzije. Na slici 45 prikazan je koncept navedenog slučaja upotrebe. Za svaki od njih definisani su koncepti činjenica i dimenzija i uspostavljene relacije između njih na osnovu transakcionih modela podataka.

Koncept kojim se definišu činjenice je Dokument, koji u sebi sadrži broj dokumenta i količinu.

Koncepti kojima se definišu dimenzije su: Artikli, koji u sebi sadrže šifru artikla, naziv artikla i grupu, Magacin, koji u sebi sadrži naziv, šifru i mesto magacina, Vrsta promene, koja u sebi sadrži broj promene (VK) i opis promene, Vreme, koja u sebi sadrži mesec, kvartal, polugodišta i godine.

Slika 45. Konceptualni model analize magacinskog poslovanja

34

7. SKLADIŠTA PODATAKA

Analitički sistemi su sistemi koji obezbeđuju informacije koje se koriste za analizu problema ili situacija. Za analitičke sisteme razvijaju se analitičke baze podataka. Analitičke baze podataka ne sadrže ažurirane podatke, već čuvaju informacije iz određenog trenutka vremena. Takvi podaci su od značaja za poređenja i analizu trendova.

Analitička baza podataka odnosno skladište podataka (Data Warehouse-DW), ima osnovnu namenu izveštavanje korišćenjem transakcionih podataka, istorijskih podataka, kao i podataka iz drugih sistema.

Skladištenje podataka - DW je proces integracije podataka u jedan repozitorijum iz kojeg krajnji korisnici mogu sprovoditi ad - hock analize podataka i praviti izveštaje.

Warehousing koncept je skladištenje agregiranih, ekstrahovanih i filtriranih podataka u meta baze, koje omogućavaju slojevit, multidimenzionalni pristup podacima, kakav je potreban za donošenje odluka najvišeg strateškog nivoa.

Skladište podataka je ulazna baza podataka dizajnirana za podršku jedne ili više klasa analitičkih zadataka, kao što su nadgledanje i izveštavanje, analiza i dijagnoza i simulacija i planiranje.

Osnovni cilj skladištenja podataka je prikupljanje i distribucija informacija kroz preduzeće, tj. korišćenje bilo koje informacije, sa bilo kog mesta, u bilo koje vreme, tačnije ostvarenje principa „Biti uvek na usluzi korisniku informacija“.

Cilj skladištenja podataka nije da se podaci samo skladište, već je cilj da menadžeri mogu sami da vrše analize. Čak i u svetu uspešnih menadžera postoje ljudi koji nisu tehnički obrazovani, a imaju potrebu za informacijama i ne znaju da programiraju.

Skladište podataka je arhitektura za organizovanje informacionih sistema. Sastoji se od skupa programa koji vrše ekstrakciju podataka iz transakcionih sistema, baze podataka u koju se smeštaju podaci i sistema koji obezbeđuju podatke korisnicima (slika 46).

35

Slika 46. Osnovna arhitektura skladišta podataka

7.1. Dimenziono modeliranjePri izgradnji skladišta podataka najbitniji su sami podaci, a ne poslovni procesi i funkcije,

kao što je to slučaj sa transakcionim sistemima (slika 47). Za razvoj skladišta podataka potrebno je: izvršiti analizu izvora podataka, pripremiti podatke, izgraditi skladište podataka.Izgradnja skladišta podataka nije samo prosto kopiranje podataka i prepuštanje korisnika

alatima za podršku odlučivanju već pretstavlja i restrukturiranje podataka denormalizacijom tabela, čišćenjem podataka od redundansi, nelogičnosti i dodavanjem novih polja i ključeva radi zadovoljenja korisnikovih potreba za sortiranjem, kombinovanjem i sumiranjem podataka.

Slika 47. Razvoj skladišta podataka

Prvi korak je identifikacija dimenzija i atributa koja podseća na klasično projektovanje upotrebom ER modela i zove se dimenziono modeliranje.

Dimenziono modeliranje je tehnika logičkog dizajna čiji je cilj prezentacija podataka u obliku koji obezbeđuje visoke performanse sistema radi vršenja analize podataka.

U dimenzionom modeliranju, strukture podataka su tako organizovane da opisuju mere i dimenzije.

Mere su numerički podaci smešteni u centralnoj, takozvanoj tabeli činjenica (fakt tabela).

Dimenzije su standardni poslovni parametri koji definišu svaku transakciju.Osnovu za izradu dimenzionog modela predstavljaju meta podaci, na osnovu kojih se vrši

definisanje hijerarhija, elemenata i atributa, normalizacija i denormalizacija i definisanje agregacija.

Svaka dimenziona tabela ima svoj primarni ključ, a svi oni učestvuju u stvaranju primarnog ključa tabele činjenica. Ovakvi modeli se nazivaju šemama zvezde.

36

Tabele činjenica sadrže podatke koji su, najčešće, numeričkog tipa i mogu sadržati veliki broj zapisa.

Slika 48. Primeri dvodimenzionih i trodimenzionih modela podataka

Kao što se vidi na slici 48 u slučaju pod a) podaci o prodaji za svaku oblast se nalaze u različitim tabelama, dok su u slučaju pod b) svi podaci smešteni u trodimenzioni niz.

Iako su podaci sačuvani samo jednom i to na jednom mestu, svaki korisnik može dobiti različite poglede na jedne iste podatke. Jedan od primera dat je na slici 49.

Slika 49. Različiti pogledi na iste podatke

Sve dimenzione tabele su denormalizovane, što znači da se isti podaci čuvaju na više mesta da bi se obezbedila jednostavnost i poboljšale performanse. Primer normalizovane i denormalizovane reprezentacije podataka dat je na slici 50.

37

Slika 50. Različiti načini reprezentacije podataka

Izgradnja skladišta podataka se sastoji od sledećih zadataka: denormalizacija podataka, definisanje hijerarhija, kreiranje agregacija, kreiranje fizičkog modela, generisanje baze podataka, učitavanje podataka.

7.1.1. Denormalizacija podataka

U zavisnosti od predstave dimenzija na modelu, govorimo o normalizovanom ili denormalizovanom modelu.

Slika 51. Šeme zvezde, pahulje i galaksije

Kod denormalizovanog modela dimenzije su ogranizovane u šemu zvezde, a kod normalizovanog u šemu snežne pahuljice (slika 51).

Postoji situacije u kojima šema zvezde nije pogodna za skladište podataka. Osnovni razlozi za to su:

Denormalizovana šema zvezde može zahtevati previše memorijskog kapaciteta, Veoma velike dimenzione tabele mogu uticati na pad performansi sistema.

38

Ovi problemi se mogu rešiti normalizacijom dimenzija. Time se šema zvezde prevodi u šemu pahulje. Glavni nedostatak šeme pahulje je njena složenost u odnosu na šemu zvezde, čime se otežava održavanje skladišta podataka. Zato je potrebno vršiti normalizaciju samo onih dimenzija koje sadrže mnogo redova podataka i koje imaju mnogo atributa.

Osnovna karakteristika šeme pahulje jeste da se ne vrši denormalizacija tabela, čime se poboljšavaju performanse sistema.

Šema galaksije predstavlja kolekciju šema zvezde, tj. ako se ne može kreirati model koji bi imao samo jednu činjeničku tabelu, tada je potrebno povezati dve šeme zvezde da bi se zadovoljile potrebe korisnika.

Fizička arhitektura dimenzionog modela opisana je pomoću šeme zvezde definisane sa dve vrste tabela – dimenzione tabele (dimension table) i tabele činjenica (fact table).

Tabela činjenica sadrži kvantitativne podatke o poslovima koji opisuju specifične događaje u poslovanju, kao što su bankarske transakcije ili prodaja proizvoda, a koje korisnici analiziraju. Može sadržati i agregirane podatke, kao što je npr. mesečna prodaja. Ovi podaci su najčešće numeričkog tipa i mogu se sastojati i od nekoliko miliona redova i kolona.

Dimenzione tabele su znatno manje i sadrže podatke koji opisuju dati posao, tj. one podatke po kojima se vrši analiziranje. Ti podaci se nazivaju atributi.

Osnovne prednosti šeme zvezde su što omogućava definisanje složenih višedimenzionih podataka u vidu jednostavnog modela, smanjuje broj fizičkih veza koje se moraju procesirati pri zadavanju upita, čime se postiže poboljšanje performansi sistema i omogućava proširenje skladišta podataka uz relativno jednostavno održavanje.

Velika mana šeme zvezde je što se povećava redundantnost podataka.Svaka tabela mora sadržati primarni ključ čiji sadržaj jedinstveno identifikuje zapise. Na sledećoj slici prikazana je šema zvezde za magacinsko poslovanje (dokumenta –

prijemnica i trebovanje). Primarni ključ tabele činjenica je sastavljen od četiri spoljna ključa i jednog primarnog ključa. Spoljni ključ je kolona jedne tabele, čija je vrednost definisana kao primarni ključ druge tabele (slika 52).

Slika 52. Šema zvezde za magacinsko poslovanje

39

7.1.2. Definisanje hijerarhija

Dimenzione tabele memorišu sledeće elemente: traženje hijerarhijskih relacija u svakoj dimenziji, definisanje opisnih atributa svake dimenzije.Dimenzije veoma često mogu biti organizovane u hijerarhiji. Na primer, kod dimenzije

proizvod, mogu postojati tri dimenziona elementa: prozvod, grupa i vrsta proizvoda. U ovom modelu možemo reći da dimenzioni element "proizvod" predstavlja najniži hijerarhijski nivo u dimenziji proizvod, dok vrsta proizvoda predstavlja najviši nivo.

Posmatranje podataka iz različitih, ali blisko povezanih perspektiva omogućava da korisnik analizira podatke na različitim nivoima detalja.

Drill-down - Postupak prelaska sa nivoa sa manjim brojem detalja na nivo sa većim brojem detalja naziva se spuštanje u dubinu (drill down) i predstavlja zahtev korisnika da mu se prikaže više detalja. Na primer, pošto se pronađe podatak o prodaji nekog regiona, spušta se naniže da bi se saznalo kako se prodaja odvija po opštinama.

Drill-up - Postupak prelaska sa nivoa sa većim brojem detalja na nivo sa manjim brojem detalja, na tzv. sumarne podatke, naziva se dizanje naviše (drill up). Na primer, upit bi mogao prezentovati prodaju u odnosu na neke regione.

Drill across - koristi se za povezivanje dve ili više činjeničnih tabela na istom nivou hijerarhije.

7.1.3. Kreiranje agregacije

Agregacijama se sumiraju detalji podataka i smeštaju u posebne tabele. Ove tabele se koriste od strane aplikacija da bi se eliminisala potreba da se ponovo vrše proračuni koji bi se inače morali sprovesti ako ove tabele ne bi postojale.

Glavni razlozi kreiranja agregacija su da se poboljšaju performanse upita, tj. da se smanji vreme odziva na upit, kao i da se smanji broj resursa potrebnih za izvršenje upita.

Jedan od načina na koji se mogu kreirati agregacije jeste korišćenje SQL naredbi. Iako ovaj način nije najbolji po pitanju performansi sistema, on je najjednostavniji.

U slučaju kreiranja agregacija koje nisu zasnovane na SQL naredbama, potrebno je razviti specijalizovane programe, što usložnjava procese razvoja i održavanja skladišta podataka.

Na primer, ako se izvrši sortiranje redova podataka po dimenziji Vreme, u tabeli će se prvo nalaziti redovi podataka koji se odnose na Dan, iza njih će biti redovi podataka koji se odnose na Nedelju itd. Zatim se na svakom mestu prelaza sa jednog nivoa dimenzije na drugi (na primer, sa Dana na Nedelju) kreiraju podzbirovi za taj nivo dimenzije. Pri tome je moguće iskoristiti prednosti paralelnog procesiranja jer su podaci podeljeni po grupama (jedan proces može računati podzbirove vezane za nivo Dan, a drugi za nivo Nedelja). Tako dobijene podzbirove treba učitati i izvršiti agregaciju. Time je proces agregacije podataka završen.

7.1.4.Kreiranje fizičkog modela

U okviru kreiranja fizičkog modela baze podataka, izvodi se postupak prevođenja logičkog modela u fizički model prikazan preko dijagrama entiteti – veze koji fokusira podatke. Fizički model za potrebe našeg skladišta podataka biće orjentisan relacionim bazama podataka i koristiće se za kreiranje šeme baze podataka.

Za kreiranje fizičkog modela koristiće se CASE alat ERWin, koji omogućava ostvarivanje veze između konceptualnog, dimenzionog i fizičkog modela.

40

Referencijalni integritet se reflektuje kao postojanje prenesenog ključa u nekoj tabeli. Tamo gde se nalazi preneseni ključ, postoji “ciljna tabela”, a tamo gde je definisan primarni ključ, nalazi se “izvorna” tabela. Referencijalni integritet tabele zahteva da unesena vrednost atributa odgovara vrednosti atributa koji je primarni ključ druge tabele. Referencijalni integritet se definiše za operacije ubacivanja, brisanja i ažuriranja.

Kreiranje indeksa je izvršeno automatski za sve primarne ključeve u entitetima i za prenesene ključeve u entitetu.

7.1.5.Generisanje baze podataka

ERwin omogućava automatsko generisanje koda preko tzv. DDL (Data Definition Language) datoteka.

Prilikom generisanja baze mora se doneti odluka o načinu mapiranja operacija koje će biti na raspolaganju u okviru fizičke baze podataka.

Kada se ovi poslovi uspešno urade, baza (skladište) podataka je generisana.

7.1.6. Učitavanje podataka

ETL je skup procesa koji ima za cilj vađenje (engl. Extract), preoblikovanje (engl. Transform) i punjenje (engl. Load) podataka iz jednog ili više transakcijskih sistema u skladište podataka (slika 53).

Pre samog početka ETL procesa potrebno je izvršiti pripremne aktivnosti: reformatiranje, usklađivanje i čišćenje podataka. Podaci u stvarnom svetu su nekompletni (nedostaju vrednosti atributa, tačne vrednosti važnih atributa, ili postoje samo agregirani podaci), neprecizni (greške, ili autlejeri), nekonzistentni (neslaganje u imenima ili šiframa). Izvorne podatke, dopremljene iz različitih datoteka i baza podataka je potrebno unificirati, odnosno prikazati u jedinstvenom formatu. U takvim formatima podaci će se koristiti u svim daljim fazama obrade. Usklađivanje podataka se sprovodi da bi se izbegla redundansa podataka. Čišćenje kao pripremna aktivnost ETL procesa ima zadatak da ukloni one podatke koji se pojavljuju kao posledica ranijih grešaka u radu informacionih sistema.

Slika 53. ETL procesi

Za pronalaženje odgovarajućih podataka u bazi mogu se koristiti tabele, ali je to često veoma zamoran posao. Umesto toga koriste se upiti pomoću kojih se željeni podaci mogu pronaći zadavanjem odgovarajućih uslova.

Append query (slike 54 i 55) pripada Action upitima i u radu je korišćen za prebacivanje podataka iz relacione baze u skladište. Za svaku posebno tabelu napravljen je poseban upit za prebacivanje. Prvo se pokreću upiti za prebacivanje podataka za artikal, magacin, vrstu promene, vreme i dokument. Sa naglaskom na to da su za tabele vreme i dokument kreirana po dva upita za prijem i trebovanje.

41

Slika 54. Upiti za unos podataka iz transakcione baze

Slika 55. Upit za unos podataka iz transakcione baze za artikal

7.2. Analitički OLAP sistemiInteraktivno analitičko procesiranje (On Line Analytical Processing - OLAP) namenjeno

je on line analizama i izveštajima, za razliku od produkcionih sistema namenjenih ažuriranju baza podataka i obradi transakcija (On Line Transaction Processing - OLTP).

Postavlja se pitanje: šta je to krajnjem korisniku potrebno? Ono što krajnjem korisniku treba je sledeće:

Da može da postavi bilo koje poslovno pitanje, Da bilo koji podatak iz preduzeća koristi za analizu, Mogućnost neograničenog izveštavanja.U tu svrhu se koriste analitički OLAP sistemi koji obezbeđuju informacije koje se koriste

za analizu problema ili situacija.

42

OLAP sistemi omogućavaju jednostavnu sintezu, analizu i konsolidaciju (agregacija podataka po zadatom kriterijumu) podataka. Koriste se za intuitivnu, brzu i fleksibilnu manipulaciju transakcionim podacima. OLAP sistemi podržavaju kompleksne analize koje sprovode analitičari i omogućavaju analizu podataka iz različitih perspektiva (poslovnih dimenzija).

OLAP sistemi kao skladišta podataka koriste multidimenzionalnost i denormalizaciju i može se reći da predstavljaju nadgradnju skladišta podataka.

Osnovni elementi OLAP sistema su: baza podataka, koja služi kao osnova za analizu, OLAP server, za upravljanje i manipulaciju podacima, interfejs sistem, prema korisniku i prema drugim aplikacijama, alati za administriranje.Za korišćenje OLAP složene procedure potrebno je transakcione podatke prebaciti u

posebnu bazu podataka.OLAP pristup mora od hardvera da poseduje poseban računar, tzv. OLAP server, na koji

se povezuju relacione baze podataka, eksterni izvori podataka i ostali interni podaci, koji su podržani grafičkim interfejsima, radnim tabelama i ostalim PC alatima.

OLAP serveri koriste višedimenzione strukture za čuvanje podataka i veza između njih. Višedimenzione strukture se najbolje vizuelizuju kao kocke podataka i kao kocke u kockama podataka. Svaka strana kocke se naziva dimenzijom. Dimenzija predstavlja kategoriju podataka, kao što su tip proizvoda, region, vreme itd. Svaka ćelija kocke sadrži agregirane podatke koji su u vezi sa dimenzijama. Na primer, jedna ćelija može sadržati podatke o ukupnoj prodaji za dati proizvod i region u toku jednog meseca.

OLAP serveri podržavaju tipične analitičke operacije: konsolidacija – ovom operacijom se vrši agregacija podataka po zadatom kriterijumu, drill down/up – ove operacije omogućavaju prikazivanje više ili manje detalja

podataka, isecanje (slice & dice) – ove operacije obezbeđuju prikazivanje podataka iz različitih

perspektiva, pri čemu se isecanje najčešće vrši po vremenskoj dimenziji da bi se analizirali trendovi (na primer, jedan isečak kocke može prikazivati sve podatke o prodaji za zadati tip proizvoda za sve regione, a drugi isečak može prikazivati sve podatke o prodaji po kanalima za svaki tip proizvoda).

Još jedna karakteristika OLAP servera jeste ta što oni smeštaju podatke u sabijenom, zgusnutom obliku. Ovo se postiže dinamičkom selekcijom tehnika za kompresiju podataka da bi se što bolje iskoristili prostori za čuvanje podataka. Retko popunjene matrice se čuvaju odvojeno od dosta popunjenih matrica. Na ovaj način OLAP serveri minimizuju zahteve za čuvanje podataka.

Interfejs OLAP sistema treba da omogući korisniku komforan rad, samostalno izvođenje analitičkih operacija i dobijanje pregleda i poslovne grafike, bez znanja programiranja i strukture baze podataka.

Zahtevi koje OLAP mora da ispuni su: mogućnost rada sa velikim skupom podataka i velikim brojem korisnika, kratko vreme odziva na upit, mogućnost rada sa podacima sa različitim nivoima detalja, sposobnost proračuna složenih matematičkih funkcija, podrška za šta - ako analizu, modelovanje i planiranje, jednostavnost uvođenja i održavanja sistema,

43

zaštita podataka, mogućnost rada sa velikim brojema alata pomoću kojih će se pristupati podacima,

vršiti analiza i prikazivati podaci.

7.3. Arhitekture OLAP sistemaNeki od OLAP alata fizički prenose sve povezane transakcione podatke iz relacione baze

podataka i iz drugih izvora u višedimenzionalnu bazu podataka, koristeći meta nivo, i puni skladište preko noći (batch pristup), tj. izvode kompletno obnavljanje podataka u određenim vremenskim intervalima.

Drugi pristup, tzv. On - line, prenosi svaku pojedinačnu izmenu relacione u višedimenzionu bazu podataka, tj. izvodi se ažuriranje skladišta samo onim podacima koji su se izmenili između dva intervala ažuriranja.

Ova dva pristupa uslovila su pojavu i dve osnovne arhitekture, tzv. multidimenzioni OLAP (MOLAP) i relacioni OLAP (ROLAP). MOLAP je rešenje kada se koriste multidimenzione baze podataka, a ROLAP nastaje kao nadgradnja relacionih baza podataka.

Dakle, postoje sledeće arhitekture OLAP sistema: Višedimenzioni OLAP (MOLAP), Relacioni OLAP (ROLAP), Hibridni OLAP (HOLAP).MOLAP i ROLAP se razlikuju po načinu čuvanja podataka. Kod MOLAP sistema podaci

se čuvaju u višedimenzionoj strukturi, a u slučaju ROLAP sistema podaci se čuvaju u relacionim bazama podataka.

7.3.1 Višedimenzioni OLAP (MOLAP)

Ovaj način realizacije OLAP-a predstavlja tradicionalni način OLAP analize. Podaci koji su predmet analize, nalaze se smešteni izvan relacione baze podataka, organizovani u OLAP kocku, u formatima koji su prilagođeni potrebi analize.

MOLAP se karakteriše odličnim performansama, sposobnošću izvršavanja izuzetno složenih kalkulacija (koje su deo same kocke podataka).

Nasuprot dobrim svojstvima, ovaj način organizacije negativne strane ima prema ograničenoj količini podataka koji čine kocku. Ograničenje nije uslovljeno brojem podataka od kojih je kocka formirana, nego činjenicom da su podaci izvučeni iz transakcione baze podataka i da su zapravo u kocki podaci statični. Osvežavanje podataka u kocki novim podacima podrazumeva novo formiranje kocke. Ukoliko je skup podataka veliki, a tipično to i jeste, tada formiranje kocke može da bude operacija koja traži vreme.

7.3.2. Relacini OLAP (ROLAP)

ROLAP arhitektura zasniva se na relacionim bazama podataka, na ugrađena svojstva koja se već nalaze u RDBMS rešenju, koje je već deo svakodnevnog života kompanije. Podaci za analizu su dostupni neprekidno, ažurirani podaci odmah mogu da budu predmet analize u OLAP stilu. Sve što je deo relacionog pristupa podacima, ujedno stoji i na raspolaganju OLAP analizama.

Međutim, RDBMS je opterećen svojim primarnim zadatkom, servisiranjem transakcionih zahteva pa OLAP upiti nemaju maksimalni prioritet. Po svojoj prirodi, OLAP upiti moraju da budu vrlo zahtevni pa stoga performanse sistema mogu znatno da opadnu ukoliko se na pravilan način ne administrira pravo korišćenja OLAP alata. Ova okolnost deo novih zadataka prenosi na

44

RDBMS administratore koji po svojoj prirodi i ne moraju da budu OLAP orjentisani. Svaki database administrator veću važnost pridavaće zaštiti resursa sistema pre nego ugodnom ambijentu za neke analitičare koje svašta zanima. Skup kalkulacija koji stoji na raspolaganju OLAP analitičarima neminovno je ograničen mogućnostima koje je proizvođač RDBMS pružio za OLAP svet. Nadograđivanje OLAP mogućnosti nabavkom drugih proizvođača može da proizvede troškove koji često mogu da budu i nepredvidivo visoki.

7.3.3. Hibridni OLAP (HOLAP)

Hibridni OLAP ujedinjuje najbolje osobine MOLAP-a i ROLAP-a. Da bi omogućio dobre performanse, ovaj pristup formira kocke podataka. Brzina se postiže na prihvatljivom nivou. Kada je neophodno da se vrši detaljan uvid u podatke, tada se koriste mehanizmi RDBMS. Pad performansi u ovom slučaju je očekivan pa se različitim tehnikama pokušava optimizovati rad sistema.

7.4. Kreiranje OLAP kocki u Microsoft Query-juKreiranje OLAP kocki korišćenjem Cube Wizard-a integrisanog u Microsoft Query vrši

se na osnovu prethodno definisanih upita nad skladištem podataka. Proces kreiranja kocke se odvija kroz sledeće korake:

1. Po startovanju MS Query-ja izabere se tip baze podataka (MS ACCESS) i pronađe odgovarajuća baza podataka (u našem slučaju skladiste.mdb - slika 56).

Slika 56. Izbor tipa baze podataka

Na osnovu prikazanih tabela biraju se kolone, kao što je prikazano na slici 57.

45

Slika 57. MS Query izbor kolona

2. Pritiskom na tipku Next prikazuje se MS Query upit i bira opcija Create OLAP Cube (slika 58).

Slika 58. Opcija Create OLAP Cube

3. Ovo je prvi korak u formiranju OLAP Cube gde se odrađuju polja koja formiraju sumarne podatke i matematičke operacije koje će se izvršiti nad tim poljima (slika 59). Polja koja se ne koriste za sumarne podatke predstavljaju kandidate za dimenzije kocke.

Slika 59. Izbor polja sumarnih podataka

46

4. Definisanje dimenzija OLAP kocke – izbor između preostalih polja (kandidata za dimenzije) onih koja će formirati dimenzije kocke (slika 60). U ovom koraku se vrši i formiranje hijerarhije dimenzija. Hijerarhija dimenzija treba da omogući više nivoa detaljnosti, u zavisnosti od potreba korisnika u procesu analize podataka.

Slika 60. Formiranje dimenzija OLAP kocke

5. Snimanje fajla kocke na disk računara – u trećem koraku se bira mesto snimanja OLAP kocke kao fajla na disk računara, što se vidi na slici 61.

Slika 61. Izbor mesta snimanja OLAP kocke

Na osnovu ovako generisane OLAP kocke, posredstvom Microsoft Excel-a, vrši se kreiranje pivot tabele za pristup podacima koje ta kocka sadrži.

47

8. ANALIZA PODATAKA MAGACINSKOG POSLOVANJA

Analiza podataka organizovanih u OLAP kocke može da se vrši korišćenjem PivotTable (dinamička tabela sa objedinjenim podacima iz neke baze podataka) servisa koji omogućava pristup podacima u OLAP kockama. Na slici 62 su prikazana dva načina pristupa podacima u OLAP kockama, korišćenjem Microsoft Excel-a ili izradom posebne aplikacije, primenom tzv. ADO mehanizama.

Slika 62. Pristup OLAP kockama

U našem slučaju korišćen je Microsoft Excel jer je to alat čija je osnovna namena analiza podataka (Microsoft klasifikacija). Analiza podataka organizovanih u OLAP kocke u Excel-u se vrši izradom tzv. pivot tabela. Microsoft Excel omogućava i vršenje analiza korišćenjem dodatnih alata, koji su njegov sastavni deo. Korisnik ima mogućnost da direktno iz Excel-a vrši štampanje izveštaja za određeni pogled na podatke (izabrani nivoi detaljnosti i raspored dimenzija).

Pivot tabela predstavlja dinamičku tabelu sa objedinjenim podacima iz neke baze podataka. Ona služi za tabelarno prikazivanje više vrsta podataka. U okviru nje se sumarni podaci mogu prikazivati na bilo kom nivou detaljnosti. Za potrebe izrade pivot tabela, u Microsoft Excel-u postoji čarobnjak (PivotTable Wizard). Sam postupak izrade se odvija u sledećim koracima:

1. Određivanje lokacije podataka (slika 63) – da bismo pristupili prethodno generisanim OLAP kockama, bira se opcija spoljni izvor podataka (External data source).

48

Slika 63. Određivanje lokacije podataka

2. Povezivanje sa spoljnim izvorom podataka – bira se opcija OLAP Cubes i u okviru nje se bira kocka na osnovu koje formiramo pivot tabelu (slika 64).

Slika 64. Izbor OLAP kocke

3. Formiranje pivot tabele – sa prozora PivotTable Fild vrši se prevlačenje polja (dimenzija i sumarnih podataka) na odgovarajuća mesta u pivot tabeli (polja, strane, reda i kolone). Formirana pivot tabela je prikazana na slici 65.

49

Slika 65. Formiranje pivot tabele

Grafički prikaz pivot tabele prikazan je na slici 66. Ovaj grafik omogućava prikaz količine odabranih artikala po vrstama promene za sve magacine u periodu od godinu dana, tj. za 2009 godinu. Odabrana su tri artikla (cipele radne, elektroda evb.50 2.5 mm i gips alabaster) na kojima se vrši analiza po kvartalima i po vrstama promene.

Slika 66. Grafik Pivot tabele

Na slici 67 je dat prikaz količine artikala po svim vrstama promene za prvi kvartal 2009 godine. U ovom periodu svaki od odabranih artikala imao je bar po jednu promenu. Na osnovu grafika vidi se da je količina cipela radnih prisutna na stanju za naredni vremenski period, kao i količina gips alabastera, dok je količina elektroda evb.50 2.5 mm utrošena u vremenskom periodu za prvi kvartal 2009 godine.

50

Slika 67. Količine artikala po vrstama promene za prvi kvartal

U drugom kvartalu na slici 68 primećuje se da su artikli cipele radne i gips alabaster prisutni u dovoljnoj količini za naredni vremenski period. Količina elektroda evb.50 2.5 mm i u ovom periodu je na trebovanju, što znači da je potrebna njegova nabavka.

Slika 68. Količine artikala po vrstama promene za drugi kvartal

Na slici 69 je dat prikaz količine artikala po svim vrstama promene za treći kvartal 2009 godine. Na osnovu grafika vidi se da je stanje elektroda evb.50 2.5 mm popravljeno.

51

Slika 69. Količine artikala po vrstama promene za treći kvartal

Količine artikala po vrstama promene za četvrti kvartal je prikazano na slici 70. U ovom periodu je povećana potrošnja elektroda evb.50 2.5 mm što se i vidi na osnovu grafika.

Slika 70. Količine artikala po vrstama promene za četvrti kvartal

Slika 71 prikazuje sve promene za tri artikla (cipele radne, elektroda evb.50 2.5 mm i gips alabaster) u vremenskom periodu za sva četiri kvartala u 2009 godini.

52

Slika 71. Količine artikala po vrstama promene za četiri kvartala

Na slici 72 prikazana je količina artikala po vrstama promene za prvo polugodište. U ovom periodu za razliku od cipela radnih i gips alabastera, elektroda evb.50 2.5 mm ima samo jednu promenu tj. potrošnju.

Slika 72. Količine artikala po vrstama promene za prvo polugodište

53

Na slici 73 prikazana je količina artikala po vrstama promene za drugo polugodište. U ovom periodu napravljen je preokret u odnosu na prvo polugodište, tj. u ovom periodu elektroda evb.50 2.5 mm nadohnađuje svoje zalihe.

Slika 73. Količine artikala po vrstama promene za drugo polugodište

Sledeće slike daju prikaz analize svih artikala iz baze (uneto je 11 artikala) za odabrani magacin tj. centralni magacin Direkcije (ima 4 takva magacina: M-1, M-2, M-3 i M-4) sa ograničenjem vrste promene (ulaz od dobavljača iz zemlje). Analiza je izvršena za vremenski period od godinu dana po kvartalima.

Na slici 74 prikazana je primljena količina artikala u magacine za prvi kvartal. Primećuje se prisustvo dva artikla (cipele radne i trihloroetilen) i njihova raspodela u magacinima M – 1 i M - 3.

Slika 74. Primljena količina artikala u magacine za prvi kvartal

54

Slika 75 prikazuje primljenu količinu artikala u magacine za drugi kvartal. U ovom periodu za magacine M – 1 i M – 3 prisutan je prijem artikla gips alabaster (M - 1), ležaj 6202 zz i rukavice „ALJASKA“ – zimske (M - 3).

Slika 75. Primljena količina artikala u magacine za drugi kvartal

Na slici 76 za treći kvartal prikazana je primljena količina artikala za magacine ovde je prijem izvršen u tri magacina (M – 4, M – 3, M - 1) za tri artikla (daska čamova okr. 24 mm, elektroda evb – 50 2.5mm i gips alabaster).

Slika 76. Primljena količina artikala u magacine za treći kvartal

55

U četvrtom kvartalu (slika 77) izvršen je prijem za tri artikla, od kojih su dva (azbestno platno 5mm i daska čamova okr. 24 mm) primljena u isti magacin (M - 4), dok je treći (rukavice „ALJASKA“ - zimske) primljen u magacin M - 3.

Slika 77. Primljena količina artikala u magacine za četvrti kvartal

Prikaz primljene količine artikala za centralne magacine Direkcije (ima 4 takva magacina: M-1, M-2, M-3 i M-4) u vremenskom periodu za sva četiri kvartala 2009 godine dat je na slici 78.

Slika 78. Primljena količina artikala u magacine za četiri kvartala

56

9. ZAKLJUČAK

Standardna metodologija projektovanja informacionih sistema ima za cilj da obezbedi najmanju moguću redundantnost podataka. Smanjivanje redundantnosti podataka kao posledicu ima povećanje vremena odziva sistema jer se dodatno vreme troši na spajanje relacija i kreiranje složenih upita radi dobijanja željenih informacija. Specifičnost skladišta podataka se ogleda u ogromnom broju zapisa što čini standardnu metodologiju za projektovanje informacionih sistema nedovoljno efikasnom u slučaju projektovanja baze podataka za podršku odlučivanju. Sa druge strane tradicionalni pristup podrške odlučivanju ne obezbeđuje zahtevanu fleksibilnost sistema koju nameću savremeni zahtevi poslovanja.

Za svako preduzeće jedan od osnovnih poslova koji se obavlja u sistemu privređivanja je tačna i ažurna evidencija artikala, njihov smeštaj (lokacija) i praćenje trenutnih zaliha. Zalihe se moraju održavati u optimalnom nivou, zato se mora planski odrediti nabavka artikala kako se ne bi proizveli dodatni troškovi za organizaciju.

U radu je izvršeno definisanje zahteva magacinskog poslovanja kroz informaciono modeliranje magacinskog poslovanja za izradu aplikativnog modela koji će omogućiti bolje upravljanje i efikasniju transakcionu obradu podataka.

Na osnovu urađenog konceptualnog modela kreirano je skladište podataka koje omogućava raspolaganje i skladištenje podataka koji su transformisani u oblik koji omogućava jednostavniji pristup i analizu podataka u cilju kvalitetnijeg odlučivanja.

Na osnovu grafika dobijenih analizom odabranih artikala (cipele radne, elektroda evb.50 2.5 mm i gips alabaster) po vrstama promene za četiri kvartala dobijamo tačno stanje artikala na kraju 2009 godine po kvartalima. Ovom analizom pratimo prijem, trebovanje i prenos artikala po kvartalima, a time postižemo plansku nabavku zaliha za naredni period i nepotrebne dodatne troškove preduzeća.

Kao rezultat urađenih analiza prijema artikala po magacinima za četiri kvartala prikazan na grafiku u radu dobijamo mogućnost grupisanja magacina na osnovu vrste ili namene artikla za koji je izvršen prijem.

Ovim radom smo dobili odvojene podatke od relacionih baza podataka u skladištu podataka koje omogućava analizu količine primljenih i trebovanih artikala po magacinima i vrsti promene za vremenske periode mesec, kvartal, polugodište i godinu. Rezultat rada je dinamički prikaz podataka gde se sumarni podaci o količini artikala prikazuju na višem nivou detaljnosti prema definisanim dimenzijama.

Ovakav način analize omogućava visok nivo performansi za analizu podataka i prikaz po različitim nivoima detalja što pruža podršku rukovodstvu za poređenje podataka i donošenje odluka na osnovu činjenica.

57

10. LITERATURA

[1] Dokumentacija Privrednog društvo za proizvodnju, preradu i transport uglja Rudarski basen „Kolubara“ d.o.o. Lazarevac.

[2] „Projektovanje baza podataka ″ Alempije V. Veljović, Nataša R. Gojgić, Čačak, 2006.[3] „Razvoj informacionih sistema i baza podataka“, Alempije V. Veljović.[4] „Poslovni informacioni sistemi“, dr Angelina Njeguš.

58

SPISAK KORIŠĆENIH SKRAĆENICA I SIMBOLA

Skraćenice i simboli Objašnjenje

MS MicrosoftIDEF0 Funkcionalno modeliranjeBPwin Bussines Process windowsABC Activity Based CostingICOM Input, Control, Output, MehanizamIDEF1X Informaciono modeliranjeERwin Entity Realitionships for WindowsCASE Computer Aided Software EngineeringSUBP Sistem za upravljanje bazom podatakaVB VisualBasicISO International Organization for StandardizationSQL Structured Query LanguageUML Unified Modeling LanguageOMG Open Municipal Geodata StandardOO Objektno orijentisaneDW Data WarehouseOLAP On-Line Analytical ProcessingMOLAP Multidimenzioni OLAPROLAP Relacioni OLAPHOLAP Hibridni OLAPOLTP On Line Transaction ProcessingDDL Data Definition LanguageRDBMS Relational data base management systemMAG Magacinsko poslovanje

59

SPISAK SLIKA

Oznaka Naziv slike Str.Slika 1. Prijemnica 7Slika 2. Prenosnica (interna) 8Slika 3. Revers 9Slika 4. Jedinično trebovanje materijala 9Slika 5. Trebovanje materijala 10Slika 6. Trebovanje osnovnih sredstava i investicionog materijala 10Slika 7. Zapisnik o prijemu robe 11Slika 8. Otpremnica materijala na obradu i doradu 11Slika 9. Reversna knjižica sitnog inventara 12Slika 10. Magacinska kartica 12Slika 11. Konteksni dijagram poslova magacina 16Slika 12. Stablo aktivnosti poslova magacina 16Slika 13. Dekompozicioni dijagram prvog nivoa 17Slika 14. Dekompozicioni dijagram drugog nivoa 18Slika 15. Identifikujuća veza 20Slika 16. Neidentifikujuća veza 20Slika 17. Veza kategorije 20Slika 18. Neodređujuća veza tipa više prema više 21Slika 19. Logički model magacinskog poslovanja u ERwin-u 21Slika 20. Fizički model magacinskog poslovanja u ERwin-u 22Slika 21. Model baze podataka magacinskog poslovanja realizovan u MS ACCESS-u 24Slika 22. Glavni meni transakcione baze podataka 24Slika 23. Forma Artikal 25Slika 24. Forma Grupa artikala 25Slika 25. Forma Jedinica mere 26Slika 26. Forma Magacin 26Slika 27. Forma Vrsta promene 26Slika 28. Forma Prijem artikala 27Slika 29. Forma Trebovanje artikala 27Slika 30. Izveštaj Stanje magacina 28Slika 31. Klasa 30Slika 32. Interfejs 30Slika 33. Učesnik 30Slika 34. Slučaj korišćenja 30Slika 35. Interakcija 30Slika 36. Automat stanja 31Slika 37. Zavisnost 31Slika 38. Asocijacija 31Slika 39. Agregacija 31Slika 40. Generalizacija 31Slika 41. Grafički prikaz poslovnih slučajeva upotrebe 32Slika 42. Dijagram poslovnih aktivnosti magacinskog poslovanja 33Slika 43. Dijagram sistemskih slučajeva upotrebe 33

60

Slika 44. Sistemski slučaj upotrebe 33Slika 45. Konceptualni model analize magacinskog poslovanja 34Slika 46. Osnovna arhitektura skladišta podataka 35Slika 47. Razvoj skladišta podataka 36Slika 48. Primeri dvodimenzionih i trodimenzionih modela podataka 37Slika 49. Različiti pogledi na iste podatke 37Slika 50. Različiti načini reprezentacije podataka 38Slika 51. Šeme zvezde, pahulje i galaksije 38Slika 52. Šema zvezde za magacinsko poslovanje 39Slika 53. ETL procesi 41Slika 54. Upiti za unos podataka iz transakcione baze 42Slika 55. Upit za unos podataka iz transakcione baze za artikal 42Slika 56. Izbor tipa baze podataka 45Slika 57. MS Query izbor kolona 46Slika 58. Opcija Create OLAP Cube 46Slika 59. Izbor polja sumarnih podataka 46Slika 60. Formiranje dimenzija OLAP kocke 47Slika 61. Izbor mesta snimanja OLAP kocke 47Slika 62. Pristup OLAP kockama 48Slika 63. Određivanje lokacije podataka 49Slika 64. Izbor OLAP kocke 49Slika 65. Formiranje pivot tabele 50Slika 66. Grafik Pivot tabele 50Slika 67. Količine artikala po vrstama promene za prvi kvartal 51Slika 68. Količine artikala po vrstama promene za drugi kvartal 51Slika 69. Količine artikala po vrstama promene za treći kvartal 52Slika 70. Količine artikala po vrstama promene za četvrti kvartal 52Slika 71. Količine artikala po vrstama promene za četiri kvartala 53Slika 72. Količine artikala po vrstama promene za prvo polugodište 53Slika 73. Količine artikala po vrstama promene za drugo polugodište 54Slika 74. Primljena količina artikala u magacine za prvi kvartal 54Slika 75. Primljena količina artikala u magacine za drugi kvartal 55Slika 76. Primljena količina artikala u magacine za treci kvartal 55Slika 77. Primljena količina artikala u magacine za četvrti kvartal 56Slika 78. Primljena količina artikala u magacine za četiri kvartala 56

61

Documents

ANALIZA MAGACINSKOG POSLOVANJA SA ASPEKTA PRIMENE SKLADIŠTA PODATAKA