J u PRAVLJANJE IN UPORABA PODATKOV UNIVERZA V LJUBLJANI Ekonomska fakulteta .*»*• UNIVERZA V LJUBLJANI Založništvo Ekonomske fakultete Jurij JAKLIČ UPRAVLJANJE IN UPORABA PODATKOV LJUBLJANA, 2002 544734 Dr. Jurij Jaklič: Upravljanje in uporaba pode Ekonomska fakulteta - skripta; šifra: JJA02i Založila: Ekonomska fakulteta v Ljub lota za založništvo Za založnika: Prof.dr. Bogdan Lipičnik Natisnil: COPIS, Dunajska 158, Ljubljana Naklada: 400 izvodov, 1. natis Recenzent: prof.dr. Andrej Kovačič Oblikovanje: dr. Jurij Jaklič CIP - Kataložni zapis o publikaciji Narodna in univerzitetna knjižnica, Ljubljana 004.6(075.8) JAKLIČ, Jurij - 1967 Upravljanje in uporaba podatkov / Jurij Jaklič. -1. izd. - Ljubljana : Ekonomska fakulteta, 2002. - (EF. Skripta) ISBN 961-6430-29-7 119208448 Vse pravice pridržane. Noben del tega gradiva se ne sme reproducirati ali kopirati v kakršnikoli obliki: grafično, elektronsko ali mehanično, kar vključuje (ne da bi bilo omejeno na) fotokopiranje, snemanje, skeniranje, tipkanje ali katerekoli druge oblike reproduciranja vsebine brez pisnega dovoljenja avtorja ali druge pravne ali fizične osebe, na katero bi avtor prenesel materialne avtorske pravice. 18 -09- 2002 j Kazalo 1. POGLAVJE PODATKOVNI VIRI V ORGANIZACIJI . 1 1.1 Učinkovita uporaba podatkov.2 Problemi upravljanja podatkov . 4 Uporabniki . 9 1.2 Podatkovna arhitektura.10 Operativni nivo . 12 Zgodovinski podatki . 13 Referenčni podatki . 14 Zunanji podatkovni viri . 15 Podatkovni viri %a analitično obdelavo . 16 Podatkovno skladišče . 18 Področno podatkovno skladišče . 20 Operativna shramba podatkov . 21 Tokovi podatkov . 21 Opisovanje podatkov . 22 Vprašanja za preverjanje razumevanja .25 Ključni pojmi 26 2. POGLAVJE UPRAVLJANJE PODATKOV .. 27 ./fjr) 2.1 Življenjski cikel upravljanja podatkov.28 2.2 Aktivnosti upravljanja podatkov.30 Načrtovanje . 30 Viri . 31 Pridobivanje in vzdrževanje . 31 Opredelitev in opis . 32 Organizacija in dostopnost . 32 Nadgor kakovosti in celovitosti . 33 Varovanje in zaščita . 34 Obračun uporabe . 37 Obnavljanje in nadgradnja . 37 Odločanje o ob držanju in odstranitvi . 38 Izobraževanje in svetovanje za uporabo . 39 2.3 Načrtovanje podatkovnih virov.39 Model entitet - povezav . 41 Analiza povezav med entitetnimi tipi . 49 Funkcionalna odvisnost . 53 Podatkovno modeliranje . 56 b/i r 2.4 Upravljanje znanja .59 Vprašanja za preverjanje razumevanja .67 Ključni pojmi 68 3. POGLAVJE PODATKOVNE BAZE. 69 3.1 Podatkovne baze in njihove značilnosti.70 Značilnosti podatkovne bage ... 70 Uporaba in druge aktivnosti . 71 Sistemi ga upravljanje podatkovnih bag . 75 \'Ioge . 84 3.2 Načrtovanje podatkovnih baz.85 Podatkovni modeli . 86 12 Hierarhični model . 88 Mregni model . 92 Relacijski model podatkov . 93 Objektni model . 102 Večdimengionalni model . 105 . .7 Osnove dobrega načrtovanja podatkovne bage . 110 Programska orodja ga podporo ragvoju bagpodatkov . 123 3.3 Uporaba podatkovnih baz.125 Kaj je SOI J . 125 Zakaj SQL? . 126 Jegjk SOL . 126 Igmenjava podatkov .-. 144 Vprašanja za preverjanje razumevanja.146 Ključni pojmi 146 4. POGLAVJE INFORJHACIJSKA PODPORA MANAGEMENTU . 147 Proces odločanja in analiza podatkov . 150 4.1 Sistemi za podporo odločanju .159 r 4.2 Uporaba programskih paketov za delo s preglednicami .164 4.3 Poslovno obveščanje.177 Sprotna analitična obdelava podatkov . 178 Rudarjenje v podatkih . 184 & 4.5 Poslovni portali.198 Vprašanja za preverjanje razumevanja .201 Ključni pojmi.202 LITERATURA . 203 STVARNO KAZALO . 207 Predgovor Pri nastanku pričujočega gradiva sem imel v mislih predvsem študente pri predmetu Informatika 2 na Ekonomski fakulteti v Ljubljani, v uporabi pa bo tudi pri nekaterih drugih predmetih, ki pokrivajo področje upravljanja podatkov, podatkovnih baz in njihove uporabe. Ker gradivo torej ni v prvi vrsti namenjeno specialistom na tem področju (informatikom), gre predvsem za pregled področja s poudarki na tistih delih, ki bi jih morali razumeti tudi uporabniki za svoje uspešno delo. Pri pisanju sem predvideval, da ima študent, ki bo to gradivo uporabljal, znanja, ki so v učnem načrtu pri predmetu Informatika 1 (ah Poslovna informatika). Prvi inačici gradiva je sledil dodatek, ki je pokrival manjkajoča poglavja iz osnovnega gradiva. Tokratna izdaja obsega celotno gradivo, ki je z nekaterimi vsebinami še dodatno dopolnjeno, nekatere obstoječe vsebine pa so skrajšane ali delno spremenjene glede na dosedanje izkušnje z uporabo. V informatiki predstavlja zaradi hitrega razvoja področja večen problem slovensko izrazje. Trudil sem se, da bi uporabil čim več uveljavljenih slovenskih prevodov za angleške izraze. Zaradi razvoja so se tudi nekateri prevodi spremeniti glede na prejšnjo izdajo. Na primer, podatkovna tržnica je zdaj področno p odatkovno skladišče. Posebno težavo je predstavljala uporaba izraza za management, saj se pojavljajo kar trije različni izrazi: management (informacijska podpora managementu), uravnavanje (uravnavanje odnosov s kupci) in upravljanje (upravljanje podatkov, znanja, podatkovnih baz ...). Pri odločitvi je bilo potrebno upoštevati kriterije enovitosti, uveljavljenosti izraza in pomenom. Tokrat je pretehtala uveljavljenost. Prof. dr. Andreju Kovačiču se zahvaljujem za pregled gradiva in opozorila na nekatere pomanjkljivosti in napake. Seveda je vse, kar je morebiti ostalo napak, izključno moja odgovornost. Zavedam se, da je gradivo še potrebno izboljšav, popravkov in dopolnitev, ki jih načrtujem v prihodnje. Pri tem želim uporabiti predvsem izkušnje z uporabo te izdaje. Zato študente vabim, da mi sporočite svoja opažanja. Za vsako opozorilo ali nasvet za izboljšavo vam bom hvaležen. Še to: Dele vsebine, ki so namenjene zahtevnejšim študentom, sem posebej označil s prekinjeno črto ob besedilu, na enak način kot ta odstavek. Za uspešno opravljen izpit študij teh delov ni obvezen, vendar je za poglobljeno razumevanje ostalega besedila priporočljiv. V Ljubljani, julija 2002 ; ' ■ n POGLAVJE Podatkovni viri v organizaciji Cilji poglavja V tem poglavju boste spoznali: ► Da so vlaganja v informacijsko tehnologijo lahko donosna le, če je organizacija informacijsko usmerjena. ^ Kateri so poglavitni elementi informacijske usmerjenosti in kako so med seboj povezani? ► Kateri so problemi upravljanja podatkov v organizacijah in kaj so razlogi zanje? ► Kdo so uporabniki podatkov v organizacijah in kakšne so njihove značilnosti? ► Kakšna je sodobno zasnovana podatkovna arhitektura? ► Katere so vrste, značilnosti in pomen različnih vrst podatkov? ► Zakaj so potrebni posebni podatkovni viri za analitične potrebe, kateri so ti viri in kakšne so njihove značilnosti? ► Zakaj je pomembno opisovanje podatkov in kaj obsega? 2 Podatkovni viri v organizaciji 1.1 Učinkovita uporaba podatkov Podatki in informacije, ki so bile nekoč redka dobrina, postajajo z razvojem informacijske in komunikacijske tehnologije (na primer Interneta) vsepovsod prisotne in dostopne. Kupci, zaposleni, dobavitelji in tekmeci imajo možnost dostopa po mnogih komunikacijskih poteh do istih poslovnih in gospodarskih podatkov (Marchand, Kettinger, Rollins, 2001). To zahteva od organizacij "se večji trud, da bi dosegle in povečale informacijsko asimetrijo oziroma uporabile podatke in informacije, ki jih zbirajo in so dostopne, za doseganje konkurenčne prednosti. Razumevanje, da je osnova učinkovite uporabe podatkov zgolj uporaba sodobnih informacijskih tehnologij za pretvarjanje le-teh v informacije, se je v praksi izkazalo za napačno. Večina raziskav, v katerih so iskali povezave med vlaganji v informatiko (ali informacijsko tehnologijo) ter uspešnostjo podjetij, tovrstnih povezav ni odkrila ali pa je bila podpora povezavam zelo šibka 1 - 2 . To kaže na dejstvo, da zgolj uvajanje novih tehnologij ni dovolj, pač pa mora postati organizacija informacijsko usmerjena (Marchand, Kettinger, Rollins, 2001), kar vključuje poleg uporabe sodobnih informacijskih tehnologij %a podporo odločanju in reševanju problemov tudi upravljanje podatkov in informacijsko obnašanje (informacijsko kulturo). Slika 1 prikazuje medsebojno povezanost vseh elementov: dobro razvita informacijska kultura in dobro upravljanje podatkov povečujejo možnost učinkovite uporabe informacijske tehnologije za podporo odločanju, to pa spet povečuje informacijsko obnašanje in vzpodbuja izboljšanje upravljanja podatkov. 1 I .ester (1998 v Marchand, Kettinger, llollins, 2001) pravi: »Računalnike lahko najdete povsod, le v statistikah o produktivnosti ne.« “ Velika vlaganja v informacijsko tehnologijo v ameriških podjetjih v 1980. letih, se niso odracala v povečani produktivnosti gospodarstva (Marchand, Kettinger, Rollins, 2001). Upravljanje in uporaba podatkov 3 Slika 1: Spirala učinkovite uporabe podatkov (Marchand, Kettinger, Rollins, 2001) Medtem ko sta področji upravljanja podatkov ter upravljanja in uporabe informacijske tehnologije relativno dobro razviti, pa področje informacijskega obnašanja šele v zadnjem času vzbuja več zanimanja in raziskovanja. Informacijsko obnašanje se je namreč v preteklosti obravnavalo kot del splošnega upravljanja (managementa). Značilnost dobrega informacijskega obnašanja je proaktivna uporaba podatkov in informacij, ld pa je odvisno od drugih dimenzij informacijskega obnašanja: ■ podatki morajo biti celoviti , to je verodostojni , točni in nepristrani, zaposleni morajo verjeti vanje, ■ uporaba formalnih virov podatkov mora imeti prednost pred uporabo podatkov iz neformalnih virov, kar povečuje zanesljivost in kakovost uporabljenih podatkov, * podatki (npr. računovodski) omogočajo nadzor nad delovanjem posameznika in organizacije kot celote in imajo s tem motivacijsko funkcijo, ■ transpar entnost delovanja zahteva pošteno obravnavanje odločitev, napak, zmot, problemov; iz podatkov so razvidni tudi neuspehi in problemi, ne le pozitivne plati poslovanja, 4 Podatkovni viri v organizaciji ■ deljenje podatkov ima veliko poslovno vrednost; za deljenje mora obstajati volja, ki jo lahko dosežemo z ustreznim vzdušjem zaupanja, ki je spet lahko posledica drugih dimenzij informacijskega obnašanja (z dostopnostjo posameznikov do verodostojnih, formalnih in uporabnih podatkov o poslovanju), ali pa s preoblikovanjem organizacij tako, da namesto vertikalnim komunikacijskim povezavam damo večji poudarek medfunkcijskim procesnim informacijskim tokovom. V Delu 28. junija 2002, na primer, zasledimo: "Notranja finančna preiskava je odkrila prirejanje podatkov o denarnih tokovih ... S pravilno vodenimi računovodskimi izkazi bi imelo podjetje izgubo ... VVorldcom pa je imel s prirejeno bilanco lani za 35,2 milijarde dolarjev prodajnih prihodkov, prijavil je 1,4 milijarde dolarjev dobička,..., saj je zdaj že nekdanji finančni direktor knjižil operacijske stroške, denimo vzdrževanja opreme, kot kapitalska vlaganja..." Praktične izkušnje kažejo, da je prav transparentnost tisti element, ki pogosto povzroča zastoje pri projektih informatizacije poslovanja. Dogaja se, da si vplivni zaposleni (kljub drugačnim besedam in deklarativni podpori) možnosti, da bi imeli ostali vpogled v dejansko stanje, ne želijo. Problemi upravljanja podatkov Podatki predstavljajo enega najpomembnejših virov v vsaki organizaciji, saj večina opravil na vseh nivojih organizacije (glej sliko 2) danes temelji na informacijah. To pomeni, da moramo podatke obravnavati in upravljati na enak način kot vse druge vire: stroje, človeške vire, kapital ... Uspešno upravljanje podatkov pomeni, da morajo biti podatki dostopni takrat, ko jih potrebujemo, in v obliki, v kakršni jih potrebujemo. Poglavitni podatkovni problemi, ki jih opažamo v praksi so (Turban, Aronson, 2001): podatki niso pravilni, podatki niso pravočasno na voljo ali pa potrebni podatki sploh ne obstajajo. Upravljanje podatkov je torej odgovornost vsakega manageja , tako kot je to upravljanje financ, zaposlenih, opreme ... Aktivnosti upravljanja podatkov, kot so načrtovanje, nadzor kakovosti, vodenje evidence, identifikacija kakovostnih virov, načrtovanje zaščite in podobno so tipično najprej poslovna vprašanja in šele nato tehnična vprašanja. Sele ko se odločimo, kdo ima pravico dostopa do katerega podatka, lahko skrbnik podatkovne baze (glej poglavje Podatkovne baze) poskrbi za ustrezne tehnološke rešitve, ki omogočajo dostop samo pooblaščenim. Upravljanje in uporaba podatkov 5 Pri upravljanju podatkov pa v organizacijah tradicionalno opažamo probleme, ki izhajajo iz zastarele miselnosti in načina obdelave podatkov in so znak slabo razvitega informacijskega obnašanja. Posamezni oddelki ali managerji si namreč lastijo podatke, ki jih uporabljajo. Posledično si podatkov ne delijo, izmenjava podatkov je otežkočena ah nemogoča, za odločanje ni na voljo informacij, ki jih potrebujemo, podatki pa se v veliki meri podvajajo. Vzroki za tako "zaklepanje" podatkov izhaja iz dejstva, da podatki pomenijo moč, ki je pogosto povezana z netransparentnostjo, neverodostojnim in pristranim prikazom podatkov navzven in podobno. To pa je s stališča organizacije kot celote nesprejemljivo. Tak način upravljanja podatkov je bil še podkrepljen z informacijsko tehnologijo preteklosti, ko je vsak program (npr. računovodski, kadrovska evidenca, obračun plač) uporabljal svoje podatkekdCer programi niso uporabljali skupnih podatkov, je bilo nujno, da so bili isti podatki shranjeni večkrat v različnih oblikah in pod različnimi imeni. 6 Podatkovni viri v organizaciji Slika 3: Zaradi "zaklepanja" podatkov znotraj oddelkov prihaja v organizaciji do otokov informacij Za skrbnike podatkovnih virov je to predstavljalo "nočne more" pri vzdrževanju, po drugi strani pa je prihajalo do nekonsistentnih podatkov, saj isti podatki niso bili spremenjeni hkrati na vseh mestih. Na primer, naslov zaposlenega, ki se je pred kratkim preselil, je bil v enem programu 3 že spremenjen, v drugem pa ne. Podatki morajo biti torej zbrani v skupnem viru podatkov, brez njihovega nepotrebnega podvajanja. Hkrati to pomeni, da mora biti načrtovanje in upravljanje podatkov koordinirano. Idealna rešitev za tak skupni vir podatkov je celovita (integrirana) računalniško podprta podatkovna baza 4 , za katero je značilno prav to, da ne vsebuje nepotrebnega podvajanja podatkov, dostop do podatkov pa imajo, vsi uporabniki, ki te podatke potrebujejo. Ker je danes podatkovna baza pomemben del informacijskega sistema večine organizacij, ji namenjamo posebno poglavje (glej Tako izražanje ni povsem natančno, saj so bili podatki shranjeni na datotekah in ne neposredno kodirani v programih. Ker pa so bili podatki tesno povezani s programi, moremo in želimo s takim "pogovornim" izražanjem to povezavo še posebej poudariti. ^ Podatkovna baza je, kot bomo podrobneje videli v nadaljevanju, neka urejena, računalniško podprta zbirka podatkov. Upravljanje in uporaba podatkov 7 poglavje Podatkovne baze). Čeprav bomo imeli pri obravnavi opisovanja in upravljanja podatkovnih virov v tem in naslednjem poglavju pogosto v mislih predvsem podatkovne baze, se bomo temu izrazu namenoma, kjer se le da, izogibali, saj se velik del razmisleka enako dobro nanaša na vse vrste podatkovnih virov, tudi tradicionalnih kot so, na primer, papirni arhivi. Podatke torej načrtujemo in organiziramo neodvisno od načina uporabe, na primer programov, ki bodo te podatke uporabljali. Zal pa je bil razvoj v mnogih organizacijah kljub uporabi podatkovnih baz drugačen: ■ Zaradi potreb po hitrem razvoju uporabniških rešitev se je marsikje zanemarjalo celovito načrtovanje informatike, kar je privedlo ponovno do uporabe internih (lokalnih) podatkovnih virov. ■ Marsikje obstoječi sistemi delujejo dobro in-bi jih bilo nesmotrno zavreči, zato so podatkovni viri integrirani le deloma v novejših delih informacijskega sistema. ■ Celovite rešitve so lahko izjemno drage, česar si nekatere organizacije ne morejo privoščiti. ■ Zaradi razvoja osebnih računalnikov ter uporabniško prijazne informacijske tehnologije in s tem "demokratizacije" informatike ter neučinkovitih služb za informatiko še je mnogo uporabnikov lotilo izdelave lastnih podatkovnih virov~(največkrat v obliki preglednic, tabel v urejevalnikih besedil, pa tudi preprostih podatkovnih baz). Uporabniki so s tem tudi prevzeli nadzor nad lastnimi podatkovnimi viri, kar je v nasprotju z željo po integraciji podatkov. * V nekaterih organizacijah se še vedno lotevajo informatizacije tako, da informatizirajo oddelke in ne procese, kar vodi v nepovezanost delov informacijskega sistema. Zaradi teh in drugih razlogov se v večini organizacij danes srečujejo s stanjem, ko imajo množico podatkovnih virov, v zelo različnih oblikah, šibko povezanih, z močno prisotnim podvajanjem podatkov, z nekonsistentnimi podatki. Slabosti takih sistemov se pokažejo predvsem na višjih nivojih odločanja, ko pri analizah 8 Podatkovni viri v organizaciji potrebujemo množice raznovrstnih podatkov, ki se nahajajo v različnih podatkovnih virih. Ko nam le uspe identificirati podatke, jih zbrati, prečistiti ... pa ugotovimo, da podatkovni viri niso konsistentni 5 . Takšnemu okolju množice nekoordinirano nastalih podatkovnih virov pravimo okolje pajkove mreže (angl. spider web environment). Čeprav si takega stanja ne želimo, pa ga moramo pri sodobnem načrtovanju sistema podatkovnih virov v organizaciji upoštevati (glej podpoglavje Podatkovna arhitektura). Poudarimo pa, da lahko razpršeni sistemi, to so sistemi, v katerih imamo več podatkovnih virov, prav tako dobro služijo svojemu namenu, če le upoštevamo načela, ki veljajo za izgradnjo integrirane podatkovne baze, in načela dobrega upravljanja s podatki. Kadar imamo v organizaciji razpršene podatkovne vire, moramo skrbeti za dovolj pogost 5 (in po možnosti avtomatiziran) prenos podatkov med podatkovnimi viri, ki vsebujejo iste podatke. V idealnem primeru vsak podatek zajamemo- samo . enkrat, nato pa ga posredujemo v vse podatkovne vire, ki ta podatek ah od njega odvisen podatek vsebujejo. Na primer, spremembo naslova kupca, ki jo zajamemo v računovodstvu, shranimo v računovodsko podatkovno bazo, nato pa posredujemo v trženjsko podatkovno bazo. Iz podatkov o prodaji moramo vsaj enkrat mesečno izračunati skupno prodajo in ta sumarni podatek posredovati v bazo, ki se uporablja za napoved prodaje. 5 To pomeni, da npr. če pri analizi uporabimo istovrstne podatke, ki se nahajajo v dveh podatkovnih virih, dobimo različne rezultate. Neredko se zgodi, da bosta dala dva oddelka popolnoma različni poročili o isti dejavnosti. Za širšo obravnavo razlogov za takšne dogodke glej (Inmon, 1996). Natančneje pogostosti ne moremo opredeliti, saj je le-ta odvisna od potreb organizacije. 6 Upravljanje in uporaba podatkov 9 Hkrati z razvojem pajkovih mrež se je povečevala pri uporabnikih na vseh nivojih odločanja tudi "lakota" po informacijah. Uporaba kakovostnih, to je pravočasnih, relevantnih , konsistentnih ter popolnih podatkov je za poslovno odločanje postaja nepogrešljiva. Podatki, ki jih dobimo iz operativnih podatkovnih virov,' ne zadoščajo za učinkovito podporo odločanju. Zato je razumljivo prišlo do razvoja novih vrst podatkovnih virov, to je podatkovnih bazj^ki so namenjene pravjf) podpori odločanju: operativnih shramb podatkov, podatkovnih skladišč in področnih podatkovnih skladišč. Ena od njihovih najpomembnejših značilnost je, da vsebujejo integrirane podatke iz okolja pajkove mreže, to je iz operativnih podatkovnih virov. Uporabniki Za učinkovito informacijsko podporo je pomembno tudi razumevanje potreb uporabnikov. Čeprav so te potrebe zelo raznolike, lahko uporabnike podatkov 7 v grobem razdelimo v dve veliki skupini: * operativni uporabniki ter ■ uporabniki podatkov za podporo odločanju (analitični nivo). Operativni uporabniki se ukvarjajo s trenutnimi in zelo neposrednimi odločitvami, na primer: * Koliko pošiljk moramo pripraviti danes? ■ Kje je ta trenutek pošiljka? ■ Kakšen je skupni znesek računa? * Koliko izdelkov imamo na zalogi? ' * 1 Tu niso mišljeni le tisti uporabniki, ki uporabljajo podatke (do njih dostopajo), pač pa širše vsi, ki imajo opravka s podatki (vnos, ažuriranje in podobno). 10 Podatkovni viri v organizaciji Uporabnik podatkov za podporo odločanju (managerski in strateški nivo) pa se ukvarja z mnogo širšimi in bolj dolgoročnimi vprašanji. Analitične uporabnike zanima, na primer: ■ Primerjava prodaje določenega izdelka v prvem trimesečju lani in letos? ■ Primerjava prodaje po regijah; za vse izdelke in za vsak izdelek posebej? ■ Vpliv postavitve izdelka v trgovini na njegovo prodajo? ■ Kakšne bi bile posledice 5% povečanja cen na prodajo (elastičnost povpraševanja)? Analitični uporabnik ima torej povsem drugačen pogled na podatke; širši, integrativen, zanimajo ga podatki daljšega časovnega obdobja in ne le trenutne vrednosti. 1.2 Podatkovna arhitektura Sodobno^ zasnovana podatkovna arhitektura mora izhajati iz prej opisane problematike in zagotavljati povezano ter uravnoteženo informacijsko ok olje. Sistem podatkovnih virov in drugih komponent (programska oprema, komunikacijska tehnologija ...) mora biti prilagodljiv in se spreminjati v skladu s spremembami v okolju. Upravljanje in uporaba podatkov 11 Slika 4: Primer podatkovne arhitekture (Inmon, Imhoff, Sousa, 1998) Podatkovna arhitektura, prikazana na sliki 4, vsebuje vse bistvene komponente takega sistema podatkovnih virov, vsaka organizacija pa bo glede na lastne informacijske potrebe izdelala ustrezno podatkovno arhitekturo, ki bo vsebovala vse ali samo nekatere od teh komponent. Na sliki 5 so prikazane nekateri primeri možnih podatkovnih arhitektur. 12 Podatkovni viri v organizaciji Dinamične poizved be operativnih podatkovnih virov Več področnih podatkovnih skladišč, ni podatkovnega skladišča Ni uporabniškega dostopa do podatkovnega skladišča, samo do področnih podatkovnih skladišč Slika 5: Različne možnosti podatkovnih arhitektur (Gartner Gorup, 1999) Operativni nivo Surovi detajlni podatki so podatki o vseh objektih in dogodkih, ki so povezani z vsakodnevnim poslovanjem organizacije, na primer, podatki o kupcih, dobaviteljih, naročilih, dobavah, prodajah, plačilih računov, notranjih delovnih naročilih, projektih, zaposlenih ... Surove detajlne podatke v splošnem zajamemo in uporabljamo na operativnem nivoju. Z ustrezno programsko opremo jih shranimo v operativne podatkov ne, baze posameznega področja (lokalne podatkovne vire), od koder jih preko transformacijskega in integracijskega sloja prenesemo v integrirane podatkovne vire, namenjene odločanju (operativno shrambo podatkov, podatkovno skladišče in področna podatkovna skladišča). Le redko podatke zajemamo tudi neposredno v operativno shrambo podatkov, kadar potrebnih podatkov, ne zajemamo z nobeno programsko rešitvijo na operativnem nivoju. Upravljanje in uporaba podatkov 13 Na operativnem področju detajlne podatke tudi urejamo in posodabljamo (popravljamo, brišemo ...). Kot že omenjeno, so podatkovni viri na operativnem nivoju lahko zaradi različnih vzrokov neintegrirani. Posledica so nekonsistentne strukture podatkov, nekonsistentni opisi in identifikatorji podatkov, nekonsistentna poročila in podobno. Organizacija se mora truditi, da iz takega stanja preide v integrirano stanje, kar pa je zapleten in drag proces, sestavljen iz naslednjih korakov (Inmon, Imhoff, Sousa, 1998): ■ izdelave strateškega načrta poslovanja in informatike, ■ definiranja informacijske arhitekture, ■ analize obstoječe programske opreme in podatkovnih virov, * razvoja načrta projekta prehoda ter ■ izvedbe. Mnoge organizacije se v okviru zadnjega koraka — izvedbe odločajo tudi za nakup že izdelanih celovitih programskih rešitev, kot so SAP, Baan, Oracle ... Več o informatizaciji lahko bralec najde v (Kovačič, 1998). Zgodovinski podatki Nekateri podatkovni viri (predvsem operativni) so namenjeni zlasti hranjenju trenutnih podatkov, oziroma podatkov iz bližnje preteklosti. Podatkovni viri, ki so usmerjeni v. uporabo pri podpori odločanju, pa morajo vsebovati tudi t.i. zgodovinske podatke, to je podatke iz daljšega časovnega obdobja. Kdaj postanejo podatki zgodovinski? Pravzaprav lahko rečemo, da so vsi podatki, takoj ko vstopijo v sistem, zgodovinski (razen napovedi). Torej vprašanje ni, ali je podatek zgodovinski, pač pa, koliko je zgodovinski. Pri zgodovinskih podatkih se nam zastavlja vprašanje, kako dolgo naj jih hranimo in v kakšni obliki (detajlni ah sumarni)? Na odločitev vplivajo elementi: 14 Podatkovni viri v organizaciji ■ Količina podatkov. S. časom-se nabere ogromna količina podatkov, kijih več ne obvladujemo. ‘-—----—.— I ■ Poslovna uporabnost. Za podatke iz bližnje preteklosti je večja verjetnost, da bodo relevantni za poslovne odločitve. ■ Stopnja agregacije. Podatki iz bližnje preteklosti bodo verjetneje uporabljeni na detajlnem nivoju, starejši podatki pa verjetneje na sumarnem nivoju. Več o vprašanju odločanja o obdržanju ali odstranitvi podatkov najde bralec še v poglavju Upravljanje podatkov. Referenčni podatki T Referenčni podatki so operativni podatki, ki povezujejo raznolike uporabnike in omogočajo standardizacijo procesov med različnimi oddelki. To so torej podatki, ki so skupni za več uporabniških področij (programskih rešitev) in so torej last organizacije kot celote in ne posameznih skupin uporabnikov (oddelkov in podobno). Tipični primeri referenčnih podatkov so podatki o izdelkih, podatki o kupcih, podatki o poštnih-številkah. Referenčni podatki zagotavljajo določeno mero integracije . operativnih podatkovnih virov. Na primer, z referenčnimi podatki o izdelkih bosta dva oddelka enako razvrstila izdelke v kategorije pri pripravi poročil o prodaji izdelkov. Praviloma se spreminjajo redko in so stabilni) zato se z njimi.(strukturiranjem in urejanjem) ne ukvarjamo dosti. Seveda pa je zaradi pomembnosti referenčnih podatkov za podjetje nujna stalna skrb za njihovo ažurnost Referenčni podatki namreč odražajo trenutno stanje - so ažurni v trenutku uporabe. Pri prehodu v druge podatkovne vire, kjer je pomembno tudi hranjenje starih vrednosti, npr. opis izdelka pred spremembo, pa se spremenijo v zgodovinske referenčne podatke. Pogosto so viri referenčnih podatkov zunanji, na primer podatki o poštnih številkah ah devizni tečaji. Upravljanje in uporaba podatkov 15 Zunanji podatkovni viri Zunanji podatki niso generirani znotraj organizacije, jih tam ne zajemamo na detajlnem nivoju. Predstavljajo dogodke in objekte izven organizacije, ki so za organizacijo zanimivi. Uporabljamo jih lahko povsod: na operativnem nivoju, lahko jih vključimo v podatkovno skladišče, področna podatkovna skladišča ali v operativno shrambo podatkov. Ker jih zajemamo iz zunanjih podatkovnih virov, nimamo vpliva na njihovo obliko: lahko so kakršnegakoli tipa in velikosti, strukturirani ali nestrukturirani, detajlni ali sumarni, zato jih na vhodu običajno obdelamo tako, da ustrezajo našim potrebam. Zeleno je, da tudi zunanje podatke zajemamo avtomatizirano. Internet je v zadnjem času eden pomembnejših medijev za dostop do zunanjih podatkovnih virov. Omogoča dostop do bolj ali manj urejenih podatkovnih baz (npr. statističnih podatkov) ali kar neposredno do podatkov na spletnih straneh 8 . Dostopamo lahko do podatkov o strankah, kupcih, konkurentih ... Čeprav je preko Interneta dostopnih ogromno podatkov, pa je uporabo bolj kakovostnih podatkovnih virov ponavadi potrebno plačati. Podatki lahko prihajajo v podatkovne vire organizacije tudi skozi sistem računalniške izmenjave podatkov — RIP (angl. Electronic Data Interchange — EDI), kjer gre za povezavo informacijskih sistemov dveh ali več organizacij. V zadnjem času se za povezovanje čedalje bolj pogosto uporabljajo ekstraneti, kjer gre za skupne informacijske sisteme več organizacij, ki temeljijo na tehnologijah Interneta, predvsem spletnih tehnologijah in standardu za opis podatkov XML (glej podpoglavje Opisovanje podatkov v nadaljevanju). Tako lahko, na primer, dobavitelj preko (ustrezno zaščitenih) spletnih strani svojega kupca pregleda stanje zalog in ugotovi, katere izdelke mora dobaviti. Na ta način podjetja ne le povezujejo informacijske sisteme, pač pa integrirajo tudi poslovne procese. 8 Sodobna orodja omogočajo kar poizvedovanje po podatkih na spletnih straneh. Na primer, eno od najpogosteje uporabljenih analitičnih orodij MS Kxcel ima že vgrajeno funkcijo Spletna poizvedba (angl. VVeb Qucry), ki omogoča poizvedovanje po tabelah na spletnih straneh na podoben način kot po ostalih strukturiranih podatkovnih virih. 16 Podatkovni viri v organizaciji Procese, ki potekajo med podjetji, obravnavajo kot celoto, jih sk ušajo op timirati kot celoto in ne le znotraj posameznega podjetja. Podatkovni viri za analitično obdelavo Kot smo že ugotovili, večino podatkov zajamemo v operativne podatkovne baze. Torej bi lahko uporabniki analitična orodja Uporabljali kar neposredno nad podatki v operativnih podatkovnih bazah. Zato se na tem mestu, preden se lotimo obravnave analitičnih podatkovnih virov'"'(podatkovna skladišča in področna podatkovna skladišča), vprašajmo, zakaj so pravzaprav potrebni posebni podatkovni viri, namenjeni analitičnim obdelavam, to je podpori odločanju. Enega izmed razlogov lahko razberemo iz že povedanega. Podatki v operativnih podatkovnih virih so neintegrirani, zato se prekrivajo, opisi niso enaki, identifikatorji 9 se razlikujejo in podobno. Zato je potrebno za analize, za katere je običajno potrebnih veliko podatkov iz različnih operativnih podatkovnih virov, podatke predhodno integrirati in prečistiti (odpraviti podvajanja, poenotiti obliko , , , in podobno). Potrebe po podatkih na /operativnem nivoju in na analitičnem nivoju se povsem razlikujejo. Tako je za uporabo podatkov na operativnem nivoju značilno: da se podatki ne bi smeh podvajati, s čemer se izognemo težavam pri njihovem posodabljanju, uporabnike zanimajo predvsem trenutne vrednosti podatkov, dostop do podatkov je pogost (č asovno enakomerna obremenjenost podatkovnih virov), količina podatkov, s katerimi delamo pa ponavadi majhna (podatki o enem nakupu, enem kupcu in le nekaj izdelkih), 9 Identifikator (tudi oznaka ali ključ) je podatek, ki nam omogoča razlikovanje istovrstnih objektov, o katerih hranimo podatke. Na primer, zaposlene lahko identificiramo z KMSO, šifro zaposlenega in podobno. Več o tem v podpoglavju Načrtovanje podatkovnih virov. Upravljanje in uporaba podatkov 17 * način uporabe podatkov se le redko spreminja (ponavljajoč vzorec uporabe), ■ zanesljivost mora biti visoka, čas dostopa pa majhen. Po drugi strani pa za uporabo na analitičnem nivoju velja: ■ da podatkov večinoma ne posodabljamo, zato podvajanje ne predstavlja problema, ■ uporabnike zanimajo tudi zgodovinski podatki (npr. gibanje prodaje v preteklih letih), * dostop do podatkov je neenakomeren (morda nekaj analiz dnevno), količina podatkov, s katerimi delamo, pa ponavadi velika, čeprav analitik dobi kot rezultat le nekaj sumarnih vrednosti, ■ način uporabe podatkov zelo raznolik, ■ zanesljivost ni tako pomembna kot na operativnem nivoju, za zahtevnejše analize pa smo pripravljeni počakati nekaj sekund ali minut, morda celo ur. Ker je za operativni nivo pomembno, da se podatki ne podvajajo, je struktura podatkov v operativnih bazah zapletena. Uporabniki te zapletene strukture večinoma ne opazijo, saj zaradi ponavljajočih se vzorcev uporabe do podatkov dostopajo skozi vnaprej pripravljene programe, ki . strukturo podatkov skrijejo. Način uporabe analitikov' pa je zelo raznolik; vseh analiz, ki jih potrebujejo, ni mogoče vnaprej predvideti. Zato tudi ni mogoče vnaprej pripraviti vseh mogočih poročil oziroma pregledov podatkov. Sprotna analitična obdelava (angl. On¬ line Analytical Processing - OLAP) omogoča uporabniku izdelavo poljubnih analiz nad podatki. Zato potrebujemo: * orodja, ki tako analizo omogočajo in so dovolj preprosta za uporabo, ter ■ preprosto strukturirane podatke , saj mora analitik, ki z orodji obdeluje podatke, razumeti njihovo strukturo. Zato so analitični podatkovni viri ponavadi strukturirani preprosto (večdimenzionalni model, o katerem pišemo v poglavju Podatkovne baze) tudi na škodo podvajanja podatkov. 18 Podatkovni viri v organizaciji Če bi izvajali analitično obdelavo kar nad operativnimi podatko vnimi viri, bi to pomenilo tudi njihovo dodatno obremenitev. Te obremenitve so, kot vidimo iz zgornje primerjave potreb po podatkih, neenakomerne, vendar velike, saj analitik ponavadi hkrati obdeluje veliko množico podatkov. Tipičen primer poizvedbe na \/ analitičnem nivoju je primerjava prodaje nekega izdelka v preteklem in tem 3 četrtletju. Čeprav bo rezultat predstavljen le z dvema številoma, je potrebno pregledati vse prodaje v zadnjega pol leta, kar pa je običajno ogromno podatkov. Izvajanje .take poizvedbe bi lahko povsem obremenilo operativni podatkovni vir. Nekoliko nerodno bi bilo stranki v trgovini reči: "Oprostite. Ne morem vam računati blaga. Počakati bo potrebno kakih petnajst minut, saj naš direktor ravno analizira prodajo izdelkov, da bo ugotovil, kako bi privabili več kupcev." Operativne podatkovne baze tudi nima smisla obremenjevati z zgodovinskimi podatki, lci na tem nivoju običajno niso potrebni. Podatkov o prodaji v enem letu je ogromno, vendar jih na blagajni trgovine ne potrebujejo. Zato je smotrno operativno bazo razbremeniti in po določenem času operativne podatke prenesti v podatkovno skladišče. Tudi s finančnega vidika je nesmotrno imeti dovolj zmogljivo strojno in programsko opremo, ki bi uspešno obvladovala velike množice podatkov, na operativnem nivoju. Podatkovno skladišče Podatkovno skladišče torej ni, kot bi utegnili sklepati iz imena, neko odlagališče nepotrebnih podatkov, temveč rešuje problem, la ga ima danes mnogo organizacij: gore podatkov, kijih pa ne moremo uporabiti. Podatkovno skladišče (angl. Data Warehouse) je podatkovni vir, ki je: ■ integriran — vsebuje podatke o vseh vidikih dejavnosti organizacije, ■ organiziran po poslovnih področjih, to je okrog glavnih entitet podjetja, ■ vsebuje ...zgodovinske podatke, ki so pomembni za poslovne analize, zato ima skladišče tudi časovno dimenzijo (podatki so točni glede na časovni trenutek, zato ponavadi vsebujejo zaznamek časa), Upravljanje in uporaba podatkov 19 ■ nespremenljiv (podatkov v glavnem ne posodabljamo), * vsebuje detajlne (podrobne) in sumarne (zbirne) podatke. Podatkovno skladišče je torej namenjeno podpori odločanju. Ker podatki v skladišču "pokrivajo" celotno poslovanje, ga uporabljamo predvsem za odločanje na strateškem nivoju. Tudi struktura (organizacija) podatkov je taka, da ni prirejena za delo posameznega oddelka. Kot bomo videli v nadaljevanju, običajno za posamezna poslovna področja razvijemo področna podatkovna skladišča, ki šo podmnožice skladišča. To pa tudi pomeni, da je podatkovno skladišče "last" celotne organizacije in ne posameznega oddelka ali skupine uporabnikov. Zagotavlja torej dostop do organizacijskih podatkov neposredno ali preko področnih podatkovnih skladišč. Ker podatkovno skladišče vsebuje podatke iz mnogih raznolikih notranjih in zunanjih podatkovnih virov, moramo pri prenosu podatkov v skladišče poskrbeti za integracijo in transformacijo podatkov, na primer: ■ Poenotenje identifikatorjev. Na primer, na enem oddelku (operativni bazi) na drugačen način dodeljujejo šifre kupcem kot na drugem. Zgodi se lahko celo, da imata različna kupca enako šifro ali obratno. * Poenotenje oblik podatkov. V organizaciji datume hranimo v "evropskem formatu" (24.8.2000), uporabljamo pa tudi podatke iz podatkovne baze, dostopne preko Interneta, kjer so datumi zapisani v "ameriškem formatu" (8/24/00). * Ža isti podatek imamo več virov (podvajanje podatkov v operativnih podatkovnih virih), v katerih pa sc lahko vrednost podatka razlikuje. Ker transformacija podatkov v podatkovno skladišče poteka avtomatizirano, moramo definirati pravila, po katerih bo izbran boljši vir za ta podatek. Proces prenosa podatkov v skladišče se ponavadi izvaja enkrat dnevno (ponoči), včasih pa še bolj redko, saj za analize ni potreben dostop do trenutnih podatkov. Na primer, podatek o trenutni prodaji ni bistven za analizo prodaje nekega izdelka. Problem podatkovnih skladišč je količina podatkov,, predvsem zaradi potrebe hranjenja zgodovinskih podatkov. Tako lahko podatkovno skladišče neke trgovske 20 Podatkovni viri v organizaciji družbe s podatki o prodaji v vseh njenih trgovinah obsega nekaj sto milijonov zapisov, kar ustreza dvajsetim giga bytom 10 . To pa seveda pomeni, da je za uporabo podatkovnih skladišč potrebna dovolj zmogljiva programska in strojna oprema. Področno podatkovno skladišče Zaradi velike količine podatkov in njihove še vedno precej zapletene strukture je skladišče za neposredno uporabo analitikov manj primerno. Področno podatkovno skladišče (angl. Data Mart) je podatkovni vir prirejen za uporabo v sistemih za podporo odločanju za posamezna poslovna področja (finance, prodaja, trženje ...). Oddelki so potemtakem "lastniki" področnih podatkovnih skladišč in jy"i jih povsem nadzorujejo. ves r' ^ Edini legitimni vir podatkov za področno podatkovno skladišče je podatkovno skladišče, x saj so podatki tam že integrirani in prečiščeni. Je torej podmnožica skladišča podatkov, vendar so podatki nekoliko prirejeni; ker analitiki pogosto dostopajo neposredno do področnega podatkovnega skladišča, mora le-ta: ■ imeti strukturo enostavno za razumevanje; praviloma so^ podatki organizirani večdimenzionalno, kar omogoča poljubne poglede na podatke, .. ■ vsebovati že izračunane sumarne podatke, kar omogoča hitrejše poizvedovanje. Po (Gartner Group, 1999) imajo področna podatkovna skladišča za razliko od podatkovnega skladišča tudi nekatere pomanjkljivosti, ki jih poznamo že iz preteklih obdobij, saj so zaradi prilagojenosti določeni uporabi manj fleksibilne. Hkrati so stroški razvoja področnih podatkovnih skladišč visoki (Gartner Group, 1999), zato je pred začetkom razvoja nujno izdelati natančno analizo potreb po področnih podatkovnih skladiščih. 10 Izračun jc narejen (Kimball, 1996) na predpostavkah, da ima podjetje 300 trgovin, ki poročajo dnevno o prodaji posameznega izdelka. V vsaki trgovini prodajo dnevno 3.000 različnih izdelkov. Upravljanje in uporaba podatkov 21 Operativna shramba podatkov Čeprav imata podatkovno skladišče in operativna shramba podatkov skupen cilj, to je integracijo podatkov, se po nekaterih drugih značilnostih ta dva podatkovna vira med seboj razlikujeta. Operativna shramba podatkov (angl. Operational Data Store - ODS) pokriva potrebe po integriranem podatkovnem viru na operativnem nivoju. Pogosto je namreč tudi za odločanje na operativnem nivoju potreben integriran podatkovni vir. Te potrebe ponavadi nastanejo, ko se sprejmejo strateške odločitve z uporabo podatkovnih skladišč in področnih podatkovnih skladišč in je potrebno na njihovi podlagi začeti izvajati aktivnosti. Bistvene razlike med operativno shrambo podatkov in podatkovnim skladiščem so (Inmon, Zachman, Geiger, 1997): * V operativni shrambi podatkov so shranjeni trenutni in časovno bližnji podatki, v podatkovnem skladišču pa podatki iz daljšega časovnega obdobja. ■ Operativna shramba podatkov vsebuje pretežno detajlne podatke, podatkovno skladišče pa je usmerjeno bolj v sumarne podatke. ■ Skladišče običajno ne dovoljuje posodabljanja, shramba pa običajno ponuja omejene možnosti posodabljanja podatkov. * Podatki se iz operativnih podatkovnih baz prenašajo v skladišče dnevno ali redkeje, v operativno shrambo podatkov pa zelo pogosto, mnogokrat kar v realnem času, to je sproti ob spremembah v operativnih podatkovnih bazah. Operativna shramba podatkov ima torej dvojno naravo, saj združuje operativne potrebe in potrebe podpore odločanju. Zaradi tega je najbolj kompleksen tip podatkovnega vira. To vrsto podatkovnega vira srečamo najbolj redko. Zelo koristen je v primeru slabe integriranosti operativnih podatkovnih virov. Tokovi podatkov S slike 4 je razvidno, da so za sistem podatkovnih virov značilni tudi številnTtokovT podatkov. Podatke bolj ali manj pogosto prenašamo iz enega vira v drugega. Pri 22 Podatkovni viri v organizaciji tem je pomembno, da prenos podatkov dodaja vrednost in ni samemu sebi namen. Vsak premik in transformacija mora pomeniti kvalitativne spremembe v podatkih. Tako gredo, na primer, pri prenosu iz operativnih podatkovnih virov v podatkovno skladišč e. skoz i transformacijski in integracijski sloj. To je r? hnika.| saj pravilno organizirani podatki odracajo poslovna pravila področja, ki ga baza pokriva. Res je, da večji del poslovnih pravil identificiramo že v fazi analize oziroma podatkovnega, a le redko prav vsa, ki So potrebna za načrtovanje. Tvorba podatkovne baze pomeni, da v podatkovn i sl ovar, ki je v primeru podatkovne baze kar njen_s£S.tavnL_del r vnesemo definicijo oziroma opis podatkovne baze, tako kot smo to opredelili z načrtom podatkovne baze (glej poglavje Upravljanje podatkov). Čeprav se zdi vnos začetnih podatkov, to je trenutnega opisa realnega sveta, precej rutinsko opravilo, v praksi mnogokrat pri tem naletimo na obilo težav, posebej če podatke v novo podatkovno bazo prenašamo iz obstoječih virov (starih podatkovnih baz, datotek ...). Drugače zapisani datumi, nekonsistentnost različnih virov (npr. različne šifre za iste entitete), uporaba decimalnih pik namesto decimalnih vejic, pomanjkljivi podatki o že izvedenih transakcijah in podobno so Upravljanje in uporaba podatkov 75 razlogi, zaradi katerih lahko postane ta aktivnost zelo zamudna, saj jo je težko popolnoma avtomatizirati. Zelo pomembno je tudi redno vzdrževanje podatkovne baze, ki je naloga skrbnika podatkovne baze (angl. Database Administrator — DBA). Če sta analitik in načrtovalec podatkovne baze lahko zunanja sodelavca, pa je skrbnik podatkovne baze praviloma zaposlen v organizaciji, saj je pogosto potrebno hitro ukrepanje. Seveda ima lahko v manjših organizacijah ista oseba tudi druge naloge. Med naloge skrbnika podatkovne baze sodijo (med drugimi) tudi: ■ izvajanje vseh vrst zaščit, kot jih opredeljuje politik a zaš čit e pod atkov (glej poglavje Upravljanje podatkov), od izdelave rezervnih kopij podatkovne baze do dodeljevanja uporabniških imen in z njimi povezanih pravic dostopa do podatkov, ■ po potrebi spremembe strukture podatkov, * izvajanje zahtevnejših ad hoc poizvedb in poročil po naročilu uporabnikov, ■ nastavitve, ki omogočajo optimalno delovanje, kar uporabnik zazna kot ustrezno kratke odzivne čase oziroma hitre odgovore na poizvedbe, ■ občasno čiščenje podatkov, ki so označeni kot zbrisani... Vzdrževanje je del upravljanja podatkov, pri čemer gre za bolj tehnični del oziroma implementacijo poslovnih zahtev v tem okviru. Sistemi za upravljanje podatkovnih baz Sistem za upravljanje podatkovnih baz (SUPB, angl. Database Management System, DBMS) je %birka programov, ki omogočajo tvorbo, uporabo in vzdrževanje podatkovnih baz Z njimi torej izvajamo vse aktivnosti, povezane s podatkovno bazfi^ razen načrtova nj kateremu so namenjena druga programska orodja (ČASE, glej poglavje v nadaljevanju). To pomeni, da so SUPB namenjeni raznolikim uporabnikom, od načrtovalca podatkovne baze, programerja, skrbnika, do uporabnika. Zato v mnogih primerih SUPB res sestavlja množica programov, vsak od njih pa je namenjen določeni aktivnosti v povezavi s podatkovno bazo. 76 Podatkovne baze Preprostejši SUPB pa so integrirani, vse aktivnosti opravimo z enim samim programom. Značilnost uporabe podatkovnih baz je predvsem ta, da uporabnik (ali program) ne more neposredno dosegati ali spreminjati podatkov v bazi. S tem je dosežena neodvisnost med programi in podatki, ki jo omogočajo prav SUPB. Podatke lahko dosegamo in spreminjamo samo tako, da SUPB posredujemo zahtevo ta pa le-to izvede, kar pomeni, da spremeni podatke ali poišče in vrne odgovor na postavljeno poizvedbo. Neodvisnost med programi in podatki je prikazana na sliki 19 . Slika 19: Uporaba sistemov za upravljanje podatkovnih baz Ta neodvisnost j e dosežena s podatkovnim slovarjem, v katerem je shranjen opis podatkovne baze: njene strukture, tipov podatkov ... Kot že vemo, tem podatkom pravimo metapodatki. V primeru podatkovne baze je podatkovni slovar tudi shranjen v računalniški obliki in je običajno kar del podatkovne baze. Pr ogra mjjard-t^ftozmict -Strukture podatkov, saj dostopajo do podatkov preko SUPB, ki pa uporablja strukturo podatkov, zapisano v podatkovnem slovarju. Upravljanje in uporaba podatkov 77 Pri tvorbi uporabljamo za vnos opisa podatkovne baze (in kasnejšega spreminjanja le-tega), glede na SUPB, enega izmed jezikov za definiranje podatkov — DDL (angl. Data Definition Language). Za enostavnejše delo pa ima večina SUPB tudi grafične uporabniške vmesnike za definiranje in spremembo strukture baze. CREATE TABLE ODDELEK ( ŠIFRAODDINTEGER, NAZIVODD VARCHAR(20), ŠIFRAŠEFA CHAR(6), CONSTRAINT ODDPK PRIMARY KEY (ŠIFRAODD) (b) Slika 20: Definicija dela podatkovne baze (ene tabele) z uporabo grafičnega uporabniškega vmfcSJtujEfŽ (a) in z jezikom SQL (b) Uporaba SUPB omogočajo tudi vsa opravila povezana z uporabo podatkovne baze: vnos, spreminjanje (ažuriranje), brisanje ter poizvedovanje. Kot smo že poudarili, lahko up orabnik (preko programa ali uporabnik neposredno! _to-poi ne le skozi SUPB. kar pomeni, da morajo obstajati pravila .sporazuinevanja.med uporabniki in SUPB 78 Podatkovne baze — jeziki. Jeziki, ki so namenjeni delu s podatki (angl. data manipulation), se imenujejo jeziki za manipulacijo podatkov (angl. Data Manipulation Language - DML). INSERTINTO ODDELEK VALUES (2233, 'Trženje', '645231') Slika 21: Vnos podatkov z jezikom SQL Eden najpogosteje uporabljenih jezikov za delo s p odatkovnimi bazami je SQL (angl. Structured Query Language), ki je standard za delo z relacijskimi podatkovnimi bazami. Zaradi njegove pomembnosti ga obravnavamo podrobneje v posebnem poglavju. S slik 20 in 21 je razvidno, da gre za jezik, ki je tako DDL kot tudi DML. Čeprav govorimo o programskih jezikih (četrte generacije), pa je potrebno opozoriti, da gre običajno za bolj preproste jezike, kot so programski jeziki tretje generacije. ZaSQL pravimo, da je nepostopkovn i (angl. non procedural) jezik, saj povemo le, kaj želimo, ne pa, kako naj se poizvedba izvede. Na primer, s stavkom SELECT IME, PRIIMEK FROM DELAVEC WHERE PLAČA > 100000; zahtevamo imena in priimke vseh delavcev, katerih plača je večja od 100.000. Verjetno za bralca, ki pozna nekaj angleškega jezika, razlaga stavka sploh ni potrebna. V jeziku tretje generacije bi morali zapisati postopek, kako naj se poizvedba izvede, na primer 18 : 18 Za prikaz primera ni uporabljen konkreten programski jezik, pač pa so uporabljeni tipični konstrukti programskih jezikov tretje generacije. Upravljanje in uporaba podatkov 79 datoteka = open file (Delavec) do while not eof(datoteka) readln (šifra, priimek, ime, plača, oddelek) lf plača > 100000 then print ime, priimek end if end do close file datoteka Razlika, ki je prikazana s preprostim primerom, se v zapletenejših poizvedbah še poveča. Čeprav je zastavljanje poiz vedb v nepostopkovnih jezikih—r elativno preprosto (vsaj za enostavnejše poizvedbe), pa je po drugi strani včasih tudi omejujoče. Za t.i. arDhoc delo s po darkovno.-hazn to je delo, za katerega ni vnaprej predvidenih in izdelanih programov, večina SUPB vsebuje tudi up orabniško pr ijazn e vme snike, ki omogočajo poizvedovanje in druga opravila, ne da bi poznali programski jezik. Vzdrževanje V okviru SUPB je del programov oziroma del programa namenjen tudi aktivnostim, povezanim z vzdrževanjem oziroma skrbništvom podatkovne baze. Tudi ta del SUPB postaja čedalje bolj preprost za uporabo in uporabniško prijazen, hkrati pa omogoča tudi avtomatizacijo nekaterih opravil (npr. redno izdelavo rezervnih kopij). Mnogi SUPB omogočajo nadzor celovitosti podatkov (angl. data integrity). Gre za semantične (pomenske) omejitve, ki jih lahko načrtovalec definira na podatkovni bazi. Na primer, v tabeli s podatki o postavkah naročil ne moremo imeti vrstice s šifro izdelka (IZDELEK#), ki ne obstaja v tabeli s podatki o izdelkih. To pravilo je odraz očitnega poslovnega pravila, ki pravi, da kupci ne morejo naročiti izdelkov, ki jih ne prodajamo. Omejitve, ki jih načrtovalec podatkovne baze definira, morajo izvirati iz realnega sveta in so dejansko pravila, ki veljajo na poslovnem področju, ki ga opisujejo 80 Podatkovne baze podatki v bazi. SUPB z nadzorom nad upoštevanjem teh pravil onemogoča uporabniku, da bi nenamerno privedel podatkovno bazo v nedovoljeno stanje. Slika 22: Definiranje celovitosti V grobem lahko omejitve celovitosti delimo na tri vrste: ■ omejitve območja, referenčna celovitost in eksplicitna celovitost. Omejitve območja določajo, kakšne vrednosti lahko zavzame atribut. Na primer, šifre študentov so lahko cela števila med 1 in 99999, poštne številke lahko zavzamejo vrednosti med 1000 in 9999 in spol je lahko 'M' ali 'Ž'. V SUPB, ki ne omogočajo preverjanja omejitve območja, za vsak atribut definiramo le tip, ki je lahko eden izmed vgrajenih tipov. Na sliki 23 je prikazan primer definiranja pravila (Validation Rule), da mora biti cena izdelka pozitivno število (>0). Upravljanje in uporaba podatkov 81 Slika 23: Nadzor celovitosti - omejitve območja Referenčna celovitost določa, da lahko nek atribut zavzame le vrednosti, ki jih ima ustrezni ključ. Na primer, podatki o opravljenih izpitih vsebujejo tudi vpisno številko študenta, da vemo, kdo je opravil izpit. Vpisna številka je hkrati tudi ključ za entitetni tip ŠTUDENTI. Očitno je, da ne more biti med podatki o ocenah vpisne številke, ki je nima nihče od študentov, saj bi to pomenilo, da je izpit opravljal nekdo, Iti ni študent. Če definiramo ustrezno referenčno omejitev, bi pri (nenamernem ali morda namernem) poskusu vnosa, da je izpit opravil neobstoječi študent, SUPB tak vnos preprečil. Le redki SUPB omogočajo nadzor nad eksplicitno celovitostjo. Zahteve (pogoji in dovoljene vrednosti) so pri eksplicitni celovitosti navadno definirane s konkretnimi vrednostmi. Vzemimo za primer, da je predpogoj za opravljanje izpita pri predmetu Informatika 2 opravljen izpit pri predmetu Informatika 1. Potem lahko postavimo pogoj, da v tabelo s podatki o opravljanju izpitov ni mogoče vnesti vrstice s šifro predmeta IN200 (Informatika 2), če se v tej relaciji ne nahaja že vrstica z isto šifro študenta in s šifro predmeta IN100 (Informatika 1). V okviru zaščite pred nepooblaščenim dostopom skrbnik vsakemu uporabniku dodeli uporabniško ime , na katerega so vezane pravice dostopa, ki jih preverja SUPB. 82 Podatkovne baze Uporabniku lahko na delu podatkovne baze omogočimo branje podatkov, pisanje (spremembo, dodajanje) podatkov ali celo spreminjanje strukture. Mehanizem zaščite lahko omogoča zaščito večjih ah manjših delov podatkovne baze. Nekateri SUPB omogočajo zaščito le na nivoju tabel, nekateri pa tudi na nižjih nivojih (atributi, podatkovni zapisi). Na primer, vodja oddelka lahko spremlja le plače delavcev, ki so zaposleni na tem oddelku, ne pa tudi plač ostalih delavcev. Za zaščito pred posledicami napak zaradi poškodb podatkovne baze (npr. fizičnega uničenja vira) je najpomembnejša aktivnost izdelava rezervnih kopij (angl. backup). Poleg občasne izdelave rezervne kopije omogoča večina SUPB tudi avtomatsko redno izdelavo rezervnih kopij. Te so lahko inkrementalne (shranijo se samo spremembe od prejšnjega shranjevanja) ali popolne. V praksi se najpogosteje uporablja kombinacija obeh, tako da se bolj pogosto (npr. dnevno) izdeluje inkrementalna rezervna kopija, redkeje (npr. tedensko) pa popolna. Pomembno je seveda, da je rezervna, kopija shranjena na drug em mediju kot original da bi bilo tako mogoče obnoviti original tudi v primeru poškodbe medija. Kako pogosto izdelujemo rezervne kopije, mora biti opredeljeno z načrtom zaščite podatkov , kar je poslovna odločitev. V redkih primerih, ko je zahtevana neprekinjena možnost dostopa do podatkovne baze, imamo ves čas dve enaki kopiji le-te. Ta pristop imenujemo zrcaljenje (angl. mirroring). V primeru poškodbe originalne podatkovne baze le-to rekonstruiramo iz rezervne kopije z.modulo m za . Qbna.vlj.anje (angl. recovery). V vsaki večji podatkovni bazi so pomemben element tudi indeksi 19 , ki omogočajo sistemom za upravljanje podatkovnih baz b oli učinkovito ^vn jg nje pnbvfl dh Uporabnik indekse torej občuti kot praviloma krajše odzivne čase pri poizvedovanju. Namen indeksov je podoben, kot je namen stvarnih kazal (indeksov) v knjigah. V stvarnih kozalih so pomembnejši pojmi, ki se pojavljajo v knjigi, urejeni po abecedi, kar nam omogoča hitrejše iskanje teh pojmov. 19 Ker so lahko podatkovne strukture, ki jih uporabljamo za implementacijo indeksov, precej zapletene, tukaj prikazujemo indekse precej poenostavljeno in le v tolikšni meri, da bi lahko bralec razumel njihov namen. Upravljanje in uporaba podatkov 83 Vzemimo zo primer podatkovno bazo, ki vsebuje tudi tabelo ŠTUDENT (ŠTUDENT#. IME-ŠTUDENTA, SMER) Zanimajo nas vsi študenti, ki so vpisani na smeri MA. V ta namen mora SUPB pregledati vse podatkovne zapise retačlje^ iTUDERJ>n izpisati tiste, v katerih je vrednost atributa SMER enaka MA. Čeprav bi bilo izvrševanje te poizvedbe relativno hitro, pa časovna zahtevnost pri takem načinu iskanja podatkov hitro naraste z naraščanjem zahtevnosti poizvedbe. Posebej zahtevne (časovno) so poizvedbe, ki vključujejo dve ali verfelačipČe bi imel SUPB na voljo "kazalo", ki bi imelo za vsako od smeri kazalce na vse študente, ki so vpisani na tej smeri, je očitno, da bi lahko vrnil rezultate poizvedbe dosti hitreje. In prav to je ideja indeksov. Za posamezen atribut je indeks datoteka, ki vsebuje dve polji: polje, ki vsebuje vrednosti atributa, in polje kazalcev na fizične podatkovne zapise. Datoteka je praviloma urejena po vrednostih atributa. Vsaka vrednost atributa nastopa le enkrat in ji pripada množica kazalcev na podatkovne zapise, ki imajo tako vrednost atributa. Shematično lahko prikažemo indeks za atribut SMER takole: prucM . -S rIiH.XarietL f fizični naslov 1 2 3 4 10 11 13 Kot smo že nakazali, lahko indeks zgradimo za vsak atribut, ki nastopa v podatkovni bazi. V mnogih primerih SUPB sam zgradi indekse za ključe relacij 20 Razlog - hitrost izvajanja poizvedb - za izgradnjo indeksov nad atributi postane pri velikih podatkovnih bazah dovolj močan. Vendar obstajajo, kot ponavadi, tudi razlogi proti. Prva slabost indeksov, ki v mnogih primerih ni zanemarljiva, je prostor na nosilcih podatkov, ki ga zavzemajo. Poleg tega postane zahtevnejši vnos no vih zapisov , saj moramo ob vsaki taki spremembi ustrezno spremeniti tudi vse indekse 21 , ki so zgrajeni nad atributi relacije, v katero vnašamo nov zapis. Ko se odločamo o izgradnji indeksa, se moramo vprašati: ■ Ali imamo na voljo dovolj prostora na nosilcu podatkov? * Kako pogosto bomo izvajali poizvedbe in kako zahtevne bodo? ■ Kako pogosto bomo spreminjali podatke v relaciji, v kateri je atribut? indeks relacija ŠTUDENT To je tudi razlog, da mnogi uporabniki ne razlikujejo med ključi in indeksi. 21 Večinoma SUPB ob spremembi podatkov avtomatično ustrezno ažurirajo tudi indekse. Čeprav uporabnik z ažuriranjem indeksov nima dodatnega dela, pa lahko pri vnosu ali spremembi podatkov občuti podaljšane odzivne čase podatkovne baze. 84 Podatkovne baze V SUPB MS Access zgradimo indekse preprosto tako, do pri definiciji tabele zo vsak atribut izberemo, oli noj bo indeksiran, ali ne. Za glavni ključ je privzeta vrednost DA - indeks naj bo zgrajen. Poleg opisanih najpomembnejših funkcij imajo SUPB še mnoge druge funkcije, ki omogočajo zanesljivo in hitro uporabo podatkovnih baz (npr. optimizacijo izvajanja poizvedb in podobno). Vloge Čeprav smo o tem razpravljali že sproti, povzemimo še enkrat vloge oseb, ki so povezane s podatkovnimi bazami. ■ Analitik ugotavlja informacijske potrebe uporabnikov, poslovna pravila, semantiko podatkov ... * Na podlagi njegovih ugotovitev izdela načrtovalec podatkovne baze načrt le-te. ■ Podatkovno bazo tvori programer ali skrbnik podatkovne baze. ■ Programer tudi izdela programe, ki d ostopajo dabaze. ■ Naloge skrbnika podatkovne baze so mnogotere: od skrbi za dostopnost, odzivnost in varnost podatkovne baze, preko izdelave zahtevnejših ad hoc Upravljanje in uporaba podatkov 85 poizvedb, do izobraževanja uporabnikov in izbora sistema za upravljanje podatkovnih baz. Velja opozoriti, da ima lahko ista oseba več vlog, v kompleksnejših primerih pa je specializacija smiselna in smotrna. Na koncu (pravzaprav na začetku) je tu še uporabnik, kateremu je podatkovna baza namenjena. Njegova naloga je, da poskrbi za: ■ ažurnost, * točnost in ■ popolnost podatkov v podatkovni bazi, hkrati pa njihovo uporabo za boljše poslovanje. 3.2 Načrtovanje podatkovnih baz Tako kot to velja za razvoj vsakega izdelka, je tudi pri podatkovni bazi izjemnega pomena izdelava dobrega načrta. Načrtovanje podatkovne baze je v veliki meri tehnično opravilo, ki ga praviloma opravi strokovnjak - načrtovalec podatkovne baze, vendar tudi v tej fazi razvoj podatkovne baze ni mogoč brez sodelovanja uporabnika. Res pa je, da je sodelovanje uporabnika tu manjše kot pri analizi problema. Programska oprema za delo s podatkovnimi bazami je danes v večini primerov preprosta za uporabo, deluje v uporabniško prijaznih okoljih, zaradi podobnosti delovnega okolja pa je tudi delo v veliki meri podobno delu v drugih programih (urejevalnikih besedil, programskih paketih za delo s preglednicami). Zato mnogi uporabniki menijo, da lahko izdelajo podatkovno bazo le z dobrim (ah celo osnovnim) poznavanjem programskega paketa za delo s podatkovnimi bazami, a brez poznavanja osnovnih in najpomembnejših pravil za načrtovanje podatkovn ih baz . Podatkovna baza, ki nastane na ta način, lahko povzroča različne težave pri uporabi in vzdrževanju, na primer, ko uporabnik išče določene podatke, dobi napačne odgovore. 86 Podatkovne bare Ker je po eni strani s odelovanje uporabn ika pri načrtovanju podatkovnih baz manjše in samostojno načrtovanje le redko, po drugi strani pa je razumevanj e načel o rganizacije podatkov pomembno tudi za kasnejšo uporabo, bomo v nadaljevanju spoznali: ■ kako moremo organizirati podatke ter ■ kakšna so temeljna pravila d obre org anizacije podatkov torej kako moramo organizirati podatke. Pri tem bomo posebej poudarili tista mesta, pri katerih načrtovalec ne more dobro opraviti svojega dela brez sodelovanja uporabnika. Hkrati bomo načrtovanje spoznali v tolikšni meri, da bo uporabnik vedel, na kaj mora biti pozoren, če želi samostojno izdelati preprosto podatkovno bazo. Podatkovni modeli Da bi spoznali, kakšne imamo možnosti organizacije (strukturiranja) podatkov, najprej opredelimo pojem podatkovni model. Beseda model ima več pomenov, med drugimi tudi (Bajec, 1994 in Grad, Jaklič, 1996); 1. prikaz proučevanega realnega sistema na drugačen, poenostavljen načm ki zaobjame njegovo bistvo, ne pa vseh podrobnosti; 2. ustaljena oblika česa, po kateri se kaj d ela: vzorec, oblika, kalup. Čeprav se v ostalem besedilu pogosteje ukvarjamo z modeli v prvem pomenu, pa bo v kontekstu podatkovnih baz model pomenil "kalup", ki nas omejuje pri strukturiranju podatkov. Podatkovni model je potemtakem množica praviL ki določajo, kako smejo biti podatki v podatkovni bazi organizirani oziroma strukturirani. Na primer, rel acijski po datkovni mod el predpisuje, da smejo biti podatki organiziranijv_t abelah, kj er vsak stolpec tabele predstavlja en atribut, ena vrstica pa eno entiteto oziroma povezavo (podrobneje relacijski model obravnavamo v nadaljevanju). Za podatkovne modele naj bi veljali dve nasprotujoči si zahtevi: Upravljanje in uporaba podatkov 87 omogoča naj tak opis problemskega področja s podatki, s katerim bo mogoče izraziti čimveč podrobnosti, ■ hkrati pa naj bo opis čimbolj preprost, da je še obvladljiv. V programski opremi za delo s podatkovnimi bazami se je v dosedanjem razvoju uveljavilo pet podatkovnih modelov: ■ hierarhični podatkovni model, * mrežni podatkovni model, ■ relacijski podatkovni model, ■ objektni model podatkov in procesov ter * večdimenzionalni podatkovni model. Modeli so navedeni v kronol oškem vrstnem redu , tako kot se je njihova uporaba uveljavljala v praksi. Trenutno se v poslovnih informacijskih sistemih največ uporablja relacijski podatkovni mod el—saj je enostaven in razumljiv uporabnikom, hkrati pa lahko z njim dovolj dobro opišemo poslovni sistem in njegovo delovanje. V podatkovnih virih, n amenjenih poslovnemu odločan ju, predvsem v področnih podatkovnih skladiščih, pogosto- srečamo tudi ve čdimenzionalni model, čeprav je mnogokrat realiziran kar v relacijski podatkovni bazi. Zato bomo največ pozornosti namenili prav rda,ajs.kemu..in yeč dim e n zionaln em u modelu, medtem ko bomo za ostale spoznali le najpomembnejše značilnosti, ki naj odločevalcu pomagajo pri odločitvi o morebitni uporabi katerega izmed njih glede na potrebe in značilnosti sistema. Shema je konkretna uporaba podatkovnega modela, torej načrt (shema) neke podatkovne baze, ki je v skladu s predpisi podatkovnega modela. Hkrati pa shema odraža obravnavano problemsko področje, saj je podatkovna baza opis tega problemskega področja. Tako se mora, na primer, povezava med kupci in naročili odražati tudi v shemi kot povezava med podatki o kupcih in naročilih. Podatkovni zapis je skupina vrednosti atributov,, ki se nanašajo na isto entiteto ali povezavo in so shranjeni v podatkovni bazi skupaj. Primer podatkovnega zapisa s podatki o kupcu Janezu Novaku: 88 Podatkovne baze 123456 Janez Novak Ti podatki so ponavadi v podatkovni bazi shranjeni skupaj. Hierarhični model Najstarejši podatkovni model, ki se je uporabljal v prvih podatkovnih bazah v 1960. letih, je hierarhični podatkovni model. Ta, kot pove ime, predpisuje hierarhično oziroma drevesno organizacijo podatkovnih zapisov. Hierarhija je znana struktura; hierarhija delovnih mest in odločanja je pogosta oblika organizacije, elemente rastlinskega in živalskega sveta razvrščamo v hierarhični sorodstveni strukturi (genealoško drevo)... Hierarhična struktura določa, da ima vsak elemen t v strukturi natanko enega neposrednega prednik a, razen t.i. korena, ki nima nobenega prednika. Za podrobnejši opis drevesnih struktur glej (Grad, Dacar, 1993). Na sliki 24 je prikazan primer hierarhične oziroma drevesne strukture podatkovnih zapisov. Slika 24: Hierarhična — drevesna struktura podatkovnih zapisov Iz definicije hierarhične strukture sledi, da lahko na ta način brez težav predstavimo le primere, ko so entitetni tipi med seboj povezani s povezavami, ki so zaporedoma tipa 1:N (v tem vrstnem redu, torej ne N:l) ali 1:1. Vzemimo najprej za primer prodajno službo, ki je organizirana po regijah, v vsaki regiji imamo trgovske potnike, vsak od njih pa je zadolžen za obisk določenih Upravljanje in uporaba podatkov 89 kupcev. Naj veljata še poslovni pravili., da sme vsak trgovski potnik delovati le v svoji regiji in da so kupci tudi razdeljeni med trgovske potnike, z drugimi besedami, da ne more priti do situacije, da bi istega kupca obiskala dva trgovska potnika.r Iz ER diagrama na sliki 25 je razvidno, da imamo zaporedoma le povezave tipa 1:N. Slika 25: ER diagram za primer prodajne službe Struktura je tipično hierarhična, saj je vsak trgovski_|)otnikJahko.p.ov.eZ.an.ie^_eno regijo, vsak kupec pa le z enim trgovskim po tnikom. Na sliki 26 je prikazan primer hierarhične podatkovne baze. V tem primeru so podatkovni zapisi o regijah predniki podatkovnih zapisov o trgovskih potnikih in podatkovni zapisi o trgovskih potnikih predniki podatkovnih zapisov o kupcih. Slika 26: Primer hierarhične podatkovne baze za primer prodajne službe Težave pa nastopijo, kadar je zaporedje povezav 1:N (ali 1:1) prekinjeno s povezavo N:1 ali M:N. V podjetju želijo hraniti v hierarhični podatkovni bazi •podatke o^i zdelkih njihovih dobavitelji h in s kladiščih , kjer hranimo izdelke. Entitetni tipi bi bili potemtakem IZDELEK, DOBAVITELJ in SKLADIŠČE, med seboj pa naj bodo povezani kot je to prikazano na sliki 27. 90 Podatkovne baze Slika 27: ER diagram za primer skladiščenja izdelkov Iz modela je razvidno, da poslovna pravila tega podjetja dovoljujejo, da jim nek izdelek dobavlja le en dobavitelj; za nek izdelek torej ne morejo imeti več dobaviteljev. Izdelke hranijo v za vsak izdelek določenih skladišči h, torej ne morejo imeti istega izdelka v več skladiščih. I^kA_paJrnajo-vt-enem.^.kladišču^različne. izdelke. Vidimo torej, da imamo zaporedoma povezavi 1:N in N:l. V hierarhični podatkovni bazi so podatkovni zapisi o dobaviteljih predniki podatkovnih zapisov o izdelkih, ti pa so predniki podatkovnih zapisov o skladiščih. Pri delu baze DOBAVITELJ — IZDELEK nimamo težav, saj ima vsak izdelek samo enega prednika. To pa ne velja za del IZDELEK — SKLADIŠČE, saj je lahko vsako skladišče povezano z več izdelki. Na sliki 28 je prikazan primer podatkovnih zapisov in povezav med njimi. Slika 28: Primer podatkovnih zapisov in povezav med njimi za primer skladiščenja izdelkov Očitno je, da taka organizacija podatkov v hierarhični podatkovni bazi ni dovoljena , saj imamo primer, ko je en podatkovni zapis (neposredno) povezan z dvema prednikoma. Takšne primere lahko v hierarhični podatkovni bazi razrešimo le_s_ po dvajanjem podatkovnih zapisov lin s tem seveda podatkov), kar pa je nezaželena lastnost podatkovne baze (glej podpoglavje Značilnosti podatkovne baze). Na sliki 29 je prikazano, kako bi v hierarhični podatkovni bazi organizirali podatke s slike 28. Vidimo, da se podatki o skladišču Naklo 1 podvajajo, ker v tem skladišču skladiščimo dva izdelka. V realnem primeru bi imeti seveda za skl adiš ča v cc Upravljanje in uporaba podatkov 91 a tributov, v vsakem skladišču pa veliko izdelkov, kar bi pomenilo mnogo podvojenih podatkov. _ !_ Slika 29: Primer hierarhične podatkovne baze za primer skladiščenja izdelkov Tudi, če bi želeli hierarhično bazo organizirati obratno (skladišča predniki izdelkov, ti pa predniki dobaviteljev) bi naleteli na enak problem. Na podoben način, torej s podvajanjem podatkovnih zapisov, rešimo tudi problem povezav M:N. Prednost hierarhičnega modela v primerjavi z drugimi je v tem, da omogoča zelo naravno predstavitev hierarhične strukture iz realnega sveta. Ima pa mnoge slabosti: programiranje uporabe podatkovne baze je zapleteno, redko se lahko izognemo podvajanju poda tkov , pojavljajo se težave pri operacijah za doseganje podatkov v podatkovni bazi. Na primer, če želimo v podatkovno bazo s slike 29 vnesti podatke o izdelku, za katerega še nimamo dobavitelja, moramo vpeljati na mišljenega do bavitelja, saj so podatki o izdelkih vedno vezani na dobavitelja. Začetki hierarhičnih SUPB segajo v konec šestdesetih let, ko se je na tržišču pojavil IBM-ov Information Management System (IMS), ki velja za njihovega poglavitnega predstavnika. Še danes je eden najhitrejših SUPB, zato se še vedno včasih uporablja za velike podatkovne baze, ki jih označuje veliko število obdelav. 92 Podatkovne baze Povzetek značilnosti ■ Zaradi hierarhične strukture je skoraj vedno neizogibno podvajanje podatkov. * Omogoča hitro izvajanje poizved b. ■ Razlika med logično strukturo podatkov in fizično predstavitvijo podatkovne baze je zelo majhna. ■ Nekoč je bil zelo razširje n. Mrežni model Mrežni model, ki se je uveljavljal predvsem v 1970. letih, odpravlja najpomembnejšo pomanjkljivost hierarhičnega modela, to je podvajanje podatkov. Mrežni model namreč dovoljuje tudi neposredno predstavitev povezav N:l, posredno pa tudi predstavitev povezav M:N brez podvajanja podatkov. Povezave tipa M: N predstavimo tako, da med prvotne podatkovne zapise vrinemo še pov ezovalne podatk ovne zapise. Na to način pretvorimo eno povezavo M:N v dve povezavi, eno tipa N:l, drugo pa tipa 1:N. Na spodnji sliki je prikazan primer predstavitve podatkovnih zapisov o zaposlenih in projektih ter povezav med njimi. Vsak zaposleni lahko dela na več projektih, no vsakem projektu pa vež zaposlenih. Vsak zaposleni je lahko povezan z več povezovalnimi podatkovnimi zapisi (povezava tipa h N), prav tako po je tudi vsok projekt lahko povezan z več povezovalnimi podatkovnimi zapisi (povezava tipa N:l). S tem, ko je bilo omogočeno predstaviti tudi povezave tipa N:M brez podvajanja podatkov, pa je postal mrežni model precej zapleten za razumevanje in uporabo. Danes se mrežni model (za razvoj novih podatkovnih baz) v praksi ne uporablja več. Tudi zato ne, ker ga je nadomestil sodobnejši objektni podatkovni model (glej Upravljanje in uporaba podatkov 93 nadaljevanje), ki je glede na dovoljeno strukturo podatkov pravzaprav naslednik mrežnega modela, ima pa pred njim nekatere prednosti. Mrežni modeli so dali pečat razvoju podatkovnih baz v 1970. letih. Večina SUPB se je držala priporočil standarda za mrežne podatkovne baze CODASYL (Conference on Data System Language) iz leta 1971. Med mrežnimi SUPB omenimo le IBM-ov IDMS. Povzetek značilnosti * Mrežni model omogoča predstavitev povezav tipa M:N brez podvajanja podatkov. ■ Je precej zapleten za^ razumevanj e in uporabo^ ■ Model je bil standardiziran. * Danes ni več pogosto v uporabi. Relacijski model podatkov Relacijski podatkovni model temelji na matematičn Uteo riji relacij 22 . Podatki so potemtakem organizirani v relacijske po datkovne strukture, ki pa so fizično predstavljene z d vodimenzionalnimi tabelami. Ker je razumevanje tako lažje, bomo v nadaljevanju razmišljali o relacijah kot o tabelah, oba pojma pa bomo uporabljali kot sopomenki, čeprav to ni popolnoma korektno. Praviloma hranimo v eni tabeli podatke o vseh entitetah nekega entitetnega tipa ah o vseh povezavah nekega tipa povez&v. Vsaka vrstic.a..predatavl}a..-ena_entit£La-ali povezavo; v njej so shranjeni podatki o eni entiteti (povezavi). V sak stolpec pa predsta vlja en atribut, v njem so shranjene vrednosti tega atributa za vse entitete (povezave) tega tipa. Na sliki 30 je prikazan primer relacije IZDELEK; v tabeli so shranjeni vsi podatki o izdelkih. Vsaka- vrstica predstavlja en i zdelek , vsak stolpec ga en atribu t izdelkov . Zahtevnejši bralec bo za spoznavanje ali osvežitev spomina o relacijah posegel po drugi literaturi, ki je temu namenjena, na primer, (Prijatelj, 1980). 94 Podatkovne baze RELACIJA IZDELEK IME RELACIJE M - 1_ Slika 30: Tabela/relacija IZDELEK Pozoren bralec bo opazil, da tudi v relacijskem modelu da njegovo ime podčrtamo . ” Stolpcu relacije pravimo tudi polje (angl. field), vrstici pa podatkovni zapis (angl. record). Ta terminologija se večinoma uporablja v_ si stemih za upravljanje relacijskih poda tkovnik baz. Povzemimo zdaj značilnosti relacije in dodajmo še nekatere: 1. Vsak posamezni stolpec v relaciji vsebuje vrednosti nekega atributa za vse entitete obravnavanega entitetnega tipa, ki ga relacija predstavlja. 2. Vrednost atributa neke entitete mora biti v relacijskem modelu elementarni podatek. To pomeni, da ne more biti sestavljen atribut ali večvrednostni atribut. 3. Vsak stolpec oziroma atribut je poimenovan z imenom, ki se razlikuje od imen drugih stolpcev oziroma atributov. 4. Vrstni red (poimenovanih) stolpcev je nepomemben. 5. Zaporedje vrstic v relaciji je nepomembno in ga praviloma ne poznamo. Glavni ključ relacije V primeru, ko relacija predstavlja entitetni tip, glavni ključ tega entitetnega tipa postane v relacijskem modelu glavni ključ pripadajoče relacije. Upravljanje in uporaba podatkov 95 Vemo, da glavni ključ med seboj razlikuje entitete nekega tipa in ne moreta imeti dve entiteti iste vrednosti tega atributa. Ker v relacijskem modelu vrstica pripadajoče relacije opisuje eno ent iteto, posledično ne moreta imeti dve vrstici relacije (dva podatkovna popisa) iste vredn osti glavne ga .ključa. Iz tega pa sledi tudi to, da vsaki vrednosti ključnega atributa pripada največ ena vrednost vseh ostalih atributov, saj v relacijskem modelu velja, da .v eni vrstic i nek, atribut ne more imeti, več vrednosti. Z drugimi besedami, vsi neključni atributi so funkcionalno odvisni od glavnega ključa. To je pravzaprav tudi formalna definicija kandidata za ključ v relacijskem podatkovnem modelu, ki pravi: Atribut ali skupina atributov A je kandidat za ključ relacije R natanko takrat, ko eni vrednosti A pripada v vsakem trenutku največ ena vrednost vsakega drugega atributa iz R-A (atributi, ki so v R in niso v A). * Vteaji"' Razjasnimo zgornji razmislek še na primeru. V podatkovni bazi želimo hraniti podatke o delavcih. Entitetni tip DELAVCI vsebuje vse delavce, katerih atributi, ki nas zanimajo so: IME, PRIIMEK; ŠIFRA, EMŠO, PLAČA. Očitno sta kandidata z ključ atributa EMŠO in ŠIFRA, med njima pa smo izbrali za glavni ključ atribut ŠIFRA. V relacijskem modelu naredimo ustrezno relacijo DELAVCI, kjer vsaka vrstica vsebuje podatke o enem delavcu. Ker vsaka vrstica predstavlja podatke o enem delavcu, je jasno, da ne moremo imeti dveh vrstic z isto šifro ali EMŠO, lahko pa imamo več vrstic z istim imenom, priimkom ali plačo. Ker imamo le eno vrstico z neko šifro (npr. 1234), lahko tepšifrLpripndn le ena vrednost drugih atributov: IME, PRIIMEK, EMŠO in PLAČA. Tako šifri 1234 pripada le ime Miha, priimek Kovač, EMŠO 1111111 in plača 90.000. Ne velja pa obratno, saj, na pri mer, imenu Ana pripadata dve šifri: 2345 te r 3211 Prikažimo to odvisnost neključnih atributov od glavnega ključa še grafično. CT IME CT" PRIIMEK C T~ ŠIFRA C T EMŠO C T PLAČA f 96 Podatkovne baze Na sliki so prikazane odvisnosti neključnih atributov od ključnega in še primer povezave v nasprotno smer med imenom in šifro, ki kaže, da šifra ni odvisna od imena, kar pomeni, da ime ne more biti kandidat za ključ te relacije. Pogosto pa v relacijah en sam atribut ne zadošča zahtevi za glavni ključ relacije. Praviloma to velja za relacije, ki predstavljajo tipe povezav med entitetnimi tipi. V tem primeru moramo za glavni ključ izb rati več atributov, za katere velja, da se vsaka kombinacija njihovih vrednosti pojavi samo v eni vrstici. Pravimo, da ima relacija sestavljen glavni ključ. Vzemimo za primer povezave med naročili in izdelki. Če je izdelek s šifro 123-456 povezan z naročilom številka 423, pomeni, da je kupec z naročilom številka 423, morda joleg drugih izdelkov, naročil tudi izdelek s šifro 123-456. Tovrstne povezave predstavimo z relacijo POSTAVKA, na primer, Povzemimo torej najpomembnejše ugotovitve o ključih relacij: ■ Relacija ima lahko več kandidatov za ključ, od katerih izberemo enega za glavni ključ, ostali pa so nadomestni ključi. ■ Glavni ključ relacije ne more imeti v dveh vrsticah iste vrednosti. ■ Glavni ključ označimo tako, da ga podčrtamo. Ostalim atributom pravimo neključni atributi. ■ Vsi neključni atributi so odvisni od glavnega ključa. ■ Če nimamo v relaciji atributa, ki bi sam zadoščal zahtevam za glavni ključ, izberemo za glavni ključ ustrezno kombinacijo atributov, ki ji pravimo sestavlj en glavni ključ. Upravljanje in uporaba podatkov 97 Na koncu poudarimo izjemen pomen, ki ga ima pravilna izbira ključev v relacijah za kasnejšo uporabo podatkovne baze. Slaba izbira ključa lahko, na primer, pomeni, da ne bomo dobili pravih odgovorov na vprašanja (poizvedbe). Relacijska shema Pri prikazu relacij ponavadi ne prikazujemo celotne tabele z vsemi podatki, saj nas pogosto zanima le slruktura-rekcije (posebej pri načrtovanju), poleg tega pa se podatki, ki odražajo realnost, pogosto spreminjajo, pri čemer pa struktura relacije ostaja ista. - Struktura relacije je dobro opredeljena s svojim imenom in seznamom atributov, kar prikažemo tako, da za imenom jrdacijc _ v.-okroglem oldepaju.našiej.emo atribute relacije, glavni ključ pa podčrtamo. N a primer, IZDELEK (IZDELEK#. NAZIVIZD, ME, CENA) Tak zapis imenujemo relacijska shema. Relacijska she ma poda tkovne baze bo praviloma vsebovala več takih shem za posamezne relacije, na primer NAROČILO (NAROČILO#. DATUM, KUPEC#, TP#, POPUST) IZDELEK (IZDELEK#. NAZIVIZD, ME, CENA) POSTAVKA (IZDELEK#. NAROČILO#- KOLIČINA) KUPEC (KUPEC#. NAZIVKUP, NAŠLO VKUP, TELEFON, KONTAKT) TRG-POTNIK (TP#. IMETP, PRIIMEKTP, REGIJA) Relacijska shema podatkovne baze je hkrati njen načrt 23 , saj opredeljuje, kako naj strukturiramo podatke: tabele, njihove atribute, glavne ključe ... Povezave Po datki iz dveh ali več relacij so lahko med seboj p ovezani. Tako so, na primer, podatki o naročilih in kupcih povezani, saj je vsako naročilo povezano z nekim kupcem. Vzemimo, da bi imeli relaciji 23 Tak načrt za tvorbo podatkovne baze še ne zadostuje. V nadaljevanju izdelamo še t.i. fizični načrt, v katerem natančneje opredelimo fizične značilnosti, na primer, tipe m velikosti posameznih atributov (tekstovni podatek dolžine 20 znakov, celo število, realno število, denarni znesek ...) 98 Podatkovne baze in ki opisujeta entitete tipov NAROČILO in KUPEC. Iz tako strukturiranih podatkov ne bi mogli nikakor ugotoviti, čigavo je posamezno naročilo. V relacijskem modelu podatke h? dveh ali več relacij vsebinsko povezujemo s skupnimi atributi. Če želimo v zgornjem primeru povedati, da gre za naročilo nekega kupca, bomo to storili tako, da v relacijo NAROČILO dodamo atribut KUPEC# in dobimo NAROČILO (NAROČILO#. DATUM, TP#, POPUST, KUPEC#) KUPEC (KUPEC#. NAZIVKUP, NAŠLO VKUP, TELEFON, KONTAKT) Skupni atributi, ki služijo za povezavo dveh (ali več) relacij so tist o nujn o po dvajanje podatko v (npr. imamo dvakrat atribut KUPEC#), ki ga v relacijskih podatkovnih bazah dopuščamo. Poglejmo zdaj, kako lahko prikažemo povezave med entitetami v relacijskem modelu. Možna sta dva načina. L Kadar med entitetnima tipoma obstaja povezava 1:1 ali 1:N, potem lahko povezavo med ustreznima relacijama vzpostavimo tako, kot smo to storili v zgornjem primem povezave med relacijama NAROČILO in KUPEC. V tem primem v relacijo na strani N dodamo glavni ključ relacije na strani 1. V konkretnem primem je na strani N relacija NAROČILO- saj je vsak kupec lahko poveza n z več naročili , eno naročilo pa samo z enim kupcem. Zakaj Upravljanje in uporaba podatkov 99 d odamo atribut prav v relacijo na strani N. naj razmisli bralec sam. Kadar imamo povezavo 1:1, pa je izbira, kam damo atribut, načeloma poljubna, pa vendar je v večini primerov ena od izbir boljša kot druga 24 . NAROČILO (NAROČILO#, DATUM, TP#, POPUST, KUPEC#) KUPEC (KUPEC#. NAZIVKUP, NAŠLO VKUP, TELEFON, KONTAKT) 2. Kadar med entitetnima tipoma obstaja povezava M:N, potem t vnrimn novo JSlacija, ^ predstavlja prav povezavo med tema entitetnima tipoma. Glavni ključ te relacije bo sestavljen iz glavnih ključev relacij, ki ju povezuje. Na primer, povezava med entitetnima tipoma NAROČILO in IZDELEK je tipa M:N, saj je lahko na vsakem naročilu več izdelkov, en izdelek pa se lahko pojavi na več naročilih. V tem primeru ne moremo dodati glavnega ključa ene relacije v drugo, saj bi moral biti to večvrednostni atribut, ki pa v relacijskem modelu ni dopusten. Zato smo tvorili jrelacijo POSTAV KA, ki pred stavlja povezavo med naročiliin_i zdclki NAROČILO (NAROČILO#. DATUM, KUPEC#, TP#, POPUST) IZDELEK (IZDELEK#. NAZIVIZD, ME, CENA) POSTAVKA (IZDELEK#. NAROČILO#. KOLIČINA) V zvezi s prvim načinom povezave med relacijami lahko definiramo pojem tuji ključ. Tuji ključ je neključni atribut ene relacije, ki je v drugi relaciji glavni ključ. Označimo ga tako, da ga_po dčrta mo s prekinjeno črto. Na primer, v relaciji NAROČILO je šifra kupca (KUPEC#) tuji ključ, saj je tu neključni atribut, je relaciji KUPEC pa je isti atr ibut glavni ključ . Povzemimo: R elaciie so m ed, seboj povezan em at ributi. Povezave med entitetami lahko predstavimo s tujimi ključi ali z relacijo, ki ima sestavljen glavni ključ. Poglejmo to na primeru naročanja izdelkov: NAROČILO (NAROČILO#. DATUM, KUPEC#, TP#, POPUST) IZDELEK (IZDELEK#, NAZIVIZD, ME, CENA) POSTAVKA (IZDELEK#, NAROČILO#. KOLIČINA) 24 Obravnavo te teme najde zahtevnejši bralec v vsaki boljši knjigi o podatkovnih bazah. Podatkovne baze 100 KUPEC (KUPEC#. NAZIVKUP, NAŠLO VKUP, TELEFON, KONTAKT) TRG-POTNIK (TP#, IMETP, PRIIMEKTP, REGIJA) V tem primeru so relacije povezane takole: relaciji NAROČILO in POSTAVKA POSTAVKA in IZDELEK NAROČILO in KUPEC NAROČILO in TRG-POTNIK skupni atribut NAROČILO# IZDELEK# KUPEC# TP# Relacije NAROČILO, IZDELEK, KUPEC in TRG-POTNIK predstavljajo entitete, ki so med seboj povezane takole: entitetipovezava predstavljena NAROČILO in IZDELEK povezovalna relacija POSTAVKA NAROČILO in KUPEC tuji ključ KUPEC# v relaciji NAROČILO NAROČILO in TRG-POTNIK tuji ključ TP# v relaciji NAROČILO Relacijska podatkovna baza Relacijska podatkovna baza je taka baza podatkov, v kateri so podatki strukturirani v skladu z relacijskim podatkovnim modelom. Z drugimi besedami, relacijska podatkovna baza je množica med seboj povezanih relacij oziroma tabel. Njeno strukturo lahko prikažemo z relacijsko shemo podatkovne baze. Značilnosti relacijskega podatkovnega modela Relacijske podatkovne baze 50 v 1980. letih postale izjemno razširjene in še danes je to v poslovnih informacijskih sistemih n ajpogosteje u porabljen podatkovni model . Nekatere izmed naslednjih značilnosti relacijskega podatkovnega modela in sistemov za upravljanje relacijskih podatkovnih baz so k temu gotovo prispevali: * Relacijski podatkovni model je preprost za razumevanje. * Kljub preprostosti pa temelji na čvrsti matematični podlagi, to je teorija relacij. Upravljanje in uporaba podatkov 101 ■ Dejanska fizična predstavitev je uporabniku skrita. Uporabnik podatke vidi, kot da bi bik shranjeni v dvodimenzionalnih tabelah, čeprav je lahko dejanska predstavitev zaradi učinkovitosti bistveno bolj zapletena. ■ Poizvedova nje je praviloma počasn ejše kot pri uporabi ostakh modelov, saj so pove zave med poda tki implicitne (skupni atributi), pri drugih modekh pa so ekspkcitne. ■ Za poizvedovanje se uporablja standardni poizvedovalni jezik SQL (glej poglavje Uporaba podatkovnih baz), kar omogoča enostaven prehod na uporabo drugega sistema za upravljanje podatkovnih baz. Sistemi za upravljanje relacijskih podatkovnih baz Z razvojem teorije relacijskega modela so se relacijske podat kovne baze zaradi enostavnosti izredno razširile v praksi. Tako lahko danes izbiramo med večjim številom relacijskih SUPB, med katerimi velja omeniti: Oracle, MS SQL, DB2 (IBM), Sybase in Informix. Večina jih je na voljo za razkčne računalniške strojne in operacijske sisteme, od vehkih (angl. mainframe) računalnikov do osebnih računalnikov. Uporaba omenjenih SUPB temelji na ar hitekturi odjemalec/strežnik, kjer je SUPB podatkovni strežnik, programi, ki dostopajo do podatkov pa so odjemalci. Poleg tega je v zadnjih letih na tržišču tudi večje število programskih paketov za delo z (relacijskimi) podatkovnimi bazami na osebnih računalnikih 25 . Prvi, ki je bil tržno uspešen in še Manes velja za standard podatkovnih baz na osebnih računalnikih, je dBase. Čeprav so imeli ti paketi na začetku le malo tistih funkcij, ki so jih poznali strežniški SUPB, pa so danes že precej izpopolnjeni. Večinoma so več kot le SUPB, saj omogočajo tudi razvoj programov, ki dostopajo do podatkovnih baz. Skoraj vsi omogočajo tudi povezavo s podatkovnimi bazami na velikih sistemih. Ker so tudi prijazni do uporabnika (okensko okolje), jih mnogokrat uporabljamo kot vmesnik za strežniške SUPB, ki so praviloma manj 25 V tem, primeru se SUPB ne obnašajo kot strežniki. 102 Podatkovne baze uporabniško prijazni. Najbolj znani primeri paketov za osebne računalnike in okolje oken so: MS Access, dBase in FoxPro. Objektni model Čeprav segajo začetki objektnega pristopa že v konec 1960. let, pa se je v podatkovnih bazah uveljavil šele v zgodnjih 1990. letih. Poglavitna ideja objektnega modela je, da naj bo podatkovna ba%a čimbolj verna slika našega videnja realnosti. Ker realni svet vidimo kot množico objektov s svojimi značilnostmi in obnašanjem naj bodo ti objekti tudi v podatkovni bazi opisani z značilnostmi (lastnostmi, podatki) - atributi in o b naš a n i cm ..- -met odami . Poleg podatkov o objektih so torej v podatkovnih bazah shranjeni tudi programi, ki opisujej o nhnašanjp objektov. Poleg atributov, ki opisujejo študente, na primer, vpisna številka, ime, priimek ..., nas pri objektnem pristopu zanima tudi njihova aktivna vloga, na primer, prijava na izpit, opravljanje izpita, prijava diplomskega dela ... Ker so v bazi shranjeni poleg podatkov tudi programi , se pri objektnem pristopu pomembno spremeni način razvoja programske oprem e, saj so metode, hkrati že deli le-te. Zaradi istega razloga tudi uporabljamo izraz objektn i.modeLpodatkov-jg procesov . hkrati pa še vedno (zdaj neprimeren) izraz objektne podatkov neiiaze. Kljub smiselnim predpostavkam, iz katerih izhaja objektni pristop, pa se objektne podatkovne baze 26 v poslovnih informacijskih sistemih do danes niso uveljavile v večji meri. Poglavitni razlogi so: ■ Ker je namen objektnega modela čimbolj natančen opis realnosti, gre to seveda nujno na škodo enostavnosti in razumljivosti. Zato je sam objektni model bistveno b olj zapleten za razumevan je kot relacijski podatkovni model, hkrati pa je načrtovanje objektne podatkovne baze bistveno bolj zahtevno kot načrtovanje relacijske podatkovne baze. 26 Mišljene so podatkovne baze, ki popolnoma upoštevajo zahteve objektnega modela. Upravljanje in uporaba podatkov 103 Prednosti objektnega pristopa pridejo mnogo bolj do izraza na nekaterih drugih področjih (programiranje, CAD/CAM sistemi, večpredstavni sistemi) kot v poslovnih informacijskih sistemih. V začetnem razvoju ni bilo enega standardnega objektnega modela, temveč je vsak proizvajalec sistemov za upravljanje objektnih podatkovnih baz uporabljal svoj model. Danes je stanje na tem področju boljše, saj sistemi za u pravliame ohie ktnih poda tkovnih haz , npr. Poet, Objectstore, Versant, Objectivity, Gemstone ..., temeljijo na skupnem standardu skupine Object Database Management Group (ODBMG). Ker pa so nekateri el em en t j ob)ektnega pristop a zelo uporabni tudi v poslovnih podatkovnih bazah, v zadnjem času tudi sistemi za upravljanje relacijskih podatkovnih baz (Oracle, IBM DB2 ...) vsebujejo čedalje več teh elementov. Na ta način so združeni enostavnost in razumljivost relacijskih podatkovnih baz ter nekatere prednosti objektnega pristopa. Zaradi kompleksnosti objektnega modela v nadaljevanju navajamo le njegove najpomembnejše značilnosti, za zahtevnejše bralce pa še nekaj osnovnih pojmov. Za podrobnejši opis objektnega modela glej (Grad, Jaklič, 1996). Povzetek značilnosti ■ r.'■'■'z - ■ Objektni model združuje atribute objektov in njihovo obnašanje. ■ Med objekti so dovoljene povezave vseh tipov (1:1, 1:N in N:M). * Dovoljeni so (za razliko od relacijskega modela) tudi večvr ednostn i atributi. ■ Poizvedov an je j e p raviloma h itrejše k ot pri relacijskih podatkovnih bazah. ■ Istovrstne objekte združujemo v razrede. ■ Objekt ustreza entiteti v modelu entitet povezav, razred pa entitetnemu tipu. ^ * Razvoj in formacij skega. sistema, ki temelji na objektnem modelu, je bolj zahteven če primerjamo z razvojem informacijskega sistema, ki temelji na relacijski podatkovni bazi. Hkrati pa vzdr ževanje boli enostavno, sistem pa bolj robusten. 104 Podatkovne baze Povezave med objekti so lahko tipov 1:1,1:N ali M:N. Realizirane so z referenčnimi atributi, ki jih imenujemo tudi mehki kazalci. Mehki kazalci so po svojem značaju nekje med kazalci, ki jih poznamo iz hierarhičnega in mrežnega modela, in med tujimi ključi, ki jih za realizacijo povezav uporabljamo v relacijskem modelu. Na primer, trgovsko podjetje hrani podatke o svojih trgovinah in zaposlenih. V ta namen uporablja dva razreda objektov ZAPOSLENI in PRODAJALNA. Na sliki sta prikazana dva objekta: Janez Kos je objekt tipa ZAPOSLENI, Koseze pa je objekt tipa PRODAJALNA. Poleg ostalih atributov imajo objekti tipa ZAPOSLENI tudi referenčni atribut DELA-V, katerega vrednost je mehki kazalec na objekt tipa PRODAJALNA. Uporabnik vrednosti tega atributa ne vidi. Če uporabnika zanima, v kateri prodajalni dela Janez Kos, bo kot odgovor dobil objekt Koseze in ne vrednosti nekega enostavnega atributa kot pri relacijskem modelu (npr. šifre prodajalne 045). Iz tipov lahko z generalizacijo (oziroma v obratni smeri specializacijo) dobimo nove tipe. Med takima tipoma potem obstaja povezava, ki jo največkrat imenujemo ISA (je). Tip OSEBA ima lahko podtipa ZAPOSLENI in KUPEC. Iz tipa ZAPOSLENI pa lahko s specializacijo dobimo podtipa ADMINISTRATOR in PRODAJALEC. Na ta način dobimo hierarhijo tipov. Nadtip je bolj splošen od svojega podtipa. Podtip deduje podatkovno strukturo in metode svojega starša - nadtipa. Z drugimi besedami, podtip vsebuje vse atribute in vse metode nadtipa. Poleg tistega, kar podeduje, pa ima lahko podtip tudi svoje atribute in metode. Tako ima objekt tipa OSEBA atribute IME, PRIIMEK, NASLOV, TELEFON. Objekt iz podrazreda ZAPOSLENI ima iste atribute, saj glede na hierarhijo razredov sodi tudi v razred OSEBA, poleg teh pa ima še dodatne atribute PLAČA in DELOVNO MESTO. Hierarhija razredov omogoča dedovanje, ki pomembno poenostavi in skrajša čas razvoja informacijskega sistema. Pomembna lastnost objektnega modela je tudi ograjevanje (enkapsulacija), ki pomeni, da uporabniki (in drugi objekti) ne vidijo implementacije objekta. Ograjevanje skriva podrobnosti o objektu pred uporabnikom. To pomeni, da ne moremo neposredno dostopati do vrednosti atributov in ne vemo, kako so kodirane metode - ne poznamo programov (postopkov). Vse, kar želimo vedeti o objektu, lahko ugotovimo le tako, da mu pošljemo zahtevo, objekt izvede ustrezno metodo, in nam posreduje odgovor. To lahko primerjamo tudi z objekti v realnem svetu. Ce želimo vedeti ime neke osebe, ji to ponavadi "ne piše na čelu", temveč jo moramo po imenu vprašati. Prodajalci v trgovinah torej kršijo pravilo ograjevanja, ker nosijo značke s svojimi imeni. Z ograjevanjem je omogočena večja prilagodljivost pri spreminjanju obnašanja objektov. Na primer, program, ki potrebuje izračun dohodnine za državljana in v ta namen uporablja operacijo (metodo), ki pripada temu državljanu - objektu, se ne spremeni, če se spremeni način obračunavanja dohodnine. Spremeni se le metoda - operacija objekta. Upravljanje in uporaba podatkov 105 Večdimenzionalni model Čeprav je relacijski model sam po sebi enostaven za razumevanje, pa^ so shem a, relacijskih podatkovnih baz, že za relativno "majhna" problemska področja presenetljivo kompleksne. Pogosto grafični prikaz sheme pokriva celo steno sobe načrtovalca. To kompleksnost za uporabnike na operativnem nivoju skrijejo programi, s katerimi delajo, kar pomeni, da ti uporabniki sheme sploh ne poznajo oziroma ne rabijo poznati. Popolnoma drugačno pa je stanje na področjjj^od{iaEe_Qdločanja, kjer je delo s podatkovnimi viri, kot smo že ugotovili, precej bolj nerutinsko. Poizvedbe po podatkovnih virih so zelo raznolike; za ad hoc poizv edbe, za katere nimamo vnaprej pripravljenih programov, pa je nujno poznavanje sheme podatkovnega. vira . Zato je razumljiva ugotovitev, da relacijske.po.d.atkavne„.baze, vsaj v obliki, kot jih uporabljamo na operativnem nivoju, niso, ..primerne- za podatkovne vire, namenjene poslovnemu .odl očanju. Drugi pomemben razlog za drugačno organizacijo podatkov, kot je v navadi pri relacijskih podatkovnih bazah, je počaso.QS.L.poizvedovanja po več tabelah, ki posebej pride do izraza pri delu analitikov, ki naenkrat delajo z ogromnimi količinami podatkov. Zaradi teh razlogov se v po datko vnih virih, ki so namenjeni podpori, odločanju (npr. podatkovna skladišča in področna podatkovna skladišča), v uporabi večdimenzionalni podatkovni model- Njegova bistvena značilnost je, da so sheme, ki jih lahko realiziramo,-preprosiejn blizu načinu razmišljanja analitika/odločevalca. V večdimenzionalni podatkovni 106 Podatkovne baze bazi zlahka najdemo odgovor na vprašanja, kot je: "Koliko smo prodali izdelka I v regiji X v prvem četrtletju letos?" Večdimenzionalni model dopušča organizacijo podatkov v obliki večdimenzionalne kocke. Na sliki 31 je prikazan primer tridimenzionalne 27 kocke, ki prikazuje vrednost prodaje glede na izdelek, regijo in čas. Stranice kocke imenujemo tudi dimenzije. Vsaka točka oziroma element kocke je na preseku koordinat, ki jih definirajo stranice kocke. Elementi kocke so mere poslovanja glede na dimenzije. V primeru s slike 31 je mera vredno st prodaje za neko komhinarijoL-zžižff» izdelek, regij a in čas. Na primer, temneje označen element kocke (manjša temna kocka) je vrednost prodaje izdelka 13 na Primorskem v tretjem kvartalu leta 1999. Naj posebej opozorimo na dimenzijo čas , ki je značilna za podatkovna skladišča in področna podatkovna skladišča, redkeje pa jo srečamo v operativnih podatkovnih bazah, kjer nas zanimajo predvsem trenutne vrednosti podatkov. Za realizacijo večdimenzionalne sheme lahko uporabimo sisteme za upravljanje večdimenzionalnih p odat kovnih b az, zelo pogosto pa večdimenzionalno shemo realizirama-kar z relacijsko podatkovno bazo. 27 Več dimenzij kor tri je težko grafično prikazati. V nadaljevanju pa bomo prikazali na nekoliko drugačen način tudi pctdimcnzionalno shemo. Upravljanje in uporaba podatkov 107 Čas l.kv. 2. kv. 3. kv. 4. kv. l.kv. 2. kv. 1999 1999 1999 1999 2000 2000 Dolenjska Štajerska Gorenjska Regija Primorska Notranjska Ljubljana II 12 13 14 15 16 Izdelek Slika 31: Primer tridimenzionalne kocke Tako lahko večdimenzionalno shemo s slike 31 enostavno pretvorimo v relacijsko shemo: IZDELEK ( IZDELEK#. NAZIVIZD, ME, CENA) REGIJA (REGIJA#, NAZIVREG, ŠTEVPREB) ČAS (ČAS# . KVARTAL, LETO) PRODAJA ( IZDELEK#. REGIJA# . ČAS#, VREDNOSTPROD) Očitno je, da vsaki dimenziji pripada ena tabela, ki jo imenujemo dimenzijska tabela (angl. dimension table). Tabelo, v kateri shranjujemo podatke za vrednos t^ mer pri posamezni kombinaciji vrednosti dimenzijskih atributov, imenujemo tabela dejstev (angl. fact table). Tabela dejstev povezuje dimenzijske tabele, zato je njen ključ sestavljen iz glavnih ključev dimenzijskih tabel. Praviloma vsebuje več mer. Tako bi lahko v zgornjem primeru hranili še podatke o prodani količini, dobičku in podobno. 108 Podatkovne baze Tabela dejste v je ponavadi zelo velika in se hitro spreminja . V primeru s slike 33 vsako bivanje stranke v hotelu pomeni dodatno vrstico. V nasprotju s tem pa se dimenzijske tabele s preminjajo počasi in so majhne. Pogosto relacijsko shemo, ki izhaja iz večdimenzionalne, prikažemo grafično, kot je to na sliki 32. Slika 32: Grafični prikaz relacijske sheme za primer s slike 31 Zaradi specifične oblike govorimo o zvezdasti shemi. Oglejmo si še en primer zvezdaste sheme, tokrat za turistično poslovanje, natančneje za spremljanje bivanja v hotelih. Nekateri sistem i za upravljanje relacijskih .pori.atk.Qynih.haz so posebej optimizirani tudi za delo z zve zdastimi,-podatkovnimi -.shemami in s tem bolj primerni za izgradnjo podatkovnega skladišča ah področnega podatkovnega skladišča. Upravljanje in uporaba podatkov 109 Slika 33: Zvezdasta shema za spremljanje bivanja v hotelih Povzetek značilnosti ■ Večdimenzionalni podatkovni model je preprost za razumevanje, preproste pa so tudi sheme. * Primeren je predvsem za podatkovn ^vim namenjene podpori od l očanju . Ker so ti podatkovni viri namenjeni večinoma branju podatkov (poizvedovanju), je dopustno podva ja nje podatk ov, ki je značilno predvsem za dimenzijske tabele. ■ Poizvedovanje je zaradi specifične strukture praviloma hitrejše kot pri relacijskem modelu. 110 Podatkovne baze Osnove dobrega načrtovanja podatkovne baze Zdaj, ko vemo, kako moremo organizirati podatke v okviru izbranega podatkovnega modela, si poglejmo, kako moramo organizirati podatke, oziroma, kakQ^jridemo_do d o b r caa. .načrta . ..poda tko viifi-bazerll ■ Pri tem se bomo omejili zgolj na_ relacijski podatkovni mode l zaradi njegove razširjene uporabe in razumljivosti. Kakovost relacijske sheme Očitno je, da moremo v okviru istega modela iste podat ke organizirati. oziroma smilmiriraH na radirne naftn e. Na primer, namesto uporabe r elacijske _sheme (označimo jo z ji): NAROČI! .O (NAROČILO#. DATUM, KUPEC#, TP#, POPUST) p i/.dei .ek (izdelek#. na/.ivizd, mk, gena) POSTAVKA (IZDELEK#. NAROČI!/)#. KOl.IČINA) KUPEC (KUPEC#. NA/.IVKUP, NASLOVKUP, TELEFON, KON'I AK'1') TRG-POTNIK H'P#. IMETP, PRIIMEKTP, REGIJA) bi lahko tvorili podatkovno bazo, ki bi bila strukturirana takole (relacijska shema P) ; NAROČILO (NAROČILO#. PATU M.-KUP I XI#, X!>#. POPUS T. IMETP, PRIIMEKTP, REGIJA) P POSTAVKA (NAROČILO#. I/.PELEK#. NAZIVIZ.D, ME. CENA, KOLIČINA) KUPEC (KUPEC#. NA/.IVKUP, NASLOVKUP, TELEFON, KONTAK'1) S stališča zahtev relacijskega modela taka organizacija podatkov ni napačna, je pa taka relacijska shema (načrt) podatkovne baze slab. Kakovost relacijske sheme podatkovne ' baze lahko ocenjujemo glede na i-z polnjevanje štirih zahtev j ki jim mora ta shema ustrezati (Elmasri, Navathe, 2000 ): ■ semantika naj bo jasna, ■ podvajanje podatkov mora biti čim manjše, 28 Pri tem velja opozoriti, da načela, kot jih prikazujemo v tem podpoglavju, veljajo predvsem za operativne podatkovne vire. Pri podatkovnih virih, namenjenih podpori odločanju, podvajanje podatkov, katerega odsotnost je poglavitno merilo kakovosti sheme, ne predstavlja večjih težav. Upravljanje in uporaba podatkov ■ at ribu ti morajo imeti čim manj vrednosti NULL ter * shema ne sme dopuščati napačnih vrstic. Jasna semantika. Atribute združujemo v relacije tako, da je enostavno razumeti njen pomen. Na primer, v relacijski shemi P je lahko razumeti, da vsaka vrstica relacije KUPEC predstavlja podatke o enem kupcu. Po drugi strani pa v isti relacijski shemi relacija NAROČILO vsebuje a tribute naročil in trgovskih potnikov, kar otežuje razumevanje pomena (semantike) te relacije. V splošnem velja, da je relacijska shema toliko bolj kakovostna, kolikor je lažje razumeti semantiko (pomen) relacij. Med drugim to pomeni, da ne smemo mešati atributov različnih entitetnih tipov ali tipov povezav v isti relaciji. Podvajanje podatkov. Podvajanje podatkov v podatkovni bazi je nezaželeno, ker povzroča različne te žave (anomalije) prLvzdrževanju. Anomalije lahko razdelimo v tri skupine: ■ Anomalije pri vnosu. Če želimo v primeru uporabe relacijske sheme P vnesti ob zaposlim podatke o trgovskem potniku, t ega ne mo remo, s.torih. do kler trgovski pomik ne dobi vsaj. enega naroaki, saj so podatki o trgovskih potnikih vezani na naročila (relacija NAROČILO). Problem bi na (zelo neroden) način rešili tako, da bi vneslijiamiiOjeria-naračila. Z vnosom podatkov v slabo načrtovano podatkovno bazo pa je povezan še en problem. Ko v relacijo NAROČILO relacijske sheme P vnašamo podatke o naročilih, moramo za vsako naročilo vnesti podatke o trgovskem potniku. To pomeni, da mora mo mnogokrat vnesti iste podatke, pri čemer moramo paziti, da ohranjamo konsistentnost podatkovne baze, torej, da so podatki o istem trgovskem potniku vedno enaki. V relacijski shemi R teh problemov ni, saj podatke o vsakem trgovskem potniku vnesemo le enkrat (četudi še ni sprejel nobenega, naročila, ni problemov), za vsako naročilo, ki ga sprejme, pa vnesemo le njegovo šifro. ■ Anomalije pri spreminjanju vrednosti podatkov. Če trgovski potnik, na primer, spremeni priimek, moramo v primeru uporabe relacijske sheme P, kjer se podatki o trgovskih potnikih podvajajo, ta priimek spremeniti povsod. To pomeni poleg odvečnega dela tudi večjo možnost napak. V 112 Podatkovne baze relacijski shemi R teh problemov zopet nimamo, saj vsebuje posebno relacijo s podatki o trgovskih potnikih, kjer je priimek vsakega trgovskega potnika shranjen le enkrat. ■ Anomalije pri brisanju. Vzemimo za primer (spet uporabljamo nekakovostno relacijsko shemo P) . da smo za nek izdelek I do sedaj dobili le eno naročilo. Podatki o izdelku so torej zabeleženi le enkrat v tabeli POSTAVKA. Če kupec prekliče omenjeno naročilo, moramo zbrisati pojej* podatkov o naročilu (relacija NAROČILO) tudi postavke naročila (relacija POSTAVKA). S tem pa smo izgubili tudi-edin.i-aapi^'XL. .izdelkn T. torej v podatkovni bazi nimamo več podatkov o tem izdelku. Podatkovno bazo načrtujemo tako, da ne prihaja do naštetih anomalij. Če od tega pravila odstopamo, moramo poskrbeti, da programi, ki delajo s podatkovno bazo to upoštevajo, na primer, da ob spremembi podvojenega podatka avtomatično poskrbijo za ažuriranje vseh njegovih kopij. Vrednosti NULL. Veliko število vrednosti NULL lahko predstavlja težave, pri uporabi podatkovne baze (predvsem pri združevanju podatkov iz več tabel), hkrati pa otežuje razumevanje pomena relacije. Vrednost NULL lahko razumemo na različne načine: ■ endteta, ki jo predstavlja vrstica, nima vrednosti za ta atribut, ■ vrednost atributa za to vrstico ni znana ah ■ vrednost atributa je znana, a manjkajoča (je še nismo vnesli v podatkovno bazo). Iz teh razlogov atributov, za katere pričakujemo, da bodo imeli v relaciji mnogo vrednosti NULL, v to relacijo ne vključujemo. Na primer, če imamo relacijo s podatki o delavcih DELAVEC (ŠIFRA . IME, PRIIMEK, ŠIFRA, EMŠO, PLAČA, E-POŠTA) in vemo, da ima le okoli 5 % delav cev-e=poštni naslov, potem v stolpcu E-POŠTA pričakujemo mnogo (95 %) vrednosti NULL. V tem primeru je bolj smiselno narediti pose bno relacijo z nalovi e -pošte . Upravljanje in uporaba podatkov 113 DELAVEC (ŠIFRA. IME, PRIIMEK, ŠIFRA, EMŠO, PLAČA) E-NASLOV fŠIFRA. E-POŠTA) V relaciji E-NASLOV bodo podatki o e-poštnih naslovih le za delavce, ki tak naslov imajo, po potrebi pa v poizvedbi podatke iz obeh tabel združimo. Napačne vrednosti. Zaradi slabega načrtovanja lahko pri uporabi podatkov (poizvedovanju) dobimo celo napačne odgovore 2 ' 2 . Posebej pozorni moramo biti pri izbiri atributov, ki so namenjeni povezavi med relacijami. Atribut, ki služi za povezavo med dvemaAjdadjamaJnora biti vedno glavni ključ ene relacije, v drugi pa del sestavljenega ključa ali tuji ključ. V Osnovni napotki za načrtovanje podatkovne baze Tipične slabosti, ki se pojavljajo v relacijskih shemah, in kako jih odpravimo ter druge osnovne napotke za načrtovanje podatkovne baze spoznajmo kar na primeru. Tvoriti želimo podatkovno bazo za poslovno področje prodaje. Zaradi enostavnosti se bomo omejih samo na sprejem naroč il. Naši , trgovski potnik i obiskujejo stranke, (podietia ): vsak od njih je zadolžen za neko slovensko regijo. Ob vsakem obisku izpolnijo naročilnico, katere primerek je prikazan na sliki 34. Ker je razumevanje težav, ki se pri tem pojavijo, nekoliko težje, jih tu ne obravnavamo. Opisane so, na primer, v (Elmasri, Navathe, 2000). 114 Podatkovne baze ', o, o, ] Naslov |Pot 12. tffe Telefon |( 061) 33- 1 1 Kontaktna oseba Q Št. Izdelek Me 32.1-452 Kisle vj u nA s i c e k os 192, 00 S! T 1,00 192,00 $>\T 125-456 Sol dobska ne 44. JO S! T 10,00 441, 00 S! T Skupna vrednost naročila (s popustom) | 653, 00 Sl T [ Na naročilo je bil odobren popust v vi.šini | | %. Šifra TP | f| Ime in priimek |AVtej Labmeb R egija A JE B S L'A Cena Kol Znesek Slika 34: Primer naročilnice Zaradi boljšega spremljanja in učinkovitejše realizacije naročil ter boljše podpore poslovnemu odločanju želimo te podatke shranjevati v podatkovni bazi 30 . Katere podatke shranimo v bazo? Praviloma v podatkovni bazi ne shranjujemo podatkov, ki so enaki na vsakem izvodu dokumenta. V našem primeru se na vsaki naročilnici pojavi naziv, naslov in drugi podatki o našem podjetju. Teh podatkov ne bomo shranili v bazi, pač pa bodo na šabloni naročilnice (poročilu). Izpis naročilnice na tiskalniku bo torej sestavljen iz šablone, ki vsebuje fiksne elemente vsake naročilnice in opredeljuje obliko izpisa, ter podatkov o naročilu. k Lbodo prebrani iz po datkovne baze. Prav tako praviloma ne shra njnjemp,_iz£amnanih (izpeljanih, izvedenih) podatkov, to je podatkov, ki jih izračunamo (izpeljemo) iz drugih, saj jih lahko programi hitro izračunajo 31 . V bazi torej ne bomo shranili zneska za posamezni izdelek in skupne vrednosti naročila. Šablona za izpis 3 ^ Pri tem nas trenutno ne zanima, na kakšen način bo potekal vnos naročil. Vsekakor ne bi bilo smiselno izpolnjevanje naročilnic in naknadno pretipkavanje podatkov v podatkovno bazo. 31 V praksi zaradi različnih vzrokov to pravilo tudi kršimo. Na primer, zaradi problema zaokroževanja in natančnosti knjigovodskih knjižb pogosto hranimo tudi znesek naročila, računa, davka ... Upravljanje in uporaba podatkov 115 naročilnice bo na mestu teh podatkov vsebovala ustrezne formule za izračun iz nene izdelka in namrene-kokorip rih izpisu naročilnice (na zaslon ali tiskalnik) pa se vrednosti izračunajo po formuli in izpišejo. Zakaj ni smiselno shranjevati izračunanih podatkov? Če bi se spremenila vrednost nekega podatka, bi morali spremeniti vse shranjene vrednosti iz tega podatka izračunanih podatkov. Ce imamo shranjen datum rojstva, ni smiselno shranjevati starosti, saj bi morali venomer vrednost tega podatka (starost) spreminjati. Slika 35: Šablona naročilnice Znebimo se večvrednostnih atributov. Pri razmišljanju, kako bi organizirali podatke z naročilnice s slike 34, bi bila prva in najbolj preprosta misel, da bi vse podatke shranjevali v eni sami tabeli, v kateri bi vsaka vrsti ca predstavljala ena naročilo, torej podatke z ene naročilnice ( relacijska shema RO): NAROČILO (NAROČILO#, DATUM, POPUST, TP#, IMETP, PRIIMEKTP, R0 REGIJA, KUPEC#, NAZIVKUP, NASLOVKUP, TELEFON, KONTAKT, IZDELEK#, NAZIVIZD, ME, CENA, KOLIČINA) Izpeljanih atributov nismo vključili v shemo v skladu s prejšnjim nasvetom. Problem pri tej shemi so g ečvre dnostni atributi, to so tisti, kiJmaj.Q_ji 2 _e»i naročilnici več vxeduo.su (IZDELEK#, NAZIVIZD, ME, CENA, KOLIČINA). 116 Podatkovne baze Vemo, da relacijski model ne dopušča večvrednostnih atrihp fpv (glej poglavje Relacijski model podatkov) in ni mogoče tvoriti podatkovne baze, ki bi bila definirana z RO, ki potemtakem sploh ni relacijska shema. Sistemi za upravljanje podatkovnih baz torej ne dovoljujejo tvorbe tabel, kakršna je prikazana na sliki 36. Slika 36: Primer podatkov za "relacijsko shemo" RO Večvrednostnih atributov se znebimo tako, da za skupi no večvred nostnih atributov tvorimo novo relacijo (tabelo). V relaciji NAROČILO torej pustimo vse atribute, ki imajo za eno naročilo le eno vrednost; to so podatki, ki so v glavi in nogi naročilnice. Podatke o po stavkah naročil pa shrani mo, v drugo tabelo (vse postavke z vseh naročil). Relacijska shema bi bila potemtakem (R01): „ „„ NAROČILO (NAROČILO#, DATUM, POPUST, TP#, IMETP, PRIIMEKTP, R01 v REGIJA, KUPEC#, NAZIVKUP, NASLOVKUP, TELEFON, KONTAKT) POSTAVKA (IZDELEK#, NAZIVIZD, ME, CENA, KOLIČINA) Primer podatkov je prikazan na sliki 37. Upravljanje in uporaba podatkov 117 Slika 37: Primer podatkovne baze za relacijsko shemo R01 Iz primera hitro ugotovimo, da iz tako organizirane podatkovne baze ni več mogoče razbrati, katera postavka sodi h kateremu naročilu. Podatkov iz obeh tabel ni več mogoče povezah. Spoznali smo že, da v relacijski podatkovni bazi podatke iz več tabel povezujemo s skupnimi atributi. Očitno je, da bomo k vsaki postavki dodali še šifro naročila, ki mu pripada. Tako dobimo relacijsko shemo Rl: „ , NAROČILO (NAROČILO# . DATUM, POPUST, TP#, IMETP, PRIIMEKTP, Rl REGIJA, KUPEC#, NAZIVKUP, NAŠLO VKUP, TELEFON, KONTAKT) POSTAVKA fNAROČILO#. IZDELEK# . NAZIVIZD, ME, CENA, KOLIČINA) V obeh relacijah smo določili glavna ključa. Opazimo, da ima druga relacija sestavljen glavni ključ, saj nobeden od atributov sam ne zadostuje za ključ. Pomen obeh relacij je, upajmo, očiten: vsaka vrstica relacije NAROČILO predstavlja podatke o enem naročilu, vsaka vrstica relacije POSTAVKA pa eno postavko nekega naročila. 118 Podatkovne baze Slika 38: Primer podatkovne baze za relacijsko shemo R1 Splošno pravilo je: V primeru, ko bi imeli v relaciji večvrednostne atribute, Jih izločimo v novo relacijo, kaieti (razen večvrednostnih atributov) d odamo š e ključ relacije, ki nima večv rednostnih atrihutCK- Nova relacijaJaoJmelauEedna-s estavljen n g-lavni ključ, k aterega del bo tudi dodani ključ druge relacije. Odpravimo podvajanje podatkov. Shema R1 je sicer povsem v skladu z zahtevami relacijskega modela in je mogoče tvoriti tako podatkovno bazo. Pogled na primer podatkov za to shemo (glej sliko 38) pa pove, da R1 ni najboljša shema, saj je v primeru precej podv ajanja podatkov.- V relaciji POSTAVKA se pri vsakem naročilu nekega izdelka pojavijo vsi njegovi podatki (NAZIVIZD, ME, CENA). Tako ponavljanje povzroča anomalije (glej podpoglavje Kakovost relacijske sheme). Če se, na primer, spremeni cena izdelka, moramo ta podatek spremeniti pri vseh naročilih. Zato je smis£lno-tKoriti.j}ovo relacij o IZD ELEK, ki bo vsebovala podatke o. izdelkih, o vsakem izdelku samo enkrat. Ta nova tabela vsebinsko pre dstavlja šifra nt izdel k ov oziroma cenik. Povezava med relacijama. POSTAVKA in T7.DF.T.F.K vzpo stavimo s_.skupninx..a.tributQm. očitno bo to IZDELEK#. Nova relacijska shema je potem (R2): NAROČILO (NAROČILO#. DATUM, POPUST, TP#, IMETP, PRIIMEKTP, REGIJA, KUPEC#, NAZIVKUP, NAŠLO VKUP, TELEFON, KONTAKT) POSTAVKA (NAROČILO#. IZDELEK#. KOLIČINA) IZDELEK (IZDELEK#. NAZIVIZD, ME, CENA) Upravljanje in uporaba podatkov 119 Ker se količina naročenega izdelka razlikuje orl naročila Ho naročila ho ta atribut ostal v relaciji POSTAVKA. Vrstica relacije'POSTAVKA vsebuje informacijo, da je bil z naročilom s šifro NAROČILO# naročen izdelek s šifro IZDELEK# v količini KOLIČINA. Vsaka vrstica relacije IZDELEK pa vsebuje podatke o enem izdelku 32 . Podvajanje podatkov je prisotno tudi v relaciji NAROČILO, pojavi se kar za dve skupini atributov. Podatki o kupcih in o trgovskih potnikih se ponavljajo pri vseh naročilih, pri katerih gre za istega kupca ali trgovskega potnika. Tudi to podvajanje odstranimo na podoben način, torej tvorimo novi relaciji,. za. vsako.skup ino atributov (podatki o trgovskih potnikih in kupcih) eno. Spet moramo seveda poskrbeti za atribute, ki bodo služili za povezavo podatkov iz tabel. Dvom lahko povzroča atribut POPUST, če ne poznamo njegovega pomena. Je to popust, vezan ij : na kupca (določenemu kupcu priznavamo vedno isti popust), morda na trgovskega potnika? Vzemimo, da se lahko vsak trgovski potnik zarasak o naročilo posebej odloča za višino popusta. Torej je atribut P OPUST vezan na naročilo . Zdaj lahko razbijemo relacijo NAROČILO in dobimo relacijsko shemo (113). , NAROČILO (NAROČILO#. DATUM, KUPEC#, TP#, POPUST) R3 IZDELEK (T7.DELEK#. NAZIVIZD, ME, CENA) POSTAVKA (TZDELEK#. NAROČILO#. KOLIČINA) KUPEC (KUPEC#, NAZIVKUP, NAŠLO VKUP, TELEFON, KONTAKT) TRG-POTNIK (TP# . IMETP, PRIIMEKTP, REGIJA) Za vsako naročilo torej zapišemo le podatke o šifri kupca in trgovskega potnika , saj lahko ustrezne podrobnejše podatke najdemo v ustreznih tabelah - šifrantih. Zaradi poenostavitve smo v tem primeru namenoma spregledali problematiko časovne odvisnosti cene izdelka kar v praksi običajno rešujemo z uvedbo še ene relacije, ki za isti izdelek vsebuje cene, veljavne v različnih časovnih obdobjih, na primer TUNIK (IZDELEK#, DATUMOP# , DATUMDO& CENA). 120 Podatkovne baze Slika 39: Primer podatkovne baze za relacijsko shemo R3 Drugih (nepotrebnih) podvajanj podatkov v relacijski shemi R3 ni, zato je primerna kot-načrtza^rodatkovn o bazo. Opozorimo bralca, da v primeru, ko imamo v bazi dve enaki vrednosti nekega atributa, to ni nujno podvajanje podatkov. Na primer, če imamo dvakrat isto vrednost atributa POPUST v relaciji NAROČILO, vsaka izmed (sicer enakih) vrednosti predstavlja informacijo o višini p op usta za eno izmed naročil. Te vrednosti ne moremo shraniti samo enkrat, ne da bi izgubili informacijo o vrednosti popustov za enega izmed teh dveh naročil. Opisani razmisleki so zaobjeti v formalnem postopku, s katerim v treh korakih zaretnciiheinfl zan shnrp o, pri tnipri j p pnrtvnjnpjp pmtntlrnv minimalno. P ri normalizaciji, k ot se postopek imenuje, uporabljamo analizo funkcionalnih odvisnosti med atributi (glej poglavje Funkcionalna odvisnost). Normalizacijo je mogoče uporabiti na vseh vrstah modelov podatkov (hierarhičnem, mrežnem, relacijskem in objektnem), vendar se v nadaljevanju omejimo le na primer relnrijslcega modela, ki ie za današnjega uporabnika najzanimivejši in najlažje dostopen. Upravljanje in uporaba podatkov 121 Kot bomo videli, postopek normalizacije le formalizira razmisleke, ki smo jih že spoznali v bolj neformalni obliki. Začnemo z nekim uporabniškim modelom, to je uporabnikovim pogledom na podatke, ki ga prevedemo v t.i. nenormalizirano relacijo. To naredimo tako, da nenormalizirano relacija vse buje vse atribute upor abni kovega modela. Nekateri atributi so lahko večvrednostni, kar ugotovimo tako, da analiziramo povezave meri ntrihiitnm, ki identifirirn upnrnhniškj pindel, in ostalimi atributi. Vzemimo za primer uporabniškega modela spet dokument Naročilnica s slike 34. Šifra naročila identificira naročilnico, zato analizirajmo povezave med atributom NAROČILO# in ostalimi atributi. Vidimo, da skupino večvrednostnih atributov sestavljajo postavke naročil. V relacijski shemi skupine večvrednostnih atributov označimo tako, da jih omejimo s še enim (notranjim) oklepajem. 122 Podatkovne boze NAROČILO (NAROČILO#, DATUM, POPUST, TP#, IMETP, PRIIMEKTP, REGIJA, KUPEC#, NA2IVKUP, NASLOVKUP, TELEFON, KONTAKT, (IZDELEK#, NAZIVIZD, ME, CENA, KOLIČINA)) Ker relacijski model ne dopušča večvrednostnih atributov, jih odpravimo v prvem koraku normalizacije - pri pretvorbi v prvo normalno formo. To storimo tako, da aaa armalizirono relacijo pretvorimo v dve (ali več, glede na skupine večvrednostnih atributov) relaciji. V prvo relacijo damo vse atribute, ki niso večvrednostni, v drugo pa vse večvrednostne atribute .uLglavnUdjuč prve relacije V drugi relaciji dobimo vedno sestavljen glavni ključ. Relaciji sta po tem koraku vnrvi normalni formi (1 NF). kar pomeni, da ne vsebujeta večvrednostnih atributov. NAROČILO ( NAROČILO#. DATUM, POPUST,TP#, IMETP, PRIIMEKTP, REGIJA, KUPEC#, NAZIVKUP, NASLOVKUP, TELEFON, KONTAKT) POSTAVKA (NAROČILO#. IZDELEK#. NAZIVIZD, ME, CENA, KOLIČINA) V drugem koraku - pri pretvorbi v drugo normalno formo odstranimo nezaželene delne (pn rrinlne) Nek neključni atribut je delno odvisen od glavnega ključa, kadar je funkcionalno odvisen od dela sestavljenega glavnega ključa. Velja opozoriti, da je po definiciji glavnega ključa neključni atribut vedno funkcionalno odvisen od celotnega glavnega ključa. V t POSTAVKA (NAROČILO#. IZDELEK#. NAZIVIZD, ME, CENA, KOLIČINA) LLf} Očitno je tudi, da v relacijah, ki nimajo sestavljenega glavnega ključa, ne moremo imeti delnih odvisnos ti. Delne odvisnosti odstranimo tako, da relacijo, ki jih vsebuje, razbijemo v dve (ali več, če obstajajo delne odvisnosti od različnih delov glavnega ključa). V eno relac ijo damo celoten glavni Hj"č in vse ntrihnte ki so odvisni samo od celotnega, glavnejajdjuča^ v drugo relacijo pa vse nekljufne atribute, ki so delno odvisni od glavnega ključa, in še ustrezni del glavnega kljufo. Po razbitju so relacije v drugi normalni formi (2 NF), ker so vsi neključni atributi odvisni le od celotnega sestavljenega glavnega ključa. NAROČILO ( NAROČILO#. DATUM, POPUST,TP#, IMETP, PRIIMEKTP, REGIJA, KUPEC#, NAZIVKUP, NASLOVKUP, TELEFON, KONTAKT) POSTAVKA (NAROČILO#. IZDELEK#. KOLIČINA) IZDELEK (IZDELEK#. NAZIVIZD, ME, CENA) V zadnjem koraku normalizacije, pretvorbi v tretjo normalnu formo, pclstmnimo.Ja-.tmnzitivne_od-visiiQstL, ki prav tako povzročajo težave (anomalije) pri uporabi podatkovne baze. Tranzitivna odvisnost je funkcionalna odvisnost med dvema neklj" f n imn atuhuinmn R plnrijn ki vsebuje tranzitivne odvisnosti, spet razbijemo v dve (ali več, glede na število neključnih atributov, od katerih so drugi neključni atributi odvisni) relaciji. Če je skupina nekUuMJLOLTlii>Jil£^Q^isna~£ul-JieJcl 4 ci£nfiaci nlalmlfl V fntem damo v eno relacijo vse te atribute vključno z A. V tej relaciji bo A glavni ključ. V drugi relaciji bodo vsi atributi, ki niso v prvi, dodamo pa še atribut A, ki bo tu tuji ključ. Po razbitju so vse relacije v tretji normalni formi (3 NF), saj ne vsebujejo neželenih tranzitivnih odvisnosti. Upravljanje in uporaba podatkov 123 Spet torej uporabimo analizo funkcionalnih odvisnosti, da poiščemo morebitne odvisnosti med neključnimi atributi. • I 'i ^ ^ NAROČILO ( NAROČILO#, DATUM, POPUST, TP#, IMETP, PRIIMEKTP, REGIJA, i KUPEC#, NAZIVKUP, NASLOVKUP, TELEFON, KONTAKT) : I_ t t t t j in z razbitjem dobimo i NAROČILO ( NAROČILO#. DATUM, POPUST, TP#, KUPEC#) j TRG-POTNIK (IP#, IMETP, PRIIMEKTP, REGIJA) I KUPEC (KUPEC#. NAZIVKUP, NASLOVKUP, TELEFON, KONTAKT) j POSTAVKA (NAROČILO#. IZDELEK#. KOLIČINA) IZDELEK (IZDELEK#. NAZIVIZD. ME. CENA) i S pretvorbo relacij v tretjo normalno formo dobimo tako organizacijo podatkov, ki je stabilna, ne povzroča anomalij, ■ podvajanje podatkov pa je zmanjšano na najmanjšo možno mero. : Poleg omenjenih normalnih form obstajajo še višje normglneJotme, vendar so te bolj zapletene, hkrati pa obravnavajo j probleme, ki se v praksi pojavijo zelo redko. Zato jih tukaj ne obravnavamo. i To, da smo podatke z ene naročilnice porazdelili v več tabel, seveda ne pomeni, da bo moral uporabnik, če bo želel pregledati naročilnico, brskati po vseh tabelah. Za uporabnika vedno pripravimo tak pogled na podatke, kot ga potrebuje. Na sliki 34 je prikazan primer pogleda na podatke (naročilnica), ki prikazuje hkrati podatke iz več tabel. Drug pogled na iste podatke (iz istih tabel) je prikazan na sliki 17 (b). Prednost organizacije podatkov, kot smo jo oblikovali zgoraj, pa je, da v primeru novega naročila istega kupca uporabnik ne bo več vnašal vseh podatkov o kupcu, pač pa se z vn osom šifre k upc a__takouz.pii.Ctovsi-njcgovi podadu,.ki. so žg shran j eni v t-aheli n kupni. Hkrati taka organizacija podatkov omogoča, da na isto podatkovno bazo "obesimo" različne poglede. Tako bi lahko izdelali poročila o prodaji po kupcih, po izdelkih ali po mesecih, seznam vseh kupcev, cenik izdelkov. Pri tem pa se vsaka sprememba v podatkih takoj odraža v vseh teh pogledih. Programska orodja za podporo razvoju podatkovnih baz 7o ra-zvnju po dajkovnih-haz. je na voljo velika izbira programskih orodij, ki sodijo v skupino orodij ČASE (angl. Computer Aided Sofhvare Engineenng). 124 Podatkovne baze Orodja se med seboj bistveno razlikujejo po možnostih, ki jih poleg risanja ER diagramov ponujajo, razlike pa so tudi že pri tem, kaj vse je mogoče z ER diagramom prikazati. Pri nekaterih lahko izbiramo med različnimi oznakami, nekateri dopuščajo tudi prikaz t.i. razširjenega ER diagrama ... Kakovostnejša orodja znajo iz ER diagrama tvoriti shemo relacijske podatkovne baze, ustrezne stavke jezika SQL za tvorbo podatkovne baze, ali celo kar neposredno tvoriti podatkovno bazo 33 . Pri tem poskrbijo tudi za pravilno st rukturo poHnt-hoir — odpravijo podvajanje podatkov. Seveda za slednje potrebujejo poslovna pravila, iz katerih razberejo funkcionalne odvisnosti med atribud. Pogosto so orodja za podporo razvoju podatkovnih baz le del orodij ČASE, ki podpirajo razvoj celotnega informacijskega sistema, od modeliranja preko načrtovanja pa vse do generiranja programske kode in podatkovne baze. Najboljša orodja imajo tudi možnost t.i. vzvratneg aJnžemrstva- (angl. backward engineering), kar pomeni, da iz obstoječe- podatkovne.baze, izdel ajo ER d iagram. Ta možnost je koristna pri prenovi informacijskega sistema, saj naredimo spremembe na ER diagramu in potem ponovno tvorimo prenovljeno podatkovno bazo. Pomembna je tudi možnost izdelave jdokumentacij e poda tkovne ..baze, saj so sistemi brez dokumentacije vse prepogost pojav v praksi, kar otežkoča vzdrževanje in kasnejše prenove sistema. Če orodje avtomatično tvori dokumentacijo, je verjetnost, da bo podatkovna baza dokumentirana, gotovo večja. Seveda je kakovosti primerna cena; nekatere bolj preproste pakete lahko dobimo celo brezplačno, cene najboljših orodij ČASE pa so zelo visoke. Orodja ČASE lahko bistveno prispevajo k učinkovitosti in kakovosti dela analitikov, načrtovalcev sistema in programerjev, vendar to ne pomeni, da bodomb uporabi takega orodja ostali brez dela. Ta orodja so jim le v pomoč pri delu in jih ne morejo nadomestiti. 33 vrednost orodja ocenjujemo tudi po tem, s katerimi SUPB sc zna neposredno povezati. Upravljanje in uporaba podatkov 125 3.3 Uporaba podatkovnih baz Kaj je SOL? Jezik SQL (angl. Structured Query Language) je standardni jezik za delo z tgllLgij sidrni podatk ovnimi bazami, kar pomeni, da ga razumejo vsi pomembnejši SUPB. Ime je pravzaprav ponesrečeno, saj omogoča mnogo več kot le poizvedovanje (angl. querying). S stavki tega jezika lahko: * definiramo tabele (strukturo, tipe atributov ...), ■ spreminjamo definicijo tabel, " brišemo tabele, ■ vnašamo podatke v tabele, * brišemo vrstice tabel, * spreminjamo (posodabljamo) podatke v tabelah, * poizvedujemo in * še mnogo drugega. Iz seznama je očitno, da sodi jezik SQL tako v skupino jezikov za definiranje podžtkovdB DL). kot tudi v skupino jezikov za manipula cije^.podatkov (DML). Jezik SQL je standardiziran pri organizaciji ANSI (American National Standards Institute) in pri ISO (International Standard Organization). Prva inačica jezika SQL je bila standardizirana leta 1986, tretja inačica SQL 3 pa prinaša nekatere novosti, ki v relacijske podatkovne baze že vključujejo elemente —o bjektn ega pri stopa. Želja pri razvoju jezika je bila, da bi bil čimbolj podoben naravnemu (seveda angleškemu) jeziku, hkrati pa naj bi bil dovolj strukturiran tudi za računalniško okolje. Zato se je prvotno imenoval SEQUEL (Structured English QUEry Language - strnlmim;anJingkŠkLjx^^ . Mnogi sistemi za upravljanje relacijskih podatkovnih baz ponujajo prijazne grafične uporabniške vmesnike za zgoraj našteta opravila, ki uporabniku omogoča delo, ne da bi poznal jezik SQL. 126 Podatkovne baze Zakaj SQL? Zakaj naj bi torej uporabnik poznal (vsaj osnove) dela z jezikom SQL, če so mu na voljo grafični uporabniški vmesniki, s katerimi lahko z nekaj kliki miške in le malo dpkanja naredi isto kot s stavki jezika SQL, pri čemer mora poznati še njegovo sintakso (slovnična pravila)? Najpomembnejši razlog je dejstvo, da se uporabniški vmesniki različnih SUPB med seboj razlikujejo. Po drugi strani pa je SQl»-standard, ne samo na papirju, pač pa tudi de facto standard, ki ga uporabljajo praktično vsi sistemi za upravljanje relacijskih podatkovnih baz 34 . Tako lahko nekdo (tudi program), ki pozna SQL, Pri zastavljanju poizvedb večinoma tudi ni problem poznavanje jezika SQL (ta vsebuje le malo elementov in se ga hitro naučimo) ali grafičnega okolja. Ponavadi je veliko bolj zahtevno pravilno ..se staviti vprašanje , da dobimo odgovor, kot ga pričakujemo in želimo. Vsebinsko je torej poizvedovanje lahko zelo bogato, kljub preprostosti jez i ka SQT„ Logika zastavljanja poizvedb je povsem enaka, ne glede na to, ali uporabljamo jezik SQL ali grafično okolje. Razlika med obema načinoma dela je predvsem v količini tipkanja. Učenje samega jezika je torej obrobnega pomena, poudarek naj bo na vsebini. Jezik SQL Kot je znano, moremo in moramo ločiti dve skupini opravil v okviru dela s podatkovnimi bazami: ■ delo z metapodatki (definiranje baze, sprememba strukture tabel in podobno) ter ■ delo s podatki (vnos, posodabljanje, zajemanje - poizvedovanje po bazi). Za uporabnika je bolj zanimivo slednje, zato bomo stavkom, ki so namenjeni delu s podatki, namenili več pozornosti, posebej še stavku za.poistedovan je po bazi. 34 Res pa jc^da pozna skoraj vsak SUPB nekatere posebnosti jezika SQL. Stanje lahko primerjamo s slovenskim jezikom, ki ima sicer narečja, pa vendar vsi govorimo isti jezik in se med seboj bolj ali manj razumemo. Upravljanje in uporaba podatkov 127 Jezik SQL bomo spoznavali predvsem na primerih in se ne bomo spuščali v pretirane podrobnosti 35 . Definiranje baze Za ilustracijo dela z jezikom SQL bomo tvorili in v nadaljevanju uporabljali relacijsko podatkovno bazo, katere načrt predstavlja shema R3 iz poglavja Osnove dobrega načrtovanja podatkovnih baz. Ker je shema že v primerni obliki (podvajanje podatkov je odpravljeno), jo lahko takoj uporabimo za definira nje p o datkovne Jiazg* Stavek jezika SQL, ki je namenjen defini r anju tabele, je CREATE TABLE. Ker z njim vnesemo opis (strukturo) tabele, torej metapodatke, sodi v skupino DDL stavkov jezika SQL. 35 Podrobneje lahko zahtevnejši bralec spozna jezik SQ1. v vsakem učbeniku o podatkovnih bazah; nekoliko več kot tu tudi v (Grad, Jaklič, 1996). 128 Podatkovne baze Na sliki 41 so prikazani stavki CREATE TABLE za vseh pet relacij primera naročanja. Opazimo, da moramo za vsako tabelo podati ime ter našteti imena in tipe podatkov za vse atribute, ki nastopajo v relaciji. Definicije atributov so naš tete v oklepaju i n med seboj ločene z vejicami. Tako kot vsak stavek v jeziku SQL, se tudi CREATE TABLE konča % ločilom podpičje. Po datkovni tip k; ki jih moremo uporabiti, so odvisni od SUPB. V primeru so uporabljeni nekateri najpogostejši: INTEGER (cela števila), REAL (realna števila), VARCHAR (tekstovni podatek), DATE (datum), ter CURRENCY (denarni znesek). Pri tipu VARCHAR(j) s parametrom / dolo čimo največjo dolžino, ki jo bo lahko imela vrednost tega atributa. Nize (vrednosti) zapišemo med znaka apostrofa, npr. 'To je niz z dolžino 23.' Pripomnimo, da s tem, ko določi mo tip atributa^ že v določeni meri definiramo tudi omejitve celovitosti (glej podpoglavje Sistemi za upravljanje podatkovnih baz). Na primer, pri vnosu podatka v datumsko polje bo SUPB preverjal, če je vrednost dopustna. Tako bo, na primer, preprečil vnos vrednosti 31.2.1999, ker ta datum ne obstaja. Opozoriti velja, da morata biti atributa, ki pomenita isto, a se nahajata v dveh (ah več) tabelah, istega tipa. Na primer, atributa IZDELEK# v tabeli IZDELEK in v tabeli POSTAVKA pomenita isto, zato bosta vsebovala istovrstne podatke in morata biti istega tipa. Upravljanje in uporaba podatkov 129 CREATE TABLE IZDELEK ( IZDELEK# VARCHAR(7) CONSTRAINT IZDELEKPK PRIMARY KEY, NAZIVIZD VARCHAR(50) NOT NULL, ME VARCHAR(IO), CENA CURRENCY ); CREATE TABLE KUPEC ( KUPEC# INTEGER CONSTRAINT KUPECPK PRIMARY KEY, NAZIVKUP VARCHAR(50), NASLOVKUP VARCHAR(50), TELEFON VARCHAR(30), KONTAKT VARCHAR(50) ); CREATE TABLE TRG-POTNIK ( TP# INTEGER CONSTRAINT TPPK PRIMARY KEY, IMETP VARCHAR(20), PRIIMEKTP VARCHAR(20), REGIJA VARCHAR(30) )i CREATE TABLE NAROČILO ( NAROČILO# INTEGER CONSTRAINT NARPK PRIMARY KEY, DATUM DATE, KUPEC# INTEGER, TP# INTEGER, POPUST INTEGER ); CREATE TABLE POSTAVKA ( IZDELEK# VARCHAR(7), NAROČILO# INTEGER, KOLIČINA REAL, CONSTRAINT POSTPK PRIMARY KEY ([IZDELEK#],[NAROČILO#]) ); Slika 41: SQL stavki za tvorbo podatkovne baze 130 Podatkovne baze Z določilom NOT NIJLL povemo, da mora vsaka vrstica tabele vsebovati vrednost za ta atribut. Drugače povedano, vrednost tega atributa ne sme manjkati za nobeno vrstico tabele. Tako moramo -za vsak izdelek pri vnosu navesti poleg šifre še naj manj njegov naziv , lahko pa manjka podatek o ceni (npr. dokler cena še ni določena). Glavni ključ je ena od omejitev 36 , ki jo lahko definiramo na tabeli. Zato jo definiramo v določilu CONSTRAINT (omejitev), kjer moramo omejitvi dati neko ime. Na primer, v tabeli IZDELEK smo definirali za atribut IZDELEK# omejitev vrste PRIMARY KEY (glavni ključ) z imenom IZDELEKPK. V tabeli postavka, ki ima sestavljen glavni ključ, nismo mogli omejitve vezati na en sam atribut, zato smo jo navedb posebej, v oklepaju pa smo še navedli, kateri atributi sestavljajo glavni ključ. Če se zgodi, da neke tabele ne potrebujemo več v podatkovni bazi, lahko tabelo (podatke in definicijo) odstranimo s stavkom DROP TABLE. Če bi se, na primer, odločili, da ne želimo več hraniti podatkov o trgovskih potnikih, bi lahko uporabili: DROP TABLE TRG-POTNIK; Lahko pa tudi kasneje dodamo atrib ut (stolpec) neki-tabeli. To storimo s stavkom ALTER TABLE. Na primer: ALTER TABLE TRG-POTNIK ADD TELEFON VARCHAR(30); Ta stavek doda tabeli TRG-POTNIK stolpec, kjer hranimo telefonske številke trgovskih potnikov. Vnos podatkov Ko smo definirali tabele, je vse pripravljeno za vnos podatkov. S_stavkam_ TTSJSFRT d od ajam o v tabelo nove vrstice. Najpreprostejša oblika stavka je 36 /c iz poglavja Relacijski model podatkov vemo, da vrednost tega atributa ne sme biti N Ul ,1. in da dve vrstici nc moreta imeti enake vrednosti. Upravljanje in uporaba podatkov 131 INSERT INTO TRG-POTNIK VALUES (7,'Tine','Cirman','Gorenjska 1 ); S tein Sl avkom smo v tabelo KUPEC vnesli podatke o enem kupcu, to je eno vrstico. Pri tem moramo vrednosti atributov navesti vGstera-^xstnem--redu, v katerem so bili atributi našteti v definiciji tabele. Poglejmo še en primer, kjer en pod atek (atribut) manjka.JNFa mestu, kjer bi morali zapisati vrednost atributa, zapišemo vrednost NULL:,- - INSERT INTO KUPEC VALUES (88,'Cepki',NULL,'066-33-22',NULL); Naslednja oblika stavka INSERT pa omogoča vnos_ vredno sti sa mo nekaterih atributov in to v poljubnem vrstnem redu, ki ga določimo v samem stavku INSERT. Na primer, INSERT INTO KUPEC (KUPEC#, NASLOVKUP, NAZIVKUP) VALUES (89,'Prva 1, Zg. Kašelj','AA d.o.o.'); Atributi, katerih vrednosti ne navedemo, dobijo vrednost NULL. Ce poskusimo vnesti vrstico brez vrednosti atributa, za katerega je bilo pri definiciji uporabljeno določilo NOT NULL, bo tak poskus zavrnjen. Tako nam bo po vnosu stavka INSERT INTO IZDELEK (IZDELEK#,ME,CENA) VALUES ('746-554','kg',300); javljena napaka, saj je bilo za naziv izdelka (atribut NAZIVIZD) uporabljeno določilo NOT NULL. Za nadaljnjo uporabo predpostavimo, da smo z uporabo ustreznih stavkov INSERT v tabele, ki smo jih definirali s stavki CREATE, vnesli nekaj podatkov (glej sliko 39). Brisanje vrstic S stavkom DELETE .brišemo eno ali več vrsficiz tabele. Oblika stavka je naslednja: DELETE FROM WHERE 132 Podatkovne baze Odstranijo se vrstice, ki ustrezajo pogoju navedenem v WHERE določilu. Ce bi prenehali prodajati olje, bi podatke o tern izdelku izbrisali iz tabele s stavkom DELETE FROM IZDELEK . WHERE IZDELEK# = '776-444'; Ce določilo W HERE izpustimo, se stavek nanaša na vse vrstice (pogoj je vedno izpolnjen). Spreminjanje vrednosti S stavkom UPDATE lahko s premenimo vrednosti atrihurov za en.o ali več vrstic hkrati. Sestavljen.je iz treh določil. V določilu UPDATE povemo, za katero tabelo želimo spreminjati vrednosti. V določilu-SET navedemo atribute in njihove nove vrednosti vgobliki = in te prireditvene stavke med seboj ločimo z vejicami. V določilu WHERE..pa povem o pogoje, ki določijo, za katere vrstice naj se spremenijo vrednosti at ributov iz določila SET. Oglejmo si dva primera. S stavkom UPDATE IZDELEK SET CENA = CENA*0.9 WHERE ME = 'kg’; za 10 % pocenimo vse izdelke, ki se prodajajo na kilograme. Če želimo razširiti prodajo tudi na področje notranjske regije, ki do sedaj ni bila pokrita, in bomo za to regijo zadolžili trgovske potnike, ki delajo v primorski regiji, potem uporabimo stavek: * UPDATE TRG-POTNIK SET REGIJA = 'Primorska in Notranjska' WHERE REGIJA = 'Primorska'; Upravljanje in uporaba podatkov 133 Poizvedovanje S poizvedbo (angl. query) izberemo iz podatkovne baze želene podatke. Za uporabnika je poznavanje možnosti poizvedovanja zagotovo najbolj zanimivo in uporabno, saj z a zajem (v nos) -podatkov in njihovo ažuriranje v večini primerov izdelamo ustrezne uporabniške vmesnike — pr ograme. Vseh poizvedb pa ponavadi ni mogoče vnaprej predvideti in izdelati ustreznih programov. Iz tega sledi potreba poi ad hQe..p.aizyedbah, ki je posebej značilna za višje nivoje upravljanja v podjetju. V relacijskih podatkovnih bazah in s tem pri poizvedovanju z uporabo jezika SQL je rezultat poizvedbe vedno neka tabela (relacija! . V jezikuJSQL jejpoizvedavanju na menjen stavek SELECT . katerega splošna oblika je najbolj zapletena izmed vseh stavkov te ga jezika. _ Najpreprostejša oblika stavka SELECT ima obliko SELECT FROM WHERE ; S tem stavkom iz tabele, katere ime navedemo v določilu FROM, izpišemo podatke iz tistih stolpcev, ki jih navedemo v določilu SELECT, in tistih vrstic., ki ustrezajo pogoju, navedenem v določilu. WHERE. Imena atributov (seveda morajo biti iz izbrane tabele), navedenih v določilu SELECT, morajo biti ločena z vejico. Na primer, SELECT IMETP, PRIIMEKTP FROM TRG-POTNIK WHERE REGIJA = 'Gorenjska'; nam izpiše imena in priimke trgovskih potnikov gorenjske regije. imetp priimektp Petra Cirman Tine Cirman 134 Podatkovne baze Stolpci so razporejeni, kot določimo v določilu SELECT. Na vrhu tabele se vedno izpišejo tudi imena a tributov. ‘ '7 Ce spustimo pogoj, potem se izpišejo vse vrstice tabele. Če pa namesto sčznama atributov zapišemo znak *, se izpišejo vsi atribu ti v vrstnem redu, ki je bil uporabljen pri definiranju tabele. Poizvedba SELECT * FROM KUPEC; povzroči naslednji izpis: Za numerične atribute lahko poleg enačaja v pogoju uporabimo tudi neenačaj: SELECT NAZIVIZD FROM IZDELEK WHERE CENA < 1000; izpiše nazive izdelkov, ki so cenejši od 1000 tolarjev: nazivizd __ Sol morska Kisle kumarice 500 g Jabolčni sok - šesterček * Z uporabo operatorja LIKE primerjam o., vrednosti tekstovnih atributoy_z_nddm vzorcem. S stavkom SELECT FROM WHERE NAZIVKUP, NASLOVKUP KUPEC NAZIVKUP LIKE 'A%'; Upravljanje in uporaba podatkov 135 zahtevamo izpis nazivov in naslovov kupcev, nazivkup |naslovkup Atlas d. d. Mirna 2, Lj Argonavti Cista 92a AA d.o.o. Prva 1, Zg. Kašelj katerih naziv se začne s črko A: i V vzorcu lahko uporabimo znak %, znak za podčrtavanje _ ter znake, ki so tudi sicer dovoljeni v takih atributih. Znaka % in _ imata naslednji pomen: % Označuje niz nič al i več (katerihkoli) znakov . _ Ozn ačuje nat anko efl-(kateakolj)j!jB?tk. Tako, na primer, stavek SELECT IMETP, PRIIMEKTP, REGIJA FROM TRG-POTNIK WHERE PRIIMEKTP LIKE ’%aJ; izbere trgovske potnike, katerih predzadnja črka priimka je a: Iskalni pogoj v določilu WHERE je lahko enostaven, kar že poznamo, ali pa sestavljen. Pri sestavljenem pogoju uporabimo več enostavnih pogojev, da sestavimo kompleksnejši pogoj. Če imamo dva enostavna pogoja in , potem lahko sestavimo naslednje pogoje: 136 Podatkovne baze AND Logični IN. Izbrane bodo v^e vrstice, ki izpolnjujejo tako kot . OR Logični (inkluzivni) ALI. Izbrane bodo vse vrstice, ki izpolnjujejo ali ali ( ali obal. . NOT Logična negacija. Izbrane bodo vse vrstice, ki ne izpolnjujejo pogoja . Z več enostavnimi pogoji lahko torej ob uporabi logič nih operatorjev A ND Oj-Lin. NOT sestavimo še zahtevnejše pogoje. Nekaj primerov: SELECT IZDELEK#, NAZIVIZD FROM IZDELEK WHERE ME = 'kg' AND CENA > 1000; izdelek# nazivizd 753-443 Sir Gauda Poizvedba SELECT NAZIVIZD FROM IZDELEK WHERE CENA > 100 AND NOT ME = 'kos'; izpiše nazive izdelkov, ki so dražji od 100 tolarjev na enoto in katerih merska enota ni ko s. nazivizd _ Sir Gauda Jabolčni sok - šesterček Upravljanje in uporaba podatkov 137 Namesto stavka SELECT NAZIVIZD, ME FROM IZDELEK WHERE CENA >= 100 AND CENA <= 1000; 'h, ki izpiše nazive in merske enote za izdelke, katerih cena je med 100 in 1000, lahko zapišemo tudi: SELECT NAZIVIZD, ME FROM IZDELEK WHERE CENA BETWEEN 100 AND 1000; Ta zapis določila WIIERE_ zahteva isto, namreč da je cena med (BETWEEN) 40000 in (AND) 80000. Do sedaj smo v- vseh primerih izbirali podatke (hkrati) iz ene same tabele. _S_ s t avkom S ELECT pa lahko izbiram o tudi podatke iz več tabel hkrati. SELECT FROM WHERE ; Tudi v seznamu tabel morajo biti imena tabel ločena z vejico. V določilu WHERE navedemo poleg iskalnih pogojev tudi povezovalne pogoje, ki povedo, kako so tabele med seboj povezane. Z drugimi besedami, s povezovalnim pogojem povemo, katera dy.auattibuta iz nekega para tabel, navedenih v FROM določilu, sta skupna obema tabelama. Oglejmo si primer. Za vsako naročilo želimo izpisati njegovo šifro, datum naročila ter naziv in naslov kupca. Očitno se podatki nahajajo v dveh tabelah (NAROČILO in KUPCI). Če bi zapisali poizvedbo SELECT NAROČILO#, DATUM, NAZIVKUP, NAŠLO VKUP FROM NAROČILO, KUPEC bi dobili odgovor (prikazan je le del tabele) 138 Podatkovne baze Odgovor so očitno izbrani stolpci za kartezični produkt d veKtahel. kar ni tisto, kar bi si želeli. Razlog je v tem, da nismo povedali, kako sta tabeli povezani, oziroma, da stolpec KUPEC# v tabeli NAROČILO pomeni isto kot stolpec KUPEC# v tabeli KUPCI. Stavek SELECT dopolnimo s povezovalnim pogojem SELECT NAROČILO#, DATUM, NAZIVKUP, NAŠLO VKUP FROM NAROČILO, KUPEC * WHERE NAROČILO.KUPEC# = ICUPEC.KUPEC# in dobimo kar je pravilno. Iskalnega pogoja v tem stavku nismo imeli. Upravljanje in uporaba podatkov 139 Ker se isto ime atributa (KUPEC#) pojavi v dveh tabelah, moramo, da ne bi prišlo do dvoumnosd, ime atributa razširiti še z imenom tabele, iz katere prihaja. Ime tabele zapišemo pred imenom atributa in ju povežemo s piko . kadar jv iste m stavku uporabljamo dva atributa z enakim imenom iz dveh tabel. Opozorimo še na to, da AžLumakihimeii nc. moremo sklepati na isti pomen atri b ut o v in obratno, v dveh tabelah imamo lahko atributa 'z različnima imenoma, ki pa pomenita isto. Tako bi lahko v relacijski shemi, ki jo uporabljamo, poimenovali atribute tudi takole. NAROČILO (ŠIFRA DATUM, KUPEC#, TP#, POPUST) IZDELEK (ŠIFRA. NAZIVIZD, ME, CENA) POSTAVKA (ŠIFRAIZD. ŠIFRANAR . KOLIČINA) KUPEC (ŠIFRA. NAZIVKUP, NASLOVKUP, TELEFON, KONTAKT) TRG-POTNIK (ŠIFRA. IMETP, PRIIMEKTP, REGIJA) Očitno je, da imajo atributi z imenom ŠIFRA v različnih tabelah različen pomen. Prav tako pa ima, na primer, atribut TP# isti pomen kot atribut ŠIFRA v tabeli TRG-POTNIK. Poglejmo zdaj še primer, ko poleg povezovalnih pogojev uporabimo še iskalne Za vsa naročila trgovskih potnikov iz gorenjske regije želimo izpisati, datum naročila ter kateri izdelki (nazivi) so bili naročeni. SELECT NAROČILO.NAROČILO#, DATUM, NAZIVIZD FROM N AROČILO . TRG-POTNIK, POSTAVKA, IZDELE K WHERE NAROČILO.TP# = TRG-POTNIK.TP# AND NAROČILO.NAROČILO# = POSTAVKA.NAROČILO# AND POSTAVK A.IZDELEK# = IZDELEK.IZDELEK# AND REGIJA = 'Štajerska'; Čeprav v izpisu nastopajo le atributi iz tabel NAROČILO in IZDELEK, pa v stavku potrebujemo tudi tabelo TRG-POTNIK, saj v njej preverjamo, iz katere Na la način lahko natančneje opredelimo atribut vedno, obvezno pa je le. takrat, 140 Podatkovne baze regije je trgovski potnik, in tabelo POSTAVKA, saj je le v njej informacija, kateri izdelki se nahajajo na posameznem naročilu 37 . V splošnem so rezultat poizvedbe vse vrstice, ki ustrezajo iskalnim in povezovalnim p ogojem, tudi če so vrednosti vseh atributov iz določila SELECT za nekatere pare vrstic enake. Č e želimo izpi sati vse regije, ki jih pokrivajo trgovski potniki, to lahko storimo s stavkom SELECT REGIJA FROM TRG-POTNIK; ki pa nam izpiše regije za vse trgovske potnike, torej se nekatere regije ponavljajo. C _e se želimo izogniti podvajanj e m, to lahko dosežemo jz_ uporabo določila p) MN DI STINCT . Za zgornji primer torej zapišemo stavek SELECT DISTINCT REGIJA FROM TRG-POTNIK; Poglejmo si, kakšen je izpis v enem in kakšen v drugem primeru: brez uporabe dol. DISTINCT z uporabo določila DISTINCT / Opozorimo pa naj, da lahko uporaba določila DISTINCT precej podaljša poizvedovanje, posebej pri večjih tabelah in zahtevnejših poizvedbah. 37 Bralcu, ki ima težave z razumevanjem tega, da potrebujemo za odgovor tudi tabelo POS1AVKA, priporočamo, da sc postavi v vlogo SUPB, si pogleda le podatke \/ ostalih treh tabel in skuša odgovoriti na postavljeno vprašanje. Upravljanje in uporaba podatkov 141 V aplikacijah pogosto potrebujemo agregatne (sumarne) funkcije, katerih rezultat je zbirna informacija o določeni skupini vrstic. Primer sumarne poizvedbe je, kolikšna je bila do sedaj največja količina naročenega (določenega) izdelka, skupna vrednost naročil nekega kupca ... SQL ima vgrajene naslednje agregatne funkcije: COUNT (število), SUM (vsota), MAX (največja vrednost), MIN (najmanjša vrednost) in AVG (povprečna vrednost). Agregatno funkcijo uporabimo tako, da y SELECT-določllu.. .poizvedbe .zapišemo..ime a gregatne funkcije, v okle paju pa kot parameter navedemo ime atributa, za katerega želimo izračunati vrednost te agregatne funkcije. Na primer, SELECT AVG(KOLIČINA) AS POVP, MAX(KOLIČINA) AS MAX FROM POSTAVKA WHERE IZDELEK# = '321-432'; nam vrne povprečno in največjo naročeno količino izdelka s šifro 321-432. Z določilom AS smo opredelili imen a s to l pcev izračunanih vrednosti pri izpisu. Če želimo zvedeti, koliko (funkcija COUNT) naročil smo dobili od podjetja Čredo d.o.o., potem poizvedbo zapišemo takole: SELECT COUNT(*) AS ŠTEVILO FROM NAROČILO, KUPEC WHERE NAROČILO.KUPEC# = KUPEC.KUPEC# AND NAZIVKUP = 'Čredo d.o.o.'; število 2 Tu znak zvezdica (*) pomeni, da štejemo vrstice tabele, ki je rezultat povezovalnih I n iskaln ih pogojev. Namesto zvezdice bi lahko zapisali tudi, na primer, ime atributa NAROČILO#. Naslednja možnost, ki jo ponuja SQL, je grupiranje ali združevanj vrstic v skupine na osnovi ^akTh vredno sti nekega atributa. Potem lahko za vsako od teh skupin vprašamo po vredn osti agregatne funkcije,. Poizvedba 142 Podatkovne baze SELECT REGIJA, COUNT(*) AS ŠTEVILO FROM TRG-POTNIK GROUP BY REGIJA; nam izpiše število trgovskih potnikov za vsako regijo. Določil o poizvedbe. GR OTIP BY p ove na osnovi vrednosti katerega atributa, naj se vrstic e grupirajo, V konkretnem primeru sodijo v isto skupino vsi trgovski potniki, ki imajo enako vrednost atributa REGIJA, torej ki delajo v isti regiji. V določilu poizvedbe SELECT vedno zapišemo le imena tistih atr ib utov.... po kat erih grupiramo, ter sumarne funkcije, ki naj se izpišejo za vsako grupo. Pogosto je koristna tudi možnost uporabe aritmetičnih operatorjev: + seštevanje, odštevanje, * množenje ter / deljenje. S stavkom SELECT NAZIVIZD, CENA*0.1 FROM IZDELEK; za vsak izdelek izpišemo, za koliko tolarjev bi se podražil, če bi vse izdelke podražili za 10 %. Če zberemo dosedanje znanje, lahko zapišemo nekoliko bolj zapleteno poizvedbo, s katero želimo za vsako naročila izpis šifre in skupne vrednosti naročila. Podatke, ki jih potrebujemo, najdemo v treh tabelah: NAROČILO, IZDELEK in POSTAVKA. Ker nas zanimajo sumarni podatki (vrednost naročila) glede na naročila, bomo združevali po atributu NAROČILO#. Upravljanje in uporaba podatkov 143 SELECT FROM WHERE AND GROUP BY NAROCILO.NAROČILO#, SUM(CENA*(1 OO-POPUST)/ 1 00*KOLIČINA) AS ZNESEK NAROČILO, IZDELEK, POSTAVKA NAROČILO.NAROČILO# = POSTA VKA.NAROČILO# POSTA VKA.IZDELEK# = IZDELEK.IZDELEK# Zahtevnejšega bralca bo utegnilo zanimati, zakaj ni izpisan znesek za naročilo številka 423. Odgovor mu bo razkril pogled na podatke v tabeli naročila (glej sliko 39) in preprost razmislek. Vrstice se praviloma izpišejo v vrstnem redu, v kakršnem so shranjene, v taheli. Mogoč pa je tudi izpis, pri katerem so vrstice urejene po naraščajočem (določilo ASC) ah padajočem vrstnem redu (določilo DESC) vrednosti nekega atributa. Če želimo tak izpis, dodamo še ORDER BY določilo poizvedbe, kjer navedemo ime atributa, po katerem naj bodo vrstice urejene: SELECT NAZIVIZD, ME, CENA FROM IZDELEK WHERE NOT ME = ‘kos’ ORDER BY CENA ASC; oziroma SELECT NAZIVIZD, ME, CENA FROM IZDELEK WHERE NOT ME = ‘kos’ ORDER BY CENA DESC; 144 Podatkovne baze Razširitve jezika SQL Videli smo, da je uporaba jezika SQL precej intuitivna in enostavna. Ze z osnovno obliko stavka SELECT lahko poiščemo odgovor na marsikatero vprašanje. Zal pa gredo na račun enostavne uporabe omejene možnosti poizved ovanja, saj s stavkom SELECT ni mogoče izraziti vseh poizvedb, ki bi nas utegnile zanimati. Zato ima mnogo SUPB možnost kombiniranja jezika SOL s postopkovnimi jezik i 3. generacije (ripr. Java, Visual Basic, C++ in podobno) ali pa je kar jezik SQL razširjen s postopkovnimi konstrukti, kot so prireditveni staviti, pogojno izvajanje dela kode (IF), ponavljanje (FOR) in podobno. Izmenjava podatkov. Poudarili smo že (glej podpoglavje Opisovanje podatkov) pomen, ki ga mia opisovanje pod atkov pri izmenjavi le-teh med različnimi sistemi. Tri tem gre lahko za sisteme znotraj organizacije, najpogosteje pa za izmenjavo podatkov pri medorganizacijskem poslovanju. V primeru, ko si organizacije med seboj izmenjujejo papirne dokumente, je običajno, da gre za obrazce, na katerih se nahajajo opisi_podatkoy poleg prostora, namenjenega za vpis le-teh. Podobno moramo pri _ računalniški izmenjavi dokumentov poskrbeti za opise podatkov , sicer sistem, ki dobi podatke,-teh ne more pravilno interpretirati. Na primer, če posredujemo partnerski organizaciji naročilo v obliki 423,9.7.99,123-456,44,10,10,321-432,kos,192,00,1,3 bo program, ki obdeluje naročila, razbral pomen posameznega podatka le, če smo se predhodno natančno dogovorili o.- .strukturi podatkov..,£> naročilih . Težave narastejo s številom partnerjev: morda se bomo z vsakim partnerjem posebej dogovorili o strukturi podatkov za naročila, kar pomeni za nas obilo dela, če pa je Upravljanje in uporaba podatkov 145 naša organizacija dovolj močna, bomo vsem partnerjem vsilili enako strukturo p odatkov.. M izogib takšnim težavam so se v preteklosti uveljavili standardi EDI, s katerimi so bile na enoten način opredeljene strukture posameznih vrst dokumentov, danes pa se uveljavlja mnogo bolj. fleksibilen st andard XM L 38 (angl. Extensible Markup Language), ki omogoča opis podatko v. Prednosti jezika XML se posebej pokažejo pri izmenjavi podatkov med sistemi z različnimi operacijskimi sistemi in. strojno opremo. V jeziku XML z značkami o pišemo pomen posameznega podatkovnega elementa ali skupine elementov. Značko, ki označuje začetek podatkovnega elementa, tvori ime elementa, zapisano med znakoma < in >, konec elementa pa oz načimo na enakna čin. le da pred im eJvendar za znakom <). postavimo še.znak/. Tako bi lahko podatke o naročilu, na primer, opisali takole: <šifranaročila>423 <šifianaročnika>24 . Credo d.o.o. <šifraizdelka> 123-456 Sol morska 10 <šifraizdelka>321-432 Kisle kumarice 500 g 1 < /količina> 38 XMI. je pravzaprav mvtajczk, to je jezik, s katerim opisujemo jezike za opis dokumentov, grafike, finančnih informacij in podobno. 146 Podatkovne baze | Vprašanja za preverjanje razumevanja ^ Kaj so podatkovne baze in kakšne so njihove značilnosti? ► Kakšen je odnos med različnimi vrstami podatkovnih virov, ki ste jih spoznati v prvem poglavju (operativni, podatkovna skladišča...) in podatkovnimi bazami? ¥ Kakšne so naloge skrbnika podatkovne baze? ► Za kaj je pri podatkovnih bazah odgovoren uporabnik? ► Poiščite čimveč spletnih strani, ki predstavljajo sisteme za upravljanje podatkovnih baz, in si oglejte značilnosti le-teh. Kateri bi biti po vašem mnenju lahko kriteriji, po katerih bi izbrati ustrezen sistem za upravljanje podatkovnih baz? ^ Razložite vse tri vrste nadzora celovitosti na primerih, ki jih poznate. ^ V MS Accessu izdelajte podatkovno bazo, v kateri boste beležiti podatke o izposoji CD plošč iz vaše domače zbirke. Definirajte glavne ključe. Razmislite, ali ste bazo načrtovati tako, da ne bo prihajalo do težav pri delu (anomalij). ^ V podatkovni bazi iz prejšnje naloge poiščite odgovore na vprašanja: Izpišite seznam vseh plošč slovenskih izvajalcev. Za vsakega prijatelja ugotovite, koliko plošč si je izposodil. Katerih plošč še niste posoditi nikomur? ^ Katere dimenzije in mere menite, da bi bile potrebne v večdimenzionalni podatkovni bazi, namenjeni spremljanju zalog v skladišču? V Katere so značilnosti jezika XML? | Ključni pojmi anomalija celovitost hierarhični model jezik SQL jezik XML mrežni model neodvisnost objektni model orodja ČASE podatkovna baza podatkovni model podvajanje podatkov relacijski model sistem za upravljanje podatkovne baze skrbnik podatkovne baze stavek SELECT večdimenzionalni model vzdrževanje načrtovanje J E POGLAVJE Informacijska podpora managementu Cilji poglavja V tem poglavju boste spoznali: ► Uporaba katerih informacijskih tehnologij praviloma bolj prispevaj k dvigu nivoja informacijske asimetrije? ^ Katere so faze sistematičnega odločitvenega procesa, katere informacijske tehnologije uporabljamo v posameznih fazah in kakšno vlogo imajo pri poslovnem odločanju modeli? ► Na kakšna vprašanja nam pomagajo iskati odgovore sistemi za podporo odločanju? \ Zakaj je uporaba programskih paketov za delo s preglednicami še vedno najbolj pogosto uporabljeno informacijsko orodje za podporo odločanju? ► Kaj je poslovno obveščanje in kako je povezano z informacijsko demokratizacijo? ► Kaj je sprotna analitična obdelava podatkov, katere podatkovne vire uporabljamo zanjo in kakšne so značilnosti orodij? ► Kaj imata skupnega rudarjenje v podatkih in upravljanje znanja? ► Kako lahko poslovni portali pomagajo reševati problem preobilja informacij, s katerim se danes srečujejo odločevalci. 148 Informacijska podpora manogementu Managerji morajo danes pri ocenjevanju investicij v informacijsko tehnologijo upoštevati nivo informacijske asimetrije (ta ustreza donosu na vlaganja v informatiko), ki ga sistem lahko zagotovi. Slika 42 prikazuje, kako lahko izbira različnih tehnologij vpliva na nivo informacijske asimetrije. Na desni strani so prikazane investicije v informatizacijo opterativnega dela (plače, računovodstvo, finančno poročanje, kartične obdelave ...), ki so nujni za delovanje organizacije. Tu so odloč itveuiajbo lj struk t urirane in je informacijska podpora zato relativno enostavna, hkrati pa v tem delu dosežemo zelo nizek (ali nikakršen) nivo informacijske as imetrije. V srednjem delu so odločitve manj strukturirane, zato je neposredna uporaba izkušenj drugih (tekmecev) težka. Uspešna informatizacija poslovnih procesov pa je pogoj za uspešno tekmovanje. Primeri informacijske tehnologije, ki se uporabljajo za podporo poslovnim procesom, so celovite programske rešitve (ERP sistemi), sistemi za upravljanje delovnih tokov (angl. Workflow Systems), sistemi za upravljanje zalog ... Na levem delu slike 42 pa so predstavljena vlaganja v tehnologije in uporabo le-teh, ki organizacijam omogočajo razlikovanje. Primeri tovrstnih tehnologij so sistemi za p o dporo odloč anju (angl. Decision Support Systems — DSS), orodja za sprotno analitično obdelavo podatkov, orodja za rudarjen je v podatkih, sistemi za podporo odločanju v skupinah (angl. Group Decision Support Systems), orodja za modeliranje in simulacijo (npr. poslovnih procesov), sistemu za podporo skupinskemu delu (angl. Groupware) in podobno. V tem poglavju se posvečamo te hnol o gij a m, ki omogočajo doseganje višjega nivoja informa cij ske asimetrije, to so predvsem tehnologije za podporo managementu. Informacijska podpora managementu pojmujemo kot uporabo tehnologije (samostojnih orodij ali v kombinaciji z drugo informacijsko tehnologijo) za podporo opravilom managementa v splošnem, še posebej pri odločanju (Turban, Aronson, 2001). Managerski informacijski sistemi (tudi upravljalni informacijski sistemi, angl. Management Information Systems, MIS) so nastali kot posledica ugotovitev, da dotedanji operativni sistemi ne ustrezajo managementu. Zagotavljajo predvsem sumarne podatke in prikaz izjem, kar zadostuje predvsem za rutinske, strukturirane odločitve na taktičnem nivoju, kjer so pravila in informacijski tokovi vnaprej znam. Upravljanje in uporaba podatkov 149 Odločitveni problemi Slika 42: Uporaba tehnologij in informacijska asimetrija (Marchand, Kettinger, Rollins, 2001) Leta 1971 sta raziskovalca Gorry in Scott Morton ugotavljala, da odločitvene probleme lahko v grobem razdelimo na strukturir ane, polstruknirirane in nestrukturirane. Informacijsko so bili (z managerskimi informacijskimi sistemi) podprti predvsem prvi, ni pa bilo ustrezne podpore za manj strukturirane odločitve, ki pa lahko ključno vplivajo na poslovanje. To je vodilo v razvoj | sistemov za podporo odločanju (angl. Decision Support Systems, DSS), ki so namenjeni predvsem podpori polstrukturiranih ad hoc problemov srednjega managementa. Njihov namen ni avtomatizacija odločitvenih procesov ali vsiljevanje rešitev. Po več kot tridesetih letih razvoja obetajočih in naprednih sistemov za podporo odločanju pa je v praksi še vedno najpogosteje uporabljena pojavna oblika možnost kaj-če (angl. what-if) a_ naliz v preglednicah. Uporabi preglednic pri poslovnem odločanju posvečamo v nadaljevanju posebno pozornost tudi zato, ker jih zelo pogosto najdemo v delovnih okoljih managerjev, hkrati pa 150 Informacijska podpora managementu ponujajo večje možnosti za podporo odločanju, kot jih pozna in sluti povprečni uporabnik. 1 Direktorski informacijski sistemi (angl. Executive Support Systems, ESS) so namenjeni podpori pol in nestrukturiranih strateških odločitev, naj bi bili uporabniško zelo prijazni, ponujali možnosti modeliranja in analiz, omogočali dostop do zunanjih podatkov, do kritičnih dejavnikov uspeha ... Proces odločanja in analiza podatkov Odločanje je proces izbire med različnimi možnimi alternativnimi smermi delovanja z namenom doseganja enega ali več ciljev. Okoliščine, v katerih managerji sprejemajo poslovne odločitve, se danes zelo hitro spreminjajo (Turban, Aronson, 2001): ■ zaradi razvoja računalniške in informacijske tehnologije je na voljo večje število alternativnih možnosti, med katerimi lahko izbirajo, ■ tekmovalnost se povečuje, kar povzroča večje stroške pri napačnih odločitvah, ■ globalizacija, potrošništvo in vladne intervencije povzročajo večjo negotovost glede prihodnjih okoliščin poslovanja, ■ hitre spremembe zahtevajo hitrejše odločitve. Iz naštetih razlogov se %golj pristopi k odločanju, ki so bili v navadi v preteklosti (poskušanje, učenje na napakah, uporaba intuicije), ne obnesejo več. Zato se morajo managerji naučiti uporabljati sistematične pristope ter nove tehnologije in tehnike, ki so danes na voljo. Sistematičen odločitveni proces je sosledje aktivnosti, ki jih lahko v grobem uvrstimo v 3 faze (glej sliko 43): * faza priprave, * faza oblikovanja ter faza izbire. Upravljanje in uporaba podatkov 151 V fazi priprave dobro raziščemo problem. Razumevanje problema, določanje organizacijskih ciljev in izbira pravih, kakovostnih podatkov je ključnega problema za dobro rešitev. V praksi se pogosto rešujejo problemi, ki niso dobro poznani/razumljeni. V fazi oblikovanja formuliramo model (glej nadaljevanje), določimo množic o alternativnih (dopustni h) rešitev in izberemo enega ali več kriterijev, na podlagi katerih bomo ocenjevali možne rešitve problema. Na podlagi modela in kriterijev nato v fazi izbire oc enimo a lternativne rešitve in izberemo najboljšo oziroma dovolj dobro. Poudariti je potrebno, da je pogosto iskanje ali implementacija najboljše rešitve prezahtevna (finančno, časovno, pomanjkanje ustreznih znanj ...), zato v teh primerih izberemo rešitev, ki je najboljši dovolj blizu (je zadovo ljiva), vendar jo lahko poiščemo bistveno enostavneje. Zavedati se moramo, da ima lahko tudi dobra odločitev za posledico slabe rezultate. Res pa je seveda tudi obratno. Slaba odločitev lahko privede do dobrih rezultatov. Pogosta napaka v praksi je tudi lokalna op ti mizacij a kjer pri določanju kriterijev za odločitev ne upoštevamo organizacijskih ciljev, pač pa, na primer, oddelčne cilje. Oddelek za trženje ima za cilj čim večje zadovoljstvo kupcev, kar vključuje tudi raznolikost ponudbe. Z vidika finančnega oddelka pa raznolikost izdelkov povečuje stroške. Zatorej je potrebno pri odločanju upoštevati oba kriterija in poiskati optimalno rešitev z vidika organizacije kot celote. Sestavni del izbire je anal iza občutljivost i—ki pomeni vpliv sprememb v podatkih (vhodni podatki, parametri) na predlagano rešitev. Tovrstna analiza je zelo pomembna predvsem zaradi hitrih sprememb v okolju in omogoča prilagodljivost le-tem, hkrati pa pomeni boljše razumevanje modela. Praviloma reševanje problemov razumemo kot proces odločanja, ki ga sestavljajo zgoraj omenjene tri faze, skupaj s fazo implementacije. Implementacija pomeni udejanjanje izbrane rešitve. Pomemben del implementacije je tudi merjenje uspešnosti in uporaba izkušenj pri naslednjih poslovnih odločitvah. 152 Informacijska podpora managementu Slika 43: Odločitveni proces in reševanje problemov V literaturi najdemo tudi alternativne modele procesa odločanja (glej Turban, Aronson, 2001), vendar je zgoraj opisani ustrezen za odločitvene probleme, pri katerih uporabljamo matematične modele in si pri tem pomagamo z informacijsko tehnologijo. Odločitvene probleme lahko v grobem razdehmo na strukturirane, polstrukturirane in nestrukturirane. Pri strukturiranih problemih so postopki za iskanje najboljših (dovolj dobrih) rešitev znani. Primer strukturiranega problema, kjer poznamo postopek iskanja rešitve, je o ptimizacija zalo?;. Pri nestrukturiranih problemih pa je osnova odločanju pogosto kar intuicija. Tovrstni problemi so lahko l e deloma Upravljanje in uporaba podatkov 153 pod]3rli_X-J^fQffliaciiskQ-_J:ehiiologijQ, na primer s tehnologijo za dostop do podatkov, z inteligentnimi ali ekspertnimi sistemi. Primer nestrukturirane odločitve je lahko izbira novega direktorja^ Polstrukturirani problemi imajo nekatere elemente strukturiranih in nekatere elemente nestrukturiranih problemov. Problem lahko analiziramo (faza oblikovanja in izbire v odločitvenem pmcesu) na dva načina: kvalitativno ali kvantitativno. Pri prvem se opiramo na izkušnje, občutke in je primeren predvsem za manj strukturirane probleme. Tak način odločanja pride v poštev pri relativno enostavnih ali rutinskih problemih. Pri drugem načinu pa odločitev t emelji n a podatkih, povezanih s problemom. Problem opišemo z matematičnimi izr azi, ki opisujejo cilje, omejitve in povezave med podatki, ki nastopajo v problemu. Z uporabo kvantitativnih metod nato poiščemo rešitev, kar je rezultat analize problema. Osredotočili se bomo na kvantitativ no nnai izo.~ pri kateri nam je lahko v veliko pomoč informacijska tehnologija, čeprav se le-ta čedalje pogosteje uporablja tudi pri kvalitativnih metodah (npr. sistemi za podporo skupinskemu delu). Modeli Proces kvantitativne analize obsega več korakov: 1. Razviti moramo model, ki opisuje problem. 2. Pripraviti moramo podatke, ki jih potrebujemo v modelu. 3. Poiščemo rešitev modela. 4. Analiziramo občudjivost. 5. Predlagamo rešitev oziroma sestavimo poročilo o naših ugotovitvah. Model prikazuje realne sisteme na poenostavljen način. Prikazuje le osnovne sestavne dele sistema in povezave med njimi. Navadno uporabljamo tak model, ki prikazuje tiste elemente, ki nas zanimajo v analizi sistema. Uporaba modelov ima vrsto prednosti: 154 Informacijska podpora managementu ■ Zaradi take poenostavitve sistema je analiza le-tega enostavnejša. ■ Med prednosti modeliranja lahko štejemo tudi možnost, da simuliramo obnašanje sistema glede na različne odločitve, oziroma različne vrednosti posameznih parametrov, česar v realnem sistemu ne bi mogli. V) ■ S preizkušanjem alternativnih možnosti na modelu ne vplivamo in ne motimo vsakodnevnega delovanja realnega sistema. ■ Stroški analize modela so nižji od stroškov preizkušanja alternativ v realnem sistemu. ■ Zaradi vse večje negotovosti v poslovanju lahko na mode kuanaliziramcUiidi tveganja pri določenih ravnanjih. ■ Modeli povečujejo razumevanje delovanja sistema in učenje. Modeli so lahko različni. V avtomobilski tovarni pred serijsko izdelavo novega avta izdelajo več modelov, na katerih preizkušajo, kakšno bo obnašanje pravega avta. To je fizični mode l. Arhitekturni načrti in zemljevidi spadajo med grafične modele. Model je lahko tudi opk~2LJies£dami. Velikokrat pa uporabljamo matematične modele, na primer dobiček = prihodki - stroški Skupino takih zvez med spremenl jivkami , ki op isu jejo poslovni siste m ali njegov del, imenujemo tudi poslovni m odel. V nadaljevanju nas bodo zanimali predvsem taki modeli. Poslovni modeli Čeprav se lahko poslovni modeli zelo razlikujejo od primera do primera, jih lahko vendarle razdelimo v nekaj večjih skupin. V literaturi lahko najdemo naslednje večje skupine modelov, ki jih uporabljamo v sistemih z a i modeli za napovedovanje, modeli vrst, modeli za optimizacijo, Upravljanje in uporaba podatkov 155 ■ odločitvene tabele in drevesa, ■ vodehje projektov, ■ vodenje zalog... Pri napovedovanju želimo glede na znane podatke o pojavu v preteklosti napovedati, kakšen bo pojav v prihodnosti. Za napovedovanje lahko uporabljamo več modelov, primer v bankah, restavracijah ah pri delitvi računalniških virov. S temi modeli lahko ugotavljamo, kakšen je pričakovan čas čakanja stranke, kakšen je pretok strank (število postreženih na časovno enoto) ... Tretja večja skupina modelov so modeli za optimizacijo. Glede na vrsto problema se lahko odločamo med različnimi modeli (linearni ah nelinearni program, model najkrajše poti, model najkrajšega vpetega drevesa, model maksimalnega pretoka), za vsakega izmed modelov pa poznamo eneg a ali več alg oritmav.-za..razr£Š.egajije tega_pr£>i?i£tna. Pogosto alternativ v poslovnih odločitvenih problemih ni mogoče oceniti zgolj z enim preprostim ciljem kot je npr. največji možni dobiček. V tem primeru govorimo Qj.e£klit.erijak.eiB..Ojdicičanjii», kjer moramo pretvoriti različne, včasih tudi nasprotujoče si, kriterije v eno samo mero. Na primer, managerji morajo ustreči delničarjem, hkrati pa povečati zadovoljstvo zaposlenih s povečanjem njihovih prejemkov. V teh primerih lahko uporabimo sisteme, ki podpirajo večkriterijsko- odločanje. Znan je analitični h ierarhični p ostopek (angl. Analytical Hierarchy Process), ki uporablja kvalitativne in kvantitativne kriterije za reševanje večkriterijskih odločitvenih problemov. Odločitvene tabele in drevesa nam pomagajo pri iskanju najboljše strategije v primerih, ko imamo na voljo več odločitvenih pravil in ko v problemu nastopa nedoloče nost (glej podpoglavje Priprava podatkov). Tudi pri vo denju projekto v si lahko pomagamo s kvantitativnimi metodami, na primer PERT m CPM. S temi modeli si pomagamo pri načrtovanju, določanju urnikov in nadzorovanju projektov. lahko uporabljamo povsod, kjer imamo opravka s „strežbo strank , na 156 Informacijska podpora managementu Modele, ki jih uporabljamo pri vodenju zalog, bi lahko šteli kar med optimizacijske modele, saj je njihov cilj zmanjšati (minimizirati) stroške zalog, pri čemer moramo seveda zadovoljiti povpraševanje. Za konkreten problem izberemo torej ustrezen model, za katerega imamo lahko potem več algoritmov za reševanje. Recimo, da želimo izbrati tako kombinacijo proizvedene količine dveh izdelkov, da bo dobiček karseda velik, ob določenih omejitvah proizvodnih in drugih zmogljivosti. Potem bo morda za ta problem primeren model linearni prog ram. Za reševanje modelov te vrste poznamo več al goritmov , na primer Simplex. To pomeni, da se pri istem modelu lahko odločamo med več algoritmi reševanja. Ce bi se v zgornjem primeru odločili, da bomo problem rešili z Jinearnim«programiranjem..v-.Excelu, potem smo s tem izbrali tudi algoritem reševanja, saj nam ta programski paket ponuja le en ; za reševanje Ideja neodvisnosti podatkov, ki jo poznamo iz podatkovnih baz, je našla svoje mesto tudi na področju sistemov za podporo odločanja. Tako govorimo tukaj o neodvisnosti med modelom in algoritmom za reševanje. To pomeni, da za različne modele lahko uporabljamo isti algoritem za reševanje ali za isti model več algoritmov za reševanje. Podobno lahko govorimo o neodvisnosti med modelom in množico podatkov. V tem primeru lahko isti model uporabljamo na več množicah podatkov ali obratno. Priprava podatkov Modeli praviloma zahtevajo določeno število vhodnih podatkov. Vhodne podatke, na vrednosti katerih ne moremo vplivati, imenujemo nenadzorovani podatki. V primeru odločanja o naložbi je nenadzorovan podatek lahko obrestna mera, saj njene vrednosti ne moremo spreminjati. Očitno je seveda lahko isti podatek v nekem drugem okolju ali le v drugem modelu nadzorovan. Nadzorovanim podatkom rečemo tudi odločitvene spremenljivke, saj so to odločitvene alternative, ki smo jih d oločili v fazi oblikovanj a Z drugimi besedami, želimo določiti čimboljše vrednosti odločitvenih spremenljivk glede na izbrani kriterij. Upravljanje in uporaba podatkov 157 Izdelek A prodajamo po ceni 500 denarnih enot za kos. Fiksni stroški pri proizvodnji tega izdelka znašajo 300.000 denarnih enot, variabilni pa 200 denarnih enot za kos. Zanima nas, kakšna je najmanjša količina izdelkov A, ki jo moramo proizvesti, da bomo imeli dobiček. To količino izdelkov imenujemo prelomna točka. Poglejmo, kakšen bi lahko bil model za zgornji problem. Kriterij, po katerem ocenjujemo možne rešitve (količino izdelkov), je v tem primeru dobiček. Poskusimo izraziti dobiček z vhodnimi podatki: dobiček = prihodki - stroški prihodki = cena*količina stroški = fiksni stroški + variabilni stroški * količina Torej je lahko model za naš problem naslednji: dobiček = cena*količina - (fiksni stroški + variabilni_stroški * količina) Kot vidimo, so vbodni podatki: cena, količina, fiksni stroški in variabilni stroški. Od teh je le količina nadzorovan vhodni podatek, saj drugih (v okviru te odločitve) ne moremo spreminjati. Opozorimo na to, da bi lahko bil v nekem drugem procesu odločanja nadzorovan podatek, na primer cena, po kateri prodajamo izdelek. Zgodi se, da v času odločanja ne poznamo vrednosti nekega nenadzorovanega podatka. Recimo, da za model potrebujemo kot vhodni podatek povpraševanje po izdelku, ki ga šele razvijamo. Če so vsi nenadzorovani vhodni podatki p oznani in se ne morejo spreminjati, potem je model determinističen, odločanje poteka v pogojih gotovosti (angl. ceratinty). Ce mora odločevalec analizirati problem za različne vrednosti nekega parame tra, pri čemer pozna za.t e vredno sti verjetnostno porazdelitev , govorimo o tveganju (angl. risk), če pa teh verjetnosti ne pozna oziroma ne more oceniti, pa govorimo o negotovosti (angl. unceratinity). Priprava vhodnih podatkov za model je zelo pomemben del analize problema, saj tudi tu velja splošno pravilo v informatiki: GIGO (Garbage In Garbage Out) - smeti noter, smeti ven. 158 Informacijska podpora managementu Informacijska tehnologija v procesu odločanja Na sliki 45 so prikazane različne informacijske tehnol ogije, ki se,jjpQrabliai,n-za po dporo v r a zlični h fazah odločitvenega procesa. ' Managerski informacijski sistemi Rudarjenje v podatkih \ Sprotna analitična obdelava podatkov (OLAP) Nevronske mreže Direktorski informacijski sistem ( Matematično modeliranje (operacijske raziskave) J Sistemi za podporo skupinskemu odločanju Nevronske mreže .f Sistemi za podporo skupinskemu odločanju I Sistemi za podporo odločanju Ekspertni sistemi Slika 45: Uporaba tehnologij za podporo odločanju (Turban, Aronson, 2001) S sprotnim spremljanjem notranjih in zunanjih informacij lahko pravočasno zaznamo problem oziroma poslovno priložnost, kar omogoča identifikacijo odločitvenega problema. Prav tako lahko različne tehnologije (managerski informacijski sistem, direktorski informacijski sistem, OLAP, rudarjenje v podatkih • ••) omogočajo pridobivan je. podatkov_v.pripravljalni fazi . V fazi oblikovanja in odločitve uporabljamo tehnologije, kLomogočajo izdelavo modela ali kvalitativno analizo problema* *. Mogoče je uporabiti standardne modele, mani strukturirane probleme pa lahko, podpremo .s sistemi za podporo odločanju*, ki omogočajo oblikovanje prilagodljivih modelov (npr. programi za delo s preglednicami). Isk anje alternativnih, rešitev lahko podpremo npr. z orodji za skupinsko delo ali e kspertnimi sistemi. Raziskave so pokazale, da je lin fofmarijska~pndpoa enako Upravljanje in uporaba podatkov 159 pomembna tudi v fazi implementacije za potrebe komunikacije, razlag in utemeljitev-ter reševanja problemov pri uvajanju odločitev. 4.1 Sistemi za podporo odločanju Razumevanje pojma sis temi za p odporo odloča nju j e tako v strokovni literaturi kakor tudi v praksi zelo raznoliko. Najpogosteje se sistemi za podporo odločanju povezujejo s p olstrukturiran i mi problemi. Zato v nadaljevanju privzemimo naslednjo opredelitev: Sistemi za podporo odločanju so računalniški sistemi, ki podpirajo proces odločanja managerjev predvsem pri polstrukturiranih poslovnih odločitvenih problemih (Turban, Aronson, 2001). Podpirajo lahko le posamezno fazo, lahko pa celoten odločitveni proces, včasih tudi s povezovanjem z drugimi vrstami informacijskih sistemov. Vedeti moramo, da so programske rešitve, ki jih pri tem uporabljamo, v splošnem le del sistemov za p odporo odloč anja. Res pa je, da so danes mnogi programski paketi tako izpopolnjeni, da jih managerji pogosto uporabljajo kar samostojno. Sistemi za podporo odločanju nam omogočajo na podlagi zbranih podatkov o sistemu odgovarjati na dileme, ki se pojavljajo pri odločanju. Na primer: * Kakšne bodo posledice, če sprejmemo neko poslovno odločitev? (kaj-če analiza, angl. what-if) Na primer, kako se bo spremenil dobiček, če se odločimo, da v časopisu objavimo tri dodatne oglase? Ce naj odgovorimo na to vprašanje, moramo seveda poznati povezave med dobičkom, prihodkom, stroški, reklamnimi sporočili, prodajo... Množica zvez med temi spremenljivkami je model za ta problem. * Kako naj spremenimo vrednosti določenih parametrov, če želimo doseči nek cilj? (doseganje cilja, angl. goal-seeking) V primeru objavljanja oglasov se lahko vprašamo, koliko dodatnih sporočil moramo objaviti, da se bo dobiček povečal za določeno vrednost. ■ Katera odločitev je najboljša? (optimizacija, angl. optimization) 160 Informacijska podpora managementu Zdaj se lahko odločamo med objavljanjem oglasov v časopisu in na televiziji, kjer so objave seveda dražje, imajo pa močnejši učinek. Omejeni smo tudi z denarjem, ki je na voljo za oglaševanje. Koliko sporočil naj objavimo v katerem mediju, da bo dobiček največji, če naj ne prekoračimo zneska, ki nam je na voljo? ■ Zakaj ima neka spremenljivka vrednost, kot jo ima? (zakaj, angl. why) Na to vprašanje odgovarja predvsem statisjjčna.„ .analiza. ki išče stadstične povezave med spremenljivkami. S tem si lahko pomagamo pri iskanju dejanske odvisnosti med spremenljivkami. Povezavo med objavo oglasa na televiziji in povečano prodajo izdelka lahko ugotovimo le na podlagi statistične analize podal kov o pr eteklih obj avah in prodaji . Uporaba računalniške programske in strojne opreme v sistemih za podporo odločanja omogoča hitrejše in kvalitetnejše odločanje. Z vse zmogljivejšo strojno opremo in do uporabnika vse bolj prijaznimi programskimi paketi za podporo odločanja so le-ti postali dostopni skoraj vsakomur. Med programsko opremo, ki jo uporabljamo za podporo odločanju, največkrat srečamo: * orodja za izdelavo poročil in poizvedovanje, tudi orodja za sprotno analitično obde lav o poda tkoii/OLAPi; * programske pakete za rudarjenje v podatkih, na primer SAS, Clementine, MS Analysis Services, Darwin; ■ prog ramske pak ete za delo s preglednicami,, na primer Excel, Quatro Pro, Lotus 1-2-3; ■ programske pakete za statistično analizo, na primer SPSS, SAS, StatGraph; " specializirane programske pakete za modeliranje, na primer IFPS, @Risk; Precision Tree, What's Best!; * programske pakete za podporo vodenju projektov, na primer MS Project, Super Project; ■ ekspertne sisteme, na primer XpertRule KBS. Upravljanje in uporaba podatkov 161 Programski paketi za statistično analizo pomagajo uporabniku iskati povezave ffled dvemav ah v,eč.spremenl jivkami. Odgovarjajo torej na vprašanje "zakaj?". Čeprav so ti programski paketi v zadnjem času postali zelo zmogljivi in prijazni do uporabnika, pa je interpretacija rezultatov še vedno na strani uporabnika. Programski paketi za delo s preglednicami so namenjeni splošnemu analitičnemu modeliranju. V naslednjih poglavjih bo eden izmed njih (MS Excel) orodje, ki ga bomo uporabljali pri razvoju in uporabi modelov. Slika 46: Zaslon @Risk Specializirani programski paketi za modeliranje so v večini primerov podobni programskim paketom za delo s preglednicami, pogosto pa so celo njihova nadgradnja (na primer @Risk). Namenjeni so mo deliranju na ožjih področjih. Tako je, na primer, IFPS namenjen modeliranju na finančnem področju, @Risk pa tam, kjer se pojavlja v modelih tveg anjaRazlika med temi paketi in paketi za delo s preglednicami je predvsem ta, da specializirani paketi ponujajo močn ejša orodja za modeliranje n a specializiranem področju, seveda pa je o mejenost na eno področje 162 Informacijska podpora managementu njihova slabost. Ker tudi programski paketi za delo s preglednicami ponujajo vse močnejša orodja, ki so primerna za več področij, se zdi, da bo r azvoj v p rihodnje vse manj naklonjen samostojnim specializiranim paketom in vse bolj nadgrad njam preglednic za določena področja, Sistemi za podporo vodenju projektov so v pomoč uporabnikom pri načrtovanju in organizaciji opravil v okviru projektov z upoštevanjem razpoložljivih virov. Glede na dolžine trajanja posameznih opravil, zahtevana zaporedja njihovega izvajanja, potrebne vire za posamezna opravila in vire, ld so na voljo, lahko s pomočjo teh programov odgovorimo na vprašanja kot na primer: * Koliko časa bo trajalo izvajanje projekta? ■ Kako učinkovito razporediti vire? ■ Katera so tista opravila, ki povzročijo zamudo celotnega projekta, če so izvršena prepozno? ■ Kolikšna bo zamuda pri izvedbi celotnega projekta, če je prepozno izvršeno posamezno opravilo? ■ Ali imamo dovolj virov (denarja, delovne sile, materiala) za izvedbo projekta? Programski paketi za podporo vodenja projektov nam omogočajo tudi sprotno spremljanje projekta in ustrezno odzivanje na nenačrtovane spremembe v poteku izvajanja. Ekspertni sistemi so rezultat raziskav na področju umetne inteligence. Končni cilj umetne inteligence je razvoj računalnika, ki misli: se uči, logično sklepa in rešuje probleme. Med dosedanjimi rezultati na tem področju se v praksi največ uporabljajo ravno ekspertni sistemi. Na primer, ekspertni sistemi lahko zamenjajo strokovnjaka ali mu pomagajo pri odločitvah v tistih elementih odločanja, ki se na področju, s katerim se ukvarja ekspert, večkrat p onavl jajo, Glede na bolezenske znake pacienta se zdravnik odloči, za katero bolezen naj bi šlo. V mnogih primerih je ta odločitev dokaj rutinska. Seveda lahko ekspertni sistem zdravniku le pomaga pri odločitvah, ne more ga pa zamenjati. Upravljanje in uporaba podatkov 163 Splošna arhitektura ekspertnih sistemov je naslednja (slika 47): Ekspertni sistem vsebuje bazo znanja. Baza znanja je navadno sestavljena iz podatkovne baze, v kateri so dejstva o sistemu, ter baze pravil sklepanja. Pra vila sklepanja so največkrat oblike ČE-POT EM TF-THENl. na primer. ČE prihranki > vrednost naložbe IN ocena varnosti naložbe = pozitivna POTEM je pametno naložiti sredstva Drugi del ekspertnega sistema, ki ga imenujemo mehanizem sklepanja, na podlagi dejstev in pravil sklepanja izpelje nova dejstva. Slika 47: Shema ekspertnega sistema Če je v gornjem primeru dejstvo, da so prihranki večji od vrednosti naložbe, in drugo dejstvo, da je ocena varnosti naložbe pozitivna, potem bo mehanizem sklepanja glede na navedeno pravilo v bazo de jstev dodal novo dejstvo, to je, da je smotrno naložiti sredstva. Seveda sta bili lahko tudi prvi dve dejstvi že izpeljani iz nekih drugih dejstev z uporabo nekih drugih pravil sklepanja. Na sliki 48 vidimo zaslon ekspertnega sistema, ki je razdeljen na tri dele. Zgornji del je uporabniš ki vmesnik, kar je navadno vse, kar uporabnik ekspertnega sistema vidi. V spodnjem levem delu je vidno pravilo, ki ga trenutno uporabljamo, desno spodaj pa je baza dejstev, ki so trenutno znana o sistemu. 164 Informacijska podpora managementu -I KBS: lNUfSll J ftre your s&vings satisfactor,y? Satisfactoi'y •4 Unsatisfftctor^ Is i>our Jdi ■■■ a n c a j m fc< Adeguate -4 fnadegu&te The expei't system advises you to invesc. Press the SPACEBAR to exit INUEST. -[ RULES ]- Testing 1 RULE 1 IF Sauings = Insurance THEN Aduice = to_inuest CNF 100 Finding Sauings Finding Insurance satisfactory AND = adequate -C FACTS 3! Saoings 83 Satisfactory CNF 10 .. : . : . 180 Slika 48: Zaslon ekspertnega sistema VP Expert Z uporabo ekspertnih sistemov lahko avtomatiziramo del procesa odločanja. Z njihovo uporabo lahko eksperte osvobodimo ponavljajočih se, rutinskih odločitev in jim omogočimo bolj produktivno in zanimivo delo. S širitvijo dobre informacijske tehnologije, ki služi za podporo odločanja, se širi tudi nekritična uporaba le-te. Vedeti moramo, da dobra programska oprema ni dovolj za dobro podporo odločanju. Uporabnik programske opreme mora pripraviti dober model in vhodne podatke, če želi dobiti kakovostne rezultate, te pa mora znati pravilno interpretirati in naprej uporabiti v procesu odločanja. 4.2 Uporaba programskih paketov za delo s preglednicami Čeprav na prvi pogled le privlačno orodje za oblikovanje tabel, so programski paketi za delo s preglednicami mnogo več. Večina sodobnih programskih paketov za delo s preglednicami omogoča statistične obdelave podatkov in uporabo preglednice kot preproste podatkovne baze. Seveda je na teh področjih njihova zmogljivost precej manjša od specializiranih statističnih programskih paketov in sistemov za upravljanje podatkovnih baz. Upravljanje in uporaba podatkov 165 Svojo pravo moč pa programski paketi za delo s preglednicami pokažejo kot oXQdje_za__modeliranj£... Za nekatera področja sicer obstajajo tudi specializirana orodja za modeliranje, na primer IFPS ali @Risk, ki pa so pogosto rešitve, zgrajene nad programskimi paketi za delo s preglednicami. V nadaljevanju je podanih nekaj vrst modelov, ki jih lahko uporabljamo pri poslovnem odločanju. Kot primer programskega paketa za delo s preglednicami je uporabljen Microsoft Excel. Preizkušanje scenarijev in doseganje cilja V preglednicah najpogosteje ohliknje mo matem atične .mode le, ki povezujejo izhode z vhodnimi spremenljivkami. Primer takega modela je zveza za izračun dobička iz količine prodanih izdelkov, prodajne cene, fiksnih in variabilnih stroškov: prihodek = cena * količina stroški = fiksni stroški + variabilni stroški * količina dobiček = prihodek-stroški Seveda za izračun dobička i z omenjenih štirih vh odnih_podatkov- zadostuje najpreprostejši kalkulator. Zavedati pa se moramo, da velikost modelov v praksi lahko doseže nek aj deset spreme nljivk in nekaj _stq_ povezav (formuli. V takih primerih se programski paketi za delo s preglednicami izkažejo pri: ■ enostavnem preizkušanju različnih scenarijev ( kaj-če analize), ko spreminjamo vhodne podatke in sproti spremljamo spremembe vseh izračunanih V zgornjem primeru bi lahko preverjali različne scenarije, kaj bi se dogajalo, če spreminjamo ceno izdelka 39 . Pri spremembi cene se takoj preračuna~prihodekjn podatkov, doseganju cilja , to je določitev vrednosti vhodne spremenljivke, .( vnaprej izbra no) vrednost. 39 Opozoriti moramo, da je uporabljeni model zelo poenostavljen, saj je namen lc predstavitev možnosti, ki jih ponuja informacijska tehnologija. V modelu npr. ni upoštevano, da sprememba cene praviloma spremeni povpraševanje po izdelku, torej količino prodanih izdelkov. 166 Informacijska podpora managementu dobiček . Točko preloma (angl. break-even analysis), to je količino, pri kateri bo dobiček enak 0, bi lahko dobili s preizkušanjem scenarijev, bolj elegantno (in učinkovito pri večjih modelih) pa to naredimo v Excelu X-uporabQ-m.odula_Goal ; (glej sliko 49). Slika 49: Določitev prelomne točke v Excelu Vrtilne tabele Vrtilna tabela prikazuje sumarne podatke ene spremenljivke (odvisna spremenljivka) glede na vrednosti drugih dveh (ali več) spremenljivk (neodvisni spremenljivki). Vzemimo dve spremenljivki U in V, ki lahko zavzameta vrednosti u 1, u 2> u 3 * n u 4 ter v i> v ? i n v 3- Zanimajo nas sumarni podatki (na primer vsota) _za_ spremeo likko-Sr-Oblika- vrtilne tabele za ta primer je prikazana na sliki 50. Upravljanje in uporaba podatkov 167 Slika 50: Skica dvodimenzionalne vttilne tabele Pri tem sjj pomeni vsoto vred nosti spremenljivke S,za vse enote, pri katerih ima spremenljivka U vrednost uj, spremenljivka V pa vrednost Vj. Poleg vsote lahko uporabimo tudi druge sumarne funkcije. Če, na primer, uporabimo funkcijo štetja (Count), dobimo frekvenčne porazdelitve neodvisnih spremenljivk. Vrtilno tabelo lahko posplošimo tudi na veiLdimenzij, ko namesto dveh (U in V) uporabimo več neodvisnih spremenljivk. Če z vrtilno. tabelo nismo zadovoljni, jo lahko zelo enostavno spremenimo, na primer, zamenjamo vrstice jruatolpc e tabele . Po krajšem "igranju" s tem orodjem bo tudi še neizkušeni analitik ugotovil, da gre kljub preprosti uporabi za zmogljivo in fleksibilno orodje, ki omogoča prikaz poljubnega prereza podatkov. Vrtilno tabelo v Excelu povežemo tudi z večd imenzionalno bazo podatkov (npr. MS Analysis Services), s tem pa postane vrtilna tabela v Excelu preprosto orodje za analize OLAP (glej Sprotna analitična obdelava podatkov v nadaljevanju). Na sliki 50 je prikazan primer vrtilne tabele, ki prikazuje dobiček glede na državo (angl. Country, State), izobrazbo (angl. Education Level) in promocijski medij (angl. Promotion Media). Takšno poročilo je izdelano na enak način kot običajna vrtilna tabela, le da za podatk ovni vir izberemo .-Večdimenzionalno., kocka V primeru uporabe vrtilne tabele za analize OLAP se podatki v vrtilni tabeli sproti (glede na nastavitev) spreminjajo v skladu s spremembami v podatkovnem viru. 168 Informacijska podpora managementu H Slika 51: Primer sprotne analitične obdelave podatkov (OLAP) v Excelu Časovne vrste in napovedovanje Časovna vrsta je zapored j e vre dnosti.neke spremenljivke, ki so bile ugotovljene v zaporednih časovnih točkah ah v nekem časovnem obdobju, na primer, zaporedje vrednosti dnevne prodaje, zaporedje letnih količin proizvodnje jekla v neki državi, gibanje temperature, rodnost v neki državi. Pogosto nas zanima, kako se bo pojav obnašal v prihodnosti, oziroma kakšne bodo vrednosti opazovane spremenljivke v prihodnje. Za napovedovanje sicer lahko uporabimo tudi kvalitativne metode (napovedi ekspertov), .pa obstaja tudi vrsta metod za napovedovanje na podlagi podatkov o obnašanju pojava v preteklosti. Excel p onuja (neposredno) za. napovedo vanje le _ ome-jene ... .mažnostiiH vendar lahko s pridom izkoristimo nekatere njegove druge elemente. 40 Gre xa možnost uporabe regresijske enačbe in xa drseča povprečja, ki jih lahko prikažemo na grafih. Upravljanje in uporaba podatkov 169 Na sliki 52 so v stolpcih C, E in G preglednice zaporedoma prikazane uporabe metod drseča povprečja, posplošena drseča povprečja in eksponentno glajenje 41 . V pripadajočih desnih stolpcih (D, F in H) pa je za vsako metodo prikazan še izračun povprečne kvadratne napake. Slika 52: Uporaba metod drseča povprečja, posplošena drseča povprečja in eksponentno glajenje Nekatera orodja imajo že vgrajene module, ki računajo iz danih časovnih vrst napovedi po različnih metodah. Gre predvsem za statistične programske pakete, pa tudi pri orodjih OLAP postaja možnost napovedovanja čedalje bolj pogosta. Obstaja pa tudi možnost nadgradnje preglednice MS Excel z orodjem Forecast Pro, la uporablja vgrajen ekspertni sistem za določitev metode, ki hn.za konkreten primer zagotovila najboljšona p-Ctml Tako orodje je namenjeno tudi analitikom, ki se na metode napovedovanja ne spoznajo najbolje. Optimizacija Z optimizacijo želimo določiti vrednosti nadzorovanih odločitvenih spremenljivk, tako da hn neka od njih o dvismukoličina-imela maksimalno (največjo) vrednost ali minimalno (najmanjšo) vrednost. Pri tem moramo pogosto upoštevati še omejitve in zahteve, ki določajo, kakšne smejo biti vrednosti nadzorovanih spremenljivk. Pri poslovnih odločitvah mnogokrat nastopajo na primer takšnile primeri: 41 Za opis metod glej npr. (Winston, 1991) 170 Informacijska podpora managementu * Vodja trženja mora odločiti, koliko denarja naj podjetje vloži v različne oglaševalske medije, da bo učinek največji . * Koliko katerega izdelka naj izdeluje podjetje, da_bajMziček_aajv££ji? Pri tem je podjetje omejeno s povpraševanjem kupcev po posameznih izdelkih, s proizvodno zmogljivostjo in/ali drugimi omejitvenimi danostmi. ■ Podjetje isti izdelek izdeluje v več obratih po Sloveniji. Kupci izdelka se prav tako nahajajo na različnih lokacijah v Sloveniji. Podjetje mora zadostiti povpraševanju kupcev, želi pa minimizirati transportne stroške . Koliko naj dostavi izdelkov iz posameznega obrata posameznemu kupcu? Če želimo reševati probleme optimizacije, moramo najprej dobro formulirati problem: * določiti nadzorovane odločitvene spremenljivke, ■ določiti omejitve in ■ določiti kriterijsko funkcijo, to je funkcijo odločitvenih spremenljivk, ki jo želimo maksimizirati ali minimizirati. Podjetje izdeluje dva izdelka 11 in 12. Dobiček pri 1 kg izdelka II je 25 denarnih enot, pri 1 kg izdelka 12 pa 30 denarnih enot. Obrat, v katerem izdelujejo oba izdelka, ima tri oddelke (A, B in C). Proizvodni proces zahteva za oba izdelka določeno število delovnih ur na vsakem izmed oddelkov. Število potrebnih delovnih ur za en kilogram izdelka je naslednje: V prihodnjem mesecu bodo imeli na voljo 450 delovnih ur na oddelku A, 350 na oddelku B in 50 na oddelku C. Koliko katerega izdelka naj izdelajo v prihodnjem mesecu, da bo dobiček največji? V tem primeru so kriterij ska funkcija in vse omejitve linearne funkcije odločitvenih spremenljivk. Takemu optimizacijskemu modelu pravimo linearni program, reševanju problema pa linearno programiranje. Za linearne optimizacijske probleme poznamo več algoritmov za reševanje. Programski paket Excel ima Upravljanje in uporaba podatkov 171 vgrajen modul Solver . Id omogoča tudi rgševanje_Ji Qf arnili ... nprimlzat^ jslgh problemov 4 ^: V praksi pa pogosto nastopajo tudi optimizacijski problemi, ki niso linearni. Excel omogoča njihovo reševanje na povsem enak način, kot velja za linearne probleme, le posebej moramo povedati, da gre za n elinearni prnhlem. Čeprav je tudi reševanje nelinearnih optimizacijskih problemov tako enostavno, pa moramo tukaj še posebej upoštevati dejstvo, da je programski paket le orodje in je interpretacija rezultatov še vedno naloga uporabnika. Pri nelinearnih problemih ima lahko kriterijska funkcija lokalne ekstreme, ki pa so lahko precej slabši od optimalne rešitve problema. Različne začetne vrednosti odločitvenih spremenljivk lahko dajo različne rešitve. Poleg tega problema so možni še drugi, ki so povezani z numeričnim postopkom reševanja problema, ki pa jih tu ne omenjamo, saj želimo bralca le opozoriti, da ne sme slepo verjeti rezultatom, ki jih dobi kot rešitev. Seveda pa so mu lahko ti rezultati v veliko pomoč pri iskanju prave rešitve. Na preprostem primeru pokažemo, da imajo lahko različne začetne vrednosti odločitvenih spremenljivk za posledico različne rešitve, ki jih ponudi programski paket. V problemu nastopata dve odločitveni spremenljivki X in Y. Kriterijska funkcija je sicer linearna: f(X,Y) = X vendar so omejitve nelinearne: (X-lf+(Y+2) 2 < 16 X 2 +Y 2 >13 kar pomeni, da problem ni linearen. Povejmo še, da želimo poiskati najmanjšo (minimizirati) vrednost kriterijske funkcije. Obe začetni vrednosti smo torej prvič postavili na nič. Oglejmo si rezultat: 42 Za zahtevnejše probleme linearnega programiranja priporočamo uporabo specializiranih paketov za to področje, kot na primer LINDO. 172 Informacijska podpora managementu omejitve 8 9 orni 10 orn2 C Restore Original Values 16,00 13,00 OK Cancel Save Scen. Rešitev je točka (17/5,6/5), kjer je vrednost kriterijske funkcije enaka 3,4. Excel pravi, da je zadoščeno vsem omejitvam in zahtevam po optimalnosti. Poskusimo zdaj še z začetnima vrednostma X=0, Y=-l. D Solver Results Sq|ver found a solution. Ali constraints and optimality conditions are satisfied. ikeep Solver Soiution L' Restore Original Values OK Cancel Save Scena Dobili smo drugo rešitev, ki prav tako zadošča omejitvam. Vrednost kriterijske funkcije je manjša, kar pomeni, da je bila prva rešitev le lokalni minimum. Ta rešitev (-3,-2) je res globalni minimum, česar pa nepozoren uporabnik Excela ne bi ugotovil. Monte Carlo Razmišljamo o nakupu zemljišča, ki je danes vredno 1 milijon denarnih enot. Lastnik nam ponuja možnost, da lahko ob plačilu 50.000 denarnih enot čez šest mesecev isto zemljišče kupimo za 1,1 milijon denarnih enot, n e glede na to. kakšna .bo takrat.n.jegava._trj na vre dnost. Seveda čez pol leta nismo obvezni kupiti zemljišča. Predpostavimo še to, da je ta nakup špekulativne narave in nameravamo zemljišče prodati takoj naprej ter pri tem zaslužiti. Upravljanje in uporaba podatkov 173 Možnosti, da po preteku določenega časovnega obdobja nekaj lahko kupimo po zagotovljeni ceni, pravimo opcija. Za opcijo moramo_ seveda nekaj plačat i, nekakšno zavarovalnino (v gornjem primeru 50.000 denarnih enot). Ta znesek pa se imenuje cena opcije. Vrnimo se k primeru nakupa zemljišča. Najprej moramo razlikovati nakup opcije od nakupa samega zemljišča. Z nakupom opcije smo pridobili pravico , da čez pol leta kupimo zemljišče po danes določeni ceni. Pred nami sta torej dve odločitvi. Danes se moramo odločiti, ali naj kupimo opcijo ah ne. Če bomo danes opcijo kupih, se bomo morah čez šest mesecev odločiti, ah naj zemljišče res kupimo. Najprej razmislimo slednjo odločitev. Ker se bomo o nakupu zemljišča po ceni 1,1 milijon odločah le, če bomo opcijo kupih, lahko pri odločitvi o tem, ah se zemljišče splača kupiti, zanemarimo ceno o pcije, saj bo ta takrat že plačana in je v nobenem primeru ne bomo mogh dobiti nazaj. Kdaj se nam torej splača kupiti zemljišče? Če bo tržna cena zemljišča čez šest mesecev manjša od 1,1 milijona, se nam zemljišča vsekakor ne splača kupiti po tej ceni, saj bomo poleg cene opcije utrpeh še dodatno izgubo. Če pa bo tržna cena večja od tega zneska, potem se nam nakup v vsakem primeru izplača, saj bomo lahko zemljišče prodah po tej ceni, ki je višja od cene, ki jo bomo mi plačah. Seveda, če bo tržna cena le malo višja od 1,1 milijona, še ne bomo imeli dobička, saj ne bomo pokrili cene opcije, vendar bomo z nakupom malo zmanjšah izgubo. Druga odločitev, ah naj kupim p^opdjo^ pa je težja. Težavnost odločitve je v tem, da danes, ko se moramo odločiti, ne vemo, kolikšna bo tržna cena zemljišča čez pol leta. Tako tudi ne moremo vedeti, ah se opcijo splača kupiti. V primeru, ko ne poznamo vrednosti neke spremenljivke, ki jo potrebujemo za odločanje, govorimo o negotovosti. V tem primeru lahko poskušamo čim bolje lio aniti ceno (angl. best guess), vendar se lahko veliko bolje odločamo, če poznamo porazdelitev, vrednost i spremenljivke. Z drugimi besedami, vprašamo se, kako verjetno je, da bo cena enaka neki vrednosti X. Tako porazdehtev seveda v praksi dobimo na podlagi izkušenj in znanja strokovnjakov, kar pomeni, da je tudi to le predvidevanje, vendar nam rezultati 174 Informacijska podpora managementu analize na podlagi porazdelitve dajejo mnogo boljše možnosti za odločanje kot pri ugibanju ene same vrednosti. Recimo, da za naš primer pričakujemo, da je verjetnostna porazdelitev za ceno normalna porazdelitev s pričakovano vrednostjo 1 milijon in standardnim odklonom 0,15 milijona. Torej s približno 68 % verjetnostjo pričakujemo, da bo cena zemljišča med 0,85 milijona in 1,15 milijona 43 . Kako si lahko pomagamo s podatki o porazdelitvi? Če naključno generiramo dovolj veliko število tržnih cen, kakršne naj bi bile čez 6 mesecev, lahko za vsako od njih tizračunam o T .kakšen bi bi l dobl.Č£k,(izguba) in nato izračunamo pričakovan dobiček. Seveda morajo naključno generirane cene ustrezati zahtevani porazdelitvi. S široko rabo računalnikov so se take vrste simulacij dejansko začele uporabljati v procesih odločanja, saj nam računalnik omogoča hitro generiranje velikega števila primerov in obdelavo le-teh. Zavedati se moramo, da so zaporedja števil, ki jih generiramo z računalnikom kot slučajna zaporedja, le navidezno .slučajna, saj je računalnik deterministična naprava. Vendar nam v večini primerov to zadostuje. Kadar pri reševanju problemov uporabljamo s lučajnost , govorimo o metodi Monte Carlo. Poglejmo končno, kako si z Excelom pomagamo pri odločanju o tem, ali naj kupimo opcijo v primeru nakupa zemljišča. Najprej zapišimo v preglednico vrednosti, ki jih poznamo: cena zemljišča danes, ponujena cena čez šest mesecev, če kupimo opcijo, in cena opcije. Če želimo izračunati pričakovan dobiček, potrebujemo še tržno ceno čez šest mesecev. Rekli smo, da bomo naključno generirali veliko število cen, ki ustrezajo naši predpostavki o porazdelitvi; Uporabimo generator- uiakljiičnih števil (angl. Random Number Generator) v Excelu. 43 Gre za lastnost normalne porazdelitve, da je verjetnost, da je vrednost naključne spremenljivke med |1-C in p+CT približno enaka 68 %, kjer je |1 povprečna vrednost, (J pa standardni odklon. Upravljanje in uporaba podatkov 175 Zdaj lahko za vsako ceno izračunamo dobiček. Pri računanju dobička ne smemo pozabiti, da' je vrednost denam&~e note danes drugačna, kot bo vrednost ene denarne enote čez pol leta. Zato moramo pri računanju dobička vse zneske preračunati ,na.^danja..vrednr>st (neto sedanja vrednost). Če je polletna obrestna mera enaka r, potem dobimo današnjo vrednost nekega zneska X, ki ga plačamo čez pol leta tako, da X delimo z 1+r. Vnesimo v preglednico še vrednost za r, ki naj bo v našem primer u 7.5 %. Če bo tržna_cenajnarijša^dJ.4-Jnilijnna, potem je dobiček -50.000 denarnih enot, saj potem zemljišča ne bo mo p rodali in je celoten denarni tok le cena opcije. Sicer dobiček izračunamo tako, da razliko med tržno ceno in 1,1 milijona, kolikor bomo j mi plačali za zemljišče, preračunamo na sedanjo vrednost, od katere odštejemo še ' ceno opcije. če tržna cena > 1.100.000 potem dobiček = (tržna cena - 1.100.000)/(l+r) - 50.000 sicer dobiček = -50.000 V Excelu lahko iz tržne vredn osti po zgornjem postopku izračunamo dobiček z uporabo vgrajene funkcije IF. Ta ima tri parametre, ki so lahko izrazi. Prvi parameter je logični izraz - pogoj. Če je njegova vrednost RES (TRUE), potem vrne funkcija vrednost drugega parametra - izraza, sicer pa ovrednoti tretji izraz in vrne njegovo vrednost. Torej za izračun dobička uporabimo naslednjo formulo: = IF(TC>PC ; (TC-1100000)/(1+R)-CO ; -CO) kjer so TC, PC, R in CO oznake celic, v katerih so shranjene vrednosti tržne cene, ponujene cene, polletne obrestne mere in cene opcije. 176 Informacijska podpora managementu Slika 53: Model za izračun dobička Če tak izračun naredimo za vse generirane tržne cene, dobimo porazdelitev dobička, kot kaže slika 54. dobiček frekvencerelativne frekvence =G6/1000 =G7/1000 Hi: “UZ I ! I UUU =G22/1000 Slika 54: Porazdelitev dobička Iz nje vidimo, da lahko z več kot 70 % verjetnostjo pričakujemo izgubo v znesku 50.000 denarnih enot. Iz opisnih statistik za dobiček lahko vidimo, da so možni tudi zelo veliki dobički (234.984,74 denarnih enot), vendar iz frekvenčne porazdelitve razberemo, da je verjetnost za to zelo majhna. Upravljanje in uporaba podatkov 177 Iz opisnih statistik tudi razberemo, da je povprečen dobiček -30.609,94 denarnih enot, kar pomeni, da lahko pričakujemo izgubo, če se odločimo za nakup opcije. Po taki ceni torej opcije ne bomo kupili. Ali lahko tudi odgovorimo na vprašanje, koliko smo pripravljeni plačati za opcijo? Ker smo dobičke izračunali tako, da smo na koncu vedno odšteli ceno opcije (dobiček je linearna funkcija cene opcije s smernim koeficientom -1), je očitno, da sprememba cene opcije za eno denarno enoto povzroči spremembo pričakovanega dobička prav tako za eno denarno enoto. Ce želimo, da je pričakovani dobiček vsaj 0, moramo ceno opcije znižati za 30.610 denarnih enot, torej na 19.390 denarnih enot. Znižajmo zdaj ceno opcije na 15.000 denarnih enot. Pričakovani dobiček bo zdaj pozitiven (4.390 denarnih enot), vendar bo še vedno možnost izgube, čeprav manjša. Zdaj se moramo sami odločiti za nakup opcije, glede na to, koliko smo pripravljeni tvegati. To je bil le en primer uporabe metode Monte Carlo, ki pa je uporabna povsod, kjer imamo opravka z naključnostjo oziroma nedoločenostjo. V Excelu lahko generiramo kar nekaj znanih porazdelitev, še boljšo podporo pri modelih, ki uporabljajo naključno generirana števila, pa ponuja njegova nadgradnja, to je program @Risk. Naj ob tem primeru spet opozorimo na to, da so nam ti modeli in programska oprema le v oporo pri odločanju. V tem primeru vidimo, da moramo sami določiti (na podlagi izkušenj, znanja in občutka) porazdelitev tržnih cen. Prav tako se moramo v primeru dovolj ugodne cene opcije sami odločiti, ali smo pripravljeni tvegati. 4.3 Poslovno obveščanje Z izrazom poslovno obveščanje (angl. Business Intelligence) razumemo (Inmon, Imhoff, Sousa, 1996 in Gartner Group 1999) vse sisteme, ki omogočajo uporabnikom analizo podatkov z namenom razumevan ja delovanja or ganizacije in posledic s prejetih o dločitev. V večini primerov gre za elemente sistemov za 178 Informacijska podpora managementu podporo managementu na različnih nivojih. R azvo| poslovne inteligence je tesno povezan z informacijsko demokratizacijo, ki omogoča čedalje večjemu številu uporabnikom možnost dostopa do podatkov in njihovo analizo. Po drugi strani pa tudi pri strateških odločitvah vse pogosteje ne zadošča le .presoja na podlagi izkušenj, temveč je za doseganje konkurenčnih prednosti nujna an aliza veliki h količin podatkov, kar je postalo mogoče z razvojem zmogljive strojne in programske računalniške opreme, nastankom sodobnih integriranih podatkovnih virov, npr. podatkovnih skladišč, in navsezadnje z dovolj velikimi količinami zbranih podatkov v digitalni oblilo. informacij ska-... tehnologija.'za _poslovno— .inteligeaco- ponuja danes raznolike možnosti: od orodij za poizvedovanje po podatkovnih virih, preko orodij za sprotno analitično obdelavo podatkov do orodij za rudarjenje v podatkih in specialnih orodij za analizo. Business Objects je ena od bolj znanih rešitev na področju poslovnega obveščanja. Uporabnikom ne zadoščajo več poročila, ki so jih uporabljali v preteklosti, pač pa potrebujejo boljši dostop do raznovrstnih podatkov: uporabniki želijo tvoriti lastna poročila, izvajati ad hoc poizvedbe, analizirati podatke... Zato rešitev Business Objects temelji na t.i. "semantični plasti", ki uporabnikom omogoči poslovni pogled na podatke tako, daJahnoJoške pojme preslika v poslovne, razumljive uporabniku. S tem uporabnikom omogoča preprosto poizvedovanje, analiziranje in poročanje. Sprotna analitična obdelava podatkov V začetnih fazah razvoja sistemov za podporo odločanja, managerskih in direktorskih informacijskih sistemov je bil poudarek na zagotavljanju zadbstne količine podatkov in informacij za odločanje (Sauter, 1997). Zal je bilo v lem času na voljo le malo podatkov v digitalni obliki, ki bi bili primerni za računalniško obdelavo, programi za njihovo obdelavo in strojna oprema pa nista bila dovolj zmogljiva. Z naraščanjem količine podatkov v računalniški obliki pa se je problem zagotavljanja zadostne količine podatkov prelevil y_j>rohlpjn.. zagot avljanja pravih -podatkov, to je podatkov, ki jih odločevalec v resnici potrebuje. Odločevalci se torej srečujejo z vse več podatki, ki jih za odločitve ne potrebujejo in so včasih celo zavajajoči. Managerji so dobivali na mize obsežna vnaprej pripravljena poročila, izpise iz operativnih podatkovnih baz, ki so večinoma zaradi nepreglednosti in Upravljanje in uporaba podatkov 179 neprilagojenosti dejanskim potrebam obležali neuporabljeni. Po drugi strani pa j>o managerji potrebovali mnogo poročil, ki jih zaradi raznolikosti odločitvenih situacij, s katerimi se srečujejo, ni bilo moč vnaprej pripraviti. Jezik za poizvedovanje po podatkovnih bazah SQL je sicer postajal zaradi grafičnih uporabniških vmesnikov in programov, ki so prevajali naravnemu podoben jezik v SQL, enostaven za uporabo. Za odločevalce bi torej jezik SQL lahko bil orodje za iskanje pravih podatkov, to je tistih, ki jih res potrebujejo. Težava pa je v tem, ker ima SQL zaradi svoje riaiaitnpirepmslega^e^ika le omejene zmožnosti in z njim ne moremo poiskati odgovorov na vsa poslovna vprašanja. Zaradi povečane "lakote" po podatkih tudi informacijske službe niso uspele zadostiti vsem zahtevam po pripravi acl hoc poročil oziroma pogledov na podatke. Odgovor na te težave je sprotna analitična obdelava podatkov (angl. On-Line Analytical Processing — OLAP 44 ), ki omogoča neposrede n (angl. on-line) .doslOfL do.podatkovnih virov.in izdelavo "poljubnih " 45 pogledov na podatke. Z uporabo orodij za sprotno analitično obdelavo podatkov (v nadaljevanju orodij OLAP) je torej managerjem omogočeno: ■ da si sami, na enostaven način pripravi jo pogled m podatke, k ot ga za dano odločitveno situacijo potrebujejo, ter ■ da z enostavnim spreminjanjem p ogleda na podatke u gotavljajo, kateri podatki so zanimivi in relevantni za sprejemanje poslovnih odločitev. QLAP torej zagotavlja.predvsem veliko priLagodljivast... in.. ~samostojnost pri dostopu do podatkov, vendar je izjemno pomemben predpogoj ustrezno pripravljen podatkovni vir in enostavna uporaba orodij. 44 V nadaljevanju uporabljamo zaradi uveljavljenosti v Sloveniji kratico OLAP, čeprav izhaja iz angleškega izraza za sprotno analitično obdelavo podatkov. Poljubnost jc seveda omejena na eni strani s podatki, ki jih vir vsebuje, in njihovo organizacijo, na drugi strani pa s pravicami posameznega odločcvalca do posameznih pogledov na podatke. 45 180 Informacijska podpora managementu V Merkurju že nekaj let uporabljajo t.i. k ome r cialno analitski sistem (KAS), katerega namen je omogočiti analitikom in vsem, ki morajo vsakodnevno sprejemati odločitve na področju prodaje in upravljanja z blagom, pr idobivan j e informaci j, ki jih potrebujejo pri svojem delu. Nekatera pogosto uporabljena poročila so že vnaprej pripravljena in uporabniki samo dostopajo do njih oziroma imajo vanje vpogled. Uporabniki po lahko tudi poročilo pa lahko tisti, ki ga je pripravil, ponudi v uporabo tudi ostalim uporabnikom. V prvi fazi so se osredotočili na podatke o prodaji ter zalogah in jih povezali s podatki o potrošnikih in poslovnih partnerjih. Sistem uporabljajo na različnih področjih v podjetju: od trženja do odnosov z dobavitelji. KAS uporabljajo pri analizah, ki so povezane z upravljanjem strukture prodaje v maloprodajni verigi, z učinkovitostjo prodajnih akcij, z upravljanjem asortimana ipd. Gre za orodje, ki daje odgovore na vprašanja kdo, kaj in zakaj v realnem času. S pomočjo tega tudi kompleksnejših analiz v smeri iskanj odgovorov na vprašanja tipa kaj-če. KAS je zgrajen na rešitvi Microstrategy. (Pripravil Boris Moškotelec, univ.dipl.ekon., pomočnik direktorja Marketinga, Merkur d.d.) Podatkovni viri obdelava podatkov (angl. on-line transaction processing — OLTPV niso ustrezni * značilnosti obremenitev sistemov so bistveno drugačne, ■ podatkovni model je v operativnih sistemih bistveno prezapleten, da bi lahko tak podatkovni vir uporabniki uporabljali samostojno, ■ podatki so neintegrirani v različnih operativnih podatkovnih v irih in drugo. A ' Iz povedanega je očitno, da je najprimernejšt podatkovni vir za OLAP po dročno podatkovno skladišče,...saj vsebuje integrirane podatke, podatkovni model paje prilagojen potrebam analitika in praviloma večdimenzionalen ter s tem preprost za razumevanje. Redkeje se orodja OLAP uporabljajo neposredno nad podatkovnim skladiščem, predvsem zaradi zapletenosti modela in velike količine podatkov, ki ne omogoča učinkovitega dela. i, ki jih potrebujejo, in sicer v obliki, v kakršni jih potrebujejo. Vsako novo pripravljeno :. V prihodnosti se nameravajo lotiti Že v začetku razvoja OLAP je bilo ugotovljeno, da v skupni podatkovni virL za operativne potrebe, ki jih za razliko od OLAP imenujemo sprotna transakcijska zaradi različnih razlogov (glej tudi poglavje Podatkovni viri v organizaciji): Upravljanje in uporaba podatkov 181 Večdimenzionalni pcrgled na ppdatke, ki ga> omogočajo orodja OLAP, lahko zagotovimo na različen načine, najpogosteje pa srečamo: R OLAP ali relacijski OLAP. kjer so sistemi za upravljanje relacijskih podatkovnih baz prilagojeni tako, da omogočajo učinkovito delo z velikimi količinami podatkov, s posebnimi o rodji ki podatke preslikajo v večdimenzi onalno kocko , pa skrijemo zapletenost relacijskega modela (glej sliko 41), M OLAP a li več dimenzion alni O LAP (angl. Multidimensional OLAP) pa temelji na uporabi sistema za upravljanje večdimenzionalnih podatkovnih baz, torej so podatki shranjeni tako, kakor jih vidi uporabnik. Slika 55: Primer orodja (MS OLAP Manager) za preslikavo relacijske podatkovne baze v večdimenzionalno kocko 182 Informacijska podpora managementu Orodja OLAP imi- smh t £2,6 e(k$(J Orodja OLAP ni-ncgrirbijn -irprdimpn.?innalpn pogled na podatke njihovi bistveni značilnosti pa sta preprosta uporaba in prilagodljivost pogleda na podatke. Preprosta uporaba pomeni, da lahko z nekaj kliki miške dobimo .pidjuben-prerez. podatkov, pravil oma v obliki vrtilne tnhele (glej podpoglavje Vrtilne tabele v nadaljevanju). Zaželeno je tudi, da je delovno okolje orodja tako, v katerem se uporabnik že dobro znajde. Tako je, na primer, programski paket za delo s preglednicami MS Excel. ki ga uporabljajo mnogi analitiki, mogoče uporabiti tudi kot or odje OLAP. Orodja OLAP vedno bolj pogosto srečujemo tudi kot del spletni h a plikacij, ki jih uporabljamo v standardnih spletnih brskalnikih. Primer sprotne analitične obdelave podatkov preko Interneta je prikazan na sliki 56. •'jj$ PASEF - Zaključni računi slovenskih podi File Edit View Favorit es Tools Help Osnovne informacije | Študij | Pedagogi | Raziskovalno delo j Viri PASEF Podatkovno analitično središče Ekonomske fakultete Prijavljeni ste kot: docent Jurij Jaklič, dr. odjava iz sistema Pogoste težave in njihove rešitve Navodila za uporabo Sporočilo skrbniku Pomen AOP-iev : Seznam vseh AOP-jev ( spletna stran . Word datoteka ) Kontakt | Iskanje j Novice Dr ag itemstothe PivotTable list O AOPllOpovp j V Aoplll O AOPlllpovp Aopl 12 JO AOP112povp Ci Aopl13 H AOPllSpovp Št podjetij ;+:■ fO Kraj + ' Lastnina i+j - Leto + ■ Občina + Poreklo kapitala +: - Regija +; £ SkdSkd +!• 'A- Velikost podjetja (AOP093). Add to jRow Area i-kra jetij JŽ.i ^ Internet Slika 56: Uporaba sprotne anlitične obdelave podatkov preko Interneta Pri izdelavi pogledov na podatke naj bi orodja OLAP ponujala predvsem naslednje možnosti: Upravljanje in uporaba podatkov 183 Enostavno izdelavo pogledov na podatke in prikaz le-teh v obliki grafov razl i čnih' tipov. zu mU ef£Y (TUjfiMA Posebej pomembna je tudi možnost izdelavi: primerjav na primer primerjava prodaje izdelkov v prvem četrtletju preteklega in letošnjega leta. Opomnimo, da z jezikom SQL ni mogoče neposredno izdelati take primerjave. ■ Definirati je mogoče pravila za prikaz izjem. Na primer, v pregledu rasti prodaje po izdelkih in prodajalcih lahko definiramo, da s e poudarjeno i z drugo barvo ali podobno) izpiš ejo vredno sti, ki so manjše od 2 %, da tako hitro opazimo, pri katerih prodajalcih in izdelkih dejanska rast ne dosega zahtevane oziroma pričakovane. ■ Iz obstoječih podatkov je mogoče je izračunati nove, na primer, bruto mejni donos na zalogo iz prodane količine, prodajne cene, nabavne cene in povprečne dnevne zaloge. ■ Orodja OLAP omogočajo tudi izračun agregatnih podatkov, ki niso na voljo že v podatkovnem viru. Tipične operacije, ki jih z orodji OLAP izvajamo nad pogledi na podatke, so (Jarke et al., 2000): ■ Zvijanje (angl. roll-up). Podatke prikažemo man j podrobn o. ■ Vrtanje v globino (angl. drill-do\vn). Podatke prikažemo bolj podrobno. Pogosto uporabimo vrtanje, ko opazimo v tabeli zanimiv (npr. izstopajoč) sumaren podatek in nas zanima bolj podrobno, kako je do te vrednosti prišlo. Na primer, ko prikazujemo rast prodajo izdelkov po regijah, opazimo padec vrednosti prodaje izdelka A v regiji X, zato pogled razširimo še z dimenzijo prodajalne (torej v dimenzijo prodaja glede na izdelek, regijo in trgovino, da ugotovimo, če je morda katera izmed trgovin v regiji X posebej odgovorna za padec prodaje v tej regiji. Ta operacija je značilna pri iskanju odgovora na vprašanje "Zakaj?". ■ Rezanje (angl. slice and dice). Naredimo . izbor podatkov , prikažemo pndk-orko. Na primer, v pogledu prodaje izdelkov po regijah izberemo samo izdelke določene kategorije. 184 Informacijska podpora managementu Vrtenje (angl. pivot). Obračamo pogle d na pod atke, na primer, pogled •prodaja po regijah ■spremenimo v pogled prodaja po izdelkih in nato v pogled prodaja po izdelkih znotraj posamezne regije. Slika 57: Prikaz izjem in možnost vrtanja v globino v orodju Oracle Discoverer Rudarjenje v podatkih Čeprav je sprotna analitična obdelava zelo uporabna v mnogih primerih, ko nas zanima vpogled v podatke in želimo odkrivati zanimive informacije, pa ne omogoča avtomatičnega odkri vanj^Lznanja (zanimivih informacij, vzorcev, pravil ...) -vrve hkih količinah podatkov. Prav to pa nam omogoča rudarjenje v podatkih (angl. Data Mining), ki ga lahko definiramo kot proces odkrivanj a vzorcev in povezav v podatkih z namenom boljših poslovnih odločitev. čeprav so tehnike, ki se uporabljajo pri rudarjenju v podatkih, znane že od prej, pa je razvoj rudarjenja pogojen z razvojem zmogljive računalniške opreme, saj je za Upravljanje in uporaba podatkov 185 rudarjenje značilno, da iskanje pravil in vzorcev poteka avtomatično v veliki množici podatkov. Namen uporabe rudarjenja je prav razumevanje ogromnega števila podatkov, ki so bili zbrani v letih od začetkov računalniške obdelave podatkov v organizacijah. Ker so ujjorabniki orodij za rudarjenje praviloma (poslovni) analitiki, je pomembna zahteva za ta orodja, da so preprosta za uporabo in da ni potrebno posebno poglobljeno znanje tehnik rudarjenja. Uporabniki torej praviloma niso profesionalni statistiki, matematiki, programerji in podobno. Rudarjenje v podatkih se ponavadi omenja v zvezi s poslovno uporabo (glej npr. definicijo zgoraj), a je njegova uporaba mnogo širša in obsega, na primer: * medicinsko diagnostiko, ■ odkrivanje prevar (npr. davčne napovedi), ■ nadzor onesnaževanja v elektrarnah, * prijaznejša uporaba spleta (v veliki množici informacij na spletu dobite izbor tistih, ki vas utegnejo zanimati glede na vaše dosedanje obiske spletnih strani), * kriminalistiko (odkrivanje vzorcev pri kriminalnih dejanjih), * preverjanje identitete (npr. v računalniških sistemih). Na poslovnem področju se je rudarjenje najbolj uveljavilo na^odročj.u_tržetjja, kjer je postalo zanimivo zaradi bolj poudarjene usmeritve k posameznemu kupcu. Govorimo^uravnavanju odnosov s kupci (angl. Customer Relationship Management, CRM), ki pomeni usmerjenost na stranke, vzpostavljanje, vzdrževanje, ohranjanje ter izboljševanje odnosov z njimi. Gre za tako poslovno usmeritev podjetja oziroma način razmišljanja, ki postavlja v središče .stranko. Najpomembnejša korist koncepta CRM je privabljanje boljših strank in zadržanje obstoječih dobrih oziroma donosnih strank. Seveda moramo v primeru take usmeritve podjetja stranko dobro spoznati in razumeti njeno obnašanje, kar 186 Informacijska podpora managementu omogočajo kakovostni podatki o strankah , 46 in ustrezni analitični postopki ter orodja. Anali tični C RM (govorimo še o operativnem 47 in organizacijskem 48 CRM) je torej področje, kjer se organizacija ukvarja s postopki za doseganje temeljitega vpogleda v potrebe in želje strank, razumevanje njihovega vedenja in predvidevanje njihovih namer. Prav tu je rudarjenje izredno zmogljiva tehnologija, če gajiporabimo pravilno in če imamo dovolj kakovostnih podatkov o strankah. Najpogosteje se rudarjenje na področju trženja uporablja za: neposredno trženje, npr. ponudbe pošiljamo kupcem, od katerih z večjo verjetnostjo pričakujemo odziv, izdelavo profilov kupc ev — ug otavljamo vzorec obnašanja kupca, na podlagi le-tega pa lahko ustrezno prilagodimo ponudbo, segmentacijo - določanje skupin kupcev z enakimi značilnostmi jvzorcem obnašanja), iskanje povezav med prodajo izdelkov (analiza nakupne košarice, angl market basket analysis), kar lahko uporabimo npr. za ustrezno razporeditev izdelkov na policah, aktiviranju kupca, .. ■ navzk rižnem trženju^ to je stimulacija nakupa drugih izdelkov istega podjetja (angl. cross-selling), oz. več istih izdelkov (angl. up-selling), kar lahko nadomešča pridobivanje novih kupcev, ■ ghdržan^u-kupea, kar je bistveno ceneje od pridobivanja novega kupca ... Denimo, da pošiljatjio reklamno gradivo za nov izdelek. Če ne nameravamo gradiva poslati vsem našim kupcem, imamo dve možnosti: naslove lahko izberemo iz trženjske baze naključno, lahko pa uporabimo rudarjenje. V slednjem primeru si 48 Prav pridobivanje podatkov o strankah sc kaže kot eden najtežjih problemov pri analizi njihovega vedenja. 47 Operativni CRM se nanaša na izvajanje procesov, s katerimi se podjetje povezuje s strankami. Zanj je značilna prenova in informatizacija poslovnih procesov, pri katerih organizacija sodeluje s strankami. 48 Organizacijski CRM sc nanaša na komuniciranje med organizacijo in strankami (preko elektronske pošte, obveščanje preko spletnih strani ...) Upravljanje in uporaba podatkov 187 z rudarjenjem pomagamo tako, da na osnovi podatkov o dosedanjih nakupih izberemo tiste kupce, za katere je verjetnost, da se bodo odzvali (kupili nov izdelek) večja. Na sliki 58 je prikazano, kako nam rudarjenjfi..p!.Qv:eča-xidzivnost-na oglašev alska akcip , s tem pa tudi zniža stroške, saj lahko za isti odziv reklamno gradivo pošljemo na manj naslovov. Krivulji prikazujeta, kakšen odstotek tistih, ki bi se odzvali na reklamno gradivo, dosežemo, če pošljemo reklamno gradivo določenemu odstotku vseh kupcev. Spodnja krivulja kaže linearno povezavo v primeru, ko prejemnike gradiva izbiramo naključno, pri uporabi rudarjenja pa, na primer s pošiljanjem gradiva 50 % oseb, dosežemo kar 90 % tistih, ki se bodo na ponudbo verjetno odzvali. Tako imenovana krivulja dviga (angl, lift curve) je sicer od primera do primera različna, a je v praksi že znanih nekaj tako uspešnih primerov uporabe rudarjenja. ' Odstotek odziva 100 90 80 70 60 50 40 • 30 ■ 20 • 10 ■ 10 20 30 40 50 60 70 80 90 100 Odstotek poslanih Slika 58: Povečanje odzivnosti z uporabo rudarjenja Lep primer uporabe rudarjenja v podatkih so tudi pripor očila naslovov, k i utegnejo zanimati obiskovalc a spl etne_knjigarn e (glej npr. http://www.amazon.com). Ta priporočila so izdelana za vsakega obiskovalca posebej glede na njegovo predhodno obnašanje, to je sprehajanje po spletnih straneh knjigarne. Druga vrsta priporočil so pri opisu knjige, ker nam se izpiše seznam knjig, za katere so se zanimali obiskovalci, ki so se tudi zanimali za to knjigo. Tovrstna priporočila ^ 188 Informacijska podpora managementu pomenijo seveda dodatno vrednost, ki za spletno knjigarno predstavlja konkurenčno prednost. Slika 59: Priporočila spletne knjigarne Poleg področja trženja je možnost uporabe rudarjenja predvsem na financ in hančništoa.. (napovedi prevar, slabih odplačevalcev kreditov, napovedi vrednosti delnic...) ter zavarovalništva ( napovedi odškodninskih zahtevkov in prevar). , Tehnike/algoritmi, ki se najpogosteje uporabljajo pri rudarjenju, so: najbližji sosed, razvrščanje v skupine, drevesa odločitev, inducirana pravila, Upravljanje in uporaba podatkov 189 ■ nevronske mreže, ■ genetski algoritmi ... Najbližji sosed (angl. Nearest Neighbor) na pove duje Vrednost spremenljivke za neko (opazovano) enoto tako, da pogleda vrednost iste spremenljivke za tiste enote, ki so "najbližje" opaz ovani e noti. Predpostavka je, da imajo enote, k i so bti_zu_ skupaj, pod obne vrednosti spremenljivk . Seveda moramo pri tej tehniki določiti, kaj pomeni oziroma kako merimo "bližino". To je ena najstarejših tehnik, ld se uporablja pri rudarjenju. Pri razvrščanju v skupine (angl. Clustering) gre za razvrstitev enot v skupine tako, da je zno traj skupi n dosežena kar največja homogenost__(enote so čimbolj skupaj), hkrati pa so skupine med seboj čimbolj heterogene (čimbolj narazen). Določiti moramo število skupin in atribute, na podlagi katerih se določa "bližina". Ta algoritem se največkrat uporablja pri segmentaciji. Drevesa odločitev so simbolična predstavitev odločitvene situacije. Z rudarjenjem iz danih podatkov, to je primerov, za katere vhodne podatke in rešitve že poznamo, zgradimo odločitveno drevo, ki ga kasneje lahko uporabimo na novih primerih. Na sliki 60 (a) so prikazani podatki 49 o že obr avna vani l^prošnjah_za, krptii t Za vsako prošnjo je najprej prikazanih nekaj podatkov o prosilcu: spol, starost, koliko časa živi na zadnjem naslovu, ali je lastnik ah najemnih nepremičnine, kjer živi, poklic, trajanje trenutne zaposlitve, koliko časa je stranka banke ter kolikšni so mesečni stroški gospodinjstva. V zadnjem stolpcu pa je razvidno, ah so bančni uradniki - eksperti, prošnji za kredit ugodili ali ne. Z uporabo rudarjenja lahko iz teh podatkov izluščimo odloči tvena pr avila, ki so jih uradniki uporabljati pri obravnavanju prošnje. Z drugimi besedami, iz podatkov izluščimo znanje ekspertov. S stike 60 (b) vidimo, da je bil pri obravnavi na jpomembnejši k riterij, koliko časa je prosilec.stranka_banke; meja je tri leta. Ce je prosilec stranka banke več kot tri leta, je bila prošnja praviloma odobrena, Če pa je 49 Primer je povzet po (Al-Attar, 1999). 190 Informacijska podpora managementu prosilec pri banki manj kot tri leta, je bil naslednji kriterij trajanje trenutne zap oslitve . In tako dalje. Odločitvena pravila beremo tako, da se sprehodimo od korena drevesa (na sliki na vrhu) do listov, na primer, "C e je p rosilec pri banki manj kot 3 leta in traja njegova trenutna zaposlitev manj kot 1,02 leti, je bila prošnja praviloma zavrnjena." Odstotek primerov, ki izpolnjujejo pogoje pravila-(so pri banki manj kot 3 leta in traja njegova trenutna zaposlitev manj kot 1,02 leti) in rešitev ustreza pravilu (prošnja zavrnjena), imenujemo zaupanje. Dobljeno drevo odločanja lahko zdaj uporabimo za (delno) avtomatizacijo obravnave prošenj. 0 ) J zavrnjena delavec, umetnik... zavrnjena administrativni... ( odobrena ] (b) Slika 60: Podatki (a) in pripadajoče drevo odločanja (b) Upravljanje in uporaba podatkov 191 Inducirana pravila imajo podoben namen kot odločitvena drevesa, le da so odločitvena pravila prikazana v obliki ČE-PO TEM pravil: ČE A, & A 2 & ... & A„ POTEM B, & B 2 & ... & B m kar preberemo: "Če se zgodi Al—An, potem se v okv iru iste tran sakcije pogosto zgodi tudi Bi...B m ". Velja, da lahko vsako odločitveno drevo izrazimo kot niz pravil , ne velja pa obratno. To pomeni, da imajo inducirana pravila nekoliko večjo izrazno moč, vendar imajo odločitvena drevesa prednost z.vidika, predstavitve. Slika 61: Primer orodja za rudarjenje v podatkih DB Miner Inducirana pravila lahko razdelimo na tri vrste, glede na to, ali povezujejo podatke iz iste dimenzije (o večdimenzionalnem modelu glej več v poglavju Podatkovne baze): znotraj-dimenzionalno pravilo: kupec.država="Slovenija": izdelek.naziv="barva" => izdelek.naziv="čopič" med-dimenzionalno pravilo: kupec.država="Slovenija" => izdelek.kategorija="kava" hibridno pravilo: kupec.država="Slovenija": izdelek.naziv="barva" => izdelek.naziv="čopič" & čas = "pomlad" 192 Informacijska podpora managementu Nevronske mreže naj bi posnemale delovanje človeških možganov. Umetne nevronske mreže so množica povezanih vozlišč, ki so razporejeni v več slojev (glej sliko 62). Vozlišča nevrons ke mreže vsebujejo uteži, ki odražajo relativno moč posameznih vrednosti, ki so vhod -v vozlišče. Z uporabo transformacijske funkcije se uteženo povprečje vhodnih podatkov pretvori v izhodni podatek, ki je nato vhod v vozlišča na naslednjem nivoju, razen na izhodnem sloju, kjer je to izhod iz nevronske mreže — rešit ev problem a. Uteži v vozliščih dobimo tako, da se nevronska mreža uči na testnih podatkih, to je na podatkih, za katere poznamo tudi izhodne vrednosti. Vzemimo za primer obravnavanje prošenj za kredit (glej Odločitvena drevesa). Vhodni podatki so podatki o prosilcih, torej bi imeli ftffvliddfiem s loju 8 vozlišč, izhodni podatek pa je odločitev odobrena/zavrnjena, torej ima izhodni sloj samo eno vozlišče. Pred uporabo nevronske mreže moramo nek atere podatke sp re meniti v numeričn e vrednosti. Na primer, izhodni podatek o odločitvi bi lahko pretvorili v vrednosti 0 (zavrnjena) in 1 (odobrena). Na podlagi podatkov za učenje, kjer so znani tudi izhodi, se nevronska mreža uči, kar pomeni, da sc določijo vredn osti utež i. Za posamezen primer se izračuna vrednost izhoda z obstoječimi utežmi, primerja izračunana vrednost izhoda z dejanskim podatkom, nato pa ustrezno popravijo uteži 5f l Ta po&topek ponavljamo in s tem zmanjšujemo napako (razliko med izračunanim in dejanskim izhodom). Potem te podatke uporabimo za napovedi v primerih, ko še ne poznamo izhodnih vrednosti. V primeru obravnavanja prošenj za kredit bi za obstoječe podatke o prošnjah vstavili v vhodni sloj podatke o prosilcu, z dmiimLiitežmi in tra nsformacijsko funkcijo izračunal i izhod (0/1) in ga primerjali z dejanskim podatkom o tem, ali je bila prošnja zavrnjena ali odobrena. Po potrebi bi popravili uteži. Postopek ponovimo za vse podatke v množici podatkov za učenje. 50 Postopkov za popravljanje uteži poznamo veliko, najpogosteje backpropagation). uporablja vzvratno razširjanje (angl. Upravljanje in uporaba podatkov 193 Izhod Vhod Slika 62: Model nevronske mreže Ce primerjamo model umetne nevronske mreže z biološko, potem vsako vozliš če umetne nevronske mreže preds tavlja nevro n. Na sliki 63 sta prikazana dva povezana nevrona — živčni celici, takole pa lahko primerjamo posamezne elemente biološke in umetne nevronske mreže: Biološka nevronska mreža Umetna nevronska mreža telo vozlišče dendrit vhod akson izhod sinapsa utež Nevronske mreže se uporabljajo predvsem za- napovedo v anje in analizo tveganja , na primer v financah pri analizah tveganja, pri napovedovanju odziva kupca, pri napovedovanju prevar in podobno. Njihove značilnosti so: * velika natančnost, ■ dolgi časi "učenja" ■ vhodnL_podatkL-iaQiajQ„.hili._nuni££iČai (v nasprotnem primeru je prej potrebna pretvorba). 194 Informacijska podpora managementu Živčna celica (nevron) Čeprav je ideja, da bi programska oprema posnemala načela biološkega razvoja, že stara, pa se je uporaba genetskih algoritmov, ki temeljijo na tej ideji, razširila šele v zadnjih letih. Genetski algoritmi se uporabljajo za optimizacijo, strojno učenje, pri reševanju ekonomskih problemov ... Zavedati se moramo, da rudarjenje v podatkih ne pomeni zgolj uporabe orodja za rudarjenje, temveč ga moramo opazovati skozi celoten proces, kot je prikazan na sliki 64. Zelo pogosta napaka pri rudarjenju je slabo definiranje poslovnega problema, ki ga želimo z rudarjenjem rešiti. V tem primeru je le malo verjetno, da bo rudarjenje v poslovnem smislu uspešno, čeprav dobimo dobre in veljavne rezultate same analize. Upravljanje in uporaba podatkov 195 Slika 64: Proces rudarjenja v podatkih Izkušnje praktične uporabe kažejo, da največji del vloženega napora v okviru procesa zbiranje in priprava po trebnih p odatkov . Odvisno od kakovosti podatkov in podatkovne arhitekture v organizaciji lahko vloženo delo v to fazo dosega celo 50 % in več dela vloženega v celotni proces. Predpriprava podatkov obsega: združevanje podatkov... iz različnih virov, opredelitev izračunanih atributov, obravnava manjkajočih vrednosti, pretvorba nenumeričnih v numerične vrednosti (nekateri algoritmi zahtevajo numerične vrednosti), obravnava nekonsistentnih podatkov in osamelcev, odstranitev šuma, normalizacija podatkov, po potrebi dodajanje novih atributov ... Iz faz procesa je razvidno, da rudarjenja ne more izvajati samo nekdo, ki dobro pozna delo z orodjem za rudarjenje, pač pa gre jza-interdisciplina rno področje. Zaželeno je, da bi v procesu rudarjenja sodelovali: ■ informatik skrbi za pripravo podatkov, za lociranje le-teh, združevanje ..., * podatkovni analitik (npr. statistik) skrbi za primernost metod, za izbor primernih podatkov ..., 196 Informacijska podpora managementu ■ poznavalec področj a ki definira poslovni problem (prava poslovna vprašanja), izbira relevantne podatke, i nterpretira rezultate , - predlag a aktivnosti na podlagi rezultatov rudarjenja, ter ■ vodja projekta. Opozorimo še na nekatere značilnosti rudarjenja v podatkih: * Pogosto se zastavlja vprašanje, kakšna je razlika, med statistiko in ru.dar)euj£tXL. Pomembna razlika je predvsem v tem, da moramo v statistiki za vsak problem postaviti hipoteze. Drugače povedano, pri statistični analizi nikoli ne najdeš tistega, česar ne iščeš. Po drugi strani pa gre pri rudarjenju za avtomatizirano iskanje vzorcev, pravil. ■ Ne drži, da pri rudarjenju ne rabite vedeti, kaj iščete, ker gre za iskanje neznanih vzorcev. Res je, da programska oprema poišče neznane vzorce, vendar mora a nalitik najprejdfSrmuEratT p ro51e5> čkar ni isto kot postavljanje hipotez; glej prvo točko). ■ Najpogostejše napake neizkušenih analitikov so: ponovno odkrivanje znanja, nepoznavanje problemskega področja in neustrezna priprava podatkov. Na primer, z rudarjenjem so ugotovili, da so krediti praviloma pogosteje odobreni v primeru pisnih vlog kot v primeru telefonskih klicev. Sele, ko so v proces vključili poznavalca področja, je le-ta povedal, da se pogosto zgodi, do pri telefonskih klicih, pri katerih prošnja očitno ne ustreza zahtevam, to prosilcu povedo, ne da bi zabeležili njegov klic - prošnjo. Pri pisnih prošnjah pa vsako zabeležijo, ne glede na to, da morebiti že na prvi pogled ne ustreza. * Opozorimo še na pravne. ... vidik e rudarjen ja, saj lahko z rudarjenjem ugotovimo in kasneje uporabimo take informacije, ki bi lahko posegale v pravice posameznika (npr. kupca) do varovanja osebnih podatkov. Področje rudarjenja je posebej problematično zato, ker nikoli ne vemo, kaj bomo z njim odkrili in kako to uporabili (to je pravzaprav bistvo rudarjenja), zakonodaja pa dovoljuje zbiranje podatkov o posamezniku le, če je vnaprej določeno, v kakšne namene bomo podatke uporabljali. Upravljanje in uporaba podatkov 197 Po napovedih (Gartner Group, 1999) se bo v nekaj ledh povečala enostavnost uporabe orodij za rudarjenje, proces rudarjenja bo bolj avtomatiziran, s tem pa se bo njegova uporaba močno razširila. V podjetju Petrol so leta 2001 pripravili pilotski projekt, s katerim so skušali analizirati primernost uporabe rudarjenja in morebitne probleme, ki bi se pri tem pojavili. Najprej so identificirali dva poslovna problema, ki bi bili primerna za up orabo rudarjenj a: Prvi je napovedovanje, kateri_kupcLjr 4 }jLOjdfliL.ruLdellfiio (olja, maziva in drugi proizvodi iz nafte) utegnejo v krajšem časovnem obdobju poslati slabi.plačaiki. Drugi problem je iz maloprodaje, kjer so analizirali povezave med prodajo posameznih skupin izdelkov (nakupna košarica). Kupci na debelo so glede na višino odprtih in zapadlih obveznosti razdeljeni v tri razrede: (1) normalna prodaja, (2) vnaprejšnje plačilo in (3) prodaja zaustavljena. Ali je mogoče napovedati uvrstitev kupca v razred 2 ali 3? V tem primeru se je izkazal za večji problem dosegljivosti potrebnih podatkov o kupcih (o nabavi in prodaji, o odprtih in zapadlih obveznostih do partnerja in partnerja do organizacije, o prometu v dobro in v breme, lastnosti poslovnega partnerja), iz katerih bi sklepali na spremembo uvrstitve v razred.£otrebnbpodfltkiia.se4ialifljolHWXiziimiLvidli, vnos. .nekaterih podatkov, ni. biLabvezen, kakovost podatko v ie bila slaba , nekatere podatke o partnerjih je bilo potrebno pridobiti iz zunanjih virov. Po pripravi podatkov, oblikovanju modela in uporabi orodja za rudarjenje (IBM Intelligent Miner) so oblikovali listo 70 partnerjev, ki naj bi prišli v razred 2 ali 3, kasneje se je izkazalo, da se jih je od teh dejansko uvrstilo v ta dva razreda 14. Pomembni stranski produkti tega projekta so bili: ozaveščanje in informiranje o sodobnih informacijskih tehnologijah rudarjenja in njihovi uporabnosti, izboljšanje postopka zbiranja podatkov o poslovnih partnerjih in izboljšanje kakovosti samih podatkov. V drugem primeru, kjer so analizirali račune iz maloprodaje (trgovine HIP-HOP) in odkrivali povezave med prodajo skupin izdelkov, je bilo stanje glede kakovosti podatkov bistveno drugačno, saj im ajo vse podatke iz vseh trgovin zhrnn e v osredn j i hazL podcitlcQy. Čeprav so bili podatki kakovostni, je bila potrebna njihova predpriprav a za postopek rudarjenja (npr. izločitev "zaokroževanja" kot postavke računov). Projekt je potekal v sodelovanju s tržniki. Pravila, ki so jih z rudarjenjem našli, so tržniki primerjali z intuitivnim poznavanjem. Nekatere odkrite povezave so bile tržnikom že prej znane, odkrite pa so bile tudi nekatere presenetljive povezave, kar je pravzaprav cilj rudarjenja. Na primer, presenetljivo je bilo pravilo, da so "artikle iz skupine hrana za gospodinjstvo kupili kupci, ki so kupili izdelke iz več skupin kot povprečni kupci". Odkrili so tudi močne povezave med nakupom sladkih in slanih izdelkov ter pijačami ter da sodi skupina alkoholnih pijač med skupine z največjim vplivom na prodajo ostalih artiklov. (Pripravil mag. Sandi Pogačnik, Petrol d.d.) 198 Informacijska podpora managementu 4.4 Poslovni portali Kljub uvedbi integriranih podatkovnih virov, kot so npr. podatkovna skladišča ali operativne shrambe podatkov, pa se v mnogih organizacijah še vedno dogaja, da uporabniki nimajo učinkovitega dostopa do vseh poslovnih informacij, ki jih potrebujejo za svoje delo. Razlog tiči v tem, da so prej omenjeni integrirani podatkovni viri namenjeni predvsem shranjevanju Strukturiranih podatkov, v organizacijah pa obstaja množica n estrukturiranih podatkov kot so e -pošta, faks. spletni dokumenti, digitalizirane slike;, dokumenti, pripravljeni v urejevalnikih besedil, poskenirani dokumenti, zvočni in video dokumenti, predstavitve in drugo. Seveda so tovrstne informacije prav tako pomembne za učinkovito delo in poslovno odločanje kakor informacije, pridobljene iz strukturiranih podatkovnih virov. Ne gre pa pozabiti tudi na zunanje nestrukturiranc podatk e (npr. grafični prikaz gibanja tečaja delnice konkurenčnega podjetja, vremenska napoved z animirano satelitsko sliko in podobno). Mnogokrat uporabniki izgubljajo mnogo dragocenega časa za iskanje tovrstnih informacij. Poslovni portal je povezava različnih virov informacij iz poslovnih strukturiranih podatkovnih virov (podatkovno skladišče, področno podatkovno skladišče, operativne podatkovne baze ...), nestrukturiranih podatkovnih virov (sistemov za upravljanje z dokumenti ...), programskih rešitev (OLAP ...) ter zunanjih podatkovnih virov (predvsem z Interneta) v enotno vstopno točko , preko katere do njih dostopamo z uporabo (spletnih) brskalnikov. Gre torej za prikaz za uporabnika bistvenih informacij združenih na enem mestu (enem zaslonu). Seveda na enem mestu ni mogoče hkrati prikazati vseh informacij, ki jih potrebuje uporabnik, zato tudi p orta l i omogočajo v rtanje-v-globfao (glej podpoglavje Sprotna analitična obdelava podatkov). Če je, na primer, na uvodnem zaslonu portala grafično prikazano gibanje prodaje v zadnjih dneh, lahko s klikom na graf pridemo do bolj podrobnih (detajlnih) podatkov o prodaji. Ah, če je prikazan naš današnji urnik, kjer je zabeleženo, da imamo poslovni sestanek, lahko s klikom na ustrezno ikono pridemo do gradiv, ki jih za sestanek potrebujemo. Upravljanje in uporaba podatkov 199 mymm Baskgpotmd , Fš tundal v . N«w t|, Sto s 1; Pra duc ts : Ha?dy» ; 3r« . Si>ftwor« . Sfitvic.fij S app o rt : TVavgi, Pgopl* Findgr , Factljfe'ft . £§*W5 Sitfrs . Ma pi & Oifftotžsm . W«:at:her Pik* $116.25 itis n— rsmnmsm Higk- Um w» • hk» c ?33BgTrnisiW Šarfe ground Fmane Hi y M«w* * , gvtntv Sto c'k . Anaižysit . AUrts y=~~n| Tivoli Djg Organi!aticn činan-sial* m EV*nr Seh«dvi« $23.2$ tfe«*. iittdutiiiv ?f*s To Creste €-B >2 3uzz h^\m\ (May28. $869) ttmm SM £*£?$&£(> ,81*£ & W>atm and sunny Slika 65: Primer poslovnega portala Poslovni portal torej združuje zelo različne koncepte in informacijske tehnologije; za uporabnika postane transparentno, za katero tehnologijo gre in iz katerega podatkovnega vira pridobiva informacije. Uporabniki pričakujejo od portalov predvsem (Hrvatin, 2000): ■ enostavno iskanje in dostop do poslovnih informacij, ki jih potrebujejo za učinkovito opravljanje svojega dela, ■ smiselno povezovanje informacij v celoto, * iskanje oseb, ki lahko v določenem primeru ponudijo pomoč, ■ boljšo lastno organiziranost, ■ možnost povezovanja s sodelavci ter ■ povezanost poslovnih procesov. Poglavitne značilnosti poslovnih portalov so: 200 Informacijska podpora managementu ■ enostavna uporaba , saj so namenjeni zelo različnim uporabnikom z različnim poznavanjem informacijske tehnologije, ■ univerzalen dostop do podatkovnih virov , ■ možnost iskanja ; uporabnik mora z enim samim iskanjem priti do vseh relevantnih informacij, ne glede na obliko in vir, kar pomeni, da mora biti vgrajeno is kalno nmdjp zelo zmogljivo: ponavadi gre za integracijo različnih iskalnih orodij, optimiziranih za različne vrste podatkov, ■ sodelovanje-, portali običajno integrirajo tudi o rodja za skupinsko delo (angl. group\vare), ■ prilagajanje oz. personaligacija-, očitno je potreba po informacijah različnih uporabnikov zelo raznolika, zato je bistveni element portalov možnost prilagajanja individualnim potrebam. Z uvedbo portala se ponavadi poveča tudi donosnost ostalih informacijskih projektov, saj omogočajo, na primer, boljšo izkoriščenost že uvedenih podatkovnih skladišč in raznih poslovnih aplikacij. Poslovne portale lahko, glede na namembnost, razdelimo v tri skupine: ■ portali za zaposlene (angl, business to employee — B2E) omogočajo dostop do poslovnih informacij podjetja, do poslovnih aplikacij, izboljšuje povezave med zaposlenimi, izboljšuje poslovno odločanje ter dviguje kakovost poslovnih procesov, ■ portali za elektronsko poslovanje (angl. business to business - B2B) so nameni eni zunaniim partner j.em (angl. business to business), povečujejo učinkovitost v celotni poslovni verigi od dobaviteljev, distributerjev do končnih kupcev, ■ portali za kupce (angl. business to customer - B2C), katerih namen je kupcem posredovati informacije o izdelkih in storitvah. Poleg poslovnih portalov so nekoliko dlje znani tudi spletni portali, kjer so prav tako na enem mestu zbrane različne informacije od novic do zanimivih spletnih povezav. Tudi za spletne portale velja, da si jih lahko obiskovalec prilagaja oziroma da si določi, katere informacije želi videti. Upravljanje in uporaba podatkov 201 1 Vprašanja za preverjanje razumevanja ^ Zakaj v organizacijah uporabljamo informacijske tehnologije, ki ne povečujejo bistveno informacijske asimetrije (npr. informatizacija poslovnih procesov)? ^ Kakšna je povezava med informacijsko demokratizacijo in spremembami organizacijskih struktur v podjetjih? ^ Skušajte najti problem za vsakega izmed štirih tipov analiz, pri katerih nam pomagajo iskati odgovore sistemi za podporo odločanju (kaj-če, doseganje cilja, optimizacija, zakaj). ► Razmislite, kje bi lahko uporabili ekspertni sistem za avtomatizacijo (dela) procesa odločanja. ^ Katere (matematične) poslovne modele poznate? ^ Navedite primere nadzorovanih in nenadzorovanih odločitvenih spremenljivk. ^ Poiščite spletne strani s predstavitvami orodij za sprotno analitično obdelavo podatkov in ugotovite njihove značilnosti. ^ Kaj je po vašem mnenju pomemben pogoj za uporabo mdarjenja v podatkih? ^ Poiščite vsaj en slovenski spletni portal in ugotovite, ah res ima značilnosti portala. ^ Katere vrste modelov lahko rešujemo v programskih paketih za delo s preglednicami? 202 informacijska podpora managementu Ključni pojmi managerski informacijski sistem Literatura [1] Adam N. R., Wortmann J. C.: Security-Control Methods for Statistka! Databases: A Comparative Study. ACM Computing Survevs, 21 (1989), 4, str. 515-556. [ 2 ] Al-Attar A.: Data Mining - Beyond Algorithms. Attar Software, 1999. [http://\v\vw.attar.c.om /1 [3| Anderson R. A., Sweeney D. J.,. Williams T. A.: Quanti.tative Methods for Business. West Publishing Company, 2000. [4] Bajec A. et at, ured.: Slovar slovenskega knjižnega jezika. SAZU in ZRC SAZU, Inštitut za slovenski jezik Frana Ramovša, 1994. [5] Bock D. D., Ryan T.: Accuracv in Modeling \vith Extended Entity Relationship and Object Oriented Data Models. Journal of Database Management, 4 (1993), 4, str. 30-39. [6] Burleson D. K.: Praetieal Application of Object-Oriented Techniques to Relational Databases. John Wiley & Sons, 1994. [7] Cattell R. G. G., ed.: The Object Data Standard: ODMG 3.0. Morgan Kaufmann Publishers, 2000. [8] Cattell R. G. G.: Object Data Management. Addison-Wesley Publishing Company, 1994. [9] Chen P. P.: The Entity-Relationship Approach to Logical Data Base Design. Q.E.D. Information Sciences, Inc., Data Base Monograph Series No. 6, 1977. [10] Chen P. P.: Tire Entity-Relationship Model-Toward a Unified View of Data. ACM-TODS 1 (March), 1976, str. 9-36. 204 Literatura [11] CODASYL: Data Base Task Group Report, 1971. Association for Computing Machinery, 1975. [12] Codd E.F: A Relational Model of Data for Large Shared Data Bases. Communications of the ACM. 13 (June), 1970, str. 77-387. [13] Delphi Group: Research Services, [www.delphigroup.com/research/], 1999. [14] Dick Kevin: XML. A Manager's Guide. Addison Wesley, 2000. [15] Elmasri R., Navathe S. B.: Fundamentals of Database Systems. Addison Wesley Publishing, 2000. [16] Gartner Group: ITXPO'99 Symposium. October 11-15, 1999. [17] Grad J., Dacar F.: Podatkovne strukture, osnove baze podatkov in njene uporabe -1. del. Ekonomska fakulteta Borisa Kidriča, 1993. [18] Grad J., Jaklič J.: Baze podatkov. Ekonomska fakulteta v Ljubljani, 1996. [19] Gradišar M., Resinovič G.: Informatika v poslovnem okolju. Ekonomska fakulteta, Ljubljana, 2001. [20] Han J., Kamber M.: Data Mining: Concepts and Techniques. Morgan Kaufmann Publishers, 2001. [21] Hoffer J. A., George J. F., Valachic J. S.: Modern Svstem Analvsis and Design. The Benjamin/Cummings Publishing Company, 1996. [22] Hoffer J. A.: An Empirical Investigation into Individual Differences in Data Models. Proceedings of Third International Information Sytem Conference. Ann Harbour, Midi., 1992. [23] Hrvatin R.: Poslovni portal - vaša nova poslovna miza. Uporabna informatika, št. 2, letnik 8, 2000, str. 94-98. [24] Huh S. Y.: Modelbase Construction with Object-Oriented Constructs. Decision Sciences, Vol. 24, No. 2, 409-434,1993. [25] Inmon W. H., Imhoff C., Sousa R.: Corporate Information Factory. Wiley Computer Publishing, 1998. [26] Inmon W. H., Zachman J. A., Geiger J. G.: Data Stores, Data Warehousing and the Zachman Framework: Managing Enterprise Knowledge. McGraw-Hill, 1997. Upravljanje in uporaba podatkov 205 [27] Inmon W. H.: Building the Data Warehouse. John Wiley & Sons, 1996. [28] Jarke M., Lenzerini M., Vassiliou Y., Vassiliadis P.: Fundamentals of Data Warehouses, Springer, 2000. [29] Kennedv R., Lee Y., Van Roy B., Reed C. D., Lippmann R. P.: Solving Data Mining Problems through Pattern Recognition. Prentice Hall, 1998. [30] Kimball R.: The Data Warehouse Toolkit. John Wiley & Sons, 1996. [31] Kovačič A.: Informatizacija poslovanja. Ekonomska fakulteta v Ljubljani, 1998. [32] Kroenke D. M.: Database Processing: Fundamentals, Design, Implementation, 7 th Editron. Prentice Hall, 2000. [33] Marchand D. A., Kettinger W. J., Rollins J. D.: Information Orientation: The Link to Business Performance. Oxford University Press, 2001. [34] Martin E. W., DeHayes D. W., Hoffer J. A., Perkins W. C.: Managing Information Technology: What Managers Need to Know. Macmillan Pubhshing Company, 1991. [35] Martin J.: Principles of Object-Oriented Analysis and Design. Prentice-Hall, 1993. [36] McFadden R. F., Hoffer A. J.: Data Base Management. The Benjamin/Cummings Publishing Company, 1985. [37] Navathe S. B.: Evolution of Data Modehng for Databases. Communications of the ACM, 35 (1992), 9, str. 112-123. [38] Pigford D. V., Baur G.: Expert Systems for Business: Concepts and Applications. Boyd & Frases Publishing Company, 1992. [39] Prijatelj N.: Matematične strukture I. Partizanska knjiga, 1980. [40] Rishe N.: Database Design. The Semantic Modeling Approach. McGraw-Hill, 1992. [41] Sauter V. L.: Decision Support Systems: An Applied Managerial Approach. John Wiley & Sons, 1997. [42] Schmidt Bob: Data Modeling for Information Professionals. Prentice Hall, 1999. [43] Sobočan B.: Upravljanje z znanjem. Uporabna informatika, št. 3, letnik 6, 1998, str. 14-19. 206 Literatura [44] Stcin R. .\T.: Object Databases. Byte, 19 (1994), 4, str. 74-84. [45] Tsichritzis D. C., Lochovsky F. H.: Data Models. Prentice-Hall, 1982. [46] Turban E., Aronson J. E;: Decision Support Systems and Intelligent Svstcnis. 6' 1 ’ Edition, Prentice Hall, 2001. [47] Turban E., McLean E., Wetherbe J.: Information Technologj for Management: Making Connections for Strategic Advantage, 2 nd Edition. John Wilev & Sons, 1999. [48] Watson Richard T.: Data Management. Databases and Orgamzactions. John Wiley & Sons, 1999. [49] Winston W. L.: Operatons Research: Applications and Algorithms. Duxbuiy Press, 1991. Stvarne kazale I - 142 % '135 * 143,142 / 142 _ 135 + 142 1NI' glej normalna forma 2N1' gly, normalna forma 3N1 ■' glej normalna forma A | agregacija 14 stopnja 14 agregatne, funkcije 141 aktivnosti upravljanja, podatkov 30-39 algoritem 37, 156 Al,'II IR TAHLli 130 analitična obdelava 16 analitični hierarhični postopek 155 analitik 40, 56-57, 84, glej tudi uporabnik analiza 40-41 kaj-če glej kaj-če analiza občutljivosti 151. 153 podatkov 150 159. I povezav 49 statistična: 160 AND 136 anomalije 11 Dl 12 pri brisanju 112 pri spreminjanju 111 pri vnosu 111 arhiviranje 38 AS 141 ASC 143 atribut 42, 93, 102 elementarni 44 izpeljani 44 ključni glej ključ neključni 95-96, 99,122-123 sestavljeni 44, 94 večvrednostni 43,94, 99, 103,115-118,121-122 vrednost 43 AVG 141 avtomatizacija 79,149, 164, 190, 196, 197 - 5 - 1 baza znanja 63, 163 BETWliKN 137 -«- 1 C AS K glej orodje ČASE celovitost 23, 33 referenčna 34 celovitost podatkov 79-81, 128 eksplicitna 81 omejitev območja 80 referenčna 81 CODASYL 93 CONSTRA1NT 130 COUNT 141 GRKA Tli TAHI ,K 127-130 CllM glej uravnavanje odnosov s kupci i I časovna vrsta 168-169 208 Stvarno kazalo I- 6 - I DDL glej jefik definiranje podatkov dedovanje 104 deljenje podatkov 4, 5, 29, 30 dejstvo 163 n RT .RTF. 131-132 Dl'SC 143 dimenzija 106 časovna 18, 106 dimenzijska tabela 107 DISTINCT 140 D MI, glejjefik %a manipulacijo podatkov dodana vrednost 22 dodatna vrednost 188 dokument 64-66 življenjski cikel 64 dokumentacija podatkovne baze 124 pregled 56 zbiranje 40 dokumentna baza 64 domena 44 doseganje cilja 159-165 dostopnost 32-33, 84 drevo odločitev glej odločitveno drevo D ROP TAB! Ji 130 drseča povprečja 155, 169 I-i- RDI 15, 23-24,145 ekspertni sistem 63, 162,169 eksponentno glajenje 169 ekstranet 15 elektronsko poslovanje 23, 29, 200 entiteta 42, 93, 98 entitetni tip 45, 93, 98 RR diagram 51, 124 1ČR model glej model entitet-pove^av F fizična predstavitev 101 FOR 144 FROM 133-143 funkcionalna odvisnost 53-55 analiza 120-123 I-“-•- generalizacija 104 generator naključnih števil 174 genetski algoritmi 194 G IGO 157 gotovost 157 graf 183 GROUP BY 142 grupiranje 141,142 I H hierarhija tipov 104 I--i- identifikator 13, 16, 19 IF 144 indeks 82-84 induktivno pravilo 191 informacijska asimetrija 2,148-149 informacijska demokratizacija 178 informacijska podpora managementu 5, 148-200 informacijska usmerjenost 2 informacijsko obnašanje 2-3 informatizacija poslovnih procesov 148 INSRRT 130-131 integracija 21 inteligentni agenti 62 intervju 40, 56-57 posamični 56-57 skupinski 56-57 intranet 63 izjeme 183 izobraževanje 39, 59, 85 Upravljanje in uporaba podatkov 209 i-1 jezik nepostopkovni 78 postopkovni 144 SQI. 78,101,124, 125-144,179,183 za definiranje podatkov 77,125 za manipulacijo podatkov 78, 125 XML 15,24,145 K | kaj-če analiza 149, 159, 165 kardinalnost 48, 50-53 kartezični produkt 138 ključ 46-48 glavni 47,94-97,107,117,122,130 kandidat za 46, 96 nadomestni 96 sestavljeni 47, 96, 99,113, 117,122 tuji 99,104,113,122 kocka 106-107,167,181 kriterijska funkcija 170-172 krivulja dviga 187 - 1 - 1 lakota po podatkih 179 LIKU 134 linearni program 170 linearno programiranje 170 M I managerski informacijski sistem 148 \1AX 141 mehanizem sklepanja 163 mehki kazalci 104 mera 106 metapodatki 32, 76, 126-127 metoda 102 MIN 141 model 86, 151, 153-156,165 determinističen 157 entitet-povezav 41-53 hierarhični 87,. 88-92 matematični 154 mrežni 87, 92-93 objektni 87,102-105 podatkovni 56-59, 86 poslovni 154-156 problemskega področja 41 procesov 59, 63 relacijski 87, 93-102,110 večdimenzionalni 17, 87, 105-109, 180 vrst 154 modeliranje 150, 154, 160, 161, 165 podatkovno glej podatkovno modeliranje MO LAP 181 MonteCarlo 172-177 N | načrtovalec 41,49, 74, 84 načrtovanje 30-31, 39-59 nadgradnja 37-38 nadtip 104 najbližji sosed 189 napovedovanje 168-169 negotovost 157,173 neodvisnost med modelom in algoritmom 156 med modelom in podatki 156 med programi in podatki 76 od programov 71 neposredno trženje 186 nesreča 37 nevronska mreža 192-194 nivo analitični 16 operativni 12 normalizacija 120-123 normalna forma 121-122 prva 122 druga 122 tretja 122 NOT 130, 136 NULl.43,46,111,112,130,131 210 Stvarno kazalo I- 5 - obnavljanje 37-38, 82 obračun uporabe 37 odločanje 150 večkritertijsko 155 odločitvena tabela 155 odločitvene spremenljivke 156, 170 odločitveno drevo 155, 189-190 odvisnost delna 122 tranzitivna 122 ograjevanje 104 okolje pajkove mreže 8 OLAP glej sprotna analitična obdelava podatkov omejitev 79-81, 130,170 opcija 173-177 cena 173 operativna shramba podatkov 21 operativni nivo 12-13 opis 22-24, 32 opredelitev 23, 32 optimizacija 154, 155, 159-160,169-172 linearna glej linearni program lokalna 151 nelinearna 171-172 OR 136 ORDER BY 143 orodje ČASE 123-124 OLAP 160,167,182-184 za skupinsko delo 158, 200 oznaka 23 I P pajkova mreža glej okolje pajkove mre^e Paretovo pravilo glej pravilo 80/20 personalizacija 200 podatki agregatni 183 ažurnost 85 brisanje 131-132 celovitost^' celovitost podatkov detajlni 12 izpeljani (izračunani) 114-115, 183 kakovost 22, 33-34 modeliranje glej podatkovno modeliranje nadzorovani 156, 169 nekonsistentni 6 nenadzorovani 156,157 opisovanje 22-24 organizacija 29, 32-33 podvajanje glej podvajanje podatkov poizvedovanje 133-144 popolnost 85 priprava 156 proaktivna uporaba 3 referenčni 14 spreminjanje 132 sumarni 19, 38, 166 surovi detajlni 12 točnost 85 tok 21-22 vhodni 156 vnos 130-131 zaklepanje 5 zaznavanje 28 zbiranje 28-29 zgodovinski 13-14, 18, 38 zgodovinski referenčni 14 značilnosti uporabe 16-17 zunanji 15-16 podatkovna arhitektura 10 podatkovna baza 70, 70-85 definiranje 127-130 integrirana 6, 70 načrtovalec 74 načrtovanje 74, 85-124 operativna 198 relacijska 100, 106, 124 skrbnik glej skrbnik podatkovne ba%e tvorba 74, 75 uporaba 71-74 vzdrževanje 75, 79-84 Upravljanje in uporaba podatkov 211 podatkovna preobremenjenost 29 podatkovni slovar 32, 76 podatkovni vir 4 integrirani 9,18-21 problemi upravljanja 4-9 zunanji 15-16, 198 podatkovni zapis 87, 94 podvajanje 90 podatkovno modeliranje 56-59 podatkovno skladišče 18-20, 105,180, 198 področno podatkovno skladišče 20, 105,180, 198 podtip 104 podvajanje podatkov 70, 90-92, 98, 110,111 odprava 118-120,120-123 pogled na podatke 123,179-184 pogojno izvajanje 144 poimenovanje 22 poizvedba 133 poizvedovanje 101, 133-144 polje 94 ponavljanje 144 portal poslovni 64, 198-200 spletni 200 za elektronsko poslovanje 200 za kupce 200 za zaposlene 200 poslovna uporabnost 14 poslovni portal glej portal poslovno obveščanje 177 poslovno področje 18 poslovno pravilo 40, 48, 74,124 posplošena drseča povprečja 169 poškodovanje 37 povezava 48, 160-161,184, 194 med entitetnimi tipi 49-51 med relacijami (tabelami) 97-100, 117 povezovalni pogoj 138-140 pravica uporabe 23,32 pravilo 80/20 59 pravilo sldepanja 163 pravilo poslovno glej poslovno pravilo induktivno glej induktivno pravilo preglednica 149, 164-177 prelomna točka 166 pridobivanje 31 prilagajanje 200 PR1MARY KKY 130 primerjava 183 problem 151,156 analiza 153 kvalitativna analiza 153 kvantitativna analiza 153 strukturiranost 149,152-153 problemsko področje 40-42, 48 proces odločanja 150-156 profil kupca 186 R I računalniška izmenjava podatkov 15 razred 103 razvrščanje v skupine 189 relacija 93 reševanje problemov 151 rezanje 183 rezervna kopija 37 RIP glej računalniška izmenjava podatkov ROLAP 181 rudarjenje v podatkih 62, 160, 178, 184-197 proces 194-195 212 Stvarno kazalo I--s- segmentacija 189 SELECT 133-144 semantika 111 SEQUEL 125 SET 132 shema 87 kakovost 110-113 relacijska 97, 105,110-113,124 večdimenzionalna 106-109 zvezdasta 108 sistem za podporo odločanju 149, 159-177 sistem za upravljanje podatkovnih baz 63, 75-84 hierarhičnih 91 mrežnih 93 objektnih 103 relacijskih 101-102 uporaba 77-79 večdimenzionalnih 106 sistem za upravljanje delovnih tokov 65, 148 sistem za upravljanje dokumentov 63, 64-66 sklepanje 163 skrbnik podatkovne baze 4, 72, 75, 81, 84 sloj transformacijski 22 integracijski 22 specializacija 104 sprotna analitična obdelava podatkov 17, 148,160,167-168,178-184 sprotna transakcijska obdelava 180 l.glejje?ik SQL statistična podatkovna baza 36 stolpec 93 strojno učenje 194 struktura podatkov 17, 23, 75-76, 88-109 večdimenzionalna 20 SUM 141 SUPB glej sistem %a upravljanje podatkovnih baz svetovanje 39 I- 1 - šablona 114-115 številčnost glej kardinalnost I- T - tabela 93 dejstev glej tabela dejstev dimenzijska glej dimenzijska tabela tabela dejstev 107 tip povezave 48 transformacija 19 tveganje 157 I u učinkovita uporaba podatkov 2-4 UPDATE 132 uporabnik 9 analitik 10,105,167,169,180, 182,185,195-196 odločevalec 105, 147, 157, 178 operativni 9 podatkovne baze 85 uravnavanje odnosov s kupci 185 urejanje 64,143-144 | V varovanje 34 politika 34 vir 31 vloga 84-85 vodenje projektov 155,160, 162 vprašalniki 56 vrstica 93 vrtanje v globino 183, 198 vrtenje 184 vrtilna tabela 166-168 vzdrževanje 31 vzvratno inženirstvo 124 Upravljanje in uporaba podatkov 213 w 1 WIIKRK 133-144 X 1 XM1 , glej jegik XAiL Z i zahteva 104 zakaj 160, 161,183 zaloge 148,152,155,156 zaščita 34-37 pred nepooblaščenim dostopom 81-82 pred posledicami poškodb 82 zaupanje 190 znanje 59 odkrivanje 184 omogočanje dostopa 60 ponovno odkrivanje 196 pridobivanje 62 tvorba 60 uporaba 60, 62 upravljanje 59-66, 60 viri 63 zrcaljenje 82 zvijanje 183 življenjski cikel upravljanja podatkov 28-30 Z 1 IIUAHA ■*' .. NARODNA IN UNIVERZITETNA KNJIŽNICA NARODNA IN UNIVERZITETNI) KNJI NIC« J’- ' - ' '■%■- m Bi aiilK:- ... MsjP§®tesfeSG