Dizajn podatkovnih kocki. Stvaranje OLAP kocke pomoću Microsoft Queryja

Riža. 2. OLAP kockasti isječak

Rotacija(Slika 3) - operacija promjene mjesta mjerenja prikazanih u izvješću ili na prikazanoj stranici. Na primjer, operacija rotacije može uključivati ​​preuređivanje redaka i stupaca tablice. Osim toga, rotiranje podatkovne kocke premješta dimenzije izvan tablice na mjesto dimenzija prisutnih na prikazanoj stranici i obrnuto.

Napomena: Ovo predavanje pokriva osnove projektiranja podatkovnih kocki za OLAP skladišta podataka. Primjer prikazuje način konstruiranja podatkovne kocke pomoću CASE alata.

Svrha predavanja

Nakon proučavanja gradiva na ovom predavanju znat ćete:

• u čemu je podatkovna kocka OLAP skladište podataka ;
• kako dizajnirati podatkovnu kocku za OLAP skladišta podataka ;
• što je dimenzija podatkovne kocke;
• kako je činjenica povezana s podatkovnom kockom;
• što su atributi dimenzije;
• što je hijerarhija;
• što je metrika podatkovne kocke;

i nauči:

• izgraditi višedimenzionalne karte ;
• dizajn jednostavan višedimenzionalne karte.

Uvod

OLAP tehnologija nije jedinstvena softver, ne programski jezik. Ako pokušamo pokriti OLAP u svim njegovim pojavnim oblicima, onda je to skup koncepata, načela i zahtjeva koji su u osnovi softverskih proizvoda koji analitičarima olakšavaju pristup podacima.

Analitičari su glavni potrošači korporativnih informacija. Posao analitičara je pronaći uzorke u velikim količinama podataka. Stoga se analitičar neće obazirati na pojedinačnu činjenicu da je određenog dana serija kemijskih olovaka prodana kupcu Ivanovu - njemu su potrebne informacije o stotinama i tisućama sličnih događaja. Pojedinačne činjenice u skladištu podataka mogu biti od interesa, na primjer, za računovođu ili voditelja odjela prodaje, čija je nadležnost podrška određenom ugovoru. Analitičaru jedan zapis nije dovoljan - on će, na primjer, možda trebati informacije o svim ugovorima prodajnog mjesta za mjesec, tromjesečje ili godinu. Analitičar možda neće biti zainteresiran za kupčev TIN ili njegov telefonski broj - on radi s određenim numeričkim podacima, što je bit njegove profesionalne djelatnosti.

Centralizacija i prikladno strukturiranje nisu sve što je potrebno analitičaru. Treba mu alat za pregled i vizualizaciju informacija. Tradicionalnim izvješćima, čak i onima izgrađenim na temelju jedinstvenog skladišta podataka, nedostaje određena fleksibilnost. Ne mogu se "izokrenuti", "proširiti" ili "skupiti" da bi se dobio željeni prikaz podataka. Što više "odsječaka" i "odsječaka" podataka analitičar može istražiti, to više ideja ima, koje zauzvrat zahtijevaju sve više i više "odsječaka" za provjeru. OLAP služi kao takav alat za analizu podataka od strane analitičara.

Iako OLAP nije nužan atribut skladišta podataka, sve se više koristi za analizu informacija akumuliranih u tom skladištu podataka.

Operativni podaci prikupljaju se iz različitih izvora, čiste, integriraju i pohranjuju u skladište podataka. Štoviše, već su dostupni za analizu pomoću različitih alata za izvješćivanje. Zatim se podaci (cijeli ili djelomično) pripremaju za OLAP analizu. Mogu se učitati u posebnu OLAP bazu podataka ili ostaviti u relacijskoj bazi podataka. Najvažniji element korištenja OLAP-a su metapodaci, odnosno informacije o strukturi, položaju i transformacija podataka. Zahvaljujući njima, osigurana je učinkovita interakcija različitih komponenti za pohranu.

Tako, OLAP se može definirati kao skup alata za višedimenzionalnu analizu podataka akumuliranih u skladištu podataka. Teoretski, OLAP alati mogu se primijeniti izravno na operativne podatke ili njihove točne kopije. Međutim, postoji rizik podvrgavanja podataka analizi koji nisu prikladni za ovu analizu.

OLAP na klijentu i poslužitelju

OLAP se temelji na višedimenzionalnoj analizi podataka. Može se izraditi pomoću različitih alata, koji se mogu podijeliti na klijentske i poslužiteljske OLAP alate.

OLAP klijentski alati su aplikacije koje izračunavaju skupne podatke (zbrojeve, prosjeke, maksimalne ili minimalne vrijednosti) i prikazuju ih, dok se sami skupni podaci nalaze u predmemoriji unutar adresnog prostora takvog OLAP alata.

Ako su izvorni podaci sadržani u desktop DBMS-u, izračun skupnih podataka izvodi sam OLAP alat. Ako je izvor početnih podataka poslužiteljski DBMS, mnogi klijentski OLAP alati šalju poslužitelju SQL upite koji sadrže operator GROUP BY i kao rezultat primaju skupne podatke izračunate na poslužitelju.

U pravilu, OLAP funkcionalnost implementirana je u alatima za statističku obradu podataka (od proizvoda ove klase do rusko tržište naširoko se koriste proizvodi tvrtki Stat Soft i SPSS) iu nekim proračunskim tablicama. Konkretno, ima dobre alate za višedimenzionalnu analizu Microsoft Excel 2000. Koristeći ovaj proizvod, možete stvoriti i spremiti kao datoteku malu lokalnu višedimenzionalnu OLAP kocku i prikazati njezine dvo- ili trodimenzionalne dijelove.

Puno razvojni alati sadrže biblioteke klasa ili komponenti koje vam omogućuju stvaranje aplikacija koje implementiraju jednostavnu OLAP funkcionalnost (kao što su, na primjer, komponente Decision Cube u Borland Delphiju i Borland C++Builderu). Osim toga, mnoge tvrtke nude kontrole ActiveX i druge biblioteke koje implementiraju sličnu funkcionalnost.

Imajte na umu da se klijentski OLAP alati koriste, u pravilu, s malim brojem dimenzija (obično se ne preporučuje više od šest) i malom raznolikošću vrijednosti za ove parametre - na kraju krajeva, rezultirajući skupni podaci moraju stati u adresni prostor takvog alata, a njihov broj eksponencijalno raste kako se broj povećava mjerenja Stoga čak i najprimitivniji klijentski OLAP alati u pravilu omogućuju preliminarni izračun količine potrebne RAM-a za stvaranje višedimenzionalne kocke u njemu.

Mnogi (ali ne svi) OLAP klijentski alati omogućuju vam da spremite sadržaj predmemorije sa skupnim podacima kao datoteku, što vam zauzvrat omogućuje da izbjegnete njihovo ponovno izračunavanje. Imajte na umu da se ova prilika često koristi za otuđenje agregiranih podataka u svrhu njihovog prijenosa drugim organizacijama ili za objavljivanje. Tipičan primjer takvih otuđivih agregatnih podataka je statistika morbiditeta u različitim regijama i u različitim dobnim skupinama, što je otvorene informacije objavljuju ministarstva zdravlja raznim zemljama i Svjetske zdravstvene organizacije. Pritom, sami izvorni podaci, koji predstavljaju informacije o konkretnim slučajevima bolesti, povjerljivi su podaci zdravstvenih ustanova i ni u kojem slučaju ne bi smjeli dospjeti u ruke osiguravajućih društava, a još manje postati javni.

Ideja pohranjivanja predmemorije skupnih podataka u datoteci dalje je razvijena u poslužiteljskim OLAP alatima, u kojima spremanje i mijenjanje skupnih podataka, kao i održavanje pohrane koja ih sadrži, provodi zasebna aplikacija ili proces koji se zove OLAP poslužitelj. Klijentske aplikacije mogu zatražiti takvu višedimenzionalnu pohranu i primiti određene podatke kao odgovor. Neke klijentske aplikacije također mogu stvoriti takve trgovine ili ih ažurirati na temelju promijenjenih izvornih podataka.

Prednosti korištenja poslužiteljskih OLAP alata u usporedbi s klijentskim OLAP alatima slične su prednostima korištenja poslužiteljskih DBMS-ova u usporedbi s onima za stolna računala: u slučaju korištenja poslužiteljskih alata, izračun i pohranjivanje agregatnih podataka odvija se na poslužitelju, a klijentska aplikacija prima samo rezultate upita protiv njih, što omogućuje općenito smanjenje mrežnog prometa, vrijeme isporuke zahtjeve i zahtjeve za resursima koje troši aplikacija klijenta. Imajte na umu da se alati za analizu i obradu podataka na razini poduzeća u pravilu temelje na poslužiteljskim OLAP alatima, na primjer, Oracle Express Server, Microsoft SQL Server 2000 Analysis Services, Hyperion Essbase, proizvodi iz Crystal Decisions, Business Objects, Cognos, SAS Institut. Budući da svi vodeći proizvođači poslužiteljskih DBMS-ova proizvode (ili imaju licencu od drugih tvrtki) jedan ili drugi poslužiteljski OLAP alat, izbor je prilično širok i u gotovo svim slučajevima možete kupiti OLAP poslužitelj od istog proizvođača kao i sam poslužitelj baze podataka .

Imajte na umu da vam mnogi klijentski OLAP alati (osobito Microsoft Excel 2003, Seagate Analysis, itd.) omogućuju pristup poslužiteljskim OLAP pohranama, djelujući u ovom slučaju kao klijentske aplikacije koje izvode takve upite. Osim toga, postoji mnogo proizvoda koji su klijentske aplikacije za OLAP alate raznih proizvođača.

Tehnički aspekti višedimenzionalne pohrane podataka

Višedimenzionalna skladišta podataka sadrže skupne podatke različitih stupnjeva detalja, na primjer, količine prodaje po danu, mjesecu, godini, po kategoriji proizvoda itd. Svrha pohranjivanja zbirnih podataka je smanjenje vrijeme isporuke zahtjeva, budući da u većini slučajeva za analize i prognoze nisu zanimljivi detaljni, već zbirni podaci. Stoga se pri izradi višedimenzionalne baze podataka uvijek izračunavaju i pohranjuju neki skupni podaci.

Imajte na umu da spremanje svih skupnih podataka nije uvijek opravdano. Činjenica je da kada se dodaju nove dimenzije, količina podataka koji čine kocku eksponencijalno raste (ponekad se govori o “eksplozivnom rastu” količine podataka). Točnije, stupanj rasta volumena agregatnih podataka ovisi o broju dimenzija kocke i članovima dimenzija na različitim razinama hijerarhije tih dimenzija. Za rješavanje problema "eksplozivnog rasta" koriste se različite sheme koje omogućuju postizanje prihvatljive brzine izvršenja upita pri izračunavanju ne svih mogućih skupnih podataka.

I sirovi i skupni podaci mogu se pohraniti u relacijske ili višedimenzionalne strukture. Stoga se trenutno koriste tri metode pohrane podataka.

• MOLAP(Multidimensional OLAP) - izvorni i skupni podaci pohranjuju se u višedimenzionalnu bazu podataka. Pohranjivanje podataka u višedimenzionalne strukture omogućuje manipuliranje podacima kao višedimenzionalnim nizom, zbog čega je brzina izračunavanja agregatnih vrijednosti jednaka za bilo koju od dimenzija. Međutim, u ovom slučaju višedimenzionalna baza podataka je suvišna, budući da višedimenzionalni podaci u cijelosti sadrže izvorne relacijske podatke.
• ROLAP(Relational OLAP) - izvorni podaci ostaju u istoj relacijskoj bazi podataka gdje su se izvorno nalazili. Zbirni podaci smješteni su u servisne tablice posebno kreirane za njihovo pohranjivanje u istoj bazi podataka.
• HOLAP(Hybrid OLAP) - izvorni podaci ostaju u istoj relacijskoj bazi podataka gdje su se izvorno nalazili, a agregatni podaci pohranjuju se u višedimenzionalnu bazu podataka.

Neki OLAP alati podržavaju pohranu podataka samo u relacijske strukture, neki samo u višedimenzionalne. Međutim, većina modernih poslužiteljskih OLAP alata podržava sve tri metode pohrane podataka. Odabir načina pohrane ovisi o volumenu i strukturi izvornih podataka, zahtjevima za brzinom izvršavanja upita i učestalosti ažuriranja OLAP kocki.

Također imajte na umu da velika većina modernih OLAP alata ne pohranjuje "prazne" vrijednosti (primjer "prazne" vrijednosti bio bi izostanak prodaje sezonskog proizvoda izvan sezone).

Osnovni OLAP koncepti

FAMSI test

Tehnologija za složenu višedimenzionalnu analizu podataka naziva se OLAP (On-Line Analytical Processing). OLAP je ključna komponenta organizacije skladišta podataka. Koncept OLAP-a opisao je 1993. godine Edgar Codd, poznati istraživač baza podataka i autor relacijskog modela podataka. Godine 1995. na temelju zahtjeva koje je Codd postavio tzv FASMI test(Fast Analysis of Shared Multidimensional Information) - brza analiza zajedničkih višedimenzionalnih informacija, uključujući sljedeće zahtjeve za aplikacije za višedimenzionalnu analizu:

• Brzo(Brzo) - pružanje korisniku rezultata analize u prihvatljivom vremenu (obično ne duljem od 5 s), čak i po cijenu manje detaljne analize;
• Analiza(Analiza) - mogućnost provođenja bilo koje logičke i statističke analize specifične za određenu aplikaciju i spremanje iste u obliku dostupnom krajnjem korisniku;
• Podijeljeno(Zajednički) - višekorisnički pristup podacima uz podršku za odgovarajuće mehanizme zaključavanja i autorizirana sredstva pristupa;
• Višedimenzionalno(Multidimensional) - višedimenzionalni konceptualni prikaz podataka, uključujući punu podršku za hijerarhije i višestruke hijerarhije (ovo je ključni zahtjev OLAP-a);
• Informacija(Informacije) - aplikacija mora moći pristupiti svim potrebnim informacijama, bez obzira na njihovu količinu i mjesto pohrane.

Treba napomenuti da se OLAP funkcionalnost može implementirati različiti putevi, počevši od najjednostavnijih alata za analizu podataka u uredskim aplikacijama i završavajući s distribuiranim analitičkim sustavima temeljenim na poslužiteljskim proizvodima.

Višedimenzionalni prikaz informacija

kocke

OLAP pruža praktične, brze načine pristupa, pregledavanja i analiziranja poslovnih informacija. Korisnik dobiva prirodan, intuitivan model podataka, organizirajući ih u obliku višedimenzionalnih kocki (Cubes). Osi višedimenzionalnog koordinatnog sustava glavni su atributi analiziranog poslovnog procesa. Na primjer, za prodaju to može biti proizvod, regija, vrsta kupca. Vrijeme se koristi kao jedna od dimenzija. Na sjecištima mjernih osi (Dimensions) nalaze se podaci koji kvantitativno karakteriziraju proces – mjere (Measures). To mogu biti količine prodaje u komadima ili u novčanom iznosu, stanje zaliha, troškovi itd. Korisnik koji analizira informacije može "rezati" kocku u različitim smjerovima, dobiti sažetak (na primjer, po godini) ili, obrnuto, detaljan ( po tjednu ) informacije i provodi druge manipulacije koje mu padnu na pamet tijekom procesa analize.

Kao mjere u trodimenzionalnoj kocki prikazanoj na sl. 26.1 koriste se prodajni iznosi, a kao dimenzije vrijeme, proizvod i trgovina. Mjerenja su prikazana u određene razine grupiranja: proizvodi su grupirani po kategoriji, trgovine po državi, a podaci o vremenu transakcija po mjesecu. Malo kasnije ćemo detaljnije pogledati razine grupiranja (hijerarhije).

Riža. 26.1.

"Rezanje" kocke

Čak je i trodimenzionalnu kocku teško prikazati na zaslonu računala tako da su vrijednosti mjera od interesa vidljive. Što možemo reći o kockama s više od tri dimenzije? Za vizualizaciju podataka pohranjenih u kocki, u pravilu se koriste poznati dvodimenzionalni, tj. tablični prikazi sa složenim hijerarhijskim naslovima redaka i stupaca.

Dvodimenzionalni prikaz kocke može se dobiti "rezanjem" poprečno duž jedne ili više osi (dimenzija): fiksiramo vrijednosti svih dimenzija osim dvije i dobivamo pravilnu dvodimenzionalnu tablicu. Vodoravna os tablice (zaglavlja stupaca) predstavlja jednu dimenziju, okomita os (zaglavlja redaka) drugu, a ćelije tablice predstavljaju vrijednosti mjera. U ovom se slučaju skup mjera zapravo smatra jednom od dimenzija: ili odabiremo jednu mjeru za prikaz (a zatim možemo postaviti dvije dimenzije u naslove retka i stupca), ili prikazujemo nekoliko mjera (a zatim jednu od osi tablice će biti zauzete nazivima mjera, a druge vrijednostima jedine "nerezane" dimenzije).

Arhitektura OLAP aplikacija

Sve što je gore rečeno o OLAP-u u biti se odnosi na višedimenzionalnu prezentaciju podataka. Kako se podaci pohranjuju, grubo rečeno, ne tiče se krajnjeg korisnika niti programera alata koji klijent koristi.

Višedimenzionalnost u OLAP aplikacijama može se podijeliti u tri razine.

• Višedimenzionalni prikaz podataka - alati za krajnje korisnike koji pružaju višedimenzionalnu vizualizaciju i manipulaciju podacima; Višedimenzionalni prikazni sloj apstrahira fizičku strukturu podataka i tretira podatke kao višedimenzionalne.
• Višedimenzionalna obrada je sredstvo (jezik) za formuliranje višedimenzionalnih upita (tradicionalni relacijski jezik SQL ovdje nije prikladan) i procesor koji može obraditi i izvršiti takav upit.
• Višedimenzionalna pohrana je način fizičkog organiziranja podataka koji osigurava učinkovito izvršavanje višedimenzionalnih upita.

Prve dvije razine obavezne su u svim OLAP alatima. Treća razina, iako raširena, nije potrebna, jer se podaci za višedimenzionalni prikaz mogu izvući iz uobičajenih relacijskih struktura; Višedimenzionalni procesor upita u ovom slučaju prevodi višedimenzionalne upite u SQL upite koje izvršava relacijski DBMS.

Specifični OLAP proizvodi u pravilu su ili višedimenzionalni alat za prezentaciju podataka (OLAP klijent - na primjer, Pivot Tables u Excelu 2000 od Microsofta ili ProClarity od Knosysa) ili višedimenzionalni poslužiteljski DBMS (OLAP poslužitelj - na primjer, Oracle Express Server ili Microsoftove OLAP usluge).

Višedimenzionalni sloj obrade obično je ugrađen u OLAP klijent i/ili OLAP poslužitelj, ali se može izolirati u svom čistom obliku, kao što je Microsoftova komponenta Pivot Table Service.

/ Na kubistički način. Primjena OLAP kocki u upravljačkoj praksi velikih poduzeća

U kontaktu s

Kolege

Konstantin Tokmačev, arhitekt sustava

U kubističkom stilu.
Primjena OLAP kocki u upravljačkoj praksi velikih poduzeća

Možda je prošlo vrijeme kada su se računalni resursi korporacije trošili samo na bilježenje informacija i računovodstvenih izvješća. Pritom su se upravljačke odluke donosile “na oko” u uredima, na sastancima i sjednicama. Možda je u Rusiji došlo vrijeme da se korporativni računalni sustavi vrate njihovom glavnom resursu - rješavanju problema upravljanja na temelju podataka registriranih u računalu

O prednostima poslovne analitike

U petlji korporativnog upravljanja, između “sirovih” podataka i “poluga” utjecaja na objekt upravljanja nalaze se “indikatori uspješnosti” - KPI. Oni čine neku vrstu "kontrolne ploče", odražavajući stanje različitih podsustava kontroliranog objekta. Opremanje poduzeća informativnim pokazateljima uspješnosti te praćenje njihovog izračuna i dobivenih vrijednosti posao je poslovnog analitičara. Usluge automatizirane analize, poput uslužnog programa MS, mogu pružiti značajnu pomoć u organiziranju analitičkog rada korporacije. SQL poslužitelj Analysis Services (SSAS) i njegova glavna značajka je OLAP kocka.

Ovdje treba naglasiti još jednu stvar. Recimo, u američkoj tradiciji specijalnost usmjerena na rad s OLAP kockama zove se BI (Business Intelligence). Ne treba imati iluzija da američki BI odgovara ruskom “poslovnom analitičaru”. Bez uvrede, ali često je naš poslovni analitičar “podračunovođa” i “podprogramer”, stručnjak s nejasnim znanjem i malom plaćom, koji zapravo nema nikakav svoj alat i metodologiju.

BI specijalist je zapravo primijenjeni matematičar, visokokvalificirani stručnjak koji stavlja moderne matematičke metode u arsenal tvrtke (ono što se zvalo Operations Research - metode operacijskog istraživanja). BI je više u skladu sa specijalnošću "sistemski analitičar" koja je jednom u SSSR-u diplomirala na Fakultetu računalne matematike i matematike Moskovskog državnog sveučilišta. M.V. Lomonosov. OLAP kocka i usluge analize mogu postati obećavajuća osnova za radno mjesto ruskog poslovnog analitičara, možda nakon napredne obuke u smjeru američkog BI-a.

U U zadnje vrijeme Pojavio se još jedan štetan trend. Zahvaljujući specijalizaciji, izgubljeno je međusobno razumijevanje između različitih kategorija zaposlenika korporacije. Računovođa, menadžer i programer, poput “labuda, raka i štuke” u I.A.-ovoj basni. Krylov, vuku korporaciju u različitim smjerovima.

Računovođa je zaokupljen izvještavanjem, njegovi iznosi, kako u značenju tako iu dinamici, nisu direktno vezani uz poslovni proces poduzeća.

Menadžer je zauzet svojim dijelom poslovnog procesa, ali nije u mogućnosti globalno, na razini poduzeća kao cjeline, procijeniti rezultate i izglede svog djelovanja.

Konačno, programer koji je nekada (zahvaljujući svom obrazovanju) bio provodnik naprednih tehničkih ideja iz sfere znanosti u sferu poslovanja, pretvorio se u pasivnog izvršitelja fantazija računovođe i menadžera, pa nije više neuobičajeno da IT odjele korporacija vode računovođe i, općenito, svi kojima nije lijen. Nedostatak inicijative, nepismeni, ali relativno visoko plaćeni 1C programer prava je pošast ruskih korporacija. (Skoro kao domaći nogometaš.) O takozvanim “ekonomistima i pravnicima” da i ne govorim, o njima je sve već odavno rečeno.

Dakle, pozicija poslovnog analitičara, opremljenog SSAS aparatom koji temelji na znanju, vješt u osnovama programiranja i računovodstva, sposoban je konsolidirati rad tvrtke u odnosu na analizu i prognozu poslovnog procesa.

Prednosti OLAP kocki

OLAP kocka je moderni lijek analiza baze podataka korporativnog računalnog sustava, koja omogućava zaposlenicima na svim razinama hijerarhije pružiti potreban skup pokazatelja koji karakteriziraju proizvodni proces tvrtke. Poanta nije samo u tome da vam prikladno sučelje i fleksibilni jezik upita za MDX kocku (MultiDimensional eXpressions) omogućuju formuliranje i izračunavanje potrebnih analitičkih pokazatelja, već i nevjerojatna brzina i lakoća kojom OLAP kocka to radi. Štoviše, ta brzina i jednostavnost, u određenim granicama, ne ovise o složenosti izračuna i veličini baze podataka.

Neki uvod u OLAP-
kocka se može dati "zaokretnom tablicom" MS Excela. Ti objekti imaju sličnu logiku i slična sučelja. No, kao što će se vidjeti iz članka, OLAP funkcionalnost je neusporedivo bogatija, a performanse neusporedivo veće, pa “pivot table” ostaje lokalni desktop proizvod, dok je OLAP proizvod na razini poduzeća.

Zašto je OLAP kocka tako prikladna za rješavanje analitičkih problema? OLAP kocka je dizajnirana na način da su svi pokazatelji u svim mogućim dijelovima unaprijed izračunati (cijeli ili djelomično), a korisnik može samo "izvući" tražene pokazatelje (mjere) i dimenzije (dimenzije) s mišem, a program može ponovno crtati tablice.

Sva moguća analitika u svim dijelovima čini jedno ogromno polje, odnosno ne polje, već samo višedimenzionalnu OLAP kocku. Koji god zahtjev korisnik (menadžer, poslovni analitičar, rukovoditelj) uputi analitičkoj usluzi, brzina odgovora objašnjava se dvjema stvarima: prvo, potrebna analitika može se lako formulirati (bilo odabrati s popisa imenom ili specificirati formula u MDX jeziku ), drugo, u pravilu je već izračunata.

Formulacija analitike moguća je u tri opcije: to je ili polje baze podataka (odnosno polje skladišta), ili polje izračuna definirano na razini dizajna kocke, ili izraz MDX jezika pri interaktivnom radu s kockom.

To znači nekoliko atraktivnih značajki OLAP kocki. U biti, nestaje barijera između korisnika i podataka. Zapreka je u obliku aplikacijskog programera, koji najprije treba objasniti problem (postaviti zadatak). Drugo, morat ćete pričekati da aplikacijski programer izradi algoritam, napiše i ispravi program, a zatim ga eventualno modificira. Ako ima puno zaposlenika, a njihovi zahtjevi su raznoliki i promjenjivi, tada je potreban cijeli tim aplikativnih programera. U tom smislu OLAP kocka (i kvalificirani poslovni analitičar) zamjenjuje cijeli tim aplikativnih programera u analitičkom poslu, kao što moćni bager s bageristom zamjenjuje cijeli tim gastarbajtera s lopatama pri kopanju jarka!

Ujedno se postiže još jedna vrlo važna kvaliteta dobivenih analitičkih podataka. Budući da postoji samo jedna OLAP kocka za cijelu tvrtku, tj. Ovo je isto polje s analitičarima za sve, što eliminira dosadna odstupanja u podacima. Kada menadžer mora postaviti isti zadatak nekolicini neovisnih zaposlenika kako bi eliminirao faktor subjektivnosti, ali oni i dalje donose različite odgovore, koje se svatko obvezuje nekako objasniti itd. OLAP kocka osigurava ujednačenost analitičkih podataka na različitim razinama korporativne hijerarhije, tj. ako rukovoditelj želi detaljizirati određeni pokazatelj koji ga zanima, tada će sigurno doći do podataka niže razine s kojima radi njegov podređeni, a to će biti upravo podaci na temelju kojih je izračunat pokazatelj više razine , a ne neki drugi podatak, dobiven na neki drugi način, u neko drugo vrijeme i sl. Odnosno, cijela tvrtka vidi istu analitiku, ali na različitim razinama agregacije.

Navedimo primjer. Recimo da upravitelj kontrolira potraživanja. Sve dok je KPI za dospjela potraživanja zelen, to znači da je sve normalno i da nisu potrebne nikakve radnje menadžmenta. Ako se boja promijenila u žutu ili crvenu, nešto nije u redu: režemo KPI-ove po prodajnim odjelima i odmah vidimo odjele "crveno". Sljedeći odjeljak po menadžerima - i identificira se prodavač čiji klijenti kasne s plaćanjem. (Nadalje, dospjeli iznos može se podijeliti prema kupcima, prema uvjetima itd.) Šef korporacije može izravno kontaktirati prekršitelje na bilo kojoj razini. Ali općenito, isti KPI (na njihovim razinama hijerarhije) vide i voditelji odjela i menadžeri prodaje. Stoga, da bi ispravili situaciju, ne trebaju čak ni čekati “poziv na tepih”... Naravno, sam KPI ne mora nužno biti iznos zakašnjelih plaćanja - to može biti ponderirano prosječno razdoblje dospjelih plaćanja ili, općenito, stopa obrta potraživanja.

Napomenimo da nam složenost i fleksibilnost MDX jezika, zajedno s brzim (ponekad trenutnim) rezultatima, omogućuje rješavanje (uzimajući u obzir faze razvoja i otklanjanja pogrešaka) složenih zadataka upravljanja koji inače uopće ne bi bili postavljeni zbog složenosti za programere aplikacija i početne nesigurnosti u formulaciji. (U praksi se često susreću dugi rokovi aplikativnim programerima za rješavanje analitičkih problema zbog slabo razumljivih formulacija i dugih modifikacija programa pri promjeni uvjeta.)

Obratimo pozornost i na činjenicu da svaki zaposlenik tvrtke može od općeg polja OLAP analitičara prikupiti točno onu žetvu koja mu je potrebna za njegov rad, a ne biti zadovoljan "trakom" koja mu je izrezana u komunalnom “standardna izvješća”.

Višekorisničko sučelje za rad s OLAP kockom u načinu rada klijent-poslužitelj omogućuje svakom zaposleniku, neovisno o drugima, vlastite (čak i vlastite izrade s određenom vještinom) analitičke blokove (izvješća), koji se nakon definiranja automatski ažurirani - drugim riječima, uvijek su ažurni.

Odnosno, OLAP kocka vam omogućuje da analitički rad (koji zapravo ne provode samo analitičari recepcije, već zapravo gotovo svi zaposlenici tvrtke, čak i logističari i menadžeri koji kontroliraju stanja i pošiljke) bude selektivniji, “ne općenito” čime se stvaraju uvjeti za poboljšanje rada i povećanje produktivnosti.

Da rezimiramo naš uvod, napominjemo da korištenje OLAP kocki može podići upravljanje tvrtkom za više visoka razina. Ujednačenost analitičkih podataka na svim razinama hijerarhije, njihova pouzdanost, složenost, jednostavnost kreiranja i modificiranja indikatora, individualne postavke, velika brzina obrade podataka, te u konačnici ušteda novca i vremena utrošenog na podršku alternativnim analitičkim putovima (aplikativni programeri, neovisni izračuni zaposlenika) otvaraju izglede za korištenje OLAP kocki u praksi velikih ruskih tvrtki.

OLTP + OLAP: povratna sprega u lancu upravljanja tvrtkom

Sada pogledajmo opću ideju OLAP kocki i njihovu točku primjene u lancu korporativnog upravljanja. Termin OLAP (OnLine Analytical Processing) uveo je britanski matematičar Edgar Codd uz svoj ranije uvedeni termin OLTP (OnLine Transactions Processing). O tome će biti riječi kasnije, ali E. Codd je, naravno, predložio ne samo pojmove, već i matematičke teorije OLTP-a i OLAP-a. Ne ulazeći u detalje, u suvremenoj interpretaciji OLTP je relacijska baza podataka, koja se smatra mehanizmom za snimanje, pohranu i dohvaćanje informacija.

Metodologija rješenja

ERP sustavi (Enterprice Resource Planning), kao što su 1C7, 1C8, MS Dynamics AX, imaju korisnički orijentirana softverska sučelja (unos i uređivanje dokumenata, itd.) i relacijsku bazu podataka (DB) za pohranu i dohvaćanje informacija koje su danas predstavljene softverski proizvodi tipa MS SQL Server (SS).

Imajte na umu da su podaci registrirani u bazi podataka ERP sustava zaista vrlo vrijedan resurs. Nije stvar samo u tome da registrirani podaci osiguravaju trenutni protok dokumenata u korporaciji (vađenje dokumenata, njihovo ispravljanje, mogućnost ispisa i usklađivanja itd.), a ne samo mogućnost obračuna financijska izvješća(porezi, revizija itd.). Sa stanovišta upravljanja puno je važnije da je OLTP sustav (relacijska baza podataka) zapravo stvarni digitalni model aktivnosti korporacije u prirodnoj veličini.

Ali za upravljanje procesom nije dovoljno registrirati podatke o njemu. Proces treba predstaviti u obliku sustava numeričkih pokazatelja (KPI) koji karakteriziraju njegov napredak. Osim toga, prihvatljivi rasponi vrijednosti moraju biti definirani za indikatore. I samo ako vrijednost indikatora padne izvan dopuštenog intervala, treba slijediti kontrolna radnja.

Što se tiče takve logike (ili mitologije) kontrole (“kontrole devijacijom”), oboje starogrčki filozof Platon, koji je stvorio sliku kormilara (cybernose), koji se oslanja na veslo kada čamac skrene s kursa, i američki matematičar Norbert Wiener, koji je stvorio znanost kibernetike na pragu računalne ere.

Uz uobičajeni sustav za evidentiranje informacija OLTP metodom, potreban je još jedan sustav - sustav za analizu prikupljenih informacija. Ovaj dodatak, koji u kontrolnoj petlji ima ulogu povratne veze između menadžmenta i kontrolnog objekta, je OLAP sustav ili, ukratko, OLAP kocka.

Kao softversku implementaciju OLAP-a, razmotrit ćemo uslužni program MS Analysis Services, koji je dio standardne isporuke MS SQL Servera, skraćeno SSAS. Imajte na umu da bi, prema planu E. Codda, OLAP kocka u analitici trebala dati istu sveobuhvatnu slobodu djelovanja koju pružaju OLTP sustav i relacijska baza podataka (SQL Server) u pohranjivanju i dohvaćanju informacija.

OLAP logistika

Pogledajmo sada konkretnu konfiguraciju vanjskih uređaja, aplikacijskih programa i tehnoloških operacija na kojima se temelji automatizirani rad OLAP kocke.

Pretpostavit ćemo da korporacija koristi ERP sustav, na primjer, 1C7 ili 1C8, unutar kojeg se informacije bilježe kao i obično. Baza podataka ovog ERP sustava nalazi se na određenom poslužitelju i podržava je MS SQL Server.

Također ćemo pretpostaviti da drugi poslužitelj ima instaliran softver, uključujući MS SQL Server s uslužnim programom MS Analysis Services (SSAS), kao i MS SQL Server Management Studio, MS C#, MS Excel i MS Visual Studio. Ovi programi zajedno čine potrebni kontekst: alate i potrebna sučelja za programere OLAP kocki.

SSAS poslužitelj ima slobodno distribuiran program pod nazivom blat, koji se poziva (s parametrima) iz naredbeni redak i pružanje poštanskih usluga.

Na radnim mjestima zaposlenika, unutar lokalna mreža, između ostalog, instalirani su MS Excel programi (verzije ne manje od 2003.) te, eventualno, poseban upravljački program koji osigurava rad MS Excela s MS Analysis Services (osim ako odgovarajući upravljački program nije već uključen u MS Excel).

Definitivnosti radi pretpostavit ćemo da je na radnim stanicama zaposlenika instaliran operativni sustav Windows XP, a na poslužiteljima Windows Server 2008. Uz to, kao SQL Server koristimo MS SQL Server 2005, a instalirano Enterprise Edition (EE) na poslužitelju s OLAP kockom) ili Developer Edition (DE). U ovim izdanjima moguće je koristiti tzv. “poluaditivne mjere”, tj. dodatne agregatne funkcije (statistike) osim uobičajenih zbrojeva (na primjer, ekstrem ili prosjek).

Dizajn OLAP kocke (OLAP kubizam)

Recimo nekoliko riječi o dizajnu same OLAP kocke. Jezikom statistike, OLAP kocka je skup pokazatelja performansi izračunatih u svim potrebnim odjeljcima, na primjer, indikator otpreme u odjeljcima po kupcima, po robi, po datumima itd. Zbog izravnog prijevoda s engleskog u ruskoj literaturi o OLAP kockama, indikatori se nazivaju "mjere", a odjeljci se nazivaju "dimenzije". Ovo je matematički točan, ali sintaktički i semantički ne baš uspješan prijevod. Ruske riječi "mjera", "dimenzija", "dimenzija" gotovo su iste u značenju i pisanju, dok su engleske "mjera" i "dimenzija" različite u pisanju i značenju. Stoga dajemo prednost tradicionalnim ruskim statističkim izrazima "pokazatelj" i "rez", koji su slični po značenju.

Postoji nekoliko mogućnosti programske implementacije OLAP kocke u odnosu na OLTP sustav gdje se bilježe podaci. Razmotrit ćemo samo jednu shemu, najjednostavniju, najpouzdaniju i najbržu.

U ovom dizajnu, OLAP i OLTP ne dijele tablice, a OLAP analitika izračunava se što je moguće detaljnije tijekom faze ažuriranja kocke (Proces), koja prethodi fazi upotrebe. Ova shema se zove MOLAP (Multidimensional OLAP). Njegovi nedostaci su asinkronija s ERP-om i visoki troškovi memorije.

Iako se formalno OLAP kocka može izgraditi korištenjem svih (tisuća) tablica relacijske baze podataka ERP sustava kao izvora podataka i svih (stotina) njihovih polja kao indikatora ili odjeljaka, u stvarnosti to ne bi trebalo biti učinjeno. Obratno. Za učitavanje u kocku ispravnije je pripremiti zasebnu bazu podataka, nazvanu "izlog" ili "skladište".

Na to nas tjera nekoliko razloga.

• Prvo, vezanje OLAP kocke na tablice prava baza podaci sigurno će stvoriti tehničke probleme. Promjena podataka u tablici može pokrenuti osvježavanje kocke, a osvježavanje kocke nije nužno brz proces, tako da će kocka biti u stanju stalne ponovne izgradnje; Istovremeno, procedura ažuriranja kocke može blokirati (prilikom čitanja) podatke tablica baze podataka, usporavajući rad korisnika pri registraciji podataka u ERP sustavu.
• Drugo, Previše indikatora i rezova dramatično će povećati prostor za pohranu kocke na poslužitelju. Ne zaboravimo da OLAP kocka ne pohranjuje samo izvorne podatke, kao u OLTP sustavu, već i sve pokazatelje zbrane po svim mogućim dijelovima (pa čak i svim kombinacijama svih odjeljaka). Osim toga, brzina ažuriranja kocke i, u konačnici, brzina izgradnje i ažuriranja analitike i korisničkih izvješća koja se temelje na njima će se sukladno tome usporiti.
• Treći, previše polja (indikatora i odjeljaka) stvarat će probleme u OLAP developer sučelju, jer popisi elemenata postat će golemi.
• četvrto, OLAP kocka je vrlo osjetljiva na povrede integriteta podataka. Kocka se ne može izgraditi ako se ključni podaci ne nalaze na poveznici navedenoj u strukturi veza polja kocke. Privremena ili trajna kršenja integriteta, prazna polja uobičajena su u bazi podataka ERP sustava, ali to apsolutno nije prikladno za OLAP.

Također možete dodati da ERP sustav i OLAP kocka trebaju biti smješteni na različitim poslužiteljima kako bi podijelili opterećenje. No onda, ako postoje zajedničke tablice za OLAP i OLTP, javlja se i problem mrežnog prometa. Praktično nerješivi problemi nastaju u ovom slučaju kada je potrebno konsolidirati nekoliko različitih ERP sustava (1C7, 1C8, MS Dynamics AX) u jednu OLAP kocku.

Vjerojatno možemo nastaviti gomilati tehničke probleme. Ali što je najvažnije, upamtite da, za razliku od OLTP-a, OLAP nije sredstvo za snimanje i pohranu podataka, već analitički alat. To znači da nema potrebe prenositi i preuzimati "prljave" podatke iz ERP-a u OLAP "za svaki slučaj". Naprotiv, prvo morate razviti koncept upravljanja tvrtkom, barem na razini KPI sustava, a zatim dizajnirati aplikacijsko skladište podataka (skladište), koje se nalazi na istom poslužitelju kao i OLAP kocka, a sadrži mali , pročišćena količina podataka iz ERP-a potrebnih za upravljanje.

Bez promicanja loše navike, OLAP kocka u odnosu na OLTP može se usporediti s dobro poznatom "mirnom kockom", kroz koju se "čisti proizvod" izdvaja iz "fermentirane mase" stvarne registracije.

Dakle, dobili smo da je izvor podataka za OLAP posebna baza podataka (skladište), koja se nalazi na istom poslužitelju kao i OLAP. Općenito to znači dvije stvari. Prvo, moraju postojati posebne procedure koje će kreirati skladište od ERP baza podataka. Drugo, OLAP kocka je asinkrona sa svojim ERP sustavima.

Uzimajući u obzir gore navedeno, predlažemo sljedeću verziju arhitekture računalnog procesa.

Arhitektura rješenja

Pretpostavimo da postoji mnogo ERP sustava određene korporacije (holdinga) smještenih na različitim poslužiteljima, analitički podaci za koje bismo željeli da budu konsolidirani unutar jedne OLAP kocke. Ističemo da u opisanoj tehnologiji objedinjujemo podatke iz ERP sustava na razini skladišta, ostavljajući dizajn OLAP kocke nepromijenjen.

Na OLAP serveru kreiramo slike (prazne kopije) baza podataka svih ovih ERP sustava. Povremeno (svake noći) izvodimo djelomičnu replikaciju odgovarajućih aktivnih ERP baza podataka na te prazne kopije.

Zatim se pokreće SP (stored procedure) koji na istom OLAP poslužitelju bez mrežnog prometa, na temelju parcijalnih replika baza podataka ERP sustava, kreira (ili nadopunjuje) skladište (warehouse) - izvor podataka OLAP kocke.

Zatim se pokreće standardna procedura za ažuriranje/izgradnju kocke na temelju skladišnih podataka (Operacija procesa u SSAS sučelju).

Komentirajmo neke aspekte tehnologije. Kakvu vrstu posla rade SP-ovi?

Kao rezultat djelomične replikacije, trenutni podaci pojavljuju se na slici nekog ERP sustava na OLAP poslužitelju. Usput, djelomična replikacija može se izvesti na dva načina.

Prvo, iz svih tablica u bazi podataka ERP sustava, tijekom djelomične replikacije, kopiraju se samo one koje su potrebne za izgradnju skladišta. Ovo je kontrolirano fiksnim popisom naziva tablica.

Drugo, djelomična replikacija također može značiti da se ne kopiraju sva polja tablice, već samo ona koja su uključena u izgradnju skladišta. Popis polja za kopiranje je naveden ili dinamički kreiran u SP-u na slici kopije (ako nisu sva polja inicijalno prisutna u kopiji tablice).

Naravno, moguće je ne kopirati cijele retke tablice, već samo dodati nove zapise. Međutim, to stvara ozbiljne neugodnosti kada se ERP revizije obračunavaju "retroaktivno", što je često slučaj u stvarnim sustavima. Stoga je lakše, bez daljnjeg odlaganja, kopirati sve zapise (ili ažurirati "rep" počevši od određenog datuma).

Zatim, glavni zadatak SP-a je pretvoriti podatke ERP sustava u skladišni format. Ako postoji samo jedan ERP sustav, tada se zadatak konverzije uglavnom svodi na kopiranje i eventualno preformatiranje potrebnih podataka. Ali ako trebate konsolidirati nekoliko ERP sustava u istoj OLAP kocki različite strukture, tada transformacije postaju kompliciranije.

Zadatak objedinjavanja nekoliko različitih ERP sustava u kocku posebno je težak ako se skupovi njihovih objekata (imenici robe, izvođači, skladišta itd.) djelomično preklapaju, objekti imaju isto značenje, ali su prirodno različito opisani u imenicima. različitim sustavima(u smislu kodova, identifikatora, imena itd.).

U stvarnosti, takva slika nastaje u velikom holdingu, kada nekoliko njegovih sastavnih autonomnih društava iste vrste obavljaju približno iste vrste djelatnosti na približno istom području, ali koriste vlastite i neusuglašene sustave registracije. U ovom slučaju, kada konsolidirate podatke na razini skladišta, ne možete bez pomoćnih tablica mapiranja.

Obratimo malo pozornosti na arhitekturu skladištenja. Obično je shema OLAP kocke predstavljena u obliku "zvijezde", tj. kao podatkovna tablica okružena “zrakama” direktorija - tablice sekundarnih ključnih vrijednosti. Tablica je blok "indikatora", a referentne knjige su njihovi dijelovi. U ovom slučaju, imenik, pak, može biti proizvoljno neuravnoteženo stablo ili uravnotežena hijerarhija, na primjer, višerazinska klasifikacija robe ili izvođača. U OLAP kocki, numerička polja podatkovne tablice iz skladišta automatski postaju "indikatori" (ili mjere), a odjeljci (ili dimenzije) mogu se definirati pomoću tablica sekundarnih ključeva.

Ovo je vizualni “pedagoški” opis. Zapravo, arhitektura OLAP kocke može biti mnogo složenija.

Prvo, skladište se može sastojati od nekoliko "zvjezdica", koje su moguće povezane preko zajedničkih imenika. U ovom slučaju, OLAP kocka će biti unija nekoliko kocki (nekoliko podatkovnih blokova).

Drugo, "zraka" zvjezdice može biti ne samo jedan direktorij, već cijeli (hijerarhijski) sustav datoteka.

Treće, na temelju postojećih odjeljaka dimenzija, novi hijerarhijski odjeljci mogu se definirati pomoću alata OLAP razvojnog sučelja (recimo, s manje razina, s drugačijim redoslijedom razina, itd.)

Četvrto, na temelju postojećih indikatora i odjeljaka, korištenjem MDX jezičnih izraza, mogu se definirati novi indikatori (izračuni). Važno je napomenuti da su nove kocke, novi indikatori, novi odjeljci automatski potpuno integrirani s izvornim elementima. Također treba napomenuti da loše formulirani izračuni i hijerarhijski odjeljci mogu značajno usporiti rad OLAP kocke.

MS Excel kao sučelje s OLAP-om

Posebno je zanimljivo korisničko sučelje s OLAP kockama. Naravno, najpotpunije sučelje pruža sam uslužni program SSAS. To uključuje alat za razvoj OLAP kocke, interaktivni dizajner izvješća i prozor za interaktivni rad s OLAP kockom pomoću upita u MDX jeziku.

Osim samog SSAS-a, postoji mnogo programa koji pružaju sučelje za OLAP, pokrivajući njihovu funkcionalnost u većoj ili manjoj mjeri. Ali među njima postoji jedan, koji, po našem mišljenju, ima neporecive prednosti. Ovo je MS Excel.

Sučelje s MS Excelom pruža poseban upravljački program, koji se može zasebno preuzeti ili je uključen u distribuciju programa Excel. Ne pokriva sve funkcionalnosti OLAP-a, ali s porastom broja verzija MS Excela, ta pokrivenost postaje sve šira (primjerice, u MS Excelu 2007 pojavljuje se grafički prikaz KPI-a, što nije bilo u MS Excelu 2003 itd. ).

Naravno, uz njegovu prilično potpunu funkcionalnost, glavna prednost MS Excela je široka distribucija ovog programa i blisko poznavanje ogromnog broja uredskih korisnika. U tom smislu, za razliku od drugih programa za sučelja, tvrtka ne treba ništa dodatno kupovati niti treba ikoga dodatno obučavati.

Velika prednost MS Excela kao sučelja s OLAP-om je mogućnost daljnje samostalne obrade podataka dobivenih u OLAP izvješću (tj. nastaviti proučavati podatke dobivene iz OLAP-a na drugim listovima istog Excela, ne koristeći više OLAP alate, već koristeći obične Excel alate).

Facubi noćni ciklus tretmana

Sada ćemo opisati dnevni (noćni) računski ciklus rada OLAP-a. Izračun se provodi pod kontrolom programa facubi, napisanog u C# 2005 i pokrenutog preko Task Scheduler-a na poslužitelju sa skladištem i SSAS-om. Na početku, facubi ide na Internet i čita trenutne tečajeve (koristi se za predstavljanje niza pokazatelja u valuti). Zatim izvršite sljedeće korake.

Najprije facubi lansira SP-ove koji izvode djelomičnu replikaciju baza podataka različitih ERP sustava (elemenata držanja) dostupnih na lokalnoj mreži. Replikacija se vrši, kao što smo rekli, na unaprijed pripremljene “pozadine” – slike udaljenih ERP sustava koji se nalaze na SSAS poslužitelju.

Drugo, putem SP-a vrši se preslikavanje iz ERP replika u skladište skladišta - poseban DB, koji je izvor podataka OLAP kocke i nalazi se na SSAS poslužitelju. U ovom slučaju rješavaju se tri glavna zadatka:

• ERP podaci prilagođeni traženim formatima kocke; Govorimo i o tablicama i o poljima tablica. (Ponekad potrebnu tablicu treba "oblikovati", recimo, iz nekoliko MS Excel listova.) Slični podaci mogu imati različite formate u različitim ERP-ovima, na primjer, ključna ID polja u 1C7 imenicima imaju 36-znamenkasti kod znakova duljine 8 , i _idrref polja u imenicima 1S8 – heksadecimalni brojevi duljine 32;
• tijekom obrade provodi se logička kontrola podataka (uključujući pisanje "zadanih vrijednosti" umjesto podataka koji nedostaju, gdje je to moguće) i kontrola cjelovitosti, tj. provjera prisutnosti primarnih i sekundarnih ključeva u odgovarajućim klasifikatorima;
• konsolidacija koda objekti koji imaju isto značenje u različitim ERP-ovima. Na primjer, odgovarajući elementi imenika različitih ERP-ova mogu imati isto značenje, recimo, oni su ista druga strana. Problem konsolidacije kodova rješava se konstruiranjem tablica preslikavanja, gdje se različiti kodovi istih objekata dovode u jedinstvo.

Treće, facubi pokreće standardnu ​​proceduru za ažuriranje podataka kocke procesa (iz procedura uslužnog programa SSAS).

Na temelju popisa za provjeru facubi šalje e-poruke o tijeku koraka obrade.

Nakon izvršavanja facubi, Task Scheduler pokreće nekoliko excel datoteka naizmjenično, u kojima su izvješća unaprijed kreirana na temelju indikatora OLAP kocke. Kao što smo rekli, MS Excel ima posebno softversko sučelje (zasebno preuzimanje ili ugrađeni upravljački program) za rad s OLAP kockama (sa SSAS-om). Kada pokrenete MS Excel, aktiviraju se MS VBA programi (kao što su makronaredbe) koji osiguravaju ažuriranje podataka u izvješćima; izvještaji se po potrebi modificiraju i šalju poštom (blat program) korisnicima prema kontrolnim listama.

Korisnici lokalne mreže s pristupom SSAS poslužitelju primit će izvješća "uživo" konfigurirana za OLAP kocku. (U principu, oni sami, bez ikakve pošte, mogu ažurirati OLAP izvješća u MS Excelu koji se nalaze na njihovim lokalnim računalima.) Korisnici izvan lokalne mreže će ili dobiti izvorna izvješća, ali s ograničenom funkcionalnošću, ili za njih (nakon ažuriranja OLAP-a) izvješća u MS Excelu) izračunat će se posebna “mrtva” izvješća koja ne pristupaju SSAS poslužitelju.

Evaluacija rezultata

Gore smo govorili o asinkroniji OLTP-a i OLAP-a. U tehnološkoj varijanti koja se razmatra, ciklus ažuriranja OLAP kocke se izvodi noću (recimo, počinje u 1 sat ujutro). To znači da u tekućem radnom danu korisnici rade s jučerašnjim podacima. Budući da OLAP nije alat za snimanje (pogledajte posljednju reviziju dokumenta), već alat za upravljanje (razumijte trend procesa), takvo kašnjenje obično nije kritično. Međutim, ako je potrebno, čak iu opisanoj verziji kockaste arhitekture (MOLAP), ažuriranje se može provesti nekoliko puta dnevno.

Vrijeme izvršenja procedura ažuriranja ovisi o značajkama dizajna OLAP kocke (veća ili manja složenost, više ili manje uspješne definicije indikatora i odjeljaka) i o volumenu baza podataka vanjskih OLTP sustava. Prema iskustvu, procedura izgradnje skladišta traje od nekoliko minuta do dva sata, procedura ažuriranja kocke (Proces) traje od 1 do 20 minuta. Govorimo o složenim OLAP kockama koje ujedinjuju desetke zvjezdastih struktura, desetke zajedničkih "zraka" (referentnih odjeljaka) za njih i stotine indikatora. Procjenjujući obujam baza podataka vanjskih ERP sustava na temelju otpremnih dokumenata, govorimo o stotinama tisuća dokumenata i, sukladno tome, milijunima linija proizvoda godišnje. Povijesna dubina obrade od interesa za korisnika bila je tri do pet godina.

Opisana tehnologija korištena je u nizu velikih korporacija: od 2008. u Russian Fish Company (RRK) i Russian Sea company (RM), od 2012. u tvrtki Santa Bremor (SB). Neke su korporacije prvenstveno tvrtke za trgovinu i nabavu (PPC), druge su proizvodne tvrtke (pogoni za preradu ribe i plodova mora u Republici Moldaviji i Republici Bjelorusiji). Sve korporacije su veliki holdingi, koji ujedinjuju nekoliko tvrtki sa neovisnim i različitim računalnim računovodstvenim sustavima - u rasponu od standardnih ERP sustava kao što su 1C7 i 1C8 do "reliktnih" računovodstvenih sustava temeljenih na DBF-u i Excelu. Dodat ću da opisana tehnologija rada OLAP kocki (bez uzimanja u obzir faze razvoja) ili uopće ne zahtijeva posebne zaposlenike, ili je odgovornost jednog stalno zaposlenog poslovnog analitičara. Zadatak se već godinama izvršava automatski, pružajući svakodnevno ažurna izvješća različitim kategorijama zaposlenika poduzeća.

Prednosti i mane rješenja

Iskustvo pokazuje da je predloženo rješenje prilično pouzdano i jednostavno za korištenje. Lako se mijenja (spajanje/isključivanje novih ERP-ova, kreiranje novih indikatora i odjeljaka, kreiranje i modificiranje Excel izvješća i njihovih mailing lista) uz nepromjenjivost facubi kontrolnog programa.

MS Excel kao sučelje s OLAP-om pruža dovoljnu izražajnost i omogućava različitim kategorijama uredskih zaposlenika brzo upoznavanje s OLAP tehnologijom. Korisnik prima dnevna "standardna" OLAP izvješća; korištenjem MS Excel sučelja s OLAP-om može samostalno kreirati OLAP izvještaje u MS Excelu. Osim toga, korisnik može samostalno nastaviti proučavati informacije OLAP izvješća koristeći uobičajene mogućnosti svog MS Excela.

„Rafinirana“ skladišna baza podataka, u kojoj je nekoliko heterogenih ERP sustava konsolidirano (tijekom izgradnje kocke), čak i bez ikakvog OLAP-a, omogućuje rješavanje (na SSAS poslužitelju, korištenjem metode upita u Transact SQL ili SP metode) , itd.) mnogi primijenjeni problemi upravljanja. Podsjetimo, struktura baze podataka skladišta je unificirana i puno jednostavnija (u smislu broja tablica i broja polja tablice) od strukture baze podataka izvornog ERP-a.

Posebno ističemo da u našem predloženom rješenju postoji mogućnost objedinjavanja različitih ERP sustava u jednu OLAP kocku. To vam omogućuje da dobijete analitiku za cijeli holding i održite dugoročni kontinuitet u analitici kada se korporacija preseli na drugi računovodstveni ERP sustav, recimo, kada pređete sa 1C7 na 1C8.

Koristili smo model kocke MOLAP. Prednosti ovog modela su pouzdanost u radu i velika brzina obrade zahtjeva korisnika. Nedostaci: OLAP i OLTP su asinkroni, kao i velike količine memorije za pohranu OLAP-a.

Zaključno, evo još jednog argumenta u korist OLAP-a koji je možda bio prikladniji u srednjem vijeku. Jer njegova dokazna snaga počiva na autoritetu. Skromni, očito podcijenjeni britanski matematičar E. Codd razvio je teoriju relacijskih baza podataka u kasnim 60-ima. Snaga ove teorije bila je tolika da je sada, nakon 50 godina, već teško pronaći nerelacijsku bazu podataka i upitni jezik baze podataka osim SQL-a.

OLTP tehnologija, temeljena na teoriji relacijskih baza podataka, bila je prva ideja E. Codda. Zapravo, koncept OLAP kocki njegova je druga ideja koju je izrazio ranih 90-ih. Čak i ako niste matematičar, možete očekivati ​​da će druga ideja biti jednako učinkovita kao i prva. Odnosno, u smislu računalne analitike, OLAP ideje će uskoro preuzeti svijet i istisnuti sve ostale. Jednostavno zato što tema analitike nalazi svoje sveobuhvatno matematičko rješenje u OLAP-u, a to je rješenje „adekvatno“ (pojam B. Spinoze) praktičnom problemu analitike. “Adekvatno” znači kod Spinoze da sam Bog nije mogao smisliti ništa bolje...

1. Larson B. Razvoj poslovne analitike u Microsoft SQL Server 2005. – St. Petersburg: “Peter”, 2008.
2. Codd E. Relational Completeness of Data Base Sublanguages, Data Base Systems, Courant Computer Science Sumposia Series 1972, v. 6, Englwood cliffs, N.Y., Prentice – Hall.

U kontaktu s

Općenito, svaki stručnjak zna što je OLAP danas. Barem su pojmovi "OLAP" i "višedimenzionalni podaci" čvrsto povezani u našim umovima. Ipak, činjenica da se ova tema ponovno pokreće, nadam se, odobrit će većina čitatelja, jer kako ideja o nečemu ne bi s vremenom zastarjela, potrebno je povremeno komunicirati s pametni ljudi ili pročitajte članke u dobroj publikaciji...

Skladišta podataka (mjesto OLAP-a u informacijskoj strukturi poduzeća)

Pojam „OLAP“ neraskidivo je povezan s pojmom „skladište podataka“ (Data Warehouse).

Evo definicije koju je formulirao "otac utemeljitelj" skladištenja podataka, Bill Inmon: "Skladište podataka je domenski određena, vremenski ograničena, nepromjenjiva zbirka podataka za podršku donošenju odluka u upravljanju."

Podaci u skladište dolaze iz operativnih sustava (OLTP sustava) koji su namijenjeni automatizaciji poslovnih procesa. Osim toga, repozitorij se može nadopunjavati iz vanjskih izvora, kao što su statistička izvješća.

Zašto graditi skladišta podataka - uostalom, ona sadrže očito suvišne informacije koje već "žive" u bazama podataka ili datotekama operacijskog sustava? Odgovor može biti kratak: nemoguće je ili vrlo teško izravno analizirati podatke iz operativnih sustava. To je zbog različitih razloga, uključujući fragmentaciju podataka, njihovu pohranu u različitim formatima DBMS-a iu različitim "kutovima" korporativne mreže. Ali čak i ako poduzeće pohranjuje sve svoje podatke na središnji poslužitelj baze podataka (što je izuzetno rijetko), analitičar gotovo sigurno neće razumjeti njihove složene, ponekad zbunjujuće strukture. Autor ima prilično tužno iskustvo pokušaja “nahraniti” gladne analitičare “sirovim” podacima iz operativnih sustava - pokazalo se da im je to “previše”.

Dakle, svrha repozitorija je pružiti “sirovi materijal” za analizu na jednom mjestu iu jednostavnoj, razumljivoj strukturi. Ralph Kimball, u predgovoru svoje knjige "The Data Warehouse Toolkit", piše da ako, nakon čitanja cijele knjige, čitatelj razumije samo jednu stvar - naime, da struktura skladišta treba biti jednostavna - autor će smatrati svojim zadatak izvršen.

Postoji još jedan razlog koji opravdava pojavu zasebnog skladišnog prostora - složeni analitički upiti za operativnim informacijama usporavaju trenutni rad tvrtke, dugotrajno blokiraju tablice i oduzimaju resurse poslužitelja.

Po mom mišljenju, repozitorij ne znači nužno ogromnu akumulaciju podataka - glavna stvar je da je prikladan za analizu. Općenito govoreći, postoji poseban izraz za male skladišne ​​objekte - Data Marts (kiosci za podatke), ali u našoj ruskoj praksi to se rijetko čuje.

OLAP - praktičan alat za analizu

Centralizacija i prikladno strukturiranje nisu sve što je potrebno analitičaru. I dalje mu treba alat za gledanje i vizualizaciju informacija. Tradicionalnim izvješćima, čak i onima izgrađenim na jednom repozitoriju, nedostaje jedna stvar - fleksibilnost. Ne mogu se "zaokrenuti", "proširiti" ili "skupiti" da bi se dobio željeni prikaz podataka. Naravno, možete pozvati programera (ako želi doći), a on će (ako nije zauzet) napraviti novi izvještaj dovoljno brzo - recimo u roku od sat vremena (ovo pišem i ne vjerujem sam - to se u životu ne događa tako brzo; dajmo mu tri sata) . Ispada da analitičar ne može testirati više od dvije ideje dnevno. A on (ako je dobar analitičar) može doći do nekoliko takvih ideja na sat. I što analitičar vidi više "odsječaka" i "odsječaka" podataka, to ima više ideja, koje zauzvrat zahtijevaju sve više i više "odsječaka" za provjeru. Kad bi barem imao alat koji bi mu omogućio jednostavno i praktično proširivanje i sažimanje podataka! OLAP djeluje kao takav alat.

Iako OLAP nije nužan atribut skladišta podataka, sve se više koristi za analizu informacija akumuliranih u skladištu.

Komponente uključene u tipično spremište prikazane su na sl. 1.

Riža. 1. Struktura skladišta podataka

Operativni podaci prikupljaju se iz različitih izvora, čiste, integriraju i pohranjuju u relacijsku pohranu. Štoviše, već su dostupni za analizu pomoću različitih alata za izvješćivanje. Zatim se podaci (cijeli ili djelomično) pripremaju za OLAP analizu. Mogu se učitati u posebnu OLAP bazu podataka ili pohraniti u relacijsku pohranu. Njegov najvažniji element su metapodaci, odnosno informacije o strukturi, smještaju i transformaciji podataka. Zahvaljujući njima, osigurana je učinkovita interakcija različitih komponenti za pohranu.

Ukratko, OLAP možemo definirati kao skup alata za višedimenzionalnu analizu podataka akumuliranih u skladištu. Teoretski, OLAP alati mogu se primijeniti izravno na operativne podatke ili njihove točne kopije (kako ne bi ometali operativne korisnike). Ali time riskiramo da stanemo na već opisane grablje, odnosno počnemo analizirati operativne podatke koji nisu izravno pogodni za analizu.

Definicija i osnovni pojmovi OLAP-a

Prvo dešifriramo: OLAP je online analitička obrada, tj. analiza operativnih podataka. 12 definirajućih načela OLAP-a formulirao je 1993. E. F. Codd, "izumitelj" relacijskih baza podataka. Kasnije je njegova definicija prerađena u takozvani FASMI test, koji zahtijeva da OLAP aplikacija pruža mogućnost brze analize zajedničkih višedimenzionalnih informacija ().

FASMI test

Brzo(Brzo) - analizu treba provesti jednako brzo na svim aspektima informacija. Prihvatljivo vrijeme odgovora je 5 sekundi ili manje.

Analiza(Analiza) - mora biti moguće provesti osnovne vrste numeričke i statističke analize, unaprijed definirane od strane programera aplikacije ili slobodno definirane od strane korisnika.

Podijeljeno(Shared) - mnogi korisnici moraju imati pristup podacima, dok je potrebno kontrolirati pristup povjerljivim informacijama.

Višedimenzionalno(Multidimensional) je glavna, najbitnija karakteristika OLAP-a.

Informacija(Informacije) - aplikacija mora moći pristupiti svim potrebnim informacijama, bez obzira na njihovu količinu i mjesto pohrane.

OLAP = Višedimenzionalni pogled = Kocka

OLAP pruža praktične, brze načine pristupa, pregledavanja i analiziranja poslovnih informacija. Korisnik dobiva prirodan, intuitivan model podataka, organizirajući ih u obliku višedimenzionalnih kocki (Cubes). Osi višedimenzionalnog koordinatnog sustava glavni su atributi analiziranog poslovnog procesa. Na primjer, za prodaju to može biti proizvod, regija, vrsta kupca. Vrijeme se koristi kao jedna od dimenzija. Na sjecištima osi – dimenzija (Dimensions) – nalaze se podaci koji kvantitativno karakteriziraju proces – mjere (Measures). To mogu biti količine prodaje u komadima ili u novčanom iznosu, stanje zaliha, troškovi itd. Korisnik koji analizira informacije može "rezati" kocku u različitim smjerovima, dobiti sažetak (na primjer, po godini) ili, obrnuto, detaljan ( po tjednu ) informacije i provodi druge manipulacije koje mu padnu na pamet tijekom procesa analize.

Kao mjere u trodimenzionalnoj kocki prikazanoj na sl. 2, koriste se prodajni iznosi, a vrijeme, proizvod i trgovina koriste se kao dimenzije. Mjerenja su prikazana na određenim razinama grupiranja: proizvodi su grupirani po kategoriji, trgovine po zemlji, a podaci o vremenu transakcije po mjesecu. Nešto kasnije ćemo detaljnije pogledati razine grupiranja (hijerarhije).

Riža. 2. Primjer kocke

"Rezanje" kocke

Čak je i trodimenzionalnu kocku teško prikazati na zaslonu računala tako da su vrijednosti mjera od interesa vidljive. Što možemo reći o kockama s više od tri dimenzije? Za vizualizaciju podataka pohranjenih u kocki, u pravilu se koriste poznati dvodimenzionalni, tj. tablični prikazi sa složenim hijerarhijskim naslovima redaka i stupaca.

Dvodimenzionalni prikaz kocke može se dobiti "rezanjem" preko jedne ili više osi (dimenzija): fiksiramo vrijednosti svih dimenzija osim dvije i dobivamo pravilnu dvodimenzionalnu tablicu. Vodoravna os tablice (zaglavlja stupaca) predstavlja jednu dimenziju, okomita os (zaglavlja redaka) drugu, a ćelije tablice predstavljaju vrijednosti mjera. U ovom se slučaju skup mjera zapravo smatra jednom od dimenzija - ili odabiremo jednu mjeru za prikaz (a zatim možemo postaviti dvije dimenzije u naslove retka i stupca), ili prikazujemo nekoliko mjera (a zatim jednu od osi tablice bit će zauzete nazivima mjera, a druge - vrijednostima jedine "nerezane" dimenzije).

Pogledajte sl. 3 - ovdje je dvodimenzionalni isječak kocke za jednu mjeru - Unit Sales (prodani komadi) i dvije "nerezane" dimenzije - Store (Store) i Vrijeme (Time).

Riža. 3. 2D kockasti rez za jednu mjeru

Na sl. Slika 4 prikazuje samo jednu “nerezanu” dimenziju - Store, ali prikazuje vrijednosti nekoliko mjera - Unit Sales (prodane jedinice), Store Sales (količina prodaje) i Store Cost (troškovi trgovine).

Riža. 4. 2D kockasti rez za više mjera

Dvodimenzionalni prikaz kocke je također moguć kada više od dvije dimenzije ostanu "nerezane". U ovom slučaju, dvije ili više dimenzija "rezane" kocke bit će postavljene na osi presjeka (redovi i stupci) - vidi sl. 5.

Riža. 5. 2D presjek kocke s više dimenzija na jednoj osi

Oznake

Vrijednosti "položene" duž dimenzija nazivaju se članovi ili oznake. Oznake se koriste i za "rezanje" kocke i za ograničavanje (filtriranje) odabranih podataka - kada nas u dimenziji koja ostaje "nerezana" ne zanimaju sve vrijednosti, već njihov podskup, na primjer, tri grada od nekoliko desetaka. Vrijednosti oznaka pojavljuju se u 2D prikazu kocke kao naslovi redaka i stupaca.

Hijerarhije i razine

Oznake se mogu kombinirati u hijerarhije koje se sastoje od jedne ili više razina. Na primjer, oznake dimenzije Store prirodno su grupirane u hijerarhiju s razinama:

Zemlja

država

Grad

Store.

Skupne vrijednosti izračunavaju se prema razinama hijerarhije, na primjer obujam prodaje za SAD (razina "Država") ili za Kaliforniju (razina "Država"). Moguće je implementirati više od jedne hijerarhije u jednoj dimenziji - recimo, za vrijeme: (godina, tromjesečje, mjesec, dan) i (godina, tjedan, dan).

Arhitektura OLAP aplikacija

Sve što je gore rečeno o OLAP-u u biti se odnosi na višedimenzionalnu prezentaciju podataka. Kako se podaci pohranjuju, grubo rečeno, ne tiče se krajnjeg korisnika niti programera alata koji klijent koristi.

Višedimenzionalnost u OLAP aplikacijama može se podijeliti u tri razine:

• Višedimenzionalni prikaz podataka - alati za krajnje korisnike koji pružaju višedimenzionalnu vizualizaciju i manipulaciju podacima; Višedimenzionalni prikazni sloj apstrahira fizičku strukturu podataka i tretira podatke kao višedimenzionalne.
• Višedimenzionalna obrada je sredstvo (jezik) za formuliranje višedimenzionalnih upita (tradicionalni relacijski jezik SQL ovdje nije prikladan) i procesor koji može obraditi i izvršiti takav upit.
• Višedimenzionalna pohrana je način fizičkog organiziranja podataka koji osigurava učinkovito izvršavanje višedimenzionalnih upita.

Prve dvije razine obavezne su u svim OLAP alatima. Treća razina, iako raširena, nije potrebna, jer se podaci za višedimenzionalni prikaz mogu izvući iz uobičajenih relacijskih struktura; Višedimenzionalni procesor upita u ovom slučaju prevodi višedimenzionalne upite u SQL upite koje izvršava relacijski DBMS.

Specifični OLAP proizvodi u pravilu su ili višedimenzionalni alat za predstavljanje podataka, OLAP klijent (na primjer, zaokretne tablice u Excelu 2000 od Microsofta ili ProClarity od Knosysa), ili višedimenzionalni poslužiteljski DBMS, OLAP poslužitelj (na primjer, Oracle Express Server ili Microsoft OLAP usluge).

Višedimenzionalni sloj obrade obično je ugrađen u OLAP klijent i/ili OLAP poslužitelj, ali se može izolirati u svom čistom obliku, kao što je Microsoftova komponenta Pivot Table Service.

Tehnički aspekti višedimenzionalne pohrane podataka

Kao što je gore spomenuto, alati za analizu OLAP-a također mogu izvući podatke izravno iz relacijskih sustava. Ovakav pristup bio je privlačniji u ono doba kada OLAP poslužitelji nisu bili uključeni u cjenike vodećih proizvođača DBMS-a. Ali danas Oracle, Informix i Microsoft nude potpune OLAP poslužitelje, pa čak i oni IT menadžeri koji ne vole stvarati "zoološki vrt" softvera različitih proizvođača u svojim mrežama mogu kupiti (ili bolje rečeno, uputiti odgovarajući zahtjev uprava tvrtke) OLAP poslužitelj iste marke kao i glavni poslužitelj baze podataka.

OLAP poslužitelji ili poslužitelji višedimenzionalnih baza podataka mogu pohranjivati ​​svoje višedimenzionalne podatke na različite načine. Prije razmatranja ovih metoda, moramo razgovarati o tako važnom aspektu kao što je pohranjivanje jedinica. Činjenica je da se u svakom skladištu podataka – i običnom i višedimenzionalnom – uz detaljne podatke izvučene iz operativnih sustava, pohranjuju i zbirni pokazatelji (agregirani pokazatelji, agregacije), poput zbroja obujma prodaje po mjesecima, po kategoriji robe itd. Agregati se pohranjuju izričito u svrhu ubrzavanja izvršavanja upita. Uostalom, s jedne strane, u pravilu se u skladištu nakuplja vrlo velika količina podataka, as druge strane, analitičari u većini slučajeva nisu zainteresirani za detaljne, već za generalizirane pokazatelje. A kada bi se svaki put morali zbrajati milijuni pojedinačnih prodaja da bi se izračunala ukupna prodaja za godinu, brzina bi najvjerojatnije bila neprihvatljiva. Stoga se prilikom učitavanja podataka u višedimenzionalnu bazu računaju i spremaju svi ukupni pokazatelji ili dio njih.

Ali, kao što znate, za sve morate platiti. A za brzinu obrade zahtjeva za sažete podatke morate platiti povećanje količine podataka i vremena za njihovo učitavanje. Štoviše, povećanje volumena može biti doslovno katastrofalno - u jednom od objavljenih standardnih testova, puni izračun agregata za 10 MB izvornih podataka zahtijevao je 2,4 GB, odnosno podaci su narasli 240 puta! Stupanj "bubrenja" podataka pri izračunavanju agregata ovisi o broju dimenzija kocke i strukturi tih dimenzija, odnosno omjeru broja "očeva" i "djece" na različitim razinama mjerenja. Da bi se riješio problem skladištenja jedinica, ponekad se koriste složeni sklopovi, koji omogućuju postizanje značajnog povećanja izvedbe upita pri izračunu ne svih mogućih agregata.

Sada o raznim opcijama za pohranjivanje informacija. I granularni podaci i agregati mogu se pohraniti u relacijske ili višedimenzionalne strukture. Višedimenzionalna pohrana omogućuje vam da podatke tretirate kao višedimenzionalni niz, što osigurava jednako brze izračune ukupnih pokazatelja i razne višedimenzionalne transformacije duž bilo koje dimenzije. Prije nekog vremena, OLAP proizvodi podržavali su ili relacijsku ili višedimenzionalnu pohranu. Danas, u pravilu, isti proizvod osigurava obje ove vrste skladištenja, kao i treći tip - mješoviti. Primjenjuju se sljedeći uvjeti:

• MOLAP(Multidimensional OLAP) - i detaljni podaci i agregati pohranjuju se u višedimenzionalnu bazu podataka. U ovom slučaju se postiže najveća redundancija, budući da višedimenzionalni podaci u potpunosti sadrže relacijske podatke.
• ROLAP(Relational OLAP) - detaljni podaci ostaju tamo gdje su izvorno “živjeli” - u relacijskoj bazi podataka; agregati su pohranjeni u istoj bazi podataka u posebno kreiranim servisnim tablicama.
• HOLAP(Hybrid OLAP) - detaljni podaci ostaju na mjestu (u relacijskoj bazi podataka), a agregati se pohranjuju u višedimenzionalnu bazu podataka.

Svaka od ovih metoda ima svoje prednosti i nedostatke i treba je koristiti ovisno o uvjetima - količini podataka, snazi ​​relacijskog DBMS-a itd.

Kod pohranjivanja podataka u višedimenzionalne strukture postoji potencijalni problem "napuhanosti" zbog pohranjivanja praznih vrijednosti. Uostalom, ako je u višedimenzionalnom polju prostor rezerviran za sve moguće kombinacije dimenzijskih oznaka, ali je samo mali dio stvarno ispunjen (na primjer, određeni broj proizvoda prodaje se samo u malom broju regija), tada većina kocka će biti prazna, iako će prostor biti zauzet. Moderni OLAP proizvodi mogu se nositi s ovim problemom.

Nastavit će se. U budućnosti ćemo govoriti o konkretnim OLAP proizvodima vodećih proizvođača.

OLAP nije zaseban softverski proizvod, nije programski jezik, pa čak ni posebna tehnologija. Ako pokušamo pokriti OLAP u svim njegovim pojavnim oblicima, onda je to skup koncepata, načela i zahtjeva koji su u osnovi softverskih proizvoda koji analitičarima olakšavaju pristup podacima. Hajde da vidimo Za što analitičarima treba nešto posebno olakšati pristup podacima.

Činjenica je da su analitičari posebni potrošači korporativnih informacija. Zadatak analitičara je pronaći uzorke u velikim količinama podataka. Stoga analitičar neće obraćati pozornost na posebnu činjenicu da je u četvrtak četvrta serija crne tinte prodana drugoj strani Černovu - njemu su potrebne informacije o stotinama i tisućama slični događaji. Pojedinačne činjenice u bazi podataka mogu biti zanimljive, na primjer, računovođi ili voditelju odjela prodaje koji je odgovoran za transakciju. Analitičaru jedna evidencija nije dovoljna - njemu, na primjer, mogu trebati sve transakcije određene podružnice ili predstavništva za mjesec ili godinu. Istovremeno, analitičar odbacuje nepotrebne detalje poput PIB-a kupca, njegove točne adrese i telefona, indeksa ugovora i slično. Istodobno, podaci koje analitičar zahtijeva za svoj rad nužno sadrže numeričke vrijednosti - to je zbog same biti njegove aktivnosti.

Dakle, analitičaru je potrebno mnogo podataka, ti su podaci selektivni i također po prirodi " skup atributa – broj". Potonje znači da analitičar radi s tablicama sljedećeg tipa:

ovdje " Zemlja", "Proizvod", "Godina" su atributi ili mjerenja, A " Obujam prodaje" - time brojčana vrijednost odn mjera. Zadatak analitičara, ponavljamo, jest identificirati jake odnose između atributa i numeričkih parametara. Gledajući tablicu, primijetit ćete da se lako može pretvoriti u tri dimenzije: na jednu od osi ćemo staviti zemlje, na drugu robu, a na treću godine. A vrijednosti u ovom trodimenzionalnom nizu bit će odgovarajuće količine prodaje.

Trodimenzionalni prikaz stola. Sivi segment pokazuje da nema podataka za Argentinu 1988

Upravo se taj trodimenzionalni niz u OLAP terminima naziva kocka. Zapravo, sa stajališta striktne matematike, takav niz neće uvijek biti kocka: prava kocka mora imati isti broj elemenata u svim dimenzijama, ali OLAP kocke nemaju takvo ograničenje. No, usprkos ovim detaljima, pojam “OLAP kocke” je zbog svoje kratkoće i figurativnosti postao općeprihvaćen. OLAP kocka ne mora biti trodimenzionalna. Može biti dvodimenzionalan i višedimenzionalan, ovisno o problemu koji se rješava. Osobito iskusni analitičari mogu trebati oko 20 dimenzija - a ozbiljni OLAP proizvodi dizajnirani su za točno tu količinu. Jednostavnije aplikacije za stolna računala podržavaju oko 6 dimenzija.

Mjerenja OLAP kocke sastoje se od tzv oznake odnosno članova. Na primjer, dimenzija Država sastoji se od oznaka Argentina, Brazil, Venezuela i tako dalje.

Ne moraju se popuniti svi elementi kocke: ako nema podataka o prodaji proizvoda od gume u Argentini 1988., vrijednost u odgovarajućoj ćeliji jednostavno neće biti određena. Također uopće nije nužno da OLAP aplikacija nužno pohranjuje podatke u višedimenzionalnu strukturu - glavno je da ti podaci korisniku izgledaju točno ovako. Inače, upravo posebne metode kompaktnog pohranjivanja višedimenzionalnih podataka “vakuumom” (neispunjenim elementima) u kockama ne dovode do potrošene memorije.

Međutim, sama kocka nije prikladna za analizu. Ako je još uvijek moguće adekvatno zamisliti ili prikazati trodimenzionalnu kocku, onda je sa kockom od šest ili devetnaest dimenzija situacija mnogo gora. Zato prije upotrebe obični se izvlače iz višedimenzionalne kocke dvodimenzionalne tablice. Ova operacija se zove "rezanje" kocke. Ovaj izraz je opet figurativan. Analitičar, takoreći, uzima i "reže" dimenzije kocke prema oznakama koje ga zanimaju. Na taj način analitičar dobiva dvodimenzionalni isječak kocke i radi s njim. Otprilike na isti način drvosječe broje godišnje godove na posječenom stablu.

Sukladno tome, u pravilu samo dvije dimenzije ostaju "nerezane" - prema broju dimenzija u tablici. Dešava se da samo neka dimenzija ostane “neizrezana” - ako kocka sadrži više vrsta numeričkih vrijednosti, one se mogu iscrtati duž jedne od dimenzija tablice.

Ako još bolje pogledate tablicu koju smo prvu prikazali, primijetit ćete da podaci u njoj najvjerojatnije nisu primarni, već dobiveni kao rezultat zbrajanje na manjim elementima. Na primjer, godina je podijeljena na tromjesečja, tromjesečja na mjesece, mjeseci na tjedne, tjedni na dane. Država se sastoji od regija, a regije od naseljenih područja. Konačno, u samim gradovima mogu se identificirati četvrti i određena maloprodajna mjesta. Proizvodi se mogu kombinirati u grupe proizvoda i tako dalje. U terminima OLAP-a, takve asocijacije na više razina se sasvim logično nazivaju hijerarhije. OLAP alati omogućuju prelazak na željenu razinu hijerarhije u bilo kojem trenutku. Štoviše, u pravilu je podržano nekoliko vrsta hijerarhija za iste elemente: na primjer, dan-tjedan-mjesec ili dan-dekada-kvartal. Izvorni podaci se uzimaju s nižih razina hijerarhije i zatim zbrajaju kako bi se dobile vrijednosti na višim razinama. Kako bi se ubrzao proces prijelaza, zbrojene vrijednosti za različite razine pohranjuju se u kocku. Dakle, ono što izgleda kao jedna kocka sa strane korisnika, grubo rečeno, sastoji se od mnogo primitivnijih kockica.

Primjer hijerarhije

To je jedna od bitnih točaka koja je dovela do nastanka OLAP-a – produktivnost i učinkovitost. Zamislimo što se događa kada analitičar treba dobiti informacije, ali u poduzeću nema OLAP alata. Analitičar samostalno (što je malo vjerojatno) ili uz pomoć programera postavlja odgovarajući SQL upit i prima podatke od interesa u obliku izvješća ili ih izvozi u proračunsku tablicu. U ovom slučaju nastaju mnogi problemi. Prvo, analitičar je prisiljen raditi nešto što nije njegov posao (SQL programiranje) ili čekati da programeri završe zadatak umjesto njega - sve to ima negativan utjecaj na produktivnost rada, povećanje stope oluje, srčanih i moždanih udara, i tako dalje . Drugo, jedan izvještaj ili tablica u pravilu ne spašavaju divove misli i očeve ruske analize - i cijeli će se postupak morati ponavljati iznova i iznova. Treće, kao što smo već saznali, analitičari ne pitaju za sitnice - potrebno im je sve odjednom. To znači (iako tehnologija napreduje velikim koracima) da korporativni relacijski DBMS poslužitelj kojem pristupa analitičar može duboko i dugo razmišljati, blokirajući druge transakcije.

Koncept OLAP-a pojavio se upravo za rješavanje takvih problema. OLAP kocke su u biti meta izvješća. Rezanjem metaizvještaja (odnosno kocki) po dimenzijama analitičar zapravo dobiva “obična” dvodimenzionalna izvješća koja ga zanimaju (to nisu nužno izvješća u uobičajenom smislu riječi - govorimo o podatkovnim strukturama s iste funkcije). Prednosti kocki su očite - podatke je potrebno zatražiti od relacijskog DBMS-a samo jednom - prilikom izgradnje kocke. Budući da analitičari u pravilu ne rade s informacijama koje se nadopunjuju i mijenjaju u hodu, generirana kocka je relevantna dosta dugo. Zahvaljujući tome, ne samo da su eliminirani prekidi u radu relacijskog DBMS poslužitelja (nema upita s tisućama i milijunima odgovora), već se i brzina pristupa podacima za samog analitičara naglo povećava. Osim toga, kao što je već navedeno, performanse su također poboljšane izračunavanjem subsuma hijerarhija i drugih agregiranih vrijednosti u vrijeme izgradnje kocke. Odnosno, ako su u početku naši podaci sadržavali informacije o dnevnom prihodu za određeni proizvod u jednoj trgovini, tada prilikom formiranja kocke, OLAP aplikacija izračunava ukupne iznose za različite razine hijerarhije (tjedne i mjesece, gradove i zemlje).

Naravno, morate platiti da biste povećali produktivnost na ovaj način. Ponekad se kaže da struktura podataka jednostavno "eksplodira" - OLAP kocka može zauzeti desetke ili čak stotine puta više prostora od izvornih podataka.

Odgovori na pitanja:

Što se dogodilo kocka OLAP?

Što se dogodilo oznake specifično mjerenje? Navedite primjere.

Mogu li oni mjere u OLAP kocki sadrže nenumeričke vrijednosti.