zbp2

9 PODATKOVNA SKLADIŠČA

Pojem podatkovnega skladišča (data warehouse) pomeni v računalništvu zbirko podatkov, ki se uporablja za poročanje in analizo podatkov. Podatkovno skladišče je nek velik osrednji skupek podatkov (central repository), v katerega so integrirani podatki iz različnih virov. V podatkovnih skladiščih se tako zbirajo podatki iz različnih poslovnih sistemov, preglednic, aplikacij. Pri prenosu v podatkovno skladišče se ti podatki prefiltrirajo ter poenotijo glede na strukturo oz. organizacijo skladišča. Podatki, ki so skladiščeni v podatkovnem skladišču (pretekli podatki) so pomembni za nadaljnje poslovanje skozi čas

9.1 OSNOVE

Poslovni podatki so praviloma shranjeni v transakcijskih bazah. Ker se v podatkovni bazi beležijo vse transakcije, je ta baza zelo velika, zaradi velikega števila transakcijskih mest pa tudi polno obremenjena. Transakcijska baza praviloma obsega le podatke omejenega časovnega obdobja, po navadi enega poslovnega leta.

Podatkovno skladišče obsega podatke daljšega časovnega obdobja in agregate podatkov, ki se ne nahajajo v transakcijski bazi.

Podatkovna skladišča skladiščijo aktualne in zgodovinske podatke, ki se uporabljajo za izdelave poročil o trenutnih trendih in nudijo podporo za odločanje. Managerji se na osnovi poročil lažje odločajo oz. dobivajo dodatno podporo pri odločitvah.

Podatki v podatkovnih skladiščih se dopolnjujejo s podatki iz operativnih sistemov (prodaja, proizvodnja, marketing, finančne službe ipd.). Tipičen proces, ki se pri tem odvija, ima tri faze (ETL – Extract, Transform, Load):

• zajemanje podatkov/izdelava izvlečkov, • preoblikovanje in • prenos podatkov oz. polnjenje skladišča.

V podatkovnem skladišču se nahajajo samo tisti podatki, ki so najpomembnejši za izdelovanje analiz, iskanje trendov, za primerjave in napovedovanje itd.

Slika 106: Struktura podatkovnega skladišča (1)

64

Slika 107: Struktura podatkovnega skladišča (2)

Definicija:Podatkovno skladišče je subjektno usmerjena, integrirana, časovno odvisna in nespremenljiva zbirka podatkov ustvarjena zaradi podpiranja procesov odločanja.(William Inmon)

Splošna definicija pravi, da iz vseh pomembnih ali vsaj pomembnega dela podatkov, ki jih zbiramo iz različnih sistemov, integriramo eno centralno podatkovno skladišče. Tako se podatki iz različnih sistemov zbirajo. Potrebno jih je ustrezno agregirati. Nato nam služijo za uporabo v analitičnih aplikacijah in poizvedovanju vodstva v podjetju.

Karakteristike podatkovnih skladišč podane v definiciji razložimo na sledeči način:• Subjektna usmerjenost : podatki skladišča so organizirani okoli specifičnih

subjektov, kot so stranka ali izdelek. • Integriranost : podatki so zbrani iz različnih izvorov in so integrirani okoli

subjektov v konsistentnem formatu. • Časovna odvisnost : PS ohranja zgodovinske podatke, ki so potrebni za

ugotavljanje trendov v poslovanju, deviacij in dolgoročnih odnosov. • Nespremenljivost : uporabniki ne morejo spreminjati podatkov. Podatkovno

skladišče se spreminja s kontroliranimi postopki polnjenja. Nespremenljivost zagotavlja, da vsi uporabniki delajo z istimi podatki.

Slika 108: Proces podatkovnega skladiščenja

65

Slika 109: Primer podatkovnega skladišča

Slika 110: Poslovne odločitve in podatkovna skladišča

Poznamo tri različna podatkovna skladišča:1. področno podatkovno skladišče, 2. podatkovno skladišče podjetja, 3. operativno shrambo podatkov.

9.1.1 Področno podatkovno skladišče

Podatkovna skladišča hranijo ogromno količino podatkov iz vseh področij v podjetju (npr: finančna

služba, prodaja, kadrovska služba, nabava, marketing). Zaradi tega so zelo obsežna in težko

razumljiva, saj bi morali poznati vsa področja v podjetju. Zato v ta namen uporabimo področna

podatkovna skladišča, kar pomeni, da ne izdelujemo celotnega podatkovnega

66

skladišča, ampak po področjih, korakih. Podatkovno skladišče je lahko tudi fizično razdeljeno, tako da iz njega izhajajo področna podatkovna skladišča, ki so prilagojena skupini uporabnikov v organizaciji.

Taka področna podatkovna skladišča so taktično usmerjena, podatkovno skladišče pa strateško usmerjeno. Področnim podatkovnim skladiščem včasih tudi rečemo podatkovna tržnica. Struktura področnih podatkovnih skladišč je načrtovana za specifične namene, pri čemer so podatkovna skladišča včasih namenjena nedoločeni uporabi. Področno podatkovno skladišče lahko definiramo kot podmnožico podatkovnega skladišča, ki je prilagojena uporabnikom določenega oddelka, dopušča pa tudi možnost uporabe na več oddelkih, ki imajo podobne zahteve.

Podatki se med področnimi podatkovnimi skladišči ne morejo izmenjavati, zato jih izmenjujemo v podatkovnem skladišču, da zagotovimo združljivost podatkov med področnimi podatkovnimi skladišči in podatkovnim skladiščem.

Če neki oddelek uporablja skupno podatkovno skladišče, se mora vsak oddelek prilagajati in deliti skupne vire, kar lahko postane zelo nelagodno. To je še en razlog več, zakaj uporabljati področna podatkovna skladišča, saj si s tem uporabniki omogočijo popolni nadzor nad podatki in njihovim procesiranjem. Tako si še lahko posamezni oddelki področno podatkovno skladišče prilagajajo svojim potrebam – združujejo ali razdružujejo podatke, spreminjajo ključe, dodajajo nove izračune itd. Ker pa je področno podatkovno skladišče bistveno manjše od podatkovnega skladišča, je boljša tudi odzivnost.

9.1.2 Podatkovna skladišča za podjetja

Podatkovna skladišča za podjetja so zgrajena za celotno področje podjetja in so tako dolgoročno opredeljena skladišča. Podatki se črpajo iz različnih sistemov in s tem je zagotovljena dobra podpora za skupinsko odločanje in za uspešnost in učinkovitost menedžmenta.

9.1.3 Operativna shramba podatkov

Operativna shramba podatkov se uporablja kot začasna postavitev območij in se uporablja za kratke odločitve, zato mu včasih tudi rečejo, da je podobno kratkoročnemu spominu, ker se vanj shranjujejo pravkar prispeli podatki. Poskrbi za jasno obliko informacij kupca, operativni podatki se analizirajo multidimenzionalno.

9.2 LASTNOSTI PODATKOVNIH SKLADIŠČ

Najpomembnejše lastnosti podatkovnega skladišča so:• integriranost – iz različnih virov podatkov polnimo podatkovno skladišče, • zgodovina – shranjujemo podatke za več let nazaj, • statičnost – vsi podatki so namenjeni za poizvedovanje, • področna usmerjenost – vse najpomembnejše podatke za organizacijo

hranimo v podatkovnem skladišču.

Podatkovno skladišče uporabljajmo za preverjanje preteklega poslovanja in da z orodji OLAP

izvajamo analize in poizvedbo nad podatki. S tem ne motimo tekočega poslovanja. Zato tudi

67

rečemo, da je podatkovno skladišče proces. Uporabljamo ga pri zbiranju podatkov iz različnih virov in pri odgovarjanju na najpomembnejša vprašanja za uspešno poslovanje določenega podjetja.

Sestavni deli podatkovnega skladišča:• Pridobivanje podatkov (ETL – Extract transform Load), • PS – podatkovno skladišče, • orodja za analizo (OLAP – OnLine Analytical Processing), • metapodatki in • orodja za podatkovno rudarjenje.

Razlika med operativnimi podatki in podatki za podporo odločanjuOperativni podatki Podatki za podporo odločanjuAplikativno usmerjeni: služijo določenemu Predmetno usmerjeni: služijo določenemuposlovnemu procesu. predmetu poslovnega procesa.Podrobni podatki. Sešteti – agregirani podatki.

Struktura je ponavadi statična.Struktura je dinamična: nove vpoglede (alikocke) nad podatki dodajamo po potrebi.

Vnašalci podatkov – uradniški kader: Usmerjena k managerjem in drugimizvajanje procesov. odločevalcem v poslovnem sistemu.Spremenljivost (lahko se spremenijo). Se ne spreminjajo po vnosu v sistem.Zahteve so ponavadi znane pred gradnjo

Zahteve ponavadi niso popolnoma definirane

sistema. pred gradnjo sistema.Klasični razvojno življenjski cikel. Popolnoma drugačen življenjski cikel.

9.3 PROCES POLNJENJA PODATKOVNEGA SKLADIŠČA (ETL)

Polnjenje podatkovnega skladišča je bistvenega pomena. Pri tem moramo podatke:• prečistiti (prenašamo samo kakovostne podatke, ne nepopolnih; kaj storiti s praznimi

polji (prazne vrednosti), kaj s podobnimi vrednostmi vrednostmi polj in podobno), • pretvoriti med različnimi podatkovnimi tipi (pretvoriti znak v številko, besedilo v

datum), • povezati skupaj z različnimi OLTP (iz zbirk Access, Oracle, MS SQL itd.).

Ta proces imenujemo ETL – Extract(ion), Transform(ation) & Load (pridobi, pretvori in naloži oz. prenesi). Proces je ključnega pomena tudi pozneje zaradi uporabe tehnologijeOLAP, saj se nad podatki, ki se v tem procesu prenašajo iz OLTP -ja v podatkovno skladišče, izvajajo analize. Skratka, na tem mestu določimo, katere podatke bomo analizirali pozneje z OLAP-om, saj podatkov, ki jih v procesu ETL ne prenašamo, ne moremo vključevati pozneje v nobene analize. Najtežje delo je ravno na tem mestu, saj odločitev, kaj, kako in zakaj prenašati, velikokrat odloča o "usodi" podatkovnega skladišča. Podatki, še zlasti če vstopajo v proces ETL iz različnih virov, morajo biti po končanem procesu med seboj povezani oziroma se morajo med seboj pravilno povezovati, sicer nimajo pomena.

Izgradnja procesov ETL v podatkovnem skladišču ima naslednje faze:

• Shranjevanje podatkov Poznamo dva načina shranjevanja podatkov v operativnih sistemih. Prvi je trenutna

vrednost, ki ima vrednost atributa točno v času izvrševanja transakcije. Se

68

vedno spreminja in ni mogoče napovedati, kdaj se bo kakšna vrednost spremenila. Drugi način je status intervala. Pri tem vrednosti hranimo tudi čas in s tem je zajemanje podatkov precej lažje in imamo celotni pregled nad preteklimi podatki.

• Zajem podatkov Obstajajo trije načini zajemanja podatkov:

o S pomočjo beleženja transakcij, s pomočjo dnevnikov SUPB, v katere se zabeležijo vse spremembe v podatkovni bazi. Zajem se ustvari, preden se osveži dnevnik.

o S pomočjo prožilcev, ki so shranjene procedure v podatkovni bazi. Sprožijo se ob določeni spremembi. Prožilce, pri katerih potrebujemo zajem podatkov, lahko definiramo, zaradi tega je tudi možna upočasnitev transakcijskega sistema. Izvorni podatki pa morajo biti shranjeni v podatkovni bazi.

o Zajemanje podatkov v aplikacijah, zajem podatkov se ustvari neposredno iz aplikacije, zato je potrebo aplikacijo ustrezno sprogramirati, da omogoči zapis podatkov v izhodno datoteko ali v podatkovno bazo. Slabost tega je, da je treba vsako aplikacijo ustrezno preoblikovat (spreprogramirati) in zaradi tega je slabša odzivnost aplikacije.

• Preoblikovanje podatkov in čiščenje – Transform o Pri transformaciji podatkov poskrbimo za integracijo podatkov. To je proces

strukturiranja naloženih podatkov v tako obliko, ki nam omogoča optimiziranje in hitre poizvedbe. Viri se tako prestrukturirajo, da se odstranijo nepotrebni podatki. Podatku lahko dodamo časovno vrednost, voluto ali kakšne druge ustrezne kalkulacije.

o Postopek čiščenja podatkov preverja vse podatke, ki so bili zajeti v fazi zajemanja podatkov. Zagotoviti moramo pravilnost podatkov, pravilnost preverjanja s posameznimi procedurami. S tem zagotavljamo njihovo logično smiselnost, po potrebi ustvarimo tudi take procedure, ki dopolnijo manjkajočo vrednost podatka. Preverjamo tudi zunanje vire, da zagotovimo odražanje realnega stanja podatkov.

• Polnjenje podatkovnega skladišča – Load Zadnji korak je polnjenje podatkov v shemo podatkovnega skladišča. Poznamo tri načine polnjenja:

o začetno polnjenje, pri tem se napolni celotno podatkovno skladišče ob prvem polnjenju. Polnimo lahko celotno podatkovno skladišče ali po delih.

o vsakodnevno polnjenje se polni ob vsakodnevnih spremembah. Lahko po načinu konstruktivnega zlitja ali po načinu destruktivnega zlitja.

o popolna osvežitev, pri tem eno ali več tabel popolnoma izbrišemo, napolnimo z novimi svežimi podatki. Ta način je časovno potraten, saj periodično zamenjuje vse podatke iz podatkovnega skladišča.

69

Slika 111: Podatkovno skladišče in dostop do podatkov

9.4 OSNOVNI ELEMENTI PODATKOVNIH SKLADIŠČ

Slika 112: Osnovni elementi podatkovnih skladišč(Vir: Kimball: Developing and Deploying Data Warehouses)

70

9.4.1 Izvorni sistem (source system)

Izvorni sistem je operativni sistem, ki zapisuje poslovne transakcije. Glavna zahteva za izvorni sistem je razpoložljivost in zanesljivost obratovanja. Običajno ne vsebuje zgodovinskih podatkov. Poročanje za managerje bi predstavljalo breme za delovanje sistema, zato ne izvajamo velikih poizvedb. Izvorni sistemi običajno vsebujejo ključe za hiter dostop do podatkov in za zagotavljanje neponovljenih vnosov.

9.4.2 Področje priprave podatkov (data staging area)

To je področje, kjer shranjujemo podatke in jih v procesih preoblikovanja pripravimo za uporabo v podatkovnih skladiščih. Postopki za preoblikovanje zajemajo: čiščenje podatkov, transformacijo, kombiniranje, odpravljanje dvojnikov in arhiviranje. Področje priprave podatkov zajema vse med izvornimi sistemi in podatkovnimi skladišči, vendar ne nujno na enem samem strežniku. Poglavitno je, da to področje ne vsebuje orodij za poizvedbe.

9.4.3 Predstavitveni strežnik

Ciljni strežnik, na katerem se nahaja podatkovno skladišče, je namenjen neposrednemu poizvedovanju končnih uporabnikov, pisanju poročil in drugim aplikacijam. Na predstavitvenem strežniku morajo biti podatki shranjeni v dimenzijski obliki. Če ta strežnik temelji na relacijski bazi, potem so podatki organizirani v zvezdasti obliki. Tudi če temelji strežnik na nerelacijski OLAP-tehnologiji, so podatki še vedno opremljeni s prepoznavnimi dimenzijami.

9.4.4 Dimenzijski model

Dimenzijski model je poseben način modeliranja podatkov, ki je alternativa entitetno-relacijskemu modeliranju. Oba modela vsebujeta enako informacijo, le da je cilj dimenzijskega modela večja razumljivost za uporabnika, hitrejše izvrševanje poizvedb in prožnost za spremembe. Primeren je za oblikovanje podatkov (iskanje, seštevanje, analiziranje) pri gradnji podatkovnega skladišča. V dimenzijskem modelu so podatkovne strukture organizirane tako, da opisujejo mere in dimenzije.

Glavni objekti dimenzijskega modela so tabele dejstev in dimenzijske tabele. Obstaja več načinov organiziranja objektov v podatkovnem skladišču. Najpogostejši obliki dimenzijskega modela sta zvezdasta in snežinkasta shema. V večini podatkovnih skladišč je taka shema končni rezultat analize poslovnih procesov. Včasih je potrebno izgraditi dimenzijo iz tabel, ki jih ni v relacijskem podatkovnem skladišču. Takrat lahko uporabimo vpoglede, s katerimi prečistimo informacijo, spremenimo predstavitev določenih stolpcev in razjasnimo dimenzijski model.

9.4.5 Podatkovna tržnica (data mart)

Podatkovna tržnica je podmnožica celotnega podatkovnega skladišča. Je projekt, ki ga je mogoče dokončati, namesto da bi bila nemogoč vesoljski podvig. Podatkovno skladišče je unija vseh podatkovnih tržnic. Podatkovno tržnico lahko gledamo kot omejitev podatkovnega skladišča na en sam oziroma le nekaj povezanih poslovnih procesov. Podatkovna tržnica temelji na podrobnih podatkih, ki so lahko, ni pa nujno, sešteti za boljši odziv pri poizvedbah. Pomembno je, da so vse podatkovne tržnice zgrajene nad usklajenimi dimenzijami, saj jih lahko le v tem primeru kombiniramo.

71

9.4.6 Podatkovno skladišče

Podatkovno skladišče je vir podatkov, ki je organiziran tako, da lahko po njih poizvedujemo. Podatki morajo biti modelirani dimenzijsko, da se zagotovi razumljivost vsebine za uporabnika in hitrost izvajanja poizvedb. Podatkovno skladišče pogosto popravljamo s kontroliranim nalaganjem novih ali popravljenih podatkov. Podatkovno skladišče je unija vseh podatkovnih tržnic in se polni iz področja za pripravo podatkov.

9.4.7 OLAP (On-Line Analytic Processing)

Sprotno analitično procesiranje podatkov je v splošnem poizvedovanje in predstavitev tekstovnih in številčnih podatkov iz podatkovnih skladišč oziroma podatkovnih tržnic, kjer so ti podatki dimenzijsko modelirani.

Medtem ko so podatkovna skladišča ponavadi zgrajena nad relacijsko bazo podatkov, uporablja OLAP-tehnologija večdimenzionalni pogled oziroma večrazsežnostno podatkovno bazo (multidimensional database). To bolj določno imenujemo MOLAP-tehnologija, zagotavlja pa hiter dostop do podatkov in možnost analiz. Podatki so shranjeni v večdimenzionalnih kockah, ki jih lahko uporabniki vrtijo. To je še posebej prikladno na področju finančnih analiz, planiranja, prodajnih analiz, izdelavi scenarijev in podobno. Običajno uporabljamo OLAP-proizvode za gradnjo podatkovnih tržnic.

Kadar so podatki v podatkovni tržnici shranjeni v relacijski bazi, govorimo o ROLAP-orodjih, kar pomeni relacijski OLAP. Zaželeno je, da so podatki tudi v tem primeru organizirani na način dimenzijskega modeliranja, na primer v zvezdasti shemi.

Ime OLAP se je prvič pojavilo leta 1993, ko je Ted Codd objavil 12 pravil za OLAP-aplikacije. V literaturi se pojavljajo različni podaljški imena: OLAP-aplikacija, OLAP -sistem, OLAP-baza podatkov, OLAP-podatkovni model, OLAP-rešitev. Kasneje sta Nigel Pendse (2001) in Richard Creeth poenostavila definicijo za OLAP-aplikacije, ki naj bi zagotavljale hitro analizo skupnih večdimenzionalnih informacij (FASMI – fast analysis of shared multidimensional information). Ta definicija pomeni:

• hitra: uporabnik pričakuje informacijo v trenutku. Večina poizvedb naj bi trajala 5 sekund ali manj;

• analiza: OLAP-aplikacije so sposobne osnovnih številčnih in statističnih analiz nad podatki. Ti izračuni so lahko pripravljeni vnaprej ali pa so to ad hoc analize;

• skupnih: podatki morajo biti dostopni mnogim uporabnikov. To poudarja pomen zaupnosti in varnosti podatkov;

• večdimenzionalnih: OLAP-aplikacije so zgrajene na večdimenzionalnih bazah podatkov;

• informacij: OLAP-aplikacije morajo biti sposobne zajeti vse potrebne in ustrezne

podatke in informacije, ki so shranjene v različnih izvorih in v različnem obsegu.

72

9.5 ARHITEKTURE PODATKOVNIH SKLADIŠČ

Podatkovna skladišča, ki dosegajo velike rezultate v podjetjih in organizacijah, se še vedno razvijajo zaradi velikih napredkov programske in strojne opreme in s tem posledično prihajajo nove arhitekture podatkovnih skladišč. Vsak načrtovalec, ki se loti izgradnje podatkovnega skladišča, se mora odločiti, katero arhitekturo bo izbral. Izbira arhitektur za načrtovalca ni enostavna, saj ta določa podatkovni model, vlogo področnih skladišč in nadaljnjih korakov v razvoju podatkovnega skladišča. Cena izgradnje podatkovnega skladišča je sorazmerno zelo visoka na področju informatike v podjetju, ker vključuje dobro poznavanje obstoječih in novih sistemov.

Tri arhitekture podatkovnih skladišč so:• centralizirano, • distributivno in • federativno.

9.5.1 Centralizirana arhitektura

Iz operativnih podatkovnih baz in operativne podatkovne shrambe (ODS – Operational Data Storage) se podatki prenašajo v centralizirano podatkovno skladišče, ki je za celotno organizacijo. Iz tega centraliziranega podatkovnega skladišča pa se polnijo področna podatkovna skladišča. Zato so tudi področna podatkovna skladišča odvisna od centraliziranega podatkovnega skladišča, saj se izključno polnijo samo iz njega.

Slika 113: Centralizirana arhitektura podatkovnega skladišča

V centraliziranem podatkovnem skladišču so podatki normalizirani, včasih pa tudi delno denormalizirani. Za delno denormalizacijo se odločimo takrat, ko hočemo doseči boljšo učinkovitost.

9.5.2 Distributivna arhitektura podatkovnega skladišča

Distributivna arhitektura podatkovnega skladišča se gradi od spodaj navzdol, pri čemer pa se centralizira od zgoraj navzdol. Kar pomeni, da se distributivna arhitektura podatkovnega skladišča polni iz področnih podatkovnih skladišč. Podatkovno skladišče je unija področnih podatkovnih skladišč. Področna podatkovna skladišča so specializirana za določene oddelke v organizaciji, ne moremo pa jih med sabo povezati.

73

Slika 114: Distributivna arhitektura podatkovnega skladišča

9.5.3 Federativna arhitektura

Federativna arhitektura je hibridna rešitev, ki temelji na področjih priprave informacij in skupnem poslovnem modelu, ki je v skupni rabi. Je hitra in poceni izgradnja tovrstnih arhitektur podatkovnega skladišča. Področna podatkovna skladišča med sabo niso odvisna.

Slika 115: Federativna arhitektura podatkovnega skladišča

9.6 PRIPRAVA IZGRADNJE PODATKOVNEGA SKLADIŠČA

Nekega točno določenega procesa izgradnje ni, ker je vse odvisno od potreb in želja podjetja oz. organizacije, ki želi podatkovno skladišče zgraditi.

Pri izgradnji podatkovnega skladišča se držimo dveh pomembnih načel [7], in sicer da bi bila največja korist in čim manjše tveganje pri izvedbi. Zelo pazljivi pa moramo biti pri naslednjih dveh stvareh:

I. Dostopnost podatkov in njihova kakovost

74

Tu se nanašamo predvsem na to, kateri podatki so dobri, kvalitetni in uporabni. Če ne izpolnjujejo teh zahtev, lahko ogrozijo organizacijo.

II. Zanimivost in uporabnost podatkov Da bi se vodstvo izognilo nepričakovanim rezultatom, se moramo držati naslednjih načel:

• v nastajajoči projekt vključimo vodstveno strukturo, pri kateri vodja odgovarja za projekt,

• vodstvu redno poročamo o poteku projekta, • najprej izdelamo prototipski pristop, • omejimo projekt na določene okvirje, • pri delu se osredotočimo na določene točke, • pri vsaki skupini projekta omejimo število članov.

Načrtovanje podatkovnega skladiščaIZDELAVA PROJEKTA. AKCIJEIz pridobljenih gradiv izdelamo model in poiščemo Izdelamo model.dele poslovanja, kjer povečamo dodatno vrednostpodatkovnega skladišča.Uporabimo opisano tehniko in pregledamo vse Presojanje virov.podatkovne vire.Ugotovimo zanimiva področja za projekt in iščemo Iskanje področij za projekt.vrednostne verige, ki se pokrivajo s podatkovnimiviri in nam obetajo podporo tehnologijampodatkovnih skladišč.Člani, ki nam pomagajo pri izgradnji podatkovnega Vključimo vodstvene strukture zaskladišča. projekt.Izdelamo osnutek na predlogi za načrt. Izdelava načrta.Dopolnjujemo projekt. Končna izdelava projekta.Temeljito se pripravimo na izvedbo za začetne Pripravimo vse potrebno za projekt.aktivnosti, pripravo podatkov, skupine ljudi,potrebna izobraževanja, izdelava razvojnega okolja.Lotimo se izdelave projekta. Izdelava projekta.

Najpomembnejši metodi za zasnovo načrtovanja podatkovnega skladišča:• načrtovanje od zgoraj navzdol, • načrtovanje od spodaj navzgor.

9.6.1 Načrtovanje od zgoraj navzdol

Načrtovanje od zgoraj navzdol (Top-down), ki potegne pomembne informacije od ključnih uporabnikov ali pa se področna podatkovna skladišča polnijo iz globalnega podatkovnega skladišča.

Prednosti pri tem načinu so:• enostavno načrtovanje, • uporabniki nam lahko posredujejo nove zahteve zaradi sprememb poslovanja, • osredotočimo se na zahteve potreb vodstva.

Slabosti so:

75

• vsi podatkovni viri ne morejo pokrivati zahtev ključnih uporabnikov, • višji stroški, • več tveganja, • do rezultatov pridemo kasneje, • rešitve ne ustrezajo vsem uporabnikom.

Načrt pod. skladišča zgoraj navzdolOPRAVILO AKCIJAZbiranje informacij: Zapiski poročila.iskanje vodstvenih oseb in ključnih uporabnikov,razgovor s ključnimi vodstvenimi sodelavci,upoštevanje potreb po informacijah in iskanje poslanihciljev.Analiza izbranih informacijskih potreb: Ves seznam za potrebe in

• preciziramo poslovne cilje in merila teh ciljev, arhitekture podatkovnega• identificiramo njihov povzetek in informacijske skladišča.

potrebe,• izdelamo arhitekturo podatkovnega skladišča.

Izdelamo načrt za podatkovno skladišče: Izdelava podatkovnega• po potrebi izdelamo OLAP brskalnik, skladišča.• izdelamo načrt za OLAP tako, da pokrije vse

informacijske potrebe,• dimenzijsko modeliranje, da zadosti zahteve OLAP

baze,• izdelamo načrt procesov ETL,• izdelamo tehniške arhitekture podatkovnega

skladišča.

9.6.2 Načrtovanje od spodaj navzgor

Ta tehnika načrtovanja (Button-up), omogoča, da iz obstoječih podatkovnih virov ali katerih drugih virov izpeljemo zasnovo za podatkovno skladišče. Postopno dodajamo in polnimo podatkovno skladišče in posledično preverjamo pravilnost delovanja.Prednosti tega načina so:

• do rešitve pridemo hitreje, • manj tveganja, • nizki stroški.

Slabosti:• lahko dobimo področna podatkovna skladišča, ki med seboj niso povezana.

Načrt pod. skladišča spodaj navzgorOPRAVILO AKCIJAAnaliza poslovnega procesa: Iskanje poslovnih dogodkov.

• identificiranje poslovnih dogodkov in pregledposlovnih področij,

• pregled podatkov obravnavanega področja,• pregled poslovnih dogodkov.

Analiza poslovnih virov: Arhitektura podatkovnega

76

• pregledamo področje dokumentacije sistema, skladišča in iskanje• pregled vseh virov, iz katerih bomo črpali informacijskih potreb.

podatke,• iskanje podatkov za tabelo dejstev.

Izdelava načrta podatkovnega skladišča: Zasnova podatkovnega• arhitektura podatkovnega skladišča, skladišča.• dimenzijsko modeliranje,• načrt transformacije (procesi ETL),• tehnična arhitektura podatkovnega skladišča.

9.7 DIMENZIJSKO MODELIRANJE

Dimenzijsko modeliranje je tehnika logičnega urejanja podatkov, ki ga organiziramo tako, da omogoča hitre poizvedbe in dostop do podatkov, ki so združeni v enotne logične sheme.Podatki morajo biti razumljivi uporabnikom in prav tako informatikom. Je najzahtevnejši proces pri ustvarjanju analitičnih sistemov. Pri modeliranju dimenzijskega modela, moramo poznati celoten podatkovni model tega sistema.

9.7.1 Dimenzijski model

Dimenzijski model je razdeljen v dve kategoriji, in sicer iz srednje tabele, ki vsebuje več delne ključe in jo imenujemo tabela dejstev (fact table), in iz množice manjših tabel, ki imajo vsaka po en ključ in jih imenujemo dimenzijske tabele (dimension table). Skupek teh tabel nam opisuje neki proces. Več dimenzijskih modelov lahko povežemo v eno celoto, pri čemer so lahko pri različnih dimenzijah enaki pomeni tabel dejstev. Dimenzijski model nam služi kot analitično orodje za izgradnjo podatkovnega skladišča. Ker pa dimenzijski modeli niso vedno implementirani, v relacijski podatkovni zbirki uporabljamo programsko rešitev OLAP, ki nam omogoča večdimenzionalne podatkovne baze. Večdimenzionalni pogled nam omogoča zvezdnata shema dimenzijskega modela. Ta je podrobneje opisana v poglavju Načrtovanje sheme dimenzijskega modela.

Preden začnemo načrtovati večdimenzionalne baze, moramo podrobno poznati sisteme, za katere želimo ponuditi rešitve. Večdimenzionalne baze črpajo podatke iz več različnih virov, zato moramo definirati tudi zunanje povezave, ki skrbijo za obnavljanje podatkov. Poznamo dve vrsti zunanjih povezav, in sicer statične in dinamične. Pri dinamičnih povezavah se sprememba podatka zazna in se tako prenese na večdimenzionalno bazo. Kar je zelo pomembno pri točnosti, ažurnost in konsistentnosti podatkov. Pri statičnem teh sprememb ne moremo procesirati. Le s pravilnimi povezavami dosežemo, da se bodo ob tako veliki količini podatkov pridobile prave informacije ob pravem času.

Dimenzijski model pri podatkovnem skladišču je napovedljiv in standardiziran, ima enostavno razrešitev in nam omogoča:

• dodajanje novih dimenzij, • dodajanje novih dejstev, • dodajanje novih atributov in razgibanje atributov.

9.7.2 Načrtovanje sheme dimenzijskega modela

77

Poznamo več vrst shem za izgradnjo podatkovnega skladišča, tako lahko izpolnimo informacijske potrebe uporabnikov. Shema nam predstavlja povezovanje podatkov iz različnih virov in je postopni razvoj za izgradnjo podatkovnega skladišča.

Sheme, ki jih lahko uporabimo:• Zvezdnata shema (star scheme), najpogostejša izbira sheme, ime je dobila po obliki,

tabelo dejstev obkroža več dimenzijskih tabel. • Snežinkasta shema (snow flake schema) se izpelje iz zvezdnate sheme z razširitvijo z

normalizacijo vsaki dimenziji. • Sozvezna shema (constellation schema) iz množice zvezdnatih shem v hierarhčni

povezavi s tabelo dejstev. • Zvezdna grozdna shema (star cluster schema) minimalno število dimenzij in nima

prekrivanj med dimenzijami. • Galaktična shema (galaxy schema) sestavljena iz množic sozvezdij ali zveznih shem. • Ploska shema (flat schema) ima minimalno število entitet, ker se vse entitete združijo

v minimalno število hierarhij in zaradi tega ni izgube informacij in je najenostavnejša. • Terasasta shema (terraced schema) za vsako transakcijsko tabelo naredi svojo tabelo.

Slika 116: Sheme dimenzijskega modela

Za izgradnjo dimenzijskega modela, moramo najprej določiti, kateri poslovni proces bomo analizirali. Nato sledi določitev zrna in atributov. Najbolj pogosto uporabljena je zvezdnata shema.

Zvezdnata shema je dobila ime po njeni obliki. Sestavlja jo več dimenzijskih tabel, ki so povezane z osrednjo tabelo dejstev v relacijo 1:M (ena proti mnogo). Na podlagi poslovnega procesa določimo tabelo dejstev in zrna, nato še določimo dimenzije, ki jim določimo atribute.

9.8 OLAP (ON LINE ANALYTICAL PROCESSING)

Procesi odločanja so lahko podprti na več načinov ter z različnimi programi in metodami.Metoda OLAP je ena izmed uporabnih metodologij, ki je v Sloveniji prisotna že več let in na različnih platformah oziroma osnovah. Metodologija OLAP izhaja iz On Line Analytical Processing, kar pomeni analiziranje podatkov v nekem realnem času in na zahtevo. Sam sistem omogoča uporabniku kreiranje poročil in različnih pogledov glede na njegove trenutne potrebe.

OLAP metodologija se uporabljajo za analizo velike količine podatkov. V podjetjih, kjer se srečujemo z vsemi vrstami podatkov, je velik problem podatke jasno prikazati in jih narediti

78

uporabne. Za doseganje tega cilja potrebujemo zmogljivo OLAP orodje, ki predstavi podatke na jasen in pregleden način. Z ureditvijo podatkov pridemo lahko do koristnih informacij, ki so odlična podlaga za odločanje v podjetjih. Sistemi, ki temeljijo na OLAP tehnologiji, torej omogočajo podporo odločanju in so tudi sestavni del dobrega direktorskega informacijskega sistema. To pa še ne pomeni, da so uporabniki OLAP sistema samo ključni kadri v podjetju, ampak je krog uporabnikov lahko precej širši. Uporabljajo ga praktično vsi, ki pri svojem delu potrebujejo hiter dostop do kvalitetnih podatkov, ki jim omogočajo pravilno odločanje in ukrepanje.

9.8.1 Sistem OLAP nad podatkovnim skladiščem

Orodja za sprotno analitično obdelavo podatkov (OLAP) temeljijo na konceptu večdimenzionalnih baz podatkov ter omogočajo uporabniku pregledovati iste podatke večplastno in iz več zornih kotov. OLAP ponuja odgovore na zapletena vprašanja poslovnega analitika, ki želi npr. preučiti nakupne vzorce na podlagi podatkov o mesečni prodaji (časovna dimenzija) nekega proizvodnega programa (dimenzija izdelka) za vse tržne segmente (dimenzija trga) in skupine strank (dimenzija stranke). Ta problem bi bil z uporabo standardnih metod, kot so relacijske poizvedbe ipd., težko rešljiv in zapleten, s pomočjo OLAP orodja pa ne predstavlja prevelikega zalogaja. Ta imajo namreč veliko sposobnost večdimenzionalnega predstavljanja podatkov na različnem nivoju razdrobljenosti. Kot taka so se odlično izkazala pri preiskovanju zbirk podatkov in hitremu kreiranju raznovrstnih poročil.

Pravila za OLAP, ki jih je navedel dr. Ted Codd:• Dostopnost; da se podatki transformirajo v informacije mora biti zagotovljena velika

dostopnost. • Večrazsežni koncept, podatke lahko pregledamo iz različnih zornih kotov. • Transparentnost, dostop do metapodatkov, atributov in njihove uporabe, dostop do

poljubnega nivoja podatkovnega skladišča. • Prilagodljivost, uporabnik si sam izbere tip poročila. • Arhitektura, pridobivanje podatkov, dostop do podatkov in procesiranje podatkov je

arhitektura fizično ločena, tako da sta odjemalec in strežnik neodvisna od okolja. • Neomejeno število razsežnosti in nivojev agregacij, je neodvisna od zgradbe

podatkovnega skladišča od najnižjega do najvišjega nivoja. • Intuitivna manipulacija, definira podatke z metapodatki v poslovnem kontekstu vsem

uporabnikom. • Prilagodljivo poročanje, ciljnim uporabnikom mora ustrezati informacija in meje

razsežnosti kocke. • Neomejenost operacij po razsežnosti – na najnižjem nivoju je pomembno zavzemanje

razsežnosti entitet. • Podpora večuporabniškemu sistemu podatkovnega skladišča oskrbuje sistem

za vse potrebne atribute, da si uporabniki lahko sami določijo, iz katerih zornih kotov bodo gledali podatke.

9.8.2 OLAP kocka (cube)

Večdimenzionalnost podatkov je najlažje prikazati z več dimenzionalno kocko, ki jo v svetu informatike srečamo pod pojmom OLAP kocka (OLAP cube).

79

Slika 117: OLAP kocka

OLAP kocka je osnovna podatkovna struktura v večdimenzionalnem sistemu OLAP. Predstavlja množico podatkov, ki so shranjeni in prikazani na večdimenzionalen način. Kocko definira množica dimenzij in meritev. Dimenzije predstavljajo kategorijo, po katerih analiziramo podatke, meritve pa predstavljajo vrednost ali velikost podatka, ki ga analiziramo. Množica podatkov kocke je pogosto sestavljena iz podmnožice podatkov iz podatkovnega skladišča. Iz podmnožice podatkovnega skladišča pa zato, ker taka baza ni preobremenjena s tekočimi posli, zato je bolj primerna za procesiranje kock kot živa baza.

Baza podatkovno skladišče se polni v nekem določenem časovnem intervalu (enkrat na dan, enkrat na teden) po potrebi. Tudi procesiranje kock izvajamo v nekem časovnem intervalu, ki ga sami določimo. Pri procesiranju kocke si kocka pripravi tabelo oz. strukturo, ki vsebuje vnaprej preračunane podatke za kocko, še preden uporabnik dostopi do kocke.

Enostavnost in zmogljivost pregledovanja podatkov dopolnjujejo številne funkcije oz. operacije, kot so:

• Zvijanje (roll-up), • Vrtanje (drill-down), • Rezanje (slice and dice), • Vrtenje (pivot).

Vrtanje v globino (drill down) je ena izmed najosnovnejših operacij. S tem se nekako spustimo en nivo nižje.

Zvijanje navzgor (drill up) je obraten proces od vrtanja v globino. Iz podrobnih podatkov gremo v globalen podatek.

Vrtanje skozi (drill through) pomeni, da spreminjamo videz poročila, uporabljamo ga pri

predstavitvah analiz, omogoča zamenjavo osi podatkov, dostop do podrobnih podatkov.

80

Slika 118: Vrtanje, zvijanje OLAP kocke

Slika 119: Rezanje in vrtenje OLAP kocke

9.8.3 Razlika med OLTP in OLAP

Razlika med transakcijskim informacijskim sistemom in podatkovnim skladiščem je v dveh ločenih računalniških sistemih.

OLTP (On-line Transaction Processing): Sistem, ki sproti obdeluje transakcije, relacijske podatkovne baze, delovanje poslovanje.

OLAP (On-line Analytical Processing): Sistemi za podporo pri odločanju, več

dimenzionalna baza podatkov, optimizira poslovanje.

Slika 120: Primerjava OLTP in OLAP

81

Osnovne razlike med OLTP in OLAPOLTP OLAPPodatki se vedno spreminjajo Majhna sprememba podatkovAplikativno orientirani Subjektivno orientiranoTrenutni podatki Zgodovinski podatkiPonavljajoče operacije Operacije se spreminjajoDvodimenzionalen pogled Večdimenzionalen pogledDostopamo do manjših količin podatkov Dostop do večjih količin podatkovUporabljajo vsi uporabniki Uporablja vodstvo

S tehnologijo OLAP lahko izvajamo najrazličnejše analize in poizvedbe nad podatki

v podatkovnem skladišče, ne da bi s tem motili trenutno delovanje sistema OLTP.

82

10 PODATKOVNO RUDARJENJE (DATA MINING)

Podatkovno rudarjenje se ukvarja z iskanjem skritega znanja, nepričakovanih vzorcev in pravil iz velikih baz podatkov. Cilj pri podatkovnem rudarjenju je najti pravila, vzorce, ki nam omogočijo najti vez med vzroki in posledicami. Na primer napovedovanje nečesa na podlagi množice dejstev o tem, zbranih v preteklosti.

Podatkovno rudarjenje je ključen korak v procesu odkrivanja zakonitosti v podatkih(knowledge discovery in databases – KDD).

Opredelimo ga lahko tudi kot uporabo specializiranih algoritmov, s katerimi iz zbrane množice podatkov izluščimo zanimive ter uporabne (koristne) vzorce in modele.

Podatkovno rudarjenje je en izmed ključnih členov sistema za analiziranje podatkov ali tudi tako imenovane poslovne inteligence. Podatkovno rudarjenje nam omogoča razkrivanje skritih vzorcev v podatkih, ki so jih v letih poslovanja zbrala podjetja iz raznih sistemov kot so: poslovni informacijski sistemi, CRM sistemi in druge aplikacije za zajem podatkov.

Glavni namen podatkovnega rudarjenja je razkriti vzorce in povezave iz zbranih podatkov, prikazati njihove vrednosti, jih spremeniti v informacije in jih uporabiti v procesih (segmentacije, napovedovanja). Podatkovno rudarjenje nam omogoča avtomatizirano iskanje informacij v tej kopici podatkov.

Cilj pri podatkovnem rudarjenju je najti pravila, vzorce, ki nam omogočijo najti vez med vzroki in posledicami. Na primer napovedovanje nečesa na podlagi množice dejstev o tem zbranih v preteklosti. Podatkovno rudarjenje se uporablja za segmentiranje (razvščanje) strank (komu pošiljati in katere reklame), za optimizacijo cen, razmeščanje artiklov po policah v trgovini, iskanje ustreznega besedila in slik na spletu, pa tudi za napovedovanje vremena, trendov ali tečajev na borzi.

Področja uporabe:• Razvrščanje) strank (komu pošiljati in katere reklame). • Optimizacija cen, razmeščanje artiklov po policah v trgovini. • Iskanje ustreznega besedila in slik na spletu. • Napovedovanje vremena, trendov, tečajev na borzi.

83

10.1 ZNAČILNOSTI PODATKOVNEGA RUDARJENJA

Potrebna velika količina kakovostnih podatkov, “rudar” je navadno končni uporabnik, vendar so potrebna izrazito interdisciplinarna znanja. Uporabljajo se tehnike, ki so znane s področij strojnega učenja, statistike, umetne inteligence, računalništva …Področja uporabe:

• Trženje: izdelava in analiza profila, segmentacija, iskanje povezav med prodajo izdelkov, odziv, aktiviranje in obdržanje kupca, navzkrižna prodaja …

• Druga poslovna uporaba: finančne storitve, napovedi, nadzor kakovosti, bančništvo, trgovanje z vrednostnimi papirji …

• Medicinska diagnostika. • Odkrivanje prevar (kreditne kartice, davčne napovedi...). • Nadzor onesnaževanja v elektrarnah. • Prijaznejša uporaba spleta. • Preverjanje identitete (npr. v računalniških sistemih). • Avtomatizacija dela.

Podatkovno rudarjenje prinaša odgovore na vprašanja kot so:• Kateri kupci so najbolj donosni za podjetje? • Kako naj najbolje razporedim svoje vire? • Kako lahko povečam svoj tržni delež? • Kdo so obiskovalci mojih spletnih strani? • Katere moje stranke bodo najverjetneje odšle k tekmecem?

Slika 121: Proces izgradnje modela za podatkovno rudarjenje

84

Razlike med podatkovnim rudarjenjem in iskanjem statističnih podatkov:• klasične tehnike izkopavanja so bolj robustne pri obdelavi neurejenih podatkov

in bolj primerne za manj izkušene uporabnike, kot pa statistične, • izkopavanje podatkov je avtomatiziran proces iskanja znanja (vzorcev, pravil itd.). Pri

statistični analizi pa mora analitik za vsak problem postaviti hipoteze in v naprej vedeti, kaj želi najti,

• uporabniki orodij za izkopavanje podatkov niso nujno statistiki – dovolj je, da ima uporabnik osnovno statistično zanje in veliko izkušenj.

• “Pri statistični analizi nikoli ne najdeš tistega, česar ne iščeš.” • Zelo zanesljive napovedi obnašanja kupcev; statistične metode imajo tu slabosti.

o Statistika: “Katere stranke so v zadnjih petih letih bivale v hotelih ****?”o Rudarjenje: “Katere stranke bodo v naslednjem letu zelo verjetno bivale v

hotelih ****? Po čem se ločijo od ostalih strank? • Pri rudarjenju so lahko vprašanja tudi zelo nedorečena.

Slika 122: Rudarjenje in statistika

Tradicionalne statistične metode ne obravnavajo delov podatkov, ki ležijo izven pričakovanega vzorca. Rudarjenje tvori vzorce, ki se prilegajo podatkom. Na ta način dobljeni rezultati so bolj natančni ( Slika 122).

10.2 RAZLIKA MED OLAP ORODJI IN ORODJI ZA PODATKOVNO RUDARJENJE

• OLAP je usmerjen v večdimenzionalne podatkovne analize. • OLAP – dobimo podatke o prodaji določenega artikla. • Podatkovno rudarjenje – iščemo vzroke, ki so vplivali na prodajo. • Z OLAP detajlno ponazorimo vzročne povezave, ki smo jih našli s pomočjo

podatkovnega rudarjenja.

10.3 METODE PRI UPORABI PODATKOVNEGA RUDARJENJA

Metode pri uporabi podatkovnega rudarjenja so:• najbližji sosed (nearest neighbor),

o napovedovalna tehnika – napoveduje, katere vrednosti se nahajajo v posameznem zapisu,

o išče zapise, ki so podobni napovedani vrednosti v bazi podatkov,o uporablja napovedno vrednost iz zapisa, ki je najbližja nerazvrščenim zapisom,o če lahko predvidevaš, kaj se bo zgodilo z enim objektom, lahko

predvidiš, kaj se bo zgodilo z njegovim sosedom.

85

o Po navadi ne iščemo samo enega soseda, ampak več. Pri tem upoštevamo povprečja in se s tem izognemo nepravilnim napovedim v primeru, če je „sosed“ izjema.

• razvrščanje v skupine (clustering), o cilj je najti skupine, ki so med seboj zelo različne, a so notranje homogene.

• inducirana pravila (rule induction), je ena glavnih oblik, išče oz. uporablja: o znanje, skrito v bazi, moramo odkriti v obliki pravila, ki nam pove nekaj

novega o naših podatkih (vzorec, ki se ponavlja pri določenih podatkih po pravilu, ki smo ga odkrili s pomočjo te tehnike),

o pravilo ČE – POTEM 3:Odgovoriti je potrebno na dve vprašanji: Kako pogosto pravilo drži? (natančnost) Kako pogosto se to pravilo pojavi? (obseg)

o odločitvena drevesa (decision trees) – veje drevesa predstavljajo vprašanja o kupcih, ki si jih zastavljamo, ko hočemo ugotoviti določen segment kupcev. Cilj je najti čim boljše vprašanje na vsakem nivoju. Algoritem širi drevo dokler ni uresničen eden od naslednjih kriterijev ( Slika 123) :

ko segment vsebuje le en zapis, ko imajo vsi zapisi enake lastnosti, kadar rezultat ne bi opravičil postavljanja dodatnega vprašanja,

ki bi še naprej razdelilo segment. • nevronske mreže (neural networks) – omogočajo modeliranje kompleksnih

problemov z velikim številom odvisnih spremenljivk. Ime izhaja iz teze, da je računalnik mogoče s posnemanjem delovanja človeških možganov naučiti razmišljati.

o Hotenje po posnemanju možganov: zaznavanje vzorcev, predvidevanje, učenje.

o Model sestoji iz številčnih vrednosti in kompleksnih izračunov ter zahteva, da so vse vrednosti v številčni vrednosti.

Slika 123: Primer odločitvenega drevesa

3 Primer natančnosti in obseg pravila: Če kupec kupi kruh, potem kupi tudi mleko (natančnost 85%, pri 20% vseh nakupov)

86

11 NOSQL PODATKOVNE BAZE

Kratica NoSQL je povezana z novo generacijo podatkovnih baz, ki so se pojavile v povezavi s težavami, s katerimi se srečujemo pri uporabi relacijskih baz. Pri težavah mislimi na ogromne količine podatkov, ki se nalagajo in pretakajo po internetu preko socialnim omrežij ipd. (Facebook, Google, Tweeter…). Pri tem se samo na eno od teh omrežij dnevno naloži nekaj tera bytov podatkov (TB). Težave so seveda povezane tudi z uporabo storitev v oblaku (cloud computing). Če želimo velikemu številu uporabnikov omogočiti sočasen dostop do velikih količin podatkov od kjerkoli in kadarkoli, tega ni mogoče zagotoviti z uporabo relacijskih podatkovnih baz.

Bolj primerno ime bi sicer bilo No RDBMS 4 oz. No Relational, vendar se je prijelo ime NoSQL (verjetno zaradi enostavnosti).

Relacijsko orientirane podatkovne baze so namenjene minimiziranju redundance, pravimo, da so normalizirane. Ravno normalizacija pa pomeni težavo pri veliki količini podatkov.Pravzaprav pripelje do težave šibke točke (single point of failure). Temu so se nerelacijsko orientirani podatkovni modeli izognili, saj so podatki redundantno porazdeljeni po obroču podatkovnih strežnikov. Dosežena je zelo nizka možnost šibke točke. Posodobitve na enem mestu pa sprož ijo (običajno) asinhrono propagiranje spremembe k preostalim podatkom. S temi lastnostmi lahko pri veliki količini podatkov, ki jih dosega veliko število uporabnikov, dosežemo veliko boljše zmogljivostne kazalce kakor pri relacijskih podatkovnih bazah SQL.

Težave pri relacijskih bazah se pojavijo, ko so prekomerno obremenjene. Obremenjenost se sicer lahko zmanjša:

• s pomočjo nabave zmogljivejše strojne opreme (scale up) in/ali • s porazdeljeno distribucijo podatkovnih strežnikov (scale out), kjer se podatki in

bremena porazdelijo na več strežnikov. Sistemu se po potrebi dodajajo nova vozlišča, s tem dobimo večjo prilagodljivost in odzivnost sistema, hkrati pa se poveča kompleksnost sistema.

Slika 124; Vertikalna skalabilnost (scale up)

4 Relational DataBase Management System

87

Slika 125: Horizontalna skalabilnost (scale out)

NoSQL baze se naslanjajo predvsem na horizontalno skalabilnost, ker je cenejša. Pri tem se uporabljata dva pristopa, replikacija in delitev.

Replikacija pomeni, da je lahko n ek konkreten podatek shranjen v več kot samo enem vozlišču. S tem se poveča odzivnost podatkovne baze, ker se lahko branje podatkov porazdeli čez več vozlišč. Zagotovljena je tudi varnost podatkov, ker lahko vozlišče, ki iz nekih razlogov odpove, nadomesti drugo. Prav tako se v oblačnih storitvah s pomočjo replikacije lahko zagotovi, da so določeni podatki shranjeni bližje uporabnikom (geografska porazdelitev vozlišč). Problem pa je v operacijah zapisovanja podatkov – preden se vrne potrditev, da je zapisovanje izvršeno, bi morala vsa replikacijska vozlišča vrniti potrditev zapisa podatkov (sinhroni zapis). En način zapisovanja pa je, da se podatki zapišejo ne naenkrat na vseh eplikacijskih vozliščih, ampak sčasoma – najprej na enem ali na določeni skupini, pozneje še na ostalih (asinhroni zapis).

11.1 NOSQL IN ACID LASTNOSTI RELACIJSKIH BAZ PODATKOV

NoSQL pravzaprav ne pomeni "No SQL" ampak "Not Only SQL" (razlag je več…). V bistvu pa gre pri NoSQL bazah za to, da ne sledijo striktno ACID lastnostim relacijske baze, ki zagotavljajo s pomočjo mehanizma transakcij in zaklepanja podatkov konsistentnost relacijske baze.

ACID = Atomicity (atomarnost) + Consistency (konsistentnost) +Isolation (izolacija) + Durability (trajnost)

Atomarnost – če se transakcija prekine med delovanjem, pričakovano alinepričakovano, se razveljavijo tudi vse operacije, ki sosestavljale transakcijo.

Konsistentnost – transakcija mora vedno dati isti rezultat, pa če jo izvedemo tatrenutek ali čez pol dneva, rezultat mora biti isti – seveda, čese vhodni parametri za transakcijo ne spremenijo.

Izolacija – če je transakcija sestavljena iz velikega števila operacij,morajo biti t. i. notranja stanja, pravzaprav zaporednaizvajanja operacij, drugim delom sistema nevidna. Šele ko jetransakcija potrjena, je lahko rezultat transakcije viden drugimdelom sistema.

Trajnost – pomeni, da so rezultati transakcije trajni in se nikoli neizgubijo; poleg tega je rezultat transakcije vedno vrnljiv(reverzibilen).

88

Pri relacijski podatkovni bazi moramo pred delom s podatki najprej določiti shemo, kar vključuje:

• shemo vsake tabele, njenih atributov (stolpcev) in razmerij med entitetami,

• določitev indeksov za potrebe poizvedovanja.

Relacijski model ne uveljavlja posebnega načina za delo s podatki – zgrajen je s poudarkom na celovitosti in normalizaciji podatkov, preprostosti in abstrakciji, ki so vsi izjemno pomembni za velike kompleksne aplikacije.

NoSQL baze sledijo BASE zahtevam (Basically Available, Soft state, Eventually consistent). Lastnosti modela BASE so:

• Večinoma razpoložljiv (Basically Available): sistem zagotavlja razpoložljivost glede na CAP teorem.

• Mehko stanje (Soft-state): stanje sistema se zaradi asinhronih posodobitev čez čas spremeni tudi brez sprememb uporabnika. Posledica tega je, da so kopije podatkov v nekem času lahko nekonsistentne.

• Eventuelna konsistentnost (Eventual Consistency): nekatera vozlišča imajo točne podatke, druga vozlišča imajo zastarele podatke. Kopije podatkov sčasoma postanejo konsistentne, ko se nad njimi več ne izvajajo posodobitve.

Primerjava ACID in BASE zahtev za podatkovno bazo

ACID BASEKonsistentnost je najpomembnejša Razpoložljivost je najpomembnejša

Močna konsistentnost Eventuelna konsistentnostPočasnejše Hitrejše

Manjša prilagodljivost Enostavnejši razvojManjša skalabilnost Večja skalabilnost

Zahtevana podatkovna shema Podatkovna shema ni zahtevana

NoSQL podatkovne baze lahko podpirajo atomarnost in izolacijo v primeru, ko vsaka transakcija dostopa samo do podatkov znotraj enega objekta (npr. na nivoju ključa: dve operaciji na istem ključu bosta zaporedni, da ne pokvarita parov ključ/vrednost). Transakcije v relacijskih podatkovnih bazah zagotavljajo, da bosta na primer naročilo in postavka naročila posodobljena skupaj, pri NoSQL pa sta lahko del istega objekta in sta prav tako hkrati posodobljena. To sicer odpravlja potrebo po dragih porazdeljenih protokolih potrjevanja, vendar mora biti vsaka logična transakcija, ki se razteza čez več kot en objekt, v aplikaciji razdeljena na ločene transakcije. Sistem zato ne zagotavlja niti atomarnosti niti izolacije. Razvijalec mora tako v sami aplikaciji implementirati željene funkcionalnosti ACID in podatkovno celovitost.

11.2 LASTNOSTI NOSQL BAZ PODATKOV

NoSQL izhaja na domnevi, da ni vedno najbolj pomembno, ali se po kakšen podatek pojavil kasneje in ne takoj, ko se pojavi zahteva po njem (v skrajnem primeru se lahko tudi "izgubi" oz. zahteva po podatkih ne dobi podatkov).

89

NoSQL podatkovne baze ne zahtevajo enotne podatkovne sheme in omogočajo spreminjanje le-te brez izpada sistema. Atribute lahko poljubno dodajamo, podatki pa lahko zavzamejo poljubne vrednosti. Prav tako ni relacij med podatki. Podatki, ki so povezani, so običajno pogrupirani in shranjeni kot enota (npr. dokument, stolpec).

Podatkovne baze NoSQL tako omogočajo veliko večjo prilagodljivost podatkovnega modela kot relacijske podatkovne baze, je pa skrb za podatke brez sheme prepuščena aplikaciji, ki mora vedeti, kaj ti podatki predstavljajo ter kje in kako so shranjeni.

Podatkovne baze NoSQL imajo podatkovne strukture, ki so različne od tistih v relacijskih podatkovnih bazah, kjer je enotna podatkovna struktura tabela. Razlog je ta, da so v relacijskih podatkovnih bazah stolpci definirani na enem centralnem mestu. To posledično otežuje horizontalno skalabilnost, saj bi bilo potrebno v primeru spremembe sheme ustaviti vsa vozlišča v gruči.

Podatkovni model

Relacijski NoSQLPodatkovna struktura Uniformna - tabela (stolpci in Različna (par ključ/vrednost,

vrstice). Vrstice znotraj neke dokument, razširljivtabele imajo isto shemo. zapis,...).

Podatkovna shema Potrebna. Ni potrebna.Struktura podatkov Podatki so strukturirani. Podatki so pol-strukturirani

Struktura je vezana na in nestrukturirani.vsebino Struktura je vezana napodatkov. funkcionalnost aplikacije.

Normalizacija Zahtevana NeRazmerja So temelj relacijskega Nobeno razmerje ni izrecno

podatkovnega modela. definirano med podatki.Celovitost podatkov Zagotavlja podatkovna baza. Mora zagotoviti programer v

aplikaciji.Poizvedovanje SQL vmesnik Aplikativni dostopOperacija JOIN Da Ne

Spremembe podatkovnega modela je pri NoSQL mogoče doseči precej enostavneje kot pri relacijskih podatkovnih bazah. Vozlišče lahko enostavno vzamemo iz gruče in ga dodamo nazaj v gručo kot nov strežnik, ki ima vlogo gospodarja. Mehanizem replikacije bo poskrbel za sinhronizacijo podatkov in razmnožitev spremenjenega podatkovnega modela na ostala vozlišča v gruči.

90

Primerjava dostopa do podatkov pri relacijskih in NoSQL podatkovnih bazah

Dostop do podatkovRelacijska podatkovna baza NoSQL podatkovna baza

Operacije shranjevanja, posodabljanja, Operacije shranjevanja, posodabljanja,brisanja in poizvedovanja z uporabo SQL. brisanja in poizvedovanja izpostavlja API

vmesnik.SQL poizvedbe lahko dostopajo do podatkov Nekatere implementacije zagotavljajo zaiz ene ali več tabel s pomočjo stikov. opredeljevanje kriterijev za filtriranje

preprost poizvedovalni jezik podoben SQL.SQL poizvedbe vključujejo funkcije za Običajno omogoča samo osnovno filtriranjeagregacijo in kompleksno filtriranje. (>,<,=).Podpirajo vgraditev logike blizu shranjenih Vsa aplikacijska logika in logika zapodatkov (prožilci, shranjene procedure, celovitost podatkov sta vsebovani v kodiSQL predprocesirani paketi in funkcije). aplikacije.

Slika 126: NoSQL vozlišča

Slika 127: Replikacija NoSQL podatkovnih

baz 11.3 VRSTE NOSQL BAZ PODATKOV

Obstaja kar nekaj izvedenk NoSQL baz podatkov, ki pa se jih lahko razvrsti v naslednje štiri skupine (Vir: Monitor Pro):

• shrambe s ključi, • dokumentne zbirke, • zbirke grafov in • stolpično usmerjene zbirke.

91

11.3.1 Shrambe s ključi

Shrambe s ključi (Key-value stores) so najpreprostejše. Osnovna enota hranjenja predstavlja poljuben podatek, ki ga označimo s ključem, s pomočjo katerega potem do njega dostopamo(beremo, pišemo). Rešitev izvira iz amazon.com in je zaradi enostavnosti uporabna pri hranjenju masovnih količin podatkov. Posamezne izpeljanke se ločijo glede na število repliciranih oziroma redundatnih kopij podatkov, kompleksnosti podprtih podatkovnih tipov ipd. Primeri izvedb so BerkleyDB in njegova izpeljanka Keyspace, Dynomite, Voldemort, Mnesia (Ericsson), MemcachedDB in Tokyo Cabinet.

11.3.2 Dokumentne zbirke

V dokumentne zbirke ( document databases) lahko shranjujemo kompleksnejše podatkovne strukture. Na daleč so morda celo malce podobne že pozabljenim predmetnim zbirkam. Dokument predstavlja poljubne podatke in pogosto vsebuje seznam ključev/vrednosti. Ker lahko sorodne dokumente združujemo v skupine, imamo na voljo tudi proženje poizvedb po vrednostih ključev. Sistem naj bi bil povzet po Lotus Notes, priljubljene izvedbe soMongoDB, CouchDB, pogojno Amazonov SimpleDB in Redis. Za poseben primer dokumentih zbirk štejemo zbirke XML.

Strukture takšnih podatkovnih sistemov so dinamično razširljive. Podatki se lahko dodajajo in strukture razširjajo kadarkoli.

11.3.3 Zbirke grafov

Baza za hranjenje grafov je podatkovna baza NOSQL, ki uporablja strukture grafov za opis in shranjevanje podatkov. Temelji na teoriji grafov. Podatkovno strukturo sestavljajo vozlišča, lastnosti in robovi. Vozlišča so zelo podobna objektom, ki običajno predstavljajo ljudi, poslovne modele ipd. Lastnosti predstavljajo ustrezne informacije o vozliščih. Robovi so linije, ki med seboj povezujejo vozlišča.

Zbirke grafov (graph databases) se ne uporabljajo za hrambo podatkov samih, ampak vanje shranjujemo podatke o odnosih med predmeti (torej o grafih po "matematično"). Takšne strukture je bilo v relacijskih zbirkah vedno malce nerodno definirati, zahtevnost poizvedb pa je strmo naraščala s količino podatkov. Zbirke grafov tovrstne poizvedbe zelo pospešijo in so zato primerne za uporabo v družabnih omrežjih (iskanje skupnih prijateljev, privržencev ipd). Priljubljena izvedba je Neo4j, med znanimi so tudi AllegroGraph, InfoGrid, Sones graph DB in FlockDB, ki jo uporablja Twitter.

11.3.4 Stolpično usmerjene zbirke

Zadnjo skupino tvorijo t. i. kloni že omenjenega Googlovega sistema BigTable, za katere se uporablja tudi izraz stolpično usmerjene zbirke (Column-oriented databases). Če so implementacije v ostalih skupinah optimizirane predvsem za hitro delo s posameznimi informacijami, kot so dokumenti, BigTable uporabljajo za poizvedbe pri velikem številu podatkov in je zato primeren za razna analitična orodja in podatkovno rudarjenje (data mining). Znane implementacije so HBase, Hypertable in Cassandra.

Stolpično orientirani modeli so oblika podatkovno orientiranega upravljalnega sistema, kjer se podatki shranjujejo stolpično. Takšna predstavitev ima prednost za podatkovno skladiščenje (data warehouse) in kataloge knjižnic, kjer se agregacije izvajajo čez velike količine

92

podobnih podatkov. S stolpično orientiranim modelom se nanašamo na preprostost

predstavitve stolpične strukture in optimizacijo za stolpično orientirano agregiranje podatkov.

Prednosti:

• Stolpično orientirani modeli so učinkovitejši, kadar se podatki kopičijo čez veliko količino vrstic, pri čemer zajemajo samo manjše skupine stolpcev.

• Stolpično orientirani modeli so učinkovitejši, kadar se nove vrednosti

posameznega stolpca zapišejo hkrati za večjo količino vrstic hkrati.

Če naredimo primerjavo podatkovnega modela med sistemi RDBMS in NOSQL, bi stolpična družina iz NOSQL predstavljala tabelo v RDBMS. Vsaka kombinacija ključ-

vrednost iz stolpične družine pa vrstico v tabeli.

11.4 UPORABA NOSQL BAZ PODATKOV

Relacijske baze podatkov so narejene na splošno, ena baza rešuje vse potrebe oz. zahteve.Zbirke NoSQL so drugačne, saj so prilagojene problemu, za katerega jih uporabimo. Njihove glavne prednosti so (Vir: MonitorPro):

• Cena Veliko NoSQL-izvedb je brezplačnih, nekatere so celo predane odprtokodni skupnosti. Poleg tega se jih večina prav lepo počuti v okoljih Linux/Unix, kar dodatno znižuje stroške lastništva.

• Zmogljivost Izsledki performančnih testov rešitev RDBMS in NoSQL so osupljivi, saj izvajalci poročajo, da so slednje od deset- pa tudi do stokrat hitrejše. Čeprav je treba ohraniti trezno glavo, se na prvi pogled zdi, da sta manj pogosto zaklepanje podatkov ter njihova razpršenost po več strežnikih bistvena prednost NoSQL.

• Prilagodljivost Pri tradicionalnih zbirkah podatkov se podatkovna raven informacijskih sistemov neodvisno od problema in namena vedno razvija na podoben način. Pri NoSQL bo položaj očitno obrnjen: uporabili bomo pač izvedbo, ki bo najbližja problemu.

Eden od problemov, ki se pri uporabi NoSQL baz podatkov pojavlja zaradi pomanjkanja formalnih standardov, je problem varnosti oz. varovanje dostopa do podatkov.

Relacije in transakcije so npr. pri upravljanju finančnih podatkov še vedno nepogrešljive in nadzor lahko zagotovijo samo relacijske baze podatkov.

NoSQL baze podatkov so primerne za uporabo v primerih:• pri računalništvu v oblaku, • uporabe preprostega podatkovnega modela, • ko se zahteva visoka zmogljivost, konsistentnost podatkov pa ni nujna.

Relacijske podatkovne baze pa so hitrejše v primeru struktuiranih podatkov, indeksu (samo) na primarnem ključu in enostavnih SQL poizvedbah.

11.4.1 Aplikacijski vmesnik

93

Razlike v aplikacijskih vmesnikih, ki jih uporabljata obe vrsti podatkovnih baz, so prikazane v spodnji tabeli:

Aplikacijski vmesnik

Relacijska PB NoSQL podatkovna bazaPo navadi imajo svoj specifičen API ali Za dostop do podatkov po navadiizkoristijo generičen API kot npr. OLE-DB zagotavljajo API-je, ki temeljijo naali JDBC. standardih kot so SOAP, REST, THRIFT.Potrebna je preslikava iz relacijske strukture Struktura podatkov v podatkovni bazi jepodatkov v strukturo, ki je primerna za analogna strukturi, ki jo uporabljauporabo v aplikaciji. programski jezik oziroma aplikacija.

11.4.2 Poizvedovalni jezik

Relacijske podatkovne baze uporabljajo zelo razširjen in priljubljen poizvedovalni jezik SQL, ki omogoča skoraj neomejeno indeksiranje ter enostavne in ad hoc poizvedbe kot tudi dinamične in kompleksne poizvedbe preko več tabel. Osnovne operacije, ki jih SQL podpira so:

• Stiki (JOIN), • Filtri (WHERE), • Funkcije:

o Agregacije (GROUP BY, AVG, COUNT, MAX, MIN…),o Skalarne (ABS, DAY, DATE, TIME, POWER, SUBSTR…).

Podatkovne baze NoSQL imajo sicer lahko omejeno podporo dinamičnim poizvedbam in indeksiranju (npr. MongoDB), vendar za razliko od SQL ne podpirajo stikov, bolj kompleksnih filtrov in agregacij, zato morajo biti te operacije implementirane v aplikacijski kodi. V splošnem uporabljajo preprost vmesnik, ki podpira tri osnovne operacije:

• get(key) – vrne vrednost, ki pripada danemu ključu. • put(key, value) – shrani ali posodobi vrednost skupaj s pripadajočim ključem. • delete(key) – izbris vrednosti in pripadajočega ključa.

Nekatere podatkovne baze NoSQL imajo na voljo tudi svoj poizvedovalni jezik, ki je podoben SQL (npr. MongoDB, Hypertable, Cassandra).

Kljub temu je ena od močno pogrešanih funkcij NoSQL ravno SQL, in če želijo biti podatkovne baze NoSQL tako široko uporabljene kot relacijske, bodo verjetno morale poiskati neko podobno alternativo. Ponudniki rešitev NoSQL vedno bolj stremijo k poizvedovalnim jezikom, ki so podobni SQL, kajti zavedajo se, da če ne bodo našli nekega skupnega nabora operacij nad podatki, potem obstaja verjetnost, da bo ena ali druga implementacija postala bolj priljubljena in se bodo uporabniki ali preselili k produktu, ki rešuje njihov problem, ali pa bodo morali vsi ponudniki implementirati svoj nabor operacij, ki bo konkurenčen.

Primer poizkusa razvoja skupnega poizvedovalnega jezika za podatkovne baze NoSQL predstavlja jezik UnQL (Unstructured Data Query Language). UnQL je produkt dveh podjetij, CouchDB in SQLite. Razčleni lahko vse izjave jezika SQL in podpira številne nove izjave, operatorje in tudi izraze, ki se jih lahko razširi za bolj kompleksne dokumente. Tako kot SQL je bil osnovan na temelju relacijske algebre. Če bi ga sprejeli ostali ponudniki

94

NoSQL rešitev, bi UnQL lahko predstavljal enotni vmesnik za podatkovne baze NoSQL. Ena izmed podatkovnih baz, ki UnQL že uporablja, je Couchbase.

Za hitro obdelavo ogromnih količin podatkov ima veliko podatkovnih baz NoSQL na voljo lastno implementacijo ogrodja MapReduce.

MapReduce je primeren za probleme, ki potrebujejo paketno analiziranje celotnega nabora podatkov, zlasti za ad hoc analize. Relacijski SUPB je dober za poizvedbe in posodobitve, kjer je nabor podatkov indeksiran za hitro vračanje in posodabljanje relativno majhne količine podatkov. MapReduce ustreza aplikacijam, kjer so podatki zapisani enkrat, in velikokrat prebrani, medtem ko so relacijske podatkovne baze dobre za nabor podatkov, ki se stalno posodabljajo.

11.4.3 NoSQL in indeksi

Podatkovne baze NoSQL v splošnem ne podpirajo sekundarnih indeksov (to je indeksov po atributih, ki niso primarni ključ), vendar jih razvijalci lahko implementirajo na svoj način. Pogost pristop je kreiranje ločene tabele, ki vsebuje vse vrednosti stolpca, nad katerim bi navadno ustvarili sekundarni indeks, in pripadajoče ključe vrstic iz glavne tabele.