Diplomsko delo visokošolskega strokovnega študija Informatika v organizaciji in managementu OBDELAVA IN PRIPRAVA PODATKOVNE KOCKE OLAP Mentor: izr. pr

Transkripcija

1 Informatika v organizaciji in managementu OBDELAVA IN PRIPRAVA PODATKOVNE KOCKE OLAP Mentor: izr. prof. dr. Uroš Rajkovič Kandidat: Gregor Povhe Kranj, maj 2016

2 ZAHVALA Zahvaljujem se mentorju izr. prof. dr. Urošu Rajkoviču za strokovno pomoč, nasvete in usmerjanje pri izdelavi diplomskega dela. Posebna zahvala gre ženi Vesni za vso pomoč in potrpljenje. Zahvalil bi se tudi staršem, ki so mi vedno stali ob strani.

3 POVZETEK Diplomsko delo prikazuje obdelavo in pripravo podatkov, pridobljenih iz več različnih ERP-sistemov, tako da so primerni za OLAP-kocko. Težava takšnih podatkov iz več virov je, da jih je potrebno obdelati in uvoziti v enotno podatkovno skladišče. Cilj diplomske naloge je bila izvedba OLAP-kocke, ki je potrebna za analizo podatkov. Podatke iz različnih ERP-sistemov smo predelali, očistili in potem uvozili v podatkovno skladišče. V različnih delih ETL-procesa smo podatke obdelovali z različnimi metodami, dokler niso bili primerni za uvoz v podatkovno skladišče. Iz podatkovnega skladišča je bila nato narejena OLAP-kocka. Podatki, pridobljeni iz OLAP-kocke, so bili s testirani v vrtilni tabeli in primerjani z vhodnimi podatki pred obdelavo in pripravo za uvoz v podatkovno skladišče. Podatki iz OLAP-kocke so bili nato primerni za nadaljnje analize. KLJUČNE BESEDE ERP priprava podatkov ETL OLAP podatkovno skladišče ABSTRACT The thesis contains a display of processing and preparation of the data obtained from several different ERP systems so that they are suitable for the OLAP cube. The problem of such data from multiple sources is in that they must be processed and imported into a single data warehouse. The aim of the thesis was to create an OLAP cube that is suitable for BI data analysis. Data from various ERP systems was transformed, cleaned and then loaded into the data warehouse. In various parts of the ETL process data was transformed with different methods until they were eligible for import into the data warehouse. From this data warehouse an OLAP cube was made. Data obtained from OLAP cubes have been tested in the pivot table and compared with the input data prior to processing and preparation for import into the data warehouse. The data from the OLAP cube was then suitable for further analysis. KEYWORDS ERP data preperation ETL OLAP data warehouse

4 KAZALO 1. UVOD PREDSTAVITEV PROBLEMA CILJ DIPLOMSKE NALOGE RAZISKOVALNO VPRAŠANJE METODE DELA TEORETIČNA IZHODIŠČA PREDSTAVITEV OKOLJA IN PRIDOBIVANJE PODATKOV DATOTEKE POTREBNE ZA IZDELAVO OLAP-KOCKE ERP CELOVITE PROGRAMSKE REŠITVE ZA IZVOZ PODATKOV METODE DELA ZA PRIPRAVO PODATKOV V OLAP KOCKO ORACLE PODATKOVNO SKLADIŠČE ORACLE OLAP-KOCKA ETL-PROCES PREVERJANJE PODATKOV ZDRUŽEVANJE ALI AGREGIRANJE PODATKOV TRANSFORMACIJA PODATKOV ČIŠČENJE PODATKOV UVAŽANJE PODATKOV MANIPULACIJA ALI PRESTRUKTURIRANJE PODATKOV PROFILIRANJE PODATKOV PLEMENITENJE PODATKOV PREVERJANJE KAKOVOSTI PODATKOV PODATKOVNO RUDARJENJE PRIPRAVA BAZE PODATKOV PREVERJANJE IN ČIŠČENJE PREJETIH PODATKOV PROFILIRANJE PREJETIH PODATKOV TRANSFORMACIJA IN MANIPULACIJA ALI PRESTRUKTURIRANJE PODATKOV PODATKOVNO SKLADIŠČE NALAGANJE PODATKOV V PODATKOVNO SKLADIŠČE IZDELAVA OLAP-KOCKE TESTIRANJE V PRAKSI TESTIRANJE POPRAVKOV VHODNIH PODATKOV... 36

5 4.2. TESTIRANJE VHODNIH PODATKOV S PODATKI IZ PODATKOVNEGA SKLADIŠČA TESTIRANJE OLAP-KOCKE SKLEP LITERATURA... 42

6 1. UVOD 1.1. PREDSTAVITEV PROBLEMA Organizacije in podjetja za svoje delovanje uporabljajo velike količine podatkov. Podatki in kasneje informacije so ključnega pomena za uspešno delovanje organizacije. Podatke s pomočjo celovitih programskih rešitev ali ERP-sistemov pretvarjamo v informacijski tok, ki pomaga pri delovanju ali vodenju organizacije. Podjetja, ki za svoje delovanje uporabljajo omenjene programske sisteme, imajo celoten pregled nad poslovanjem podjetja. Vodstvo s tem dobi celovit ima tako popoln in ažuren pregled nad poslovanjem organizacije in njenih oddelkov in zaposleni imajo pregled nad stanjem procesa, da lahko in tako sledijo statusu procesa. V organizaciji s celovito programsko rešitvijo tako preko celovite programske rešitve nastane agregiran pregled nad stanjem procesov. Celovite programske opreme so združene iz več modulov, ki skupaj tvorijo ERPsistem. Osredotočili se bomo na analizo transakcij prodaje različnih podjetij, ki prodajajo medicinske pripomočke, prehranska dopolnila in ostale izdelke splošne rabe. Podatke, pridobljene od različnih podjetij iz neenakih različnih ERP-sistemov, bomo pripravili za analizo celotne prodaje vseh izdelkov. Temelj poslovnih aktivnosti (in drugih namernih dejavnosti) je obdelava informacij, kar vključuje zbiranje podatkov, skladiščenje, prenašanje, manipulacija in pridobivanje (Thomsen, 2002) CILJ DIPLOMSKE NALOGE Cilj diplomske naloge je bil zagotoviti oziroma pridobiti ustrezne podatke iz več različnih sistemov, za analizo in nadaljnjo obdelavo podatkov z OLAP-kocko. Potrebno je bilo pripraviti in zmanipulirati pridobljene podatke, da so ustrezali za pripravo baze. Pripravljene podatke je bilo potrebno shraniti v podatkovno skladišče in iz njega narediti dimenzije in mere v hierarhijah, ki so določene za izgradnjo OLAP-kocke. Z OLAP-kocko lahko vodilni kadri ali analitiki analizirajo svojo ali konkurenčno prodajo, naredijo analize trga in se odločajo o nadaljnji usmerjenosti prodaje RAZISKOVALNO VPRAŠANJE Zanimalo nas je, kako lahko iz različnih virov podatkov (ERP-sistemov in ostalih izvozov), struktur, tipov in razlik med podatki pripravimo podatke primerne za analizo z OLAP-kocko. Poskušali smo ugotoviti, ali lahko brez specializiranih ETL orodij naredimo podatke primerne za analizo. Ali bi lahko z različnimi procesi obdelave in priprave podatkov za uvoz v podatkovno skladišče naredili podatke primerne za končno analizo? S tem smo hoteli preveriti, če bi lahko s pripravo in obdelavo podatkov pred uvozom v podatkovno skladišče in Gregor Povhe: Obdelava in priprava podatkovne kocke OLAP stran 1

7 izgradnjo OLAP-kocke dobili podatke, ki bi jih lahko uporabili za končne analize, še preden bi se lotili podatkovnega rudarjenja ali analiz z OLAP-kocko. Za diplomsko nalogo smo morali uporabiti orodja, s katerimi smo obdelali in pripravili podatke pred uvozom v skladišče. Vprašanje je bilo, ali ta orodja zadoščajo ali je potrebno kupiti specializirano orodje za celoten ali posamičen del ETL-procesa METODE DELA Za analizo podatkov smo izdelali OLAP-kocko iz več virov ali različnih ERP-sistemov. Vsako podjetje ima svoj ERP-sistem in tako ne omogoča enak izvoz podatkov, ker se podatki v ERP-sistemu razlikujejo po podjetjih. Tudi baze podatkov znotraj ERPsistemov so različne. Podatki, pridobljeni iz raznih ERP-sistemov, niso enako strukturirani, uporabljajo se drugačni tipi datotek, pojavljajo se anomalije v podatkih, podatki manjkajo itd. Težava nastane pri združevanju podatkov v enotno podatkovno skladišče, ki je primerno za nadaljnjo izgradnjo OLAP-kocke. Uporabljene metode dela so bili procesi znotraj ETL-procesa: popravljanje podatkov, združevanje, transformacija, čiščenje podatkov, uvažanje podatkov in njihova manipulacija. Z omenjenimi metodami dela nismo uporabili specialnih ETL-orodij za celoten proces, temveč smo posamezne sklope procesov razdelili in jih rešili z drugačnimi orodji. Gregor Povhe: Obdelava in priprava podatkovne kocke OLAP stran 2

8 2. TEORETIČNA IZHODIŠČA Priprava podatkov je proces zbiranja, čiščenja in združevanja podatkov v podatkovna skladišča ali baze, primerne za nadaljnjo obdelavo in kasneje analizo podatkov. Proces priprave podatkov običajno vsebuje združevanje podatkov iz več virov in različnih formatov, popravljanje podatkov in vnašanje praznih vrednosti ter vnašanje manjkajočih atributov. Procesni tok, kot ga prikazuje Slika 1, od vhodnih do izhodnih podatkov primernih za analize, vsebuje več različnih podprocesov: Izvoz podatkov iz različnih podatkovnih virov kot del ETL-procesa. Obdelava podatkov kot del ETL-procesa. Uvoz podatkov v podatkovna skladišča kot del ETL-procesa. Izdelava OLAP-kocke ali drugih izvozov primernih za nadaljnje analize. Slika 1: Podatkovni tok podatkov od vira do OLAP-kocke (Super Develop, 2015) 2.1. PREDSTAVITEV OKOLJA IN PRIDOBIVANJE PODATKOV Transakcije podatkov podjetij smo pridobili iz različnih ERP-sistemov, kot so SAP ERP, Microsoft Dynamics NAV in Oracle E-Business Suite. Nekaj podatkov smo dobili z direktnimi izvozi s SQL-poizvedbami iz programov, ki jih podjetja uporabljajo za svoje delovanje. Ostali izvozi so bili narejeni preko integriranih poročil v internih programih, ki omogočajo uporabniku, da izbere polja, ki jih želi izvoziti, ali z ročnimi izvozi iz internih sistemov. Pridobivanje enako strukturiranih podatkov iz različnih ERP-sistemov je že samo po sebi zahtevno. Dodatna težava nastane pri integriteti podatkov iz večjih podatkovnih sistemov. Napake pri večjih bazah so zelo pogoste in atributi so mnogokrat nezanesljivi ali neuporabni (Witten, Eibe in Hall, 2011). Gregor Povhe: Obdelava in priprava podatkovne kocke OLAP stran 3

9 Za izvoze iz sistemov smo dobili tekstovne strukturirane datoteke ali Excel-datoteke. Organizirane so bile na dva načina: Serijsko zapisi v datotekah so bili razvrščeni, kot so nastajali po časovnem vrstnem redu. Novejši zapisi so bili na koncu datoteke. Datoteke so imele glavo in EOF (angl. End Of File). Neurejeno zapisi v datotekah niso bili urejeni DATOTEKE POTREBNE ZA IZDELAVO OLAP-KOCKE Izvozi pridobljeni iz podjetij, ki smo jih potrebovali za izdelavo OLAP-kocke, so bile narejene tri različne datoteke: Datoteka Kupcev (K-datoteka). Datoteka vsebuje podatke o kupcu. V njej so lahko vsi kupci ali samo kupci, ki so imeli prodajo v določenem obdobju. Datoteka Izdelkov (I-datoteka). Datoteka vsebuje podatke o izdelku. Lahko je presek vseh izdelkov v bazi ali samo izdelki, ki so bili prodani v določenem obdobju. Datoteka Prodaje (P-datoteka). Datoteka vsebuje vse podatke o transakcijah prodaje v obdobju enega meseca. Za vse tri datoteke smo izdelali specifikacije za ureditev datotek. Skupno jim je bilo, da mora biti datoteka zapisana v kodnem zapisu UTF-8 ali Windows Kodna zapisa sta vsebovala šumnike č, š in ž. Za razdelilnik polja (angl. Field Delimiter) v podatkih med atributi smo določili razdelilnik» «. Če je znak» «obstajal med atributi, ga je bilo potrebno izpisati v narekovajih ' '. Polja v datotekah tipa Integer, Double, Single oziroma za vsa števila v poljih, se je uporabilo pri decimalnem zapisu za vsaj dvemi decimalnimi mesti vejica (,) in za vse vrednosti nad tisoč se naj bi izognili ločilu pika (.). Imena datotek za izdelavo kocke niso bila pomembna. Odločilno je bilo, da smo iz imena lahko razbrali vir, kdo pošilja podatke in za katero vrsto datoteke gre (K-, I- ali T-datoteka). Če bi bili podatki zbirani periodično, bi bilo v nadaljevanju smotrno narediti specifikacije tudi za imenovanje datotek. Dodali bi lahko tudi datum in točno določeno strukturo poimenovanja. S tem bi dobili večjo transparentnost nad prejetimi datotekami. Datoteka Kupci Iz datoteke kupcev smo želeli pridobiti podatke končnega kupca. V datoteki so bili lahko zapisi vseh kupcev v sistemu ali pa samo izbor tistih, ki so imeli prodajo v določenem obdobju. Vsa polja v tabeli specifikacij: koda kupca, ime, kraj, naslov in poštna številka so bila obvezna. V primeru da so bila polja v datoteki prazna nam je sistem javil napako. Specifikacije polj za datoteko Kupci predstavlja Tabela 1. Gregor Povhe: Obdelava in priprava podatkovne kocke OLAP stran 4

10 # Ime polja Podatkovni tip Opis polja 1. Koda kupca String Unikatna koda kupca 2. Ime String Ime kupca 3. Kraj String Kraj kupca 4. Naslov String Naslov kupca 5. Poštna številka Integer Poštna številka kupca Datoteka Izdelki Tabela 1: Specifikacije polj za tabelo Kupci V datoteki izdelkov smo poskušali pridobiti čim več podatkov, ki bi kasneje pri združevanju podatkov pomagali pri identificiranju izdelkov. Specifikacije polj za datoteko Izdelki predstavlja Tabela 2. # Ime polja Podatkovni tip Opis polja 1. Koda izdelka String Unikatna koda izdelka 2. Ime String Ime izdelka 3. EAN Short Črtna koda izdelka 4. Proizvajalec String Proizvajalec izdelka 5. Enota mere String Enota mere izdelka 6. DDV Float Stopnja DDV za izdelek Datoteka Prodaja Tabela 2: Specifikacije polj za tabelo Izdelki V datoteki prodaje so unikatna polja kupca in izdelka, vrednost prodaje in količina. Polja za datoteko Prodaja so prikazana v Tabeli 3. # Ime polja Podatkovni tip Opis polja 1. Koda izdelka String Unikatna koda izdelka 2. Koda kupca String Unikatna koda kupca 3. Datum Date Datum 4. Količina Integer Količina prodanih izdelkov 5. Vrednost Float Vrednost prodanih izdelkov Tabela 3: Specifikacije polj za tabelo Prodaja Agregirani podatki v datoteki Prodaja obsegajo obdobje enega meseca prodaje. S to datoteko smo pridobili količino prodaje izdelkov in vrednost prodaje izdelkov za obdobje enega leta ERP CELOVITE PROGRAMSKE REŠITVE ZA IZVOZ PODATKOV Večina podatkov pridobljenih za izdelavo diplomske naloge je bilo pridobljenih iz ERP-sistemov. Angleško Enterprise Resource Planning (ERP) sistemi so temeljni programi, ki jih podjetja uporabljajo za povezovanje in usklajevanje informacij na vseh področjih Gregor Povhe: Obdelava in priprava podatkovne kocke OLAP stran 5

11 poslovanja. ERP-programi pomagajo organizaciji upravljati poslovne procese v celotnem podjetju z uporabo skupne baze podatkov in skupnih orodij za poročanje. Poslovni proces je zbirka aktivnosti, ki ima eno ali več vrst vhodnih informacij, in ustvarja izhod, na primer poročila ali napovedi, ki predstavljajo vrednost končnemu kupcu. ERP celovita programska oprema podpira učinkovito delovanje poslovnih procesov z integracijo nalog v povezavi s prodajo, trženjem, proizvodnjo, logistiko, računovodstvom in kadrovskimi nalogami v celotnem podjetju. Poleg te navzkrižno funkcionalne integracije, ki je v središču ERP-sistema, podjetja povezujejo svoje ERP-sisteme, ki uporabljajo različne metode za usklajevanje poslovnih procesov s svojimi kupci in dobavitelji (Monk in Wagner, 2013). Podatki za izdelavo OLAP-kocke so bili pridobljeni iz treh ERP sistemov: SAP ERP, Microsoft Dynamics NAV in Oracle E-Business Suite. SAP ERP je ERP-sistem, ki ga je razvilo nemško multinacionalno programsko podjetje SAP SE (angl. Systems, Applications & Products). Podjetje velja za enega vodilnih proizvajalcev poslovnih aplikacij. Podjetje SAP ima preko kupcev in pisarne v 190. državah po svetu. SAP ERP je del programskega kompleta SAP Business suite (SAP AG, 2016). SAP ERP je programska oprema za načrtovanje virov podjetja. Podpira vse ključne poslovne procese in funkcije, ki jih današnja podjetja zahtevajo. Zajema poslovanje, finančne podatke in upravljanje s človeškimi viri, dopolnjeno s skupnimi podjetniškimi storitvami. Industrijsko specifične izboljšave se skladajo z zahtevami programske opreme specifične za industrijo panogo kot so avtomobilska industrija, zdravstveno varstvo, visokotehnološka podjetja, trgovine na drobno ali zavarovanja (Böder in Gröne, 2014). Microsoft Dynamics NAV je ERP-sistem korporacije Microsoft. Microsoft Dynamics NAV izvira iz ERP-sistema Navision. Zbirko računovodskih aplikacij, ki jih je Microsoft odkupil v letu 2002 (Microsof Dynamics NAV, 2016). Microsoft Dynamics NAV je ERP-aplikacija, ki se uporablja v vseh različnih organizacijah po vsem svetu. Zagotavlja veliko različnih funkcionalnosti out-of-thebox na raznih področjih, kot so računovodstvo, prodaja in nabava, logistika in proizvodnja. Hkrati omogoča podjetjem razvoj aplikacij z uporabo in prilagajanjem rešitev za izpolnjevanje posebnih zahtev (Lorente in Lorente, 2013). Oracle E-Business Suite (znan tudi kot Applications / Apps ali EB-Suite / EBS) je integrirana programska poslovna rešitev. Oracle ERP-sistem je del oziroma modul zbirke Oracle E-Business Suite. Oracle E-Business Suite je sestavljen iz zbirke Enterprise Resource Planning (ERP), modulov za upravljanje odnosov s strankami (CRM) in upravljanje dobavne verige (SCM) računalniških aplikacij, razvite s strani Oracle korporacije ali pridobljenih s strani Oracle korporacije. Programska oprema uporablja jedro Oracle relacijski sistem za upravljanje podatkovnih baz s tehnologijo Oracle (Yang, 2010). Gregor Povhe: Obdelava in priprava podatkovne kocke OLAP stran 6

12 Vsi opisani ERP sistemi omogočajo izvoz podatkov, ki smo jih prejeli in kasneje z različnimi orodji obdelali, da smo dobili željeno obliko podatkov. Zaradi različnih virov podatkov, podatkovnih baz, struktur v podatkih, nepravilnih zapisov, različnih tipov in ostalih različnih napak prihaja do težav v kakovosti podatkov. Slaba kvaliteta podatkov se lahko pojavi pri podatkih iz enega samega vira ali pri podatkih iz več neenakih virov, ki so odvisni drug od drugega in jih je potrebno združiti. Oba problema ločimo na težavo iz enega vira ali težavo iz več virov, rešita pa se lahko s pomočjo čiščenja podatkov (Rahm in Hai, 2000). Več kot je virov, večja je verjetnost, da bodo podatki slabše kakovosti. V Sliki 2 imamo prikaz klasifikacije težav po podatkovnih virih. Slika 2: Klasifikacije težav v kvaliteti podatkov iz različnih virov (Rahm in Hai, 2000) Težava podatkov iz enega vira Pridobivanja podatkov iz samo enega vira nam lahko predstavlja več različnih težav. 1. Težava pri shemi ali opisu baze nastane zaradi pomanjkanja omejitev podatkovnih tipov in integritete omejitve atributov. Običajno se te težave pojavijo, ko baza podatkov ni pravilno zasnovana. Težava na shematskem nivoju se odraža tudi na nivoju atributov. Primeri: Neveljavne vrednosti vrednosti so izven definiranega območja vrednosti. Kršitev unitarnosti podvajanje unikatnih polj. Referenčna integriteta referenčno polje ni definirano. Kršenje odvisnosti atributov atributi, ki so odvisni, se ne ujemajo, na primer mesto se ne ujema z njegovo poštno številko. Gregor Povhe: Obdelava in priprava podatkovne kocke OLAP stran 7

13 2. Težava pri atributih kot so napake, nedoslednosti in nepravilnosti v dejanski vsebini vsakega zapisa, niso opazni na ravni sheme. Napake, ki se pojavljajo na ravni atributov, obsegajo širši spekter nedoslednosti, ki ne odražajo strukturo podatkovne zbirke, vendar so podatki v navzkrižju. Primeri: Pravopisne napake tipkarske napake ali fonetične napake. Manjkajoče vrednosti nedostopne vrednosti med vnosom podatkov. Vgrajene vrednosti več vrednosti je vnesenih v en atribut. Vrednosti v napačnih poljih atribut je zapisan v napačen stolpec. Kršenje odvisnosti atributov atributi, ki so odvisni, se ne ujemajo, na primer mesto se ne ujema z njegovo poštno številko. Podvojene vrednosti vrednost je podvojena. Kontradiktorne vrednosti isti atribut ima različne vrednosti. Težava podatkov iz več virov Ko je potrebno združiti več virov podatkov v eno podatkovno bazo, se poveča potreba po čiščenju podatkov, ker različni viri pogosto vsebujejo enake podatke, ki se večkrat pojavijo, ali se med seboj prekrivajo ali nasprotujejo. Ko so istočasno prisotne težave od shem in od atributov, pomeni, da niso težave samo pri nekaterih zapisih, ampak da so težave tudi pri strukturi baze zaradi težav s shemo podatkovne baze. Težave shem podatkovnih baz skoraj vedno povzročajo težave atributov. V kolikor se pojavita obe težavi, vplivata na ustreznost strukture baze podatkov in ustvarjata netočnosti. To pomeni tudi, da so nepravilnosti atributov povzročene ne zaradi shem, ampak zaradi napak pri vnosu (Rahm in Hai, 2000) METODE DELA ZA PRIPRAVO PODATKOV V OLAP KOCKO Za uspešen uvoz podatkov smo morali podatke obdelati in pripraviti za obliko, primerno za uvoz v podatkovno skladišče, iz katerega smo kasneje izdelali OLAPkocko za analizo podatkov. Podatke, primerne za uvoz, smo definirali s pomočjo specifikacij. Ker iz različnih ERP-sistemov ali ročnih izvozov in napačnih interpretacij specifikacij nismo dobili željene oblike, smo morali podatke preveriti in obdelati. Prejeti podatki so bili različnih tipov:.txt,.csv in Excel-datoteke. Imeli smo različna kodiranja ali kodne tabele tekstovnih datotek, ki so bile: UTF-8, Ansi in Unicode. V datotekah so bile prisotne prazne vrstice med podatki, na koncu ali na začetku datotek. Med preverjanjem smo pregledali še podvojene vrednosti in ostale anomalije, ki se lahko pojavijo pri izvažanju podatkov. Poleg.txt-datotek smo prejeli tudi Excelova poročila, ki so bila na enem listu in neprimerna za uvoz v bazo. S čiščenjem podatkov ali procesom Data Cleansing smo se znebili napak med podatki. S predelavo datotek smo naredili vse podatke primerne za uvoz. Gregor Povhe: Obdelava in priprava podatkovne kocke OLAP stran 8

14 Čiščenje podatkov, po angleško Data Cleansing ali Data Scrubbing, je postopek, ki odkriva in odpravlja napake in nedoslednosti iz podatkov, da se izboljša njihova kvaliteta. Težave s kakovostjo podatkov so prisotne v zbirki podatkov, kot so datoteke in podatkovne baze, na primer zaradi napačnega črkovanja med vnosom podatkov, manjkajočih podatkov ali drugih neveljavnosti v podatkih. V primeru združevanja iz več virov podatkov, ki se vključujejo v podatkovno skladišče, je potreba po čiščenju podatkov še večja (Rahm in Hai, 2000). Za obdelavo ali čiščenje podatkov smo med drugim uporabili orodja: MS Excel, MS Access, Notepad++, OpenRefine, Data Wrangler. Z izbranimi orodji smo odpravili napake, ki smo jih zaznali, in predelane ali preverjene podatke uvozili v podatkovno skladišče. Na voljo je še mnogo različnih orodij specializiranih za čiščenje podatkov, ki imajo svoje posebnosti, in so specializirana za odpravo določenih anomalij med podatki. Nekatera orodja za čiščenje podatkov so: Datacleaner, Winpure, Talend, Datapreparator. Z vsemi temi orodji se lahko obdelujejo podatki. Prejeli smo izvožene podatke iz različnih sistemov, zato smo morali obdelati izvožene datoteke. Obstajajo tudi orodja za čiščenje podatkov v ERP-sistemih in s temi orodji se lahko podatki prečistijo v samem ERP-sistemu. Med bolj pogostimi napakami v ERPsistemih je podvajanje zapisov, ko na primer več uporabnikov v sistem večkrat vnese istega kupca z drugačnim poimenovanjem. S temi orodji zelo učinkovito odpravimo omenjene napake ORACLE PODATKOVNO SKLADIŠČE Prejete podatke smo uvozili v podatkovno skladišče podatkov. V našem primeru v Oracle Data Warehouse. Podatkovno skladišče je vsebinsko organizirana, integrirana, časovno odvisna in nespremenljiva zbirka podatkov za namene podpore odločitvenim procesom (Oracle, 2016). Oracle podatkovno skladišče je relacijska baza, zgrajena za poizvedbe in ne za transakcijsko tekočega procesiranja. Običajno vsebuje zgodovinske podatke, pridobljene iz transakcijskih podatkov, vendar lahko vsebuje tudi podatke iz različnih virov. Podatkovno skladišče za analize je ločeno od transakcijskega tekočega obdelovanja podatkov in omogoča organizaciji zbiranje podatkov iz ločenih virov. Takšen sistem omogoča: ohranjanje zgodovinskih podatkov, analiziranje podatkov za pridobivanje boljšega razumevanja poslovanja podjetja in njegovo izboljšanje. Poleg relacijske baze lahko podatkovno skladišče vsebuje ETL-rešitev, statistične rešitve, poročanje, rešitve za rudarjenje podatkov, uporabniška orodja za analizo in ostale aplikacije, ki vodijo proces zbiranja podatkov in transformiranje podatkov v uporabne podatke in jih dostavlja končnim poslovnim uporabnikom (Oracle, 1996). Podatke, ki smo jih prejeli in obdelali, smo uvozili v Oracle podatkovno skladišče. Gregor Povhe: Obdelava in priprava podatkovne kocke OLAP stran 9

15 Glavne tabele oziroma tabela dimenzij in tabela dejstev v podatkovnem skladišču so bile organizirane v obliki zvezdne sheme. Podatkovna skladišča omogočajo različno organizirane oblike ali sheme, kot je zvezdna shema, obratna zvezdna shema, snežna shema, zvezdna snežna ali ploska shema. Zvezdna shema je logična struktura, ki vsebuje v središču tabelo z dejstvi in je obkrožena z dimenzijskimi tabelami z referenčnimi podatki, ki so lahko de normalizirani. Za naš primer je bila najbolj primerna shema v obliki zvezde, kot jo prikazuje Slika 3. Slika 3: Zvezdna shema v podatkovnem skladišču Tabela dejstev v zvezdni shemi vsebuje podatke, dejstva. Tabela ima ponavadi dva tipa stolpcev: stolpec, kjer so dejstva, in stolpec, kjer so vsi tuji ključi iz tabele dimenzij. Primarni ključ v tabeli dejstev je običajno sestavljen iz tujih ključev. Vse naravne primarne ključe se nadomesti s surogati umetnimi ključi, kjer vsak stik med tabelo dejstev in dimenzijsko tabelo temelji na surogatih. Tabela dejstev lahko vsebuje točna ali agregirana dejstva. Tabele dejstev z agregirani podatki se večinoma imenujejo zbirne tabele dejstev ali materializiran pogled (angl. Materialized View). Iz podatkovnega skladišča smo iz teh podatkov izdelali Oracle OLAP-kocko z orodjem Oracle Warehouse Builder (OWB) ORACLE OLAP-KOCKA OLAP (angl. Online Analytical Processing) ali analitična obdelava podatkov s povezavo je tehnologija zbirk podatkov, ki je bila prilagojena za poizvedovanje in poročanje in ne za obdelavo transakcij. Izvorni podatki za OLAP so zbirke podatkov OLTP (transakcijska obdelava podatkov s povezavo), ki so običajno shranjene v skladiščih podatkov. Podatki OLAP so izpeljani iz podatkov iz preteklosti ter združeni v strukture, ki omogočajo zapletene analize. Podatki OLAP so urejeni hierarhično in Gregor Povhe: Obdelava in priprava podatkovne kocke OLAP stran 10

16 shranjeni v kocke ter ne v tabelah. Gre za izpopolnjeno tehnologijo, ki uporablja večdimenzijske strukture in tako omogoča hiter dostop do podatkov za analizo (Learn about Online Analytical Processing (OLAP), 2016). Kocka OLAP je način shranjevanja podatkov v večdimenzionalni obliki, na splošno za namene poročanja. V OLAP-kocki so podatki razvrščeni po dimenzijah, kot kaže Slika 4. OLAP-kocke so pogosto vnaprej agregirane vrednosti po dimenzijah, ki pripomorejo k občutnemu izboljšanju časa za poizvedbe preko relacijskih podatkovnih baz. Uporabljen jezik za poizvedbe ali za interakcijo in opravljane s kockami OLAP je večdimenzionalni jezik (MDX). Jezik MDX je Microsoft prvotno razvil v poznih 1990-ih in sprejeli so ga tudi drugi prodajalci večdimenzionalnih baz podatkov. Kocka je zato, ker je struktura podatkov, ki združuje mere v ravneh in hierarhijah vsake od dimenzij, ki jo hočete analizirati, podobna obliki kocke. Kocke združujejo več dimenzij, na primer čas, kupce in različne izdelke s povzetimi podatki, na primer količinska prodaja ali vrednostna prodaja, kot jo prikazuje Slika 4 (Nanda, 2015). Slika 4: Dimenzije v OLAP kocki (Nanda, 2015) Oracle OLAP omogoča večdimenzionalno shranjevanje in izredno hitre odzivne čase pri analiziranju podatkov preko različnih dimenzij. Podatkovna baza nudi bogato podporo za analitiko časovnih kalkulacij, napovedovanje, napredno združevanje z dodatnimi in brez dodatnih in lokacijskih operatorjev. Te sposobnosti uvrščajo in spreminjajo Oracle podatkovno bazo v popolno analitično platformo, ki podpira celoten spekter poslovne inteligence in napredno analitično aplikacijo (Oracle, 2012). Zbirke podatkov OLAP vsebujejo dve osnovni vrsti podatkov: mere, ki so numerični podatki, količine in povprečne vrednosti, ki jih uporabljamo za sprejemanje utemeljenih poslovnih odločitev, ter dimenzije, ki so kategorije, ki jih uporabljamo za Gregor Povhe: Obdelava in priprava podatkovne kocke OLAP stran 11

17 organiziranje teh mer. Zbirke podatkov OLAP nam pomagajo organizirati podatke na več ravneh podrobnosti in uporabljajo poznane kategorije za analiziranje podatkov (Learn about Online Analytical Processing (OLAP), 2016). Kot je navedeno v (Learn about Online Analytical Processing (OLAP), 2016) so komponente znotraj OLAP-kocke: Dimenzija je nabor nekaj organiziranih hierarhij ravni v kocki, ki jih uporabnik razume in uporablja kot osnovo za analizo podatkov. Geografska dimenzija lahko vsebuje ravni za države, regije, mesta in občine. Dimenzija časa lahko vključuje hierarhijo z ravnmi za leto, četrtletje, mesec in tedne. Vse dimenzije lahko umetno spremenimo, da ustrezajo našim zahtevam. Na primer mesta lahko združimo v svojo regijo ali časovno dimenzijo naredimo iz več mesecev ali tednov. V OLAP-poročilih postane vsaka hierarhija nabor polj, ki jih lahko razširimo ali skrčimo, in s tem prikažemo nižje ali višje ravni dimenzije. Hierarhija je logična struktura drevesa, ki organizira člane dimenzije, da ima vsak član nadrejenega člana in nič ali več podrejenih članov. Podrejeni član je naslednji član v naslednji podrejeni ravni hierarhije, ki je neposredno soroden trenutnemu članu. V hierarhiji Čas, ki vsebuje ravni Leto, Četrtletje, in Mesec, je na primer januar podrejeni član Četrtletju1. Nadrejeni član je član v naslednji višji ravni hierarhije, ki je neposredno soroden trenutnemu članu. Nadrejena vrednost je običajno uskladitev vrednosti vseh njegovih podrejenih članov. V hierarhiji Čas, ki vsebuje ravni Leto, Četrtletje, in Mesec ter Teden, je na primer Četrtletje1 nadrejeni član januarja, ali pa mesec nadrejeni član tedna. Mera je niz vrednosti v kocki, ki temeljijo na stolpcu v tabeli dejstev kocke in so običajno številčne vrednosti. Mere so osrednje vrednosti v kocki, ki so predhodno obdelane, zbrane ali agregirane in analizirane. V našem primeru sta to količinska prodaja in vrednostna prodaja. Član je element v hierarhiji, ki predstavlja eno ali več pojavitev podatkov. Član je lahko enoličen ali neenoličen in 2016 na primer predstavljata enolična člana na ravni let dimenzije časa, januar pa predstavlja neenolične člane na ravni mesecev, saj se lahko mesec januar pojavi večkrat, če dimenzija vsebuje podatke za več let), če dimenzija vsebuje podatke za več kot eno leto. Izračunani član je član dimenzije, katerega vrednost se izračuna ob času zagona z izrazom. Vrednosti izračunanih članov so lahko izvedene iz vrednosti drugih članov. Izračunani član Cena izdelka določi na primer z deljenjem vrednosti člana Prodaja z vrednostjo člana Količina. Raven - znotraj hierarhije so podatki lahko organizirani v nižje in višje ravni podrobnosti, na primer ravni Leto, Četrtletje, Mesec in Teden v hierarhiji Čas. V našem primeru je bila kocka iz treh dimenzij. Uporabili smo Čas ali angleško»time«, Izdelek ali angleško»product«in Kupec ali angleško»customer«. Meri sta bili Količina in Prodaja, shranjeni v tabeli dejstev. Gregor Povhe: Obdelava in priprava podatkovne kocke OLAP stran 12

18 2.7. ETL-PROCES Proces pridobivanja podatkov iz podatkovnih virov in nalaganje podatkov v podatkovno skladišče imenujemo ETL-proces: Angleško Extract je pridobivanje podatkov iz različnih virov podatkov, kot so: operacijski sistemi, ERP-sistemi, CRM-sistemi (angl. Customer Relationship Management), ploske datoteke (angl. Flat Files). Angleško Transform je preoblikovanje podatkov v pravilen format primeren za uvoz. Angleško Load je nalaganje, importiranje ali uvažanje podatkov v baze ali podatkovna skladišča. ETL-sistem je osnova za podatkovna skladišča. Pravilno zasnovan ETL-sistem izvaža podatke, izboljšuje kakovost podatkov in doslednosti standardov, usklajuje podatke, da se lahko ločeni viri podatkov med seboj združujejo in na koncu dostavi podatke v primernem formatu, da lahko aplikacijski razvijalci izdelajo aplikacijo za končnega uporabnika (Kimball in Caserta, 2004). ETL-sistem močno pripomore h kakovosti podatkov in je veliko več kot samo izvoz podatkov iz sistemov v podatkovno skladišče. Kot navajata Kimball in Caserta (2004) je specifično za ETL-sistem, da: odstrani napake in popravi manjkajoče podatke, zagotavlja dokumentirane ukrepe za zaupanje v podatke, zajame tok transakcijskih podatkov za shranjevanje, prilagaja podatke iz različnih virov, da se lahko uporabljajo skupaj, strukturira podatke, da so uporabni za BI-orodja za končnega uporabnika. ETL-proces je potrebno učinkovito integrirati v sisteme, ki imajo različne (Kimball in Caserta, 2004): sisteme za upravljanje s podatkovnimi bazami, operacijske sisteme, strojno opremo, komunikacijske protokole. Nekaj bolj znanih komercialnih orodij za ETL-proces so Ab Initio, IBM InfoSphere DataStage, Informatica PowerCenter, Oracle Data Integrator, Microsoft Dynamics AX Transition tool, SQL server integration Sevices in SAP Data Integrator. Obstajajo tudi odprtokodni programi za ETL-proces: Apatar, CloverETL, Pentaho Data Integration, Talend. Na trgu je veliko različnih ETL-orodij, ki so prilagojeni posameznim ERP-sistemom, kot je navedeno na ETL (Extract-Transform-Load) Data Integration Info (2016). Prvi del procesnega toka podatkov do končnega kreiranja OLAP-kocke je izvažanje podatkov. Ker podatke izvažamo iz različnih sistemov, je zelo pomemben del procesa, da dobimo pravilno izvožene podatke. Pravilno izvoženi podatki so bistveni za celoten del procesa, sicer lahko na koncu dobimo napačne podatke za analize. Gregor Povhe: Obdelava in priprava podatkovne kocke OLAP stran 13

19 Vsak podatkovni vir ima svoje značilnosti, ki jih je potrebno obvladati oziroma upravljati za učinkovit izvoz podatkov v ETL-procesu (Kimball in Caserta, 2004). Pridobivanje podatkov iz različnih, med seboj neskladnih virov podatkov na pravilen način, je pogosto najbolj zahteven del ETL-procesa, s katerim se soočimo v celem ETL-procesu. Na splošno je cilj pridobivanja podatkov preoblikovati podatke primerne za naslednji del procesa, ki ga imenujemo preoblikovanje. Vsak sistem lahko uporablja različno strukturo podatkov. Običajni viri podatkov so relacijske baze, ploske datoteke, ne-relacijski modeli baz in ostalih podatkovnih struktur. Lahko so tudi podatki pridobljeni s spletnim luščenjem. Večinoma so podatki iz izvornih sistemov zelo kompleksni, zato je izvozni del procesa zelo zapleten in težaven in zamuden (Kakish in Kraft, 2012). Naslednji del ETL-procesa je preoblikovanje podatkov. Preoblikovanje podatkov je prav tako bistven pomemben del procesa, saj se znebimo anomalij in nepravilnosti v podatkih. Podatke nato preoblikujemo v obliko, ki je primerna za uvoz v podatkovno skladišče. Nekatere podatke ni potrebno preoblikovati in jih lahko neposredno uvozimo v podatkovno skladišče. Takim podatkom pravimo Rich Data ali Direct Move ali Pass Through podatki. Preoblikovanje podatkov je običajno sestavljeno iz več različnih korakov, kjer vsak korak lahko izvaja shemo transformacije, ki so med seboj povezane z naslednjimi stopnjami (preslikavami). Za zmanjšanje količine transformacij in omogočanje preoblikovanja podatkov je potrebno definirati transformacije in jih napisati v primernem jeziku. Različna ETL-orodja omogočajo transformiranje podatkov v programskih jezikih lastniškega sistema (Rahm in Hai, 2000). Podatke lahko transformiramo že pred izvozom ali pridobljene podatke kasneje preoblikujemo z različnimi koraki transformacij in validacijo: 1. Preverjanje podatkov (angl. Data Validation) je proces, ki zagotavlja, da program deluje na podlagi čistih, pravilnih in uporabnih podatkih. 2. Združevanje podatkov (angl. Data Aggregation) je proces zbiranja informacij iz podatkovnih baz z namenom, da se pripravi kombinirane podatkovne nize za obdelavo podatkov. 3. Čiščenje podatkov (angl. Data Cleansing ali Data Scrubbing) je proces odkrivanja in popravljanja ali odstranjevanje pokvarjenih ali netočnih zapisov v setih podatkov, datotekah ali bazah. 4. Preoblikovanje ali transformiranje podatkov (angl. Data Transforming) je proces preoblikovanja setov podatkov iz pridobljenih podatkov do končnih podatkov v podatkovnem sistemu PREVERJANJE PODATKOV Preverjanje podatkov (angl. Data Validation) je ocenjevanje podatkov za njihov namen z uporabo vrednotenja metod, po katerih so podatki prišli, in primerjanjem teh vrednosti z neodvisnimi pridobljenimi ocenami, ki so znani ali so najboljši približke le-teh. Uporabnik podatkov s to oceno zagotovi, da podatki izpolnjujejo Gregor Povhe: Obdelava in priprava podatkovne kocke OLAP stran 14

20 navedena merila za veljavnost iz predpostavke, da so podatki skladni z zahtevo o potrebi po določenih podatkih (Rothenberg, 1997). Proces validacije obsega dva različna koraka: 1. proces validacije, kjer se popravljajo podatki, 2. proces odločanja po validaciji, kjer se kvalificirana oseba odloči ali so podatki pravilni. Namen popravljanja je zagotovitev, da je vsak podatek točen in pravilen, da so podatki konsistentni ne glede nato, ali gre za uporabniški vnos ali avtomatiziran sistem. Implementiranje pravil validacije v sistem je lahko tudi preko uporabniškega vmesnika, aplikacijske kode ali z omejitvami vnosov v baze podatkov. Obstaja več načinov popravljanja podatkov, kot je opisano v MSDN: Data Validation (2015): Validacija tipov podatkov, kjer preverjamo tip podatkov. Na primer: ali je polje, ki je definirano kot številka, resnično številka in ali je v polju definirano kot e-poštni naslov pravilna oblika zapisa e-poštnega naslova. Obseg in omejitev vnosa, kjer preverjamo minimum in maksimum dovoljenega vnosa. Na primer: v zapisu, kjer je poštna številka, ne sme biti število večje od Koda za preverjanje, kjer podatke testiramo in na osnovi določenih operacij primerjamo podatke s pravili, ki veljajo za vnos podatkov. Ponavadi si pomagamo z lookup tabelo. Na primer: uporabnik je pravilno vnesel svoj e- poštni naslov, vendar se domena e-poštnega naslova ne ujema s podjetjem, v katerem uporabnik dela. Kompleksno strukturirano potrjevanje, kjer s kombinacijo različnih tipov validacije preverjamo podatke. Pomagamo si s pravili, ki veljajo v okolju, iz katerega pridobivamo podatke. Na primer: uporabnik ima domeno e- poštnega naslov drugačnega od podjetja, v katerem dela, ker je zunanji sodelavec. Za različne načine validacije obstaja več metod validacij: Dovoljeni znaki (angl. Allowed Character Checks) preverja ali so zapisani dovoljeni znaki. Vsote polj (angl. Batch Totals) se uporablja za preverjanje skupnega število polj za konsistentnost. Preverjanje števk (angl. Check Digits) je validacija, če so numerična polja v pravilnem zapisu. Preveri vsote (angl. Control Totals) je validacija za skupno vsoto polj konsistentnost. Preveri prisotnost (angl. Presenece Check) preverja, ali so vsa polja vnesena. Preverjanje unikatov (angl. Uniquness Check) preveri, ali so v datotekah unikatni zapisi, kjer so zahtevani. Gregor Povhe: Obdelava in priprava podatkovne kocke OLAP stran 15

21 Logično preverjanje (angl. Logic Check) preveri, ali so zapisi v poljih logični. Opisali smo nekaj metod, ki so bile uporabljene v našem primeru. Obstaja še veliko različnih metod validacij, ki jih uporabljamo ad hoc in so odvisne od posameznega primera obdelovanih podatkov ZDRUŽEVANJE ALI AGREGIRANJE PODATKOV Združevanje podatkov (angl. Data Aggregation) je vsak proces, kjer se zbirajo informacije iz podatkovnih baz z namenom, da se izražajo v obliki povzetka za nadaljnjo statistično obdelavo. Združevanje podatkov je eden ključnih elementov, ki se uporablja v podatkovnih bazah, še posebno pri poslovni inteligenci (angl. BI Businesss Inteligence), kot je ETL in OLAP ter analitika z metodo podatkovnega rudarjenja (angl. Data Mining) (Hameurlain, Liddle, Schewe in Zhou, 2011). Agregiranje vhodnih ali izhodnih podatkov lahko združuje različne primere istega primerka v enojni primer enega primerka z izračunom vsote, povprečja, minimuma ali maksimuma. Vsak posamezen nov primer z enojnim primerkom z njegovo vsoto, minimum ali maksimumom ohranja vrednost več različnih primerkov (Witten et al., 2011). Primer agregacije podatkov, ko združujemo več zapisov v enega, je, ko imamo za isto osebo v enem mesecu večdnevnih transakcij nakupa istega izdelka. V OLAPkocki je najmanjša časovna enota mesec in zato lahko zapise združimo v enega. S tem izgubimo nekaj detajlov, v našem primeru dnevne transakcije, vendar te niso bile za naše potrebe analize relevantni. Agregirani podatki bistveno izboljšajo hitrost in zmanjšajo količino podatkov v podatkovnem skladišču. Vnaprej izračunani in shranjeni povzetki podatkov ali agregacije, ki izboljšajo odzivne čase poizvedb, so shranjeni v tabeli dejstev (angl. Fact Table) TRANSFORMACIJA PODATKOV Transformacija podatkov (angl. Data Transforming) je postopek pretvarjanja podatkov iz ene oblike (datoteko zbirke podatkov, tekstovnih datotek, XMLdokumentov, Excel in ostalih formatov) v drugo. Ker se podatki pogosto nahajajo na različnih lokacijah in v različnih formatih v celotnem podjetju ali iz več različnih virov in več podjetij, je kritična integracija transformacije, da se zagotovi potrebno obliko podatkov za prenos podatkov iz ene aplikacije ali baze v drugo aplikacijo ali bazo. Postopek transformacije, kot je navedeno na strani (Oracle, 2010) delimo na dva dela: 1. Preslikava podatkov (angl. Data Mapping). Razporeditev elementov iz izvorne baze ali sistema proti končni bazi ali sistemu, da ujamemo vse transformacije, ki so izvršene. Je proces v podatkovnih skladiščih, kjer so različni izvorni seti podatkov povezani z vnaprej definirani metodami, ki Gregor Povhe: Obdelava in priprava podatkovne kocke OLAP stran 16

22 kategorizirajo podatke po specifični definiciji v podatkovnem skladišču. Proces preslikave določi, kateri podatki se prenesejo v nov sistem. Postopek nastane še težji, ko imamo relacije ena-proti-neskončno ali neskončno-protiena. Specifikacije preslikave podatkov so posebej dragocene pri: Migraciji podatkov med viri, kjer je vir podatkov prenešen v novo skladišče. Integraciji podatkov med viri, kjer je vir podatkov redno poslan v novo skladišče in si oba vira ne delita skupnega podatkovnega skladišča. Integracija se dogaja, kadar je potrebno (dnevno, tedensko, v realnem času). Postopka sta si podobna, razlikujeta se le v tem, da se po končani migraciji izvorni podatki ne vzdržujejo, medtem ko se pri integraciji vzdržujeta oba vira podatkov. Preslikava podatkov je zelo pomemben del pri integraciji podatkov v sistemu. Pravzaprav je prvi korak pri številnih zapletenih nalogah, povezanih z integracijo podatkov, ki vključujejo transformacijo podatkov med virom podatkov in končno bazo podatkov. 2. Generiranje kode (angl. Code Generation). Generiranje programa za transformiranje. Nastala specifikacija preslikanih podatkov se uporablja za izvajanje programa transformiranja na računalniku. Pogosto uporabljeni programski jeziki za generiranje kode so Pearl, AWK, XSLT, TXL, PL/SQL. Transformacije so PL/SQL-funkcije, procedure, paketi, ki omogočajo transformacijo podatkov. Transformacije se uporabljajo, ko se oblikujejo preslikave v procesnem toku, ki definira ETL-proces ČIŠČENJE PODATKOV Čiščenje podatkov (angl. Data Cleansing) je iterativen proces. Običajno je uporabnik soočen s setom podatkov, ki bi jih rad očistil, da bi podatki dosegli pričakovano raven kakovosti izbranih specifikacijah. Sam postopek čiščenja podatkov lahko potencialno predstavi ali naredi nove napake, da postanejo podatki slabše kvalitete. Zato je potrebno pred vsaki novim korakom čiščenja podatke ponovno preveriti kakovost podatkov in ponoviti ali nadaljevati s procesom čiščenja podatkov. Proces čiščenja podatkov lahko vsebuje odstranjevanje tipografskih napak ali preverjanja ali popravljanje vrednostni na osnovi že znanih entitet. Shematična predloga čiščenja podatkov ima 4 večje faze, kot je prikazano na Sliki 5. Gregor Povhe: Obdelava in priprava podatkovne kocke OLAP stran 17

23 Slika 5: Faze čiščenja podatkov (Sadiq, 2013) Sadiqu (2013) deli čiščenje podatkov v štiri faze, v katerih podatke: 1. Opredelimo in identificiramo: prvi korak je, da dobro definirano, kaj za nas predstavlja napako v podatkih. Medtem, ko so že obstoječe definicije tipov napak (manjkajoči, podvojeni, nekonsistentni) je pomembno, da identificiramo tudi tiste, ki so relevantne za naš primer. 2. Poiščemo in ovrednotimo: ko imamo definirane relevantne napake, moramo poiskati metodo, ki bo prečesala podatke, poiskala napake in jih označila. Ko so vse napake označene, lahko ovrednotimo njihovo razširjenost in definiramo kvaliteto podatkov. 3. Počistimo in popravimo: ni nujno, da se popravi ali očisti vse podatke. Nekatere napake so pomembnejše, da se popravijo, in nekatere napake nimajo nobenega vpliva za končno analizo. Ker je za vsako vrsto napak na voljo veliko metod čiščenja, se uporabnik odloči, katero metodo bo uporabil. 4. Zmerimo in preverimo: po čiščenju podatkov se preveri, ali so podatki dosegli pričakovan nivo in če so uporabni za končno analizo podatkov. Čiščenje podatkov se v določenih fazah prekriva s popravljanjem podatkov, zato so vse faze obdelave podatkov važne in se dopolnjujejo. S procesom čiščenja podatkov identificiramo in odstranimo napake v podatkih, ki jih zaznamo. Napake so lahko duplikati, nekonsistentni podatki, manjkajoči podatki in vse, kar zmanjšuje kvaliteto podatkov. Razlogov, da pride do napak v podatkih, je več: napačno črkovanje, manjkajoči atributi, napačni podatki, duplikati itd. Ko združujemo podatke v podatkovno skladišče iz več različnih sistemov in več različnih baz z različnimi formati ter odvečnimi podatki, se potreba po čiščenju podatkov še poveča. Podpora s čiščenjem podatkov se zato v podatkovnem skladišču še Gregor Povhe: Obdelava in priprava podatkovne kocke OLAP stran 18

24 potencira. Pri podatkovnih skladiščih, na osnovi katerih na koncu pride do procesa odločanja, je to še bolj bistveno Eden najpogosteje uporabljenih sistem za reševanje tega, je ETL-proces. Sam proces čiščenja se začne že pred transformiranjem in uvozom podatkov. Večina procesa čiščenja je narejeno ročno s pomočjo preprostih programov, ki jih je težko vzdrževati (Databases: Understanding Data Cleansing, 2015) UVAŽANJE PODATKOV Nalaganje podatkov (angl. Data Loading) je proces kopiranja in nalaganja oziroma importiranja, uvažanja podatkov ali setov podatkov iz izvorne datoteke, mape, aplikacije ali baze v bazo ali podatkovno skladišče ali aplikacijo. Po eksportiranju in nato transformiranju podatkov imamo podatke pripravljene za nalaganje v podatkovno bazo. Za uvažanje podatkov v podatkovno skladišče se naredijo specifikacije za uvoz podatkov. Za vnos podatkov v podatkovno skladišče poznamo tri različne načine nalaganja podatkov: Začetni uvoz - prvo nalaganje vseh podatkov v podatkovno skladišče. Inkrementalni uvoz po potrebi nalaganje samo tekočih sprememb v določenih obdobjih Popolnoma novi uvoz popolni izbris vsebine ene ali več tabel in nova naložitev podatkov v tabele. Ker je nalaganje podatkov lahko zelo zamudno opravilo, jih je potrebno izvajati premišljeno, ob pravem času. Med nalaganjem podatkov v tabele so le-te nedosegljive in jih medtem uporabniki ne morejo koristiti ali z njimi delati. Za večje količine nalaganja podatkov v podatkovna skladišča uporabljamo specialne programe, ki omogočajo hitre metode nalaganja. Za vse načine nalaganja podatkov moramo predhodno pripraviti datoteko podatkov, ki jo bomo naložili v bazo. Kot navaja Ponniah (2001), poznamo štiri načine nalaganja podatkov (Slika 6): Nalaganje (angl. Load) če ciljna tabela že obstaja in so v njej podatki, potem proces nalaganja podatkov izbriše vse obstoječe podatke in naloži podatke iz prihajajoče datoteke. Če je tabela pred nalaganjem prazna, potem proces enostavno napolni tabelo iz prihajajoče datoteke. Pripni (angl. Append) je pravzaprav podaljšek nalaganja. Če podatki v ciljni tabeli že obstajajo, potem način pripenjanja le doda prihajajoče podatke in obstoječe podatke ohrani nedotaknjene. Če so podatki, ki se nalagajo že v ciljni tabeli in so zato podvojeni, lahko definiramo, kako bomo obravnavali podvajanje podatkov. Prva možnost je, da dovolimo podvajanje podatkov, druga možnost je, da se podvojeni podatki ignorirajo ali zavrnejo med postopkom nalaganja v ciljno tabelo. Gregor Povhe: Obdelava in priprava podatkovne kocke OLAP stran 19

25 Destruktivno združevanje (angl. Destructive Merge) v tem načinu pripnemo podatke v obstoječo tabelo. Če se prihajajoči primarni ključ ujema s ključem v obstoječi tabeli, se posodobi obstoječ zapis z novim zapisom. Če prihajajoči zapis še ni v obstoječi tabeli, se samo zapiše v tabelo. Konstruktivno združevanje (angl. Constructive Merge) ta način je malo drugačen od destruktivnega združevanja. Če primarni ključ prihajajočega zapisa obstaja v obstoječi tabeli, potem pusti obstoječi zapis in doda prihajajoči zapis ter označi dodan zapis kot nadomestni zapis starega zapisa. Slika 6: Razlike med nalaganjem podatkov v podatkovno skladišče (Ponniah, 2001) MANIPULACIJA ALI PRESTRUKTURIRANJE PODATKOV Manipulacija ali prestrukturiranje podatkov (angl. Data Wrangling) je celoten proces manipuliranja z nestrukturiranimi ali neurejenimi podatki v strukturirano in čisto obliko. Gre za ohlapen proces, kjer ročno ali s pomočjo pol-avtomatskih orodij pretvarjamo ali preslikavamo podatke iz»surove«oblike v drugo strukturirano in čisto obliko primerno za nadaljnjo obdelavo. Postopek prestrukturiranja se z določenimi deli procesa prepleta s postopki čiščenja, preverjanja in transformiranja podatkov. Z omenjenim procesom, ki je tudi zelo zamuden, prestrukturiramo surove podatke in jih pripravimo za nadaljnji proces, ki sega vse do analize podatkov. Pravilno strukturirani podatki pripomorejo k natančnejši analizi (Trifacta, 2016). Podatke, pridobljene iz različnih sistemov, ne dobimo vedno strukturirane v obliki (Excel, pdf, razni generični izvozi), ki jo želimo ali jo potrebujemo za nadaljnjo Gregor Povhe: Obdelava in priprava podatkovne kocke OLAP stran 20

26 obdelavo. Z manipulacijo ali prestrukturiranjem podatkov podatke prestrukturiramo v obliko, ki je primerna za uvoz in nadaljnjo obdelavo PROFILIRANJE PODATKOV Profiliranje podatkov (angl. Data Profiling) je sistematična analiza podatkov, ki opiše njihovo vsebino, konsistentnost in strukturo. Profiliranje podatkov ima strateško in taktično nalogo. Na začetku vsakega projekta podatkovnega skladišča, takoj ko podatki prispejo, se mora narediti hitra ocena, ki pomaga pri odločitvi, ali se nadaljuje s projektom ali se projekt ustavi. Kasnejše spoznanje, da podatki ne ustrezajo projektu, je lahko usodno za celoten projekt. Profiliranje je stalen proces raziskovanja. V procesu podatkovnega skladišča je idealno mesto za odkrivanje podatkovnih napak na začetku pri viru (Kimball in Caserta, 2004). Z dobro analizo profiliranja podatkov pridobimo opise skladišča specifičnih metapodatkov: opredelitve shem, poslovne objekte, domene, vire podatkov, definicije tabel, sopomenke, pravila podatkov, pravila vrednosti. Kot je navedeno v Kimball in Caserta (2004), s tem profiliranjem podatkov pridobimo kvantitativno oceno originalnih virov podatkov PLEMENITENJE PODATKOV Plemenitenje podatkov (angl. Data Augmentation) je proces, ki doda vrednost obstoječim podatkom (šifrantom, dimenzijam ali atributom) z uporabo internih ali eksternih virov. Proces se lahko implicira na več različnih oblikah podatkov. Plemenitenje podatkov doda dodatno vrednost, na primer: kupcem dodamo koordinate k naslovu, izdelkom dodamo dodatne atribute, kot je proizvajalec, vzorcem prodaje dodamo demografske podatke. S tem dobimo poglobljen vpogled v podatke in dodatne analize. Prav tako pripomore k zmanjšanju ročnih posegov v posredovanje pomembnih informacij in močno poveča kvaliteto podatkov. Kot je navedeno na strani Techopedia (2016), so pogoste tehnike za plemenitenje podatkov: Ekstrapolacija temelji na hevristiki. Ustrezna polja so posodobljena ali pa so dodane vrednosti. Označevanje pogosti zapisi so označeni in združeni ter jih je lažje razumeti in ločiti od ostalih zapisov. Gregor Povhe: Obdelava in priprava podatkovne kocke OLAP stran 21

27 Agregiranje s pomočjo matematičnih vrednosti so izračunane določene vrednost za ustrezna polja, če so potrebna. Verjetnost tehnika - glede na hevristiko in analitično statistiko so vrednosti izpolnjene na podlagi verjetnostnih dogodkov PREVERJANJE KAKOVOSTI PODATKOV Cilj preverjanja kakovosti podatkov (angl. Data Quality Asesment) je določanje kvalitete podatkov za poslovne ali druge namene, za katere bomo podatke uporabljali. Ocena kakovosti nam pomaga pri odločitvah, ali bodo uporabljeni podatki opravičili čas in uporabljene vire z odločitvami, ki jih bodo podatki k tem analizam prinesli. Pove nam tudi, ali so analize ali odločitve iz podatkov, ki jih uporabljamo, pravilne. Ocene kakovosti podatkov se je potrebno lotiti z metodološkim pristopom. Kvalitativne mere in standarde je potrebno postaviti učinkovito, da jih lahko apliciramo vsak trenutek procesa. S tem postane primarna zahteva ocena kakovosti podatkov na začetku ali na koncu procesa. Kot je navedeno v Meersman, Tari in Herrero (2008), obstajajo metodologije za uporabo ocene kakovosti, s katerimi lahko poskusimo določiti kvaliteto. Ta merila so: Točnost (angl. Accuracy) stopnja sporazuma med sklopom podatkovnih vrednosti in ustreznih pravilnih vrednosti ali so podatki pravilni. Popolnost (angl. Completness) stopnja, kjer so vrednosti prisotne in med atributi, ki jih potrebujejo ali so podatki popolni. Doslednost (angl. Consistency) sporazum ali logična skladnost v skladu z dejstvi brez variacij ali kontradiktornosti. Točnost (angl. Precision) kvaliteta ali stanje točnosti v mejah definiranih ciljev. Zanesljivost (angl. Reliability) sporazum o zanesljivosti ali logična usklajenost, ki omogoča racionalno povezavo v primerjavi z drugimi podobnimi podatki. Začasna zanesljivost (angl. Temporal Reliability) pomen in semantika, ki se lahko spremenita s časom. Pravočasnost podatkov (angl. Timeliness Data) - elementi ali več elementov, ki so na voljo v času, ko so potrebni ali določeni. Unikatnost (angl. Uniqueness) vrednosti podatkov, ki so omejene z nizom unikatnih lastnosti vsaka vrednost je edina svoje vrste. Veljavnost (angl. Validity) skladnost vrednosti podatkov, da so sprejemljiva zmanjšanje verjetnosti napak. Enotne metodologije za določanje kakovosti podatkov ni. Z različnimi pristopi ali metodologijami določimo mero kakovosti. Gregor Povhe: Obdelava in priprava podatkovne kocke OLAP stran 22

28 Pri merjenju kvalitete podatkov si lahko pomagamo tudi s poročili oziroma poizvedbami. Na primer v poljih z diskretnimi podatki lahko izpišemo distribucije frekventnosti posameznih vrednosti in ročno pregledamo tiste, ki najbolj izstopajo. Pri datumih si lahko pomagamo z minimalnimi in maksimalnimi vrednostmi ter ponovno ročno pregledamo ali označimo tiste, ki so sumljivi (Ferle, 2013) PODATKOVNO RUDARJENJE Podatkovno rudarjenje (angl. Data Mining) je izvoz implicitnih, prej neznanih in potencialno uporabnih informacij iz podatkov (Witten et al., 2011). Z metodami podatkovnega rudarjenja samodejno iščemo po velikih količinah podatkov ter iščemo vzorce in trende, ki jih ne najdemo s preprosto analizo. Rudarjenje podatkov uporablja sofisticirane matematične algoritme za segmentiranje podatkov in ocenjuje verjetnosti bodočih dogodkov. Glavne naloge podatkovnega rudarjenja so, kot je navedeno v Oracle (2008): Avtomatično odkrivanje vzorcev (angl. Automatic Discovery) podatkovno rudarjenje je doseženo z izgradnjo modelov. Model uporablja algoritem, ki deluje na setu podatkov. Pojem avtomatskega odkrivanja vzorcev se nanaša na izvedbo modelov v podatkovnem rudarjenju. Predvidevanje najbolj verjetnih rezultatov (angl. Prediction) Veliko oblik podatkovnega rudarjenja je predvidljivih. Predvidevanja imajo določeno verjetnost, iz katerih lahko naredimo pravila, ki so pogoj za določanje rezultata. Kreiranje koristnih informacij (angl. Actionable Information) S podatkovnim rudarjenjem lahko izluščimo in kreiramo koristne informacije iz velikega obsega podatkov. Fokusiranje na velike sete podatkov (angl. Grouping) Oblika podatkovnega rudarjenja, kjer s pomočjo združevanja podatkov naredimo skupine podatkov, ki imajo enake lastnosti. Kot navajajo Fayyad, Piatetsky-Shapiro in Smyth (1996), podatkovno rudarjenje obsega več različnih tipov nalog ali metod, med drugim: Preverjanje anomalij (angl. Anomaly Detection) identificiranje nenavadnih zapisov, ki so potencialno zanimivi ali pa imajo potencialne napake, ki jih je potrebno dodatno preveriti. Asociacijsko učenje pravil (angl. Association Rule Learning Dependency Modelling) iskanje odnosov med spremenljivkami. Na primer: trgovina izbira podatke o potrošniških navadah. Z učenjem zveznih pravil se lahko naučijo, kateri so komplementarni izdelki in jih nato uporabijo v marketinške namene. Klasterska analiza (angl. Clustering) je naloga iskanja skupin in struktur v podatkih, ki so si med seboj podobni, brez uporabe znanih struktur v podatkih. Gregor Povhe: Obdelava in priprava podatkovne kocke OLAP stran 23

29 Klasifikacijska metoda (angl. Classification) je naloga iskanja splošne strukture, ki se jo implicira na nove podatke. Na primer: poštni odjemalec lahko klasificira elektronsko pošto kot nezaželeno ali kot legitimno. Regresijska metoda (angl. Regression) poskuša najti formulo, ki oblikuje podatke z najmanj napakami. Kreiranje povzetka (angl. Summarisation) zagotavlja bolj kompaktno prezentacijo sklopa podatkov na osnovi vizualizacije in generiranjem poročil. Podatkovno rudarjenje in statistika Obstaja velika korelacija med statistiko in podatkovnim rudarjenjem. Večina tehnik, uporabljenih za podatkovno rudarjenje, se uporablja v statističnem okviru nalog. Tehnike podatkovnega rudarjenja niso enake tradicionalnim tehnikam statistike. Tradicionalne statistične tehnike na splošno zahtevajo veliko interakcijo uporabnika, da se preveri pravilnost modela. Posledično je statistične metode težko avtomatizirati. Poleg tega statistične metode običajno ne ustrezajo velikim setom podatkov, bolj primerne so metode podatkovnega rudarjenja, saj se lažje implementirajo oziroma avtomatizirajo Običajno algoritmi podatkovnega rudarjenja zahtevajo velike sete podatkov. Podatkovno rudarjenja in OLAP OLAP lahko definiramo kot hitro analiziranje skupnih podatkov v več dimenzijah. OLAP in podatkovno rudarjenje sta drugačna, a se v določenih aktivnostih dopolnjujeta. OLAP podpira dejavnosti, kot so združevanje podatkov, razporejanje stroškov, časovne vrstne analize in Kaj-če-analize (angl. What-if). Večina OLAP-sistemov sicer nima induktivnega sklepanja, ki (bi presegal ali ker) presega podporo za časovno serijo napovedi. Induktivni proces splošnega sklepanja in zaključkov iz primerov je poseben (proces??? Kaj??) za podatkovno rudarjenje. Induktivno sklepanje je znano tudi kot računalniško učenje. OLAP-sistemi zagotavljajo večdimenzionalni pogled na podatke s popolno podporo hierarhij. Pogled na podatke je splošen način za analiziranje in organizacije. Podatkovno rudarjenje pa običajno nima koncepta pogleda na dimenzije in hierarhije. Podatkovno rudarjenje in OLAP lahko integriramo na več načinov. Podatkovno rudarjenje lahko uporabimo za kreiranje dimenzij v kocki, kreiranje novih vrednosti za dimenzije ali kocko. OLAP lahko uporabimo za analizo rezultatov podatkovnega rudarjenja na več ravneh. Rudarjenje podatkov lahko pomaga narediti bolj zanimive in uporabne kocke. Podatki pridobljeni iz predikativnega rudarjenja ali naše predvidevanje nam lahko pomagajo zgraditi nove mere. Taka mera bi lahko pomagala predvidevati, kaj bodo kupci kupili. Z OLAP-procesiranjem se lahko podatke agregira in kasneje povzame verjetnosti. Gregor Povhe: Obdelava in priprava podatkovne kocke OLAP stran 24

30 Podatkovno rudarjenja in podatkovna skladišča Podatkovno rudarjenje se lahko uporablja pri ploskih datotekah, preglednicah (angl. Spreadsheets), tabelah v bazah ali v kakšnih drugih oblikah. Bistven kriterij za podatke ni format, temveč uporabnost za rešitev problema. Učinkovito čiščenje podatkov in priprava podatkov sta zelo pomembni za podatkovno rudarjenje in podatkovno skladišče, da se olajša dejavnost podatkovnega rudarjenja. Podatkovno skladišče pa ne bo uporabno, če ne bo vsebovalo podatkov, ki bi rešili problem (Oracle, 2008). Obstaja zelo veliko orodij za podatkovno rudarjenje, ki so komercialna: Oracle Dataminig, PSeven, Microsoft Analysis Services, IBM SPSS Modeler. Odprto kodna programska oprema so: R, Weka, Knime, Torch, Orange. Gregor Povhe: Obdelava in priprava podatkovne kocke OLAP stran 25

31 3. PRIPRAVA BAZE PODATKOV Celoten proces, od prejema podatkov do izdelave OLAP-kocke, vsebuje več procesov. Prvi med njimi je ETL-proces. Obstaja več orodij, kjer se celoten ali samo del tega procesa implementira za izgradnjo podatkovnega skladišča. Postopki v tem procesu imajo enak cilj zagotoviti podatke, primerne za končnega uporabnika. Obstaja več načinov ali orodij in metod, kako priti do primernih podatkov. Za diplomsko nalogo smo večji del teh nalog opravili na način, ki poskuša po korakih povzeti vse postopke. Podatki, ki smo jih pridobili, so bili razdeljeni po sklopih pošiljateljev. Preden smo dobili želen izvoz, je bilo potrebno podatke preveriti, prečistiti in nato profilirati PREVERJANJE IN ČIŠČENJE PREJETIH PODATKOV Podatke, prejete v obliki tekstovnih datotek, smo uvozili v program Microsoft Access Uporabili smo specifikacije podatkov, ki smo jih zahtevali tako, da smo imeli enako število polj in tipov polja. Access omogoča uvoz različnih tipov podatkov: tekstovne datoteke (.txt,.csv), Excel (.xlsx,.xls), XML ali pa direktne povezave na podatkovne baze ali vire: ODBC, Access, Outlook mape, Sharepoint poročila. Program omogoča shranjevanje specifikacij uvoza (Slika 7), kar nam omogoča hitrejši večkratni uvoz enakih datotek. Za vsako datoteko smo naredili svojo specifikacijo in jo shranili, da smo jo lahko kasneje ponovno uporabili. Med specifikacijami določimo polja kot so: razdelilnik polja, tekstovni ločevalnik (angl. Text Qualifier), jezik, kodno tabelo, zapis datuma, decimalni simbol, tip in ime polja. Gregor Povhe: Obdelava in priprava podatkovne kocke OLAP stran 26

32 Slika 7: Specifikacije za uvoz podatkov Izbiramo lahko tudi med uvozom datoteke, kjer so polja razdeljena z razdelilniki, in med polji, ki imajo fiksno širino. S pomočjo polja Indeksiranja (polje»indexed«) v tabeli specifikacij določimo vsako polje, ki ga uvažamo, ali je lahko podvojeno ali ne. Po uspešnem uvozu vseh treh datotek v tabele smo začeli podatke preverjati. Preverjanje za dvojnike Za polja, ki smo jih označili, da ne smejo vsebovati dvojnikov, nam pri uvozu dvojnika program javi, da je zaradi kriterija, ki smo ga vnesli prišlo do podvajanja polj. Program ne izpiše, katera polja so podvojena, zato smo naredili SQL_poizvedbo: SELECT K_datoteka.kupec_code, K_datoteka.name, K_datoteka.city, K_datoteka.address, K_datoteka.zip_code FROM K_datoteka WHERE (((K_datoteka.kupec_code) In (SELECT [kupec_code] FROM [K_datoteka] As Tmp GROUP BY [kupec_code] HAVING Count(*)>1 ))) ORDER BY K_datoteka.kupec_code; Poizvedba nam izpiše vrstice, kjer so podvojene kode kupca. Preverjanje za tip podatkov Ko smo uvozili podatke s specifikacijami, ki smo jih definirali na začetku, nam program v primeru napačnih tipov podatkov samodejno javi, katera polja niso bila uspešno uvožena zaradi napačnega konvertiranja polja. Gregor Povhe: Obdelava in priprava podatkovne kocke OLAP stran 27

33 Preverjanje praznih polj (NULL) v datoteki izdelkov Med poizvedbami smo naredili SQL-stavek, ki je preveril, ali so vsa polja v tabeli zapolnjena: SELECT I_datoteka.izdelek_code, I_datoteka.kupec_code, I_datoteka.Date, I_datoteka.quantity, I_datoteka.sales FROM I_datoteka I_datoteka WHERE (((I_datoteka.izdelek_code) Is Null)) OR (((I_datoteka.kupec_code) Is Null)) OR (((I_datoteka.Date) Is Null)) OR (((I_datoteka.quantity) Is Null)) OR (((I_datoteka.sales) Is Null)); Vsa polja so morala biti polna, drugače smo dobili izpis vrstic(e), kjer manjkajo atributi. V primeru praznih polj smo prosili za nove datoteke, ali pa smo na osnovi že prejetih datotek poiskali in vnesli pravilen atribut in informacijo preverili pri viru podatkov. Enako smo naredili za tabeli Prodaje in Izdelkov. Preverjanje manjkajočih atributov Ker je tabela prodaje vsebovala kode Kupcev in kode Izdelkov, smo s SQL poizvedbo preverili, ali smo prejeli vse atribute med podatki: SQL za manjkajoče kupce: SELECT I_datoteka.* FROM I_datoteka LEFT JOIN K_datoteka ON I_datoteka.kupec_code = K_datoteka.kupec_code WHERE (((K_datoteka.kupec_code) Is Null)); SQL za manjkajoče izdelke: SELECT I_datoteka.* FROM I_datoteka LEFT JOIN P_file ON I_datoteka.izdelek_code = P_file.izdelek_code WHERE (((P_file.izdelek_code) Is Null)); V obeh primerih nam je poizvedba preverila polja v tabeli Prodaje in izpisala polja, ki so v tabeli izdelkov ali tabeli kupcev manjkala. Preverjanje obsega podatkov Zahtevali smo podatke za obdobje enega meseca. Na osnovi te informacije smo naredili SQL-poizvedbo, ki izpiše obseg datumov: TRANSFORM Sum(I_datoteka.quantity) AS SumKolicina SELECT I_datoteka.Date AS Expr1, Sum(I_datoteka.quantity) AS [Skupaj kolicina] FROM I_datoteka GROUP BY I_datoteka.Date PIVOT I_datoteka.DDV; S tem smo preverili, da prejeti podatki niso izven določenega obdobja in da so v pravilnem zapisu. Gregor Povhe: Obdelava in priprava podatkovne kocke OLAP stran 28

34 Preverjanje konsistentnosti podatkov Pridobili smo podatke za obdobje enega leta, zato smo lahko na podlagi mesečnih podatkov naredili povprečja vsot, seštevek števila vrstic ali število izdelkov in primerjali podatke po časovnih obdobjih. Uporabili smo SQL-poizvedbo: SELECT Count(I_datoteka.izdelek_code) AS SteviloIzdelkov_code, Sum(I_datoteka.quantity) AS VsotaKolicina, Sum(I_datoteka.sales) AS VsotaProdaja FROM I_datoteka; Poizvedba izpiše število različnih izdelkov, vsoto količine in vsoto prodaje. Te podatke smo izpisali v drugo tabelo, kjer smo jih primerjali z ostalimi mesečnimi povprečji in primerjali odstopanja. Kompleksno preverjanje podatkov S podatki v tabelah smo lahko preverjali logične zapise med podatki: S SQL-Distinct-poizvedbo smo naredili pregled vseh kupcev ali izdelkov in preverili doslednost. Preverili decimalne vrednosti v količinah. Preverili negativne vrednosti. Preverili vrednosti 0. Preveri/poiskali manjkajoče vrednosti. Za kompleksno preverjanje podatkov je potrebno poznavanje okolja oziroma njegova pravila in logično sklepanje, ali so podatki skladni, konsistentni ali dosledni. Pri datoteki kupcev in izdelkov smo lahko dobili v izvozu vse kupce ali vse izdelke, ali samo tiste kupce ali izdelke, ki so imeli prodajo v obdobju, ki ga ja zavzela datoteka transakcij prodaje. Vsak izvoz ima svoje prednosti in slabosti. Če smo dobili vse zapise, je iskanje atributov v datoteki kasneje lažje, ker vzamemo zadnjo datoteko, v kateri imamo zajete vse podatke. Slabost pa je, da je datoteka lahko velika in so neaktualni kupci ali izdelki lahko odveč in da datoteka ni posodobljena. Težava je lahko tudi, če se uporabi ista koda in pride do podvajanja. Če smo dobili samo izdelke ali kupce iz določenega obdobja, je bila datoteka manjša, vendar vsi kupci skozi zgodovino niso bili zajeti. Datoteka je vsebovala posodobljene vrednosti in verjetnost za podvajanje podatkov je bila manjša. Na trgu je veliko različnih orodij, s katerimi lahko preverjamo podatke. Večinoma so si takšni programi komplementarni in se prekrivajo pri opravljanju svojih nalog PROFILIRANJE PREJETIH PODATKOV Na osnovi rezultatov iz preverjanja in čiščenja ter kasneje transformacije in manipulacije podatkov, si ustvarjamo sliko podatkov. Glede na to sliko podatkov, se kasneje odločimo, če so podatki dovolj kvalitetni in uporabni za nadaljevanje projekta. Gregor Povhe: Obdelava in priprava podatkovne kocke OLAP stran 29

35 Z določenimi metodami lahko izberemo kvantitativne vrednosti, ki pomagajo pri odločitvi (Kimball in Caserta, 2004). Ko smo dobili podatke v želenem formatu z vsemi obveznimi polji, smo ponovno preverili podatke, ki so ustrezali kriterijem za izdelavo OLAP-kocke in nadaljnjo analizo podatkov. S tem profiliranjem prejetih podatkov smo preverili, ali podatki ustrezajo določenim vrednostim za izgradnjo OLAP-kocke TRANSFORMACIJA IN MANIPULACIJA ALI PRESTRUKTURIRANJE PODATKOV Vsi prejeti podatki niso bili v tekstovni obliki (.txt) in tudi struktura v datoteki je bila neuporabna za začetne uvoze v podatkovno skladišče. Takšne datoteke, na primer Excel-datoteke, smo s pomočjo programa Openrefine prestrukturirali, da je postala datoteka primerna za uvoz (Slika 8). Program omogoča veliko funkcij, med drugim tudi izbriše prazne vrstice, prerazporedi stolpce, iz enega stolpca naredi več stolpcev ali obratno. Slika 8: Transformacija podatkov s pomočjo programa Openrefine Ko smo dobili končno obliko, smo podatke izvozili v csv-format. Program Openrefine nam omogoča, da lahko shemo manipulacije ali prestrukturiranja shranimo kot projekt, kar pripomore pri prestrukturiranju več enakih datotek. Openrefine poleg manipuliranja polj omogoča še združevanje podatkov iz različnih virov, s tem lahko podatke oplemenitimo. Podatke lahko pridobimo preko internetnih virov s pomočjo programskega jezika GREL, Jython ali Clojure. Ob tem je potrebno biti previden, da se ne krši Evropska zakonodaja (Direktiva 96/9/ES Evropskega parlamenta in Sveta o pravnem varstvu baz podatkov, 1996). Za določene naloge transformacije in čiščenja podatkov smo si pomagali s programom Notepad++. Z njim smo lahko: Pretvorili kodiranje podatkov, odstranili prazne vrstice kjerkoli so bile v datoteki, odstranili vodilne in zaključne presledke, odstranili nepotrebne eol-ukaze, poiskali in odstranili nepotrebne prelome vrstic PODATKOVNO SKLADIŠČE Gregor Povhe: Obdelava in priprava podatkovne kocke OLAP stran 30

36 Podatkovno skladišče smo naredili v relacijsko-podatkovnem sistemu Oracle Database 11g Release 2. Podatkovno skladišče je relacijska baza, ki je narejena za poizvedbe in analize. Za povezavo dimenzij in tabele dejstev je bila uporabljena snežna shema. Najprej smo kreirali bazo z orodjem Oracle Warehouse Builder, v kateri smo z Data Object Editorjem kreirali vse tabele. Tabele, ki so bile izpolnjene s podatki, so bile: Product, Customers in Sales. Tabelam smo določili atribute, ki so bili enaki atributom v datotekah (specifikacijah za izvoz tabel), podatkovnemu tipu in definirali, če je polje obvezno. Atribute v tabeli Kupci prikazujejo Tabela 4. COLUMN_NAME DATA_TYPE NULLABLE COLUMN_ID Klient_ID NUMBER (5,0) No 1 Kupec_code VARCHAR2 (50 BYTE) No 2 Kupec_name VARCHAR2 (200 BYTE) No 3 country VARCHAR2 (40 BYTE) Yes 4 city VARCHAR2 (40 BYTE) No 5 address VARCHAR2 (200 BYTE) No 6 Zip VARCHAR2 (50 BYTE) No 7 VAT VARCHAR2 (50 BYTE) Yes 8 Tabela 4: Atributi v tabeli Kupci Tabela 5 prikazuje atribute v tabeli Izdelek. COLUMN_NAME DATA_TYPE NULLABLE COLUMN_ID Klient_ID NUMBER (5,0) No 1 Izdelek_code VARCHAR2 (50 BYTE) No 2 Izdelek_name VARCHAR2 (400 BYTE) No 3 EAN VARCHAR2 (200 BYTE) Yes 4 Izdelek_manufacturer VARCHAR2 (100 BYTE) No 5 Packaging NUMBER (9,6) Yes 6 DDV VARCHAR2 (50 BYTE) Yes 7 Tabela 5: Atributi v tabeli Izdelkov V Tabeli 6 imamo atribute, ki so uporabljeni v tabeli Prodaja. COLUMN_NAME DATA_TYPE NULLABLE COLUMN_ID Klient_ID NUMBER (5,0) No 1 Kupec_code VARCHAR2 (50 BYTE) No 2 Izdelek_code VARCHAR2 (50 BYTE) No 3 Tr_date DATE No 4 Quantity NUMBER(10,2) No 5 Sales NUMBER(15,2) No 6 Tabela 6: Atributi v tabeli Transakcij Gregor Povhe: Obdelava in priprava podatkovne kocke OLAP stran 31

37 Podatke smo združili s tabelo dejstev, ki je vsebovala primarne ključe od teh tabel in dejstva (Količina in Vrednost), ko smo imeli vse tabele, smo naredili še dimenzije: Product, Geography, Channel, Time. Podatkovno skladišče vsebuje dejstva o prodaji in vse podatke o prodaji izdelkov po času, kupcu, kanalu in regijah. S pomočjo OLAP-kocke smo za vsakega kupca vedeli, v katerem časovnem obdobju je prodal določen izdelek in v katero regijo ali kanal je bil prodan. Za vsak izdelek smo natančno vedeli, koliko je prodaje v določen kanal, ali koliko je bilo prodaje v določeno regijo itd. Vse kombinacije analiziranja podatkov nam omogočajo hiter vpogled v poslovanje ali analiziranje z OLAP-kocko NALAGANJE PODATKOV V PODATKOVNO SKLADIŠČE Vse pripravljene podatke smo uvozili v podatkovno skladišče s pomočjo SQL*Loader-programa. Z njim smo uvažali podatke v podatkovno skladišče s pomočjo kontrolno referenčnih datotek (angl. Control File Reference), ki smo jih izdelali. Referenčna kontrolna datoteka vsebuje DDL (angl. Data Definition Language) inštrukcije, ki upravljajo s sejami SQL*Loader-programa. S temi kontrolnimi datotekami povemo programu, katere podatke naj uvozi v določene tabele in stolpce, kakšno je kodiranje, razdelilnik polja itd. Primer kontrolno referenčne datoteke za uvoz datoteke kupcev v tabelo Kupci: options (skip=1) LOAD DATA CHARACTERSET UTF8 INFILE * "str '\r\n'" APPEND INTO TABLE KUPCI FIELDS TERMINATED BY ' ' OPTIONALLY ENCLOSED BY '"' TRAILING NULLCOLS ( DIST_ID EXPRESSION "LOADER_DIST_ID", DATA_SUPPLY_DATE EXPRESSION "LOADER_DATA_SUPPLY_DATE", INPUI_DATOTEKA_ID EXPRESSION "LOADER_INPUI_DATOTEKA_ID", PROCESS_TYPE EXPRESSION "LOADER_PROCESS_TYPE", SP_INPUI_DATOTEKA_ID EXPRESSION "LOADER_SP_INPUI_DATOTEKA_ID", SIMILAR_SEQ EXPRESSION "LOADER_SIMILAR_SEQ", KUPEC_CODE CHAR NULLIF KUPEC_CODE='NULL', KUPEC_NAME CHAR NULLIF CUSTOMER_NAME='NULL', COUNTRY CHAR NULLIF COUNTRY_NAME='NULL', CITY CHAR NULLIF CITY='NULL', ADDRESS CHAR NULLIF ADDRESS='NULL', ZIP CHAR NULLIF ZIP_CODE='NULL' "decode(:zip_code,null,'missing',:zip_code)" ) S kontrolno referenčno datoteko imamo pri uvozu tudi določen del preverjanja podatkov, saj nam program v primeru napačnega tipa, manjkajočega polja, napačne strukture itd. javi napako pri uvozu (angl. Bad Load). Tako na koncu dobimo povzetek zapisa v dnevniku. Gregor Povhe: Obdelava in priprava podatkovne kocke OLAP stran 32

38 Krajši povzetek uspešnega uvoza v tabelo Kupci: Table KLI_CUSTOMERS: 13 Rows successfully loaded. 0 Rows not loaded due to data errors. 0 Rows not loaded because all WHEN clauses were failed. 0 Rows not loaded because all fields were null. Space allocated for bind array: Read buffer bytes: Total logical records skipped: 1 Total logical records read: 143 Total logical records rejected: 0 Total logical records discarded: bytes(64 rows) V primeru neuspešnega uvoza v tabele, nam program izpiše vrsto napake in kje se je zgodila, da jo lažje rešimo in poskusimo ponovno: Table KLI_PRODUCTS: 1082 Rows successfully loaded. 11 Rows not loaded due to data errors. 0 Rows not loaded because all WHEN clauses were failed. 0 Rows not loaded because all fields were null. SQL*Loader-izvoz je naredil poročilo, da je uspešno uvozil 1082 vrstic v tabelo KLI_PRODUCTS. 11 vrstic je bilo neuspešno uvoženih. Primer neuspešno uvožene vrstice: Record 856: Rejected - Error on table KP_PRODUCTS, column DIST_PROD_NAME. ORA-01400: cannot insert NULL into ("KLI"." KP_PRODUCTS "."IZDELEK_NAME") Do težave je prišlo, ker je bila vrstica 856 prazna in ker je za polje IZDELEK_NAME pogoj, da ne sme biti prazno. To je sprožilo napako IZDELAVA OLAP-KOCKE Dimenzije smo kreirali z orodjem Oracle Analytic Workspace Manager, iz katerih smo kasneje naredili OLAP-kocko. Dimenzije so bile: Kanal (angl. Channel) kupci ločeni na dva kanala: zasebniki in javni kupci. Regija (angl. Geography) kupci razporejeni po regijah. Izdelek (angl. Product) vsi izdelki. Čas (angl. Time) čas po hierarhiji: leto, kvartal in mesec. Vsaka dimenzija v OLAP-kocki je imela svoje ravni (angl. Level), kot jih prikazuje Tabela 7: Dimenzija 1. Raven 2. Raven 3. raven Kanal Vsi kanali Zasebniki - Javni kupci - Regija Slovenija Regija Občina Izdelek Proizvajalec Izdelek - Gregor Povhe: Obdelava in priprava podatkovne kocke OLAP stran 33

39 Čas Leto Kvartal Mesec Tabela 7: Ravni po dimenzijah: Kanal, Regija, Izdelek in Čas Vsem članom hierarhije smo določili atribute. Atribute v hierarhiji prikazuje Slika 9. Slika 9: Atributi po hierarhijah Ko smo kreirali vse OLAP-objekte, smo jih morali preslikati (angl. Mapping) ali povezati z elementi v tabelah. Ko so bili vsi elementi povezani, smo naredili kocko, ki jo prikazuje Slika 10. Slika 10: OLAP kocka Sedaj smo dodali še meri Prodaja (angl. Sales) in Količina (angl. Quantity). Poleg osnovnih mer nam OLAP omogoča delanje izračunanih mer, ko iz obstoječih mer izračunamo nove, lahko pa tudi iz izračunanih mer naredimo še dodatne nove izračunane mere. Gregor Povhe: Obdelava in priprava podatkovne kocke OLAP stran 34

40 Po kreiranju OLAP-kocke smo morali preslikati podatke iz relacijskega podatkovnega skladišča z OLAP-kocko. Program nam omogoča takojšno izdelavo OLAP-kocke ali pa urnik generiramo in kocko izdelamo kasneje. Gregor Povhe: Obdelava in priprava podatkovne kocke OLAP stran 35

41 4. TESTIRANJE V PRAKSI Pri pripravi podatkov, nalaganju v podatkovno skladišče in izgradnji OLAP-kocke smo podatke, ki smo jih dobili na več različnih načinov, prilagajali našim potrebam. Zato smo morali testirati, če so izvorni podatki, ki smo jih dobili, enaki podatkom, ki jih dobimo na koncu z OLAP-kocko TESTIRANJE POPRAVKOV VHODNIH PODATKOV Pri določenih vhodnih podatkih, ki niso imeli pravilne strukture, ali če je bil napačen tip datotek, smo morali podatke narediti primerne za uvoz. Zaradi različnih ERP-sistemov in različnih regionalnih nastavitev na strežnikih ali osebnih računalnikih smo tako dobili različne zapise števil, ki so imela ločilo tisočic '.' ali pa so bile brez ločila. Prav tako smo lahko dobili za decimalno vejico piko '.',ali pa je bilo celo brez decimalnega ločila in zaokroženo. Ker v tabeli v podatkovnem skladišču za vsako polje določimo podatkovni tip, smo morali tudi pravilen tip uvoziti, drugače smo dobili napačne rezultate, ali sam uvoz ni uspel. Delno smo lahko težavo rešili s kontrolno referenčno datoteko, ki smo jo uporabili pri uvozu podatkov. V zapis smo dodali, da nam program pri uvažanju zamenja '.' z vejico ali obratno, odvisno kako smo zapis potrebovali, in dobili pravilen zapis primeren za uvoz v tabelo: SALES FLOAT EXTERNAL NULLIF SALES='NULL' TO_NUMBER(REPLACE(REPLACE(:SALES,'.',''),',','.'))", QUANTITY FLOAT EXTERNAL NULLIF QUANTITY='NULL' "TO_NUMBER(REPLACE(REPLACE(:QUANTITY,'.',''),',','.'))", S tem še nismo rešili celotnega problema, saj je bil sedaj zapis že primeren za uvoz v tabele v podatkovnem skladišču, kar pa ni nujno, da je bila zamenjava '.' ali ',' pravilna. Dobili smo lahko napačno vrednost, ki je bila 100-krat ali 1000-krat večja ali manjša od pravilne vrednosti. Na primer: 1.234,56 1, Iz omenjenega razloga smo podatke testirali že pred uvozom v podatkovno skladišče in primerjali na osnovi mesečnih povprečij. S tem smo pridobili merljivo vrednost, ki nam je povedala, ali so vrednosti v pravilnem zapisu. Prav tako smo po uvozu v podatkovno skladišče preverili podatke na podlagi mesečnih povprečij. Identificiranje težav je zelo pomembno v čimbolj zgodnjem delu ETL-procesa. Celoten tok procesa si sledi zaporedno in je zato identificiranje težave v kasnejšem delu procesa zamudnejše. Med datotekami smo prejeli tudi podatke, ki so bili brez kod kupcev in brez kod izdelkov. Ker v tabelo v podatkovnem skladišču ne moremo uvoziti podatkov brez kod izdelka in kupca, smo jih generirali iz samih podatkov. Za kodo izdelka smo zato združili ime izdelka in proizvajalca in generirali naključno kodo iz teh znakov. Za kodo kupca smo združili ime kupca in naslova ter dobili unikatno kodo. Težava je nastala, če so se imena izdelkov, proizvajalcev, kupcev ali naslovov spreminjala. Tako smo za isti izdelek ali istega kupca dobili različne unikatne kode, Gregor Povhe: Obdelava in priprava podatkovne kocke OLAP stran 36

42 čeprav je šlo za isti izdelek. Na primer:»izdelek 123«je dobil kodo»xxxx«in»izdelek123«novo kodo, čeprav sta bila izdelka enaka, je bil zapis drugačen in zato je bila koda nova. Ko smo podatke uvažali v podatkovno skladišče je nastajala težava pri spreminjanju teh imen. Istega kupca ali izdelek smo primerjali z vrednostmi iz meseca v mesec. Če spremembe ni bilo, potem smo pustili vse, kot je. Drugače je prišlo do»podvajanja«izdelkov ali kupcev z različnimi unikatnimi kodami. Sam sistem deluje v redu, vendar je več različnih kod in potrebno je več testiranja TESTIRANJE VHODNIH PODATKOV S PODATKI IZ PODATKOVNEGA SKLADIŠČA Vhodne podatke, ki smo jih prejeli, smo s SQL-poizvedbami v Access-u ali v Excelpreglednicah sešteli po vsotah in vrsticah. Število in vsota vseh vrstic je morala biti enaka vsotam vrstic v tabelah v podatkovnem skladišču. Naredili smo analizo po vsakem sklopu vhodnih podatkov in iz tabele v podatkovnem skladišču sešteli vse zapise, jih primerjali z vsotami in številom zapisov v vhodnih podatkih, narejenih s SQL-poizvedbami ali vsotam v preglednicah. Podatke iz OLAP-kocke smo primerjali z vhodnimi podatki, ki smo jih dobili, da smo podatke uvozili v tabele ali preglednice, in naredili vsote po količini in prodaji. Nato smo različne vsote od vseh vhodnih podatkov sešteli skupaj in jih primerjali s podatki iz OLAP-kocke. Primerjali smo lahko prodajo po mesecih, izdelkih, kupcih itd. Preverili smo, če so vneseni vsi podatki, da smo naredili poizvedbo in primerjali vse prejete sklope podatkov z naloženimi podatki v podatkovnem skladišču. Podatke smo prejeli ali uvažali v podatkovno skladišče kronološko po mesecih, zato smo na osnovi prejšnjih zapisov v tabelah lahko testirali konsistentnost podatkov. Testirali smo, ali so si zapisi kupcev in izdelkov enaki iz ene periode v drugo. To smo preverjali, če se je določeni unikatni kodi kupca ali izdelka spremenil zapis. V praksi to pomeni, da testiramo, ali ima koda kupca XXXX enako vrednost skozi zgodovino. Danes ima unikatna koda XX»vrednostkupec1«in naslednji mesec ima unikatna koda XX»vrednostkupec2«. S tem smo morali poiskati vse razlike in jih nato pravilno klasificirati, saj je to kasneje zelo pomembno pri regionalni razporeditvah, ker kupca s kodo XX prej in sedaj nista nujno iz iste regije. V praksi ERP-sistemi tega ne bi smeli omogočati, da se isti»unikatni«kodi spreminja vrednost, vendar temu vedno ni tako. Zato smo testirali tudi takšne nepravilnosti. Uvožene podatke v podatkovnem skladišču smo primerjali za različne nedoslednosti. Primerjali smo, ali so vse kode kupcev, ki so bile v transakcijski datoteki, tudi v datoteki kupcev. Drugače bi imeli prodajo v določeno regijo, za katero ne bi vedeli, Gregor Povhe: Obdelava in priprava podatkovne kocke OLAP stran 37

43 kam sodi. Enako smo naredili tudi s tabelo izdelkov, saj smo preverili, če so vse kode izdelkov tudi v datoteki izdelkov TESTIRANJE OLAP-KOCKE Za pregled podatkov iz OLAP-kocke smo uporabili gonilnik za MDX podjetja Simba (Simba MDX Provider for Oracle OLAP). Pri tem se uporablja standard ODBO kar je Microsoftova specifikacija ali standard za večdimenzionalno podatkovno procesiranje. S tem standardom lahko kreiramo vmesnik za programiranje aplikacij (API) za izmenjevanje metapodatkov med OLAP-strežnikom in Microsoftovim klientom. V našem primeru smo uporabili program Excel (Simba MDX Provider for Oracle OLAP, 2016). Podatke, ki smo jih povezali z OLAP strežnikom smo nato v Excel preglednici lahko pregledovali v obliki vrtilnih tabel (angl. Pivot Table), kot je prikazano na Sliki 11. Delali smo lahko analize in primerjali izhodne podatke z vhodnimi. Slika 11: Vrtilna tabela s podatki iz OLAP kocke S pomočjo vrtilne tabele smo nato preverili dimenzije, ki smo jih naredili za OLAPkocko: Kanal (angl. Channel), Regija (angl. Geography), Izdelek (angl. Product) in Čas (angl. Time). Preverili smo, ali so te dimenzije pravilno napolnjene s podatki in na vseh ravneh. Ali sta meri Količina in tudi narejeni meri Prodaja (angl. Sales) in Količina (angl. Quantity) izračunani pravilno. S temi podatki smo naredili podrobno analizo in validacijo z vrtenjem vrtilne tabele po vseh dimenzijah in merah. Tako smo dobili povprečja, vsote, minimum, maksimum in ostale vrednosti, ki smo jih med seboj primerjali ter preverjali za doslednost med podatki. Gregor Povhe: Obdelava in priprava podatkovne kocke OLAP stran 38

44 V primeru odstopanj se lotimo podrobnejše analize, preverja se podatke pri samem izvoru, zakaj je prišlo do deviacij. Enake vsote smo primerjali z vsotami, ki smo jih naredili pri validaciji vhodnih podatkov s podatki iz podatkovnega skladišča. Preverili smo doslednost podatkov v celotnem procesu od ETL-a do OLAP analize. Sam postopek testiranja tehnično ni zahteven, je pa zelo pomemben in zamuden. Testiranje podatkov nam pove, ali smo naredili OLAP-kocko primerno za analizo in ali bodo nadaljnje odločitve, sprejete na osnovi teh podatkov, pravilne. Postopek testiranja se nadaljuje s postopkom izvajanja OLAP-analiz in tudi s podatkovnim rudarjenjem, da se na podlagi nadaljnjih ugotovitev spremlja tudi integriteta podatkov, iz katerih je narejena OLAP-kocka. Gregor Povhe: Obdelava in priprava podatkovne kocke OLAP stran 39

45 5. SKLEP V septembru 1999 je v atmosferi Marsa zgorel prvi meteorološki satelit na drugem planetu, vreden misije je bila kar 327,6 milijonov dolarjev. Satelit je prenizko priletel v atmosfero in izgorel še predno je začel opravljati svojo nalogo. Ekipa NASA inženirjev je ugotovila, da je prišlo do napake pri programski opremi za izračun potiska pri pogonskih motorjih. Program je izračunal potrebno silo v funtih (angl. Pounds), medtem ko je drugi del programske opreme vzel mere v metričnem sistemu, in izračun je bil napačen. Prišlo je do napake v komunikaciji med dvema inženirskima ekipama in vzrok so bili napačni podatki za izračun. Napake v programih, bazah, pri uporabniških vnosih in še mnogo drugih napak pripelje do napačnih odločitev, ki imajo lahko velike posledice. Problem diplomske naloge je bil zagotoviti podatke, primerne za analizo z OLAPkocko. Zaradi velikih količin različnih podatkov in ERP-sistemov in različnih vrst napak se podatki, ki so združeni v podatkovnih skladiščih, lahko zelo razlikujejo in pripeljejo do napačnih odločitev. Poskušali smo spraviti podatke na skupni imenovalec in jih pripraviti ali obdelati tako, da so bili primerni za analizo kot celota. Delali smo v podatkovnem skladišču, kjer smo dobivali podatke iz različnih virov in nismo imeli specializiranih ETL-orodij. S tem smo dobili izvožene podatke, a nismo imeli vpliva na izvoz, kar poveča možnosti napak ali razlik, oziroma naredi proces preverjanja in priprave podatkov še bolj obsežnega. Naloge priprave in obdelave podatkov v diplomski nalogi so bile narejene brez uporabe večjih specializiranih ETL-programov. S tem smo dokazali da lahko z različnimi komercialnimi in nekomercialnimi orodji uspešno pripravimo in obdelamo podatke v vsaki fazi ETL-procesa. Pri izvozu podatkov iz različnih okolij smo lahko samo preverjali končni izvoz pridobljenih podatkov po naših specifikacijah, vendar nismo imeli vpliva na del procesa izvoza. Končni rezultat naloge je bila OLAP-kocka, ki je bila primerna za analizo podatkov. Obdelava in priprava podatkov je zelo pomemben del celotnega procesa. Samemu procesu se ponavadi ne posveti dovolj časa, temveč se začne s čimprejšnjo izdelavo OLAP-kock, da se lahko podatki analizirajo. Napake, ki se jih kasneje odkrije, po analizah pripeljejo do iskanja vzrokov in ne malokrat se napake odkrijejo pri vhodnih podatkih. Odpravljanje takšnih napak je zamudno in nepotrebno saj bi se jih dalo odpraviti že na začetku. Odkrivanje napak ni proces, ki bi ga lahko izmerili in ni vedno enak za vse primere, temveč je stalen proces odkrivanja in testiranja. Smeti noter smeti ven ali po angleško»garbage in garbage out«- GIGO nam pove, da s slabimi podatki na začetku procesa ne bomo dosegli dobrih rezultatov na koncu, ali drugače povedano, analize in odločitve bodo zelo verjetno napačne. Zato s pripravo in obdelavo podatkov poskušamo pripraviti podatke, da so primerni za izdelavo BI-poročil in poskušamo odpraviti čim več napak v podatkih, ki jih zaznamo. Proces ETL je pri obdelavi in pripravi podatkov lahko ponavljajoč, saj se z Gregor Povhe: Obdelava in priprava podatkovne kocke OLAP stran 40

46 vnosom podatkov odpravi nekatere napake podatke, a se pri analizi odkrije nove napake in se jih na novo popravi in ponovi celoten ETL-proces. S pravilno obdelavo in pripravo podatkov se začne proces, ki pripelje do pravilnih analiz in odločitev za potrebe poslovanja. S tem lahko veliko pridobimo pri samem poslovanju. Ali je za ETL-proces potrebno kupiti specializirano orodje ali se lotimo ETL procesa sami? Ralph Kimbal v knjigi»the Data Warehouse ETL Toolkit«predlaga, da se pretehta, ali je potrebno kupiti ETL-orodja ali uporabi svoje znanje. V vsakem primeru je to postopek, ki je zelo pomemben in meni, da večji kot je obseg ETLprocesa, bolj se nagiba h nakupu specializiranega ETL orodja. Ker v času informacij postajajo informacije vedno bolj obsežne in tudi njihova količina neizmerno hitro raste (angl.»big Data«), nastajajo nove platforme in rešitve na področju podatkovnih skladišč. Ena izmed takih je odprtokodna platforma Hadoop, ki je zelo učinkovita rešitev za zelo velike količine podatkov. Jedro Hadoopa, podjetja Apache, je sestavljeno iz dela za shranjevanje, ki je znan kot Hadoop Distributed File System (HDF), in procesorskega dela, imenovanega MapReduce. Hadoop razdeli datoteke v velike bloke in jih distribuira preko vozlišč v gruči. S tem pridobimo na hitrosti in na zmožnostih shranjevanja velikih količin podatkov. Proces ETL se zato lahko spremeni v ELT, kjer se podatki prej naložijo v Hadoop in šele nato transformirajo. Ker se podatki ne naložijo sami v Hadoop, je vseeno potrebno zagotoviti vsaj osnovne transformacije datotek, ki se uvažajo., zaradi tega lahko govorimo o ETLT-procesu. Obdelava in priprava podatkov je še vedno prisotna, saj je vsakem primeru potrebno podatke predelati ali obdelati. Gregor Povhe: Obdelava in priprava podatkovne kocke OLAP stran 41

47 LITERATURA 1. Böder, J. in Gröne, B. (2014). The Architecture of SAP ERP: Understand how successful software works. Hamburg: Tredition. 2. Direktiva 96/9/ES Evropskega parlamenta in Sveta o pravnem varstvu baz podatkov. (1996). Uradni list L 077, str ETL (Extract-Transform-Load) Data Integration Info. (2016). Pridobljeno na 4. Fayyad, U., Piatetsky-Shapiro, G. in Smyth, P. (1996). AI Magazine. From Data Mining to Knowledge Discovery in Databases, Ferle, M. (2013). Upravljanje kakovosti podatkov. Pridobljeno na 6. Hameurlain, A., Liddle, S. W., Schewe, K. in Zhou, X. (2011). Database and Expert Systems Applications. Berlin: Springer 7. Kakish, K. in Kraft, T. A. (2012). ETL Evolution for Real-Time Data Warehousing. Pridobljeno na 8. Kimball, R. in Caserta, J. (2004). The Data Warehouse ETL Toolkit: Practical Techniques for Extracting, Cleaning, Conforming, and Delivering Data. Indianapolis: Wiley Publishing, Inc. 9. Learn about Online Analytical Processing (OLAP). (2016). Pridobljeno na analiti%c4%8dne-obdelave-podatkov-s-povezavo-15d2cdde-f70b b009-ed732b75fdd6 10. Lorente, N. L. in Lorente, N. C. (2013). Implementing Microsoft Dynamics NAV Birmingham: Packt Publishing 11. Meersman, R., Tari, Z. in Herrero, P. (2008). On the Move to Meaningful Internet Systems: OTM 2008 Workshops. Monterrey: Springer 12. Microsoft Dynamics NAV. (2016). Pridobljeno na: Monk, E. F., Wagner, B. J. (2013). Concepts in enterprise resource planning (4th ed.). Boston: Cengage Learning, Inc. 14. MSDN: Data Validation. (2015). Pridobljeno na Nanda, A. (2015) Oracle Database 11g: The Top Features for DBAs and Developers Data Warehousing and OLAP. Pridobljeno na Oracle. (1996). Data Warehousing Concepts. Pridobljeno na Oracle. (2008). Oracle data mining concepts 11g. (Rel. 11.1). Pridobljeno na Oracle. (2010). Oracle Warehouse Builder Concepts Data Transformation. Pridobljeno na Gregor Povhe: Obdelava in priprava podatkovne kocke OLAP stran 42

48 19. Oracle. (2012). Oracle OLAP Application Developer s Guide. Oracle OLAP Application Developer's Guide, 10g Release 2 (10.2). Pridobljeno na Oracle. (2016). Oracle Database Data Warehousing Guide. Pridobljeno na Ponniah, P. (2001). Data Warehousing Fundamentals A Comprehensive Guide for IT Professionals. Brisbane John Wiley & Sons, Inc. 22. Rahm, E. in Hai, H. D. (2000). Data Cleaning: Problems and Current Approaches. Pridobljeno na Rothenberg, J. (1997). A Discussion of Data Quality for Verification, Validation, and Certification (VV&C) of Data to be Used in Modeling. Pridobljeno na _Quality_for_Verification_Validation_and_Certification_VVC_of_Data_to_be_ Used_in_Modeling 24. Sadiq, S. (2013). Handbook of Data Quality. Dasu, T., Data Glitches - Monsters in your Data (str ). Brisbane: Springer 25. SAP AG. (2016). Pridobljeno na Simba MDX Provider for Oracle OLAP. (2016). Pridobljeno na Driver-Overview.pdf 27. Super Develop. (2014). Databases:Understand Data Cleansing. Pridobljeno na Techopedia. (2016). What is Data Augmentation? Pridobljeno na Thomsen, E. (2002). OLAP Solutions: building multidimensional information system (2nd ed.). Canada: John Wiley & Sons, Inc. 30. Trifacta. (2016). A Modern Approach to Working With Data. Pridobljeno na Witten, I. H., Eibe, F. in Hall, M. A. (2011). Data Mining: practical machine learning tools and techniques (3rd ed.). Burlington: Morgan Kaufmann Publishers. 32. Yang, M. (2010). Oracle E-Business Suite: Integrated SOA Gateway Implementation Guide (Rel. 12.1). Pridobljeno na Gregor Povhe: Obdelava in priprava podatkovne kocke OLAP stran 43

49 Kazalo slik Slika 1: Podatkovni tok podatkov od vira do OLAP-kocke (Super Develop, 2015)... 3 Slika 2: Klasifikacije težav v kvaliteti podatkov iz različnih virov (Rahm in Hai, 2000) 7 Slika 3: Zvezdna shema v podatkovnem skladišču Slika 4: Dimenzije v OLAP kocki (Nanda, 2015) Slika 5: Faze čiščenja podatkov (Sadiq, 2013) Slika 6: Razlike med nalaganjem podatkov v podatkovno skladišče (Ponniah, 2001) Slika 7: Specifikacije za uvoz podatkov Slika 8: Transformacija podatkov s pomočjo programa Openrefine Slika 9: Atributi po hierarhijah Slika 10: OLAP kocka Slika 11: Vrtilna tabela s podatki iz OLAP kocke Kazalo tabel Tabela 1: Specifikacije polj za tabelo Kupci... 5 Tabela 2: Specifikacije polj za tabelo Izdelki... 5 Tabela 3: Specifikacije polj za tabelo Prodaja... 5 Tabela 4: Atributi v tabeli Kupci Tabela 5: Atributi v tabeli Izdelkov Tabela 6: Atributi v tabeli Transakcij Tabela 7: Ravni po dimenzijah: Kanal, Regija, Izdelek in Čas Gregor Povhe: Obdelava in priprava podatkovne kocke OLAP stran 44

50 UNIVERZA V MARIBORU Fakulteta za organizacijske vede IZJAVA O ISTOVETNOSTI TISKANE IN ELEKTRONSKE VERZIJE ZAKLJUČNEGA DELA IN OBJAVI OSEBNIH PODATKOV DIPLOMANTOV Ime in priimek diplomanta: Gregor Povhe Vpisna številka: Študijski program: ORGANIZACIJA IN MANAGEMENT Naslov diplomskega dela: Obdelava in priprava podatkovne kocke OLAP Mentor: izr. prof. dr. Uroš Rajkovič Podpisani Gregor Povhe izjavljam, da sem za potrebe arhiviranja oddal elektronsko verzijo zaključnega dela v Digitalno knjižnico Univerze v Mariboru. Diplomsko delo sem izdelal sam ob pomoči mentorja. V skladu s 1. odstavkom 21. člena Zakona o avtorskih in sorodnih pravicah dovoljujem, da se zgoraj navedeno zaključno delo objavi na portalu Digitalne knjižnice Univerze v Mariboru. Tiskana verzija diplomskega dela je istovetna elektronski verziji, ki sem jo oddal za objavo v Digitalno knjižnico Univerze v Mariboru. Podpisani izjavljam, da dovoljujem objavo osebnih podatkov vezanih na zaključek študija (ime, priimek, leto in kraj rojstva, datum diplomiranja, naslov diplomskega dela) na spletnih straneh in v publikacijah UM. Datum in kraj: Podpis diplomanta: Maribor,