Navrhovanie dátových kociek. Vytvorenie kocky OLAP pomocou programu Microsoft Query

Ryža. 2. Plátok kocky OLAP

Rotácia(Obrázok 3) - operácia zmeny umiestnenia meraní prezentovaných v správe alebo na zobrazenej stránke. Operácia rotácie môže napríklad zahŕňať výmenu riadkov a stĺpcov tabuľky. Okrem toho otáčanie dátovej kocky presúva netabuľkové dimenzie do umiestnenia dimenzií na zobrazenej stránke a naopak.

Anotácia: Táto prednáška sa zaoberá základmi navrhovania dátových kociek pre dátové sklady OLAP. Príklad ukazuje, ako zostaviť dátovú kocku pomocou nástroja CASE.

Účel prednášky

Po preštudovaní materiálu tejto prednášky budete vedieť:

• v čom je dátová kocka Dátový sklad OLAP ;
• ako navrhnúť dátovú kocku pre OLAP dátové sklady ;
• čo je rozmer dátovej kocky;
• ako skutočnosť súvisí s dátovou kockou;
• čo sú atribúty rozmerov;
• čo je hierarchia;
• čo je metrika dátovej kocky;

a učiť sa:

• stavať viacrozmerné grafy ;
• dizajn jednoduchý viacrozmerné grafy.

Úvod

Technológia OLAP nie je samostatná softvér, Nie programovací jazyk. Ak sa pokúsite pokryť OLAP vo všetkých jeho prejavoch, potom ide o súbor konceptov, princípov a požiadaviek, ktoré sú základom softvérových produktov, ktoré uľahčujú analytikom prístup k údajom.

Analytici sú hlavnými spotrebiteľmi podnikových informácií. Úlohou analytika je nájsť vzory vo veľkých súboroch údajov. Preto analytik nebude venovať pozornosť jedinej skutočnosti, že v určitý deň bola kupujúcemu Ivanovovi predaná dávka guľôčkových pier - potrebuje informácie o stovkách a tisíckach podobných udalostí. Jednotlivé skutočnosti v dátovom sklade môžu zaujímať napríklad účtovníka alebo vedúceho obchodného oddelenia, ktorého kompetenciou je podpora konkrétnej zákazky. Jeden záznam analytikovi nestačí – môže napríklad potrebovať informácie o všetkých zmluvách o predajných miestach za mesiac, štvrťrok alebo rok. Analytics nemusí mať záujem o DIČ kupujúceho alebo jeho telefónne číslo - pracuje s konkrétnymi číselnými údajmi, ktoré sú podstatou jeho profesionálnej činnosti.

Centralizácia a pohodlná štruktúra nie sú zďaleka všetko, čo analytik potrebuje. Potrebuje nástroj na prezeranie, vizualizáciu informácií. Tradičné reporty, dokonca postavené na báze jedného dátového skladu, sú však zbavené určitej flexibility. Nemožno ich "skrútiť", "rozbaliť" alebo "zbaliť", aby ste získali požadovaný pohľad na údaje. Čím viac „výrezov“ a „výrezov“ údajov môže analytik preskúmať, tým viac nápadov má, ktoré si zase vyžadujú stále viac „výrezov“ na overenie. Ako taký nástroj na prieskum údajov je analytikom OLAP.

Hoci OLAP nie je nevyhnutným atribútom dátového skladu, stále viac sa používa na analýzu informácií nahromadených v tomto dátovom sklade.

Prevádzkové údaje sa zhromažďujú z rôznych zdrojov, čistia sa, integrujú a pridávajú do dátového skladu. Zároveň sú už dostupné na analýzu pomocou rôznych reportovacích nástrojov. Potom sa údaje (celé alebo ich časti) pripravia na analýzu OLAP. Môžu byť načítané do špeciálnej databázy OLAP alebo ponechané v relačnom dátovom sklade. Najdôležitejším prvkom používania OLAP sú metadáta, teda informácie o štruktúre, umiestnení a transformácia údajov. Vďaka nim je zabezpečená efektívna súhra rôznych skladovacích komponentov.

teda OLAP možno definovať ako súbor nástrojov na multidimenzionálnu analýzu údajov nahromadených v dátovom sklade. Teoreticky možno nástroje OLAP aplikovať priamo na prevádzkové dáta resp presné kópie. Existuje však riziko podrobenia údajov analýze, ktoré nie sú vhodné pre túto analýzu.

OLAP na klientovi a serveri

Základom OLAP je multidimenzionálna analýza údajov. Dá sa vyrobiť pomocou rôznych nástrojov, ktoré možno podmienečne rozdeliť na klientske a serverové OLAP nástroje.

Nástroje OLAP na strane klienta sú aplikácie, ktoré počítajú a zobrazujú agregované údaje (súčty, priemery, maximá alebo minimá) a samotné súhrnné údaje sa ukladajú do vyrovnávacej pamäte v adresnom priestore nástroja OLAP.

Ak sú zdrojové údaje obsiahnuté v desktopovej DBMS, súhrnné údaje vypočíta samotný nástroj OLAP. Ak je zdrojom zdrojových údajov server DBMS, mnohé z klientskych nástrojov OLAP odosielajú na server dotazy SQL obsahujúce klauzulu GROUP BY a v dôsledku toho prijímajú súhrnné údaje vypočítané na serveri.

Funkčnosť OLAP je spravidla implementovaná v nástrojoch na spracovanie štatistických údajov (od produktov tejto triedy po ruský trh Produkty Stat Soft a SPSS sú široko používané) a v niektorých tabuľkových procesoroch. Najmä Microsoft Excel 2000. Pomocou tohto produktu môžete vytvoriť a uložiť ako súbor malú lokálnu viacrozmernú kocku OLAP a zobraziť jej dvoj- alebo trojrozmerné rezy.

veľa vývojové nástroje obsahujú knižnice tried alebo komponentov, ktoré vám umožňujú vytvárať aplikácie, ktoré implementujú najjednoduchšie funkcie OLAP (ako sú komponenty Decision Cube v Borland Delphi a Borland C++Builder). Okrem toho mnohé spoločnosti ponúkajú ovládacie prvky ActiveX a ďalšie knižnice, ktoré implementujú podobné funkcie.

Všimnite si, že klientske nástroje OLAP sa spravidla používajú s malým počtom rozmerov (zvyčajne sa neodporúča viac ako šesť) a malým množstvom hodnôt pre tieto parametre - prijaté súhrnné údaje sa napokon musia zmestiť do adresného priestoru takéhoto nástroja a ich počet rastie exponenciálne so zvyšujúcim sa počtom meraní. Preto aj tie najprimitívnejšie klientske nástroje OLAP spravidla umožňujú vykonať predbežný výpočet množstva potrebnej pamäte RAM na vytvorenie viacrozmernej kocky.

Mnohé (ale nie všetky) nástroje OLAP na strane klienta vám umožňujú uložiť obsah vyrovnávacej pamäte súhrnných údajov ako súbor, čo zase bráni ich prepočítaniu. Všimnite si, že táto príležitosť sa často využíva na odcudzenie súhrnných údajov s cieľom ich prenosu do iných organizácií alebo na zverejnenie. Typickým príkladom takýchto odcudzených súhrnných údajov sú štatistiky výskytu v rôznych regiónoch a v rôznych vekových skupinách, čo je otvorené informácie zverejnené ministerstvami zdravotníctva rôznych krajinách a Svetová zdravotnícka organizácia. Zároveň samotné pôvodné údaje, ktoré sú informáciami o konkrétnych prípadoch ochorení, sú dôvernými údajmi zdravotníckych zariadení a v žiadnom prípade by sa nemali dostať do rúk poisťovní, nieto ešte dostať sa na verejnosť.

Myšlienka ukladania vyrovnávacej pamäte so súhrnnými údajmi v súbore bola ďalej rozvinutá v nástrojoch OLAP na strane servera, v ktorých ukladanie a modifikáciu súhrnných údajov, ako aj údržbu úložiska, ktoré ich obsahuje, vykonávajú samostatná aplikácia alebo proces nazývaný server OLAP. Klientske aplikácie si môžu vyžiadať takéto viacrozmerné úložisko a ako odpoveď prijať nejaké údaje. Niektoré klientske aplikácie môžu tiež vytvárať takéto úložiská alebo ich aktualizovať podľa zmenených zdrojových údajov.

Výhody používania serverových nástrojov OLAP v porovnaní s klientskymi nástrojmi OLAP sú podobné výhodám používania serverových DBMS v porovnaní s desktopovými: v prípade použitia serverových nástrojov dochádza k výpočtu a ukladaniu súhrnných údajov na serveri a klientskej aplikácii prijíma iba výsledky dotazov na ne, čo umožňuje všeobecne znížiť sieťovú prevádzku, dodacia lehota požiadavky a požiadavky na prostriedky spotrebované klientskou aplikáciou. Upozorňujeme, že podniková analýza a spracovanie údajov sú spravidla založené presne na serverových nástrojoch OLAP, napríklad Oracle Express Server, Microsoft SQL Server 2000 Analysis Services, Hyperion Essbase, produkty Crystal Decisions, Business Objects, Cognos. , inštitút S.A.S. Keďže všetci poprední výrobcovia serverových DBMS vyrábajú (alebo majú licenciu od iných spoločností) určité serverové OLAP nástroje, ich výber je pomerne široký a takmer vo všetkých prípadoch si môžete zakúpiť OLAP server od rovnakého výrobcu ako samotný databázový server.

Všimnite si, že mnohé klientske nástroje OLAP (najmä Microsoft Excel 2003, Seagate Analysis atď.) vám umožňujú prístup k serverovým úložiskám OLAP, ktoré v tomto prípade fungujú ako klientske aplikácie, ktoré vykonávajú takéto dotazy. Okrem toho existuje veľa produktov, ktoré sú klientskymi aplikáciami pre nástroje OLAP od rôznych výrobcov.

Technické aspekty viacrozmerného ukladania dát

Multidimenzionálne dátové sklady obsahujú súhrnné údaje rôzneho stupňa podrobnosti, napríklad objemy predaja podľa dňa, mesiaca, roku, kategórie produktov atď. Účelom ukladania súhrnných údajov je zníženie dodacia lehota Vo väčšine prípadov nejde o podrobné, ale súhrnné údaje, ktoré sú predmetom analýzy a prognóz. Preto sa pri vytváraní multidimenzionálnej databázy vždy vypočítajú a uložia nejaké súhrnné údaje.

Upozorňujeme, že ukladanie všetkých súhrnných údajov nie je vždy opodstatnené. Faktom je, že pri pridávaní nových dimenzií množstvo údajov, ktoré tvoria kocku, rastie exponenciálne (niekedy sa hovorí o „výbušnom raste“ množstva údajov). Presnejšie povedané, množstvo rastu súhrnných údajov závisí od počtu dimenzií v kocke a členov dimenzií na rôznych úrovniach hierarchií týchto dimenzií. Na vyriešenie problému "výbušného rastu" sa používajú rôzne schémy, ktoré umožňujú pri výpočte ďaleko od všetkých možných agregovaných údajov dosiahnuť prijateľnú rýchlosť vykonávania dotazu.

Zdrojové aj agregované údaje môžu byť uložené v relačných alebo viacrozmerných štruktúrach. Preto v súčasnosti existujú tri spôsoby ukladania údajov.

• MOLAP(Multidimenzionální OLAP) – zdrojové a súhrnné dáta sú uložené vo viacrozmernej databáze. Ukladanie údajov vo viacrozmerných štruktúrach vám umožňuje manipulovať s údajmi ako s viacrozmerným poľom, takže rýchlosť výpočtu súhrnných hodnôt je rovnaká pre ktorúkoľvek z dimenzií. V tomto prípade je však viacrozmerná databáza nadbytočná, pretože viacrozmerné údaje úplne obsahujú pôvodné relačné údaje.
• ROLAP(Relačný OLAP) – Pôvodné údaje zostávajú v rovnakej relačnej databáze, kde sa pôvodne nachádzali. Súhrnné údaje sú umiestnené v servisných tabuľkách špeciálne vytvorených na ich uloženie v rovnakej databáze.
• HOLAP(Hybridný OLAP) – Pôvodné údaje zostávajú v rovnakej relačnej databáze, kde sa pôvodne nachádzali, zatiaľ čo súhrnné údaje sú uložené v multidimenzionálnej databáze.

Niektoré nástroje OLAP podporujú ukladanie údajov iba v relačných štruktúrach, niektoré iba vo viacrozmerných. Väčšina moderných serverových nástrojov OLAP však podporuje všetky tri spôsoby ukladania údajov. Výber spôsobu ukladania závisí od objemu a štruktúry zdrojových údajov, požiadaviek na rýchlosť vykonávania dotazov a frekvencie aktualizácie OLAP kociek.

Poznamenávame tiež, že veľká väčšina moderných nástrojov OLAP neukladá „prázdne“ hodnoty (príkladom „prázdnej“ hodnoty by bola absencia predaja sezónneho tovaru mimo sezóny).

Základné koncepty OLAP

FAMSI test

Technológia komplexnej multidimenzionálnej analýzy dát sa nazýva OLAP (On-Line Analytical Processing). OLAP je kľúčovým komponentom organizácie dátového skladu. Koncept OLAP opísal v roku 1993 Edgar Codd, známy databázový výskumník a autor relačného dátového modelu. V roku 1995 na základe požiadaviek stanovených Coddom, tzv FASMI test(Fast Analysis of Shared Multidimensional Information) - rýchla analýza zdieľaných multidimenzionálnych informácií, vrátane nasledujúcich požiadaviek na aplikácie pre multidimenzionálnu analýzu:

• Rýchlo(Rýchle) - poskytovanie výsledkov analýzy používateľovi v primeranom čase (zvyčajne nie viac ako 5 s), a to aj za cenu menej podrobnej analýzy;
• Analýza(Analýza) - schopnosť vykonávať akúkoľvek logickú a štatistickú analýzu špecifickú pre danú aplikáciu a uložiť ju vo forme dostupnej pre koncového používateľa;
• zdieľané(Zdieľaný) – prístup viacerých používateľov k údajom s podporou vhodných uzamykacích mechanizmov a nástrojov na autorizovaný prístup;
• Viacrozmerný(Multidimenzionální) - Viacrozmerná koncepčná reprezentácia údajov vrátane plnej podpory hierarchií a viacerých hierarchií (toto je kľúčová požiadavka OLAP);
• Informácie(Informácie) – aplikácia musí mať prístup ku všetkým potrebným informáciám bez ohľadu na ich objem a miesto uloženia.

Je potrebné poznamenať, že je možné implementovať funkčnosť OLAP rôzne cesty, počnúc najjednoduchšími nástrojmi na analýzu údajov v kancelárskych aplikáciách a končiac distribuovanými analytickými systémami založenými na serverových produktoch.

Viacrozmerná reprezentácia informácií

Kuba

OLAP poskytuje pohodlné, vysokorýchlostné prostriedky na prístup, prezeranie a analýzu obchodných informácií. Používateľ dostane prirodzené, intuitívne dátový model, ktorý ich organizuje vo forme viacrozmerných kociek (Cubes). Osi viacrozmerného súradnicového systému sú hlavnými atribútmi analyzovaného podnikového procesu. Napríklad pri predaji to môže byť produkt, región, typ kupujúceho. Ako jedno z meraní sa používa čas. Na priesečníkoch osí meraní (Dimensions) sa nachádzajú údaje, ktoré kvantitatívne charakterizujú proces – opatrenia (Measures). Môžu to byť objemy predaja v kusoch alebo v peňažnom vyjadrení, stavy zásob, náklady atď. Používateľ, ktorý analyzuje informácie, môže kocku „rezať“ rôznymi smermi, získať súhrn (napríklad podľa rokov) alebo naopak podrobný (týždenný). informácie a vykonávať ďalšie manipulácie, ktoré mu prídu na myseľ v procese analýzy.

Ako miery v trojrozmernej kocke znázornenej na obr. 26.1 sa používajú predajné množstvá a ako merania sa používa čas, produkt a sklad. Merania sú zobrazené na určité úrovne zoskupenia: tovar je zoskupený podľa kategórií, predajne – podľa krajín a údaje o čase transakcií – podľa mesiacov. O niečo neskôr sa pozrieme na úrovne zoskupovania (hierarchie) podrobnejšie.

Ryža. 26.1.

"rezanie" kocky

Dokonca aj trojrozmernú kocku je ťažké zobraziť na obrazovke počítača, aby bolo možné vidieť hodnoty meraní, ktoré nás zaujímajú. Čo môžeme povedať o kockách s viac ako tromi rozmermi. Na vizualizáciu dát uložených v kocke sa spravidla používajú bežné dvojrozmerné, t.j. tabuľkové zobrazenia, ktoré majú zložité hierarchické hlavičky riadkov a stĺpcov.

Dvojrozmernú reprezentáciu kocky možno získať jej „prerezaním“ pozdĺž jednej alebo viacerých osí (rozmerov): zafixujeme hodnoty všetkých rozmerov okrem dvoch a získame pravidelný dvojrozmerný tabuľky. Vodorovná os tabuľky (hlavičky stĺpcov) predstavuje jednu dimenziu, zvislá os (hlavičky riadkov) predstavuje ďalšiu dimenziu a bunky tabuľky predstavujú namerané hodnoty. V tomto prípade je množina mier skutočne považovaná za jednu z dimenzií: buď vyberieme jednu mieru na zobrazenie (a potom môžeme umiestniť dve dimenzie do hlavičiek riadkov a stĺpcov), alebo zobrazíme niekoľko mier (a potom jednu osí tabuľky budú obsadené názvami mier a ostatné - hodnotami jednej „neorezanej“ dimenzie).

Aplikačná architektúra OLAP

Všetko, čo bolo povedané vyššie o OLAP, sa v skutočnosti týkalo viacrozmernej prezentácie údajov. Spôsob, akým sú dáta uchovávané, sa, zhruba povedané, netýka ani koncového používateľa, ani vývojárov nástroja, ktorý klient používa.

Multidimenzionalitu v OLAP aplikáciách možno rozdeliť do troch úrovní.

• Multidimenzionálna reprezentácia údajov – nástroje pre koncových používateľov, ktoré poskytujú viacrozmernú vizualizáciu a manipuláciu s údajmi; vrstva viacrozmernej reprezentácie abstrahuje od fyzickej štruktúry údajov a zaobchádza s nimi ako s viacrozmernými.
• Multidimenzionálne spracovanie - nástroj (jazyk) na formulovanie viacrozmerných dotazov (tradičný relačný jazyk SQL je tu nevhodný) a procesor, ktorý dokáže takýto dotaz spracovať a vykonať.
• Multidimenzionálne úložisko - prostriedky fyzickej organizácie údajov, ktoré poskytujú efektívne vykonávanie viacrozmerných dopytov.

Prvé dve úrovne sú povinné vo všetkých nástrojoch OLAP. Tretia úroveň, aj keď je široko používaná, nie je potrebná, pretože údaje pre viacrozmernú reprezentáciu možno získať aj z bežných relačných štruktúr; procesor viacrozmerných dotazov v tomto prípade prekladá viacrozmerné dotazy na dotazy SQL, ktoré sú vykonávané relačným DBMS.

Špecifické produkty OLAP sú zvyčajne buď multidimenzionálny nástroj na prezentáciu údajov (klient OLAP – napríklad kontingenčné tabuľky v Exceli 2000 od Microsoftu alebo ProClarity od Knosys) alebo multidimenzionálny back-end DBMS (OLAP server – napríklad Oracle Express Server alebo Microsoft OLAP služby).

Vrstva viacrozmerného spracovania je zvyčajne zabudovaná do klienta OLAP a/alebo servera OLAP, ale môže byť izolovaná vo svojej najčistejšej forme, ako napríklad komponent služby kontingenčnej tabuľky od spoločnosti Microsoft.

/ Kubistickým spôsobom. Využitie OLAP kociek v manažérskej praxi veľkých spoločností

V kontakte s

Spolužiaci

Konštantín Tokmačev, systémový architekt

kubistickým spôsobom.
Využitie OLAP kociek v manažérskej praxi veľkých spoločností

Možno už uplynul čas, keď sa výpočtové zdroje spoločnosti vynakladali iba na registráciu informácií a účtovných správ. Manažérske rozhodnutia sa zároveň robili „od oka“ v kanceláriách, na poradách a zasadaniach. Možno je čas v Rusku vrátiť sa k podnikovým výpočtovým systémom, ich hlavným zdrojom – riešením problémov s riadením na základe údajov zaregistrovaných v počítači.

O výhodách business intelligence

V rámci podnikovej riadiacej slučky medzi „surovými“ dátami a „pákmi“ ovplyvňovania riadeného objektu existujú „ukazovatele výkonnosti“ – KPI. Tvoria akoby „palubnú dosku“, odzrkadľujúcu stav rôznych subsystémov riadeného objektu. Vybaviť spoločnosť informatívnymi ukazovateľmi výkonnosti a kontrolovať ich výpočet a získané hodnoty je úlohou obchodného analytika. Významnú pomoc pri organizovaní analytickej práce korporácie môžu poskytnúť automatizované analytické služby, ako je MS SQL Server Analysis Services (SSAS) a jej hlavným dispozitívom je kocka OLAP.

Tu je potrebné urobiť ešte jednu poznámku. Napríklad v americkej tradícii sa špecialita zameraná na prácu s kockami OLAP nazýva BI (Business Intelligence). Netreba si robiť ilúzie, že americká BI zodpovedá ruskému „obchodnému analytikovi“. Bez urážky, ale náš obchodný analytik je často „podúčtovník“ a „podprogramátor“, špecialista s nejasnými znalosťami a malým platom, ktorý skutočne nemá žiadne vlastné nástroje a metodiku.

BI špecialista je v skutočnosti aplikovaný matematik, špičkový špecialista, ktorý vo firmách používa moderné matematické metódy (to, čo sa nazývalo operačný výskum – metódy operačného výskumu). BI je viac v súlade so špecializáciou „systémový analytik“, ktorá bola v ZSSR, ktorú vytvorila fakulta VMK Moskovskej štátnej univerzity. M.V. Lomonosov. Kocka OLAP a analytické služby sa môžu stať sľubným základom pre pracovisko ruského obchodného analytika, možno po určitom zlepšení jeho kvalifikácie smerom k americkej BI.

IN V poslednej dobe Objavil sa ďalší škodlivý trend. Vďaka špecializácii sa stratilo vzájomné porozumenie medzi rôznymi kategóriami zamestnancov korporácie. Účtovník, manažér a programátor ako „labuť, rakovina a šťuka“ v bájke I.A. Krylov, ťahajúc korporáciu rôznymi smermi.

Účtovník je zaneprázdnený výkazníctvom, jeho sumy, či už z hľadiska významu alebo dynamiky, priamo nesúvisia s obchodným procesom spoločnosti.

Manažér je zaneprázdnený svojim segmentom podnikového procesu, ale nie je schopný globálne, na úrovni spoločnosti ako celku, posúdiť výsledky a perspektívy svojho konania.

Napokon, programátor, ktorý bol kedysi (vďaka vzdelaniu) dirigentom pokrokových technických myšlienok z oblasti vedy do sféry obchodu, sa zmenil na pasívneho vykonávateľa fantázií účtovníka a manažéra, takže už nie je nezvyčajné, keď účtovníci a všeobecne všetci, ktorí nie sú leniví. Nezasvätený, negramotný, ale pomerne dobre platený programátor 1C je skutočnou pohromou ruských korporácií. (Skoro ako domáci futbalista.) Nehovorím o takzvaných „ekonómoch a právnikoch“, o tých sa už dávno hovorí všetko.

Takže pozícia obchodného analytika, vybaveného high-tech SSAS aparátom, ktorý ovláda základy programovania a účtovníctva, dokáže konsolidovať prácu spoločnosti vo vzťahu k analýze a prognóze obchodného procesu.

Výhody OLAP kociek

Kocka OLAP je moderné zariadenie analýza databázy podnikového počítačového systému, ktorá umožňuje poskytnúť zamestnancom všetkých úrovní hierarchie požadovaný súbor ukazovateľov, ktoré charakterizujú výrobný proces podniku. Ide nielen o to, že užívateľsky prívetivé rozhranie a flexibilný dopytovací jazyk pre kocku MDX (MultiDimensional eXpressions) vám umožňujú formulovať a vypočítať potrebné analytické ukazovatele, ale aj o pozoruhodnú rýchlosť a jednoduchosť, s akou to táto kocka OLAP robí. Navyše táto rýchlosť a jednoduchosť v rámci určitých limitov nezávisí od zložitosti výpočtov a objemu databázy.

Určité pochopenie OLAP
kocka môže dať "kontingenčnú tabuľku" MS Excel. Tieto objekty majú podobnú logiku a podobné rozhrania. Ako ale z článku vyplynie, funkcionalita OLAP je neporovnateľne bohatšia a výkon je neporovnateľne vyšší, takže „kontingenčná tabuľka“ zostáva lokálnym desktopovým produktom, kým OLAP je produktom podnikovej úrovne.

Prečo je kocka OLAP taká vhodná na riešenie analytických problémov? Kocka OLAP je navrhnutá tak, že všetky ukazovatele vo všetkých možných rezoch sú vopred vypočítané (celé alebo čiastočne) a používateľ musí iba „vytiahnuť“ požadované ukazovatele (meria miery) a rezy (rozmery). ) pomocou myši a program prekreslí dosky.

Všetky možné analýzy vo všetkých sekciách tvoria jedno obrovské pole, alebo skôr nie pole, ale iba viacrozmernú kocku OLAP. Bez ohľadu na požiadavku, ktorú používateľ (manažér, obchodný analytik, manažér) predloží analytickej službe, rýchlosť odozvy je spôsobená dvoma vecami: po prvé, požadovaná analýza sa dá ľahko sformulovať (buď vybratá zo zoznamu podľa názvu alebo zadaná podľa vzorca v jazyku MDX) a po druhé, spravidla už bol vypočítaný.

Formulácia analytiky je možná v troch verziách: je to buď databázové pole (presnejšie skladové pole), alebo výpočtové pole definované na úrovni návrhu kocky alebo výraz jazyka MDX pri interaktívnej práci s kockou.

To znamená niekoľko atraktívnych vlastností OLAP kociek naraz. V skutočnosti zmizne bariéra medzi používateľom a údajmi. Bariéra v podobe aplikačného programátora, ktorý v prvom rade potrebuje vysvetliť problém (zadať úlohu). Po druhé, budete musieť počkať, kým aplikačný programátor nevytvorí algoritmus, napíše a odladí program, potom môže byť upravený. Ak je zamestnancov veľa a ich požiadavky sú rôznorodé a premenlivé, potom je potrebný celý tím aplikovaných programátorov. V tomto zmysle kocka OLAP (a kvalifikovaný obchodný analytik) v rámci analytickej práce nahrádza celý tím aplikačných programátorov, rovnako ako výkonný bager s rypadlom pri kopaní priekopy nahrádza celú brigádu hosťujúcich robotníkov s lopatami!

V tomto prípade sa dosiahne ďalšia veľmi dôležitá kvalita získaných analytických údajov. Keďže kocka OLAP je jedna pre celú spoločnosť, t.j. Keďže ide o rovnaké pole s analytikmi pre všetkých, nepríjemná nekonzistentnosť v údajoch je vylúčená. Keď manažér musí zadávať rovnakú úlohu viacerým nezávislým zamestnancom, aby eliminoval faktor subjektivity, no stále prinášajú rôzne odpovede, ktoré sa každý zaväzuje nejako vysvetliť atď. Kocka OLAP zabezpečuje jednotnosť analytických údajov na rôznych úrovniach podnikovej hierarchie, t.j. ak chce manažér podrobne rozviesť určitý ukazovateľ, ktorý ho zaujíma, tak určite príde na údaje nižšej úrovne, s ktorými jeho podriadený pracuje, a to budú práve údaje, na základe ktorých sa vypočíta ukazovateľ vyššej úrovne. a nie nejaké iné údaje prijaté iným spôsobom, v inom čase atď. To znamená, že celá spoločnosť vidí rovnakú analýzu, ale na rôznych úrovniach konsolidácie.

Vezmime si príklad. Predpokladajme, že manažér kontroluje pohľadávky. Pokiaľ je indikátor KPI pohľadávok po lehote splatnosti zelený, potom je všetko v poriadku, nie sú potrebné žiadne manažérske úkony. Ak sa farba zmenila na žltú alebo červenú, niečo nie je v poriadku: KPI sme zredukovali podľa obchodného oddelenia a okamžite vidíme divízie „červeno“. Definuje sa ďalšia časť o manažéroch – a predajcovi, ktorého zákazníci meškajú s platbami. (Ďalej môže byť výška oneskorenia rozdelená podľa kupujúcich, podmienok atď.) Vedúci spoločnosti môže priamo osloviť porušovateľov na akejkoľvek úrovni. Vo všeobecnosti však vedúci oddelení aj obchodní manažéri vidia rovnaký KPI ​​(na úrovniach svojej hierarchie). Preto, aby situáciu napravili, nemusia ani čakať na „výzvu na koberček“... Samozrejme, že samotný KPI ​​nemusí nutne predstavovať výšku delikvencie – môže ísť o vážený priemer doba omeškania alebo vo všeobecnosti rýchlosť obratu pohľadávok.

Všimnite si, že zložitosť a flexibilita jazyka MDX spolu s rýchlymi (niekedy okamžitými) výsledkami umožňujú riešiť (berúc do úvahy fázy vývoja a ladenia) zložité riadiace úlohy, ktoré by za iných podmienok nemuseli byť splnené. vôbec kvôli zložitosti pre aplikovaných programátorov.a počiatočnej neistote vo formulácii. (Dlhé časové rámce pre aplikačných programátorov na riešenie analytických problémov v dôsledku zle pochopenej formulácie a dlhých modifikácií programu, keď sa v praxi často vyskytujú zmeny podmienok.)

Venujme tiež pozornosť skutočnosti, že každý zamestnanec spoločnosti môže zo všeobecného poľa zbierať analytikovi OLAP presne takú úrodu, ktorú potrebuje na prácu, a neuspokojiť sa s „pásikom“, ktorý odrezal v spoločných „štandardných správach“. “.

Viacužívateľské rozhranie na prácu s kockou OLAP v režime klient-server umožňuje každému zamestnancovi, nezávisle od ostatných, mať vlastné (dokonca aj vlastnú produkciu s určitou zručnosťou) analytické bloky (reporty), ktoré sa po definovaní automaticky aktualizované - inými slovami, sú vždy v aktuálnom stave.

To znamená, že kocka OLAP vám umožňuje urobiť analytickú prácu (ktorú v skutočnosti vykonávajú nielen analytici poznámok, ale v skutočnosti takmer všetci zamestnanci spoločnosti, dokonca aj logistici a manažéri, ktorí kontrolujú zostatky a zásielky), selektívnejšou, “ z tváre nie vo všeobecnom výraze“ , čo vytvára podmienky na zlepšenie práce a zvýšenie produktivity.

Keď zhrnieme náš úvod, poznamenávame, že používanie kociek OLAP môže zvýšiť riadenie spoločnosti o viac vysoký stupeň. Jednotnosť analytických dát na všetkých úrovniach hierarchie, ich spoľahlivosť, komplexnosť, jednoduchosť vytvárania a modifikácie indikátorov, individuálne nastavenia, vysoká rýchlosť spracovania dát a v neposlednom rade úspora peňazí a času vynaloženého na podporu alternatívnych analytických ciest (programátori aplikácií, nezávislí výpočty zamestnanca), otvorené vyhliadky na použitie kociek OLAP v praxi veľkých ruských spoločností.

OLTP + OLAP: spätná väzba v reťazci riadenia spoločnosti

Teraz zvážte všeobecnú myšlienku kociek OLAP a ich miesto použitia v reťazci riadenia spoločnosti. Pojem OLAP (OnLine Analytical Processing) zaviedol britský matematik Edgar Codd popri svojom skoršom termíne OLTP (OnLine Transactions Processing). O tom bude reč neskôr, ale E. Codd, samozrejme, navrhol nielen pojmy, ale aj matematické teórie OLTP a OLAP. Bez toho, aby sme zachádzali do detailov, v modernej interpretácii OLTP je relačná databáza považovaná za mechanizmus na registráciu, ukladanie a získavanie informácií.

Metodika riešenia

Takéto ERP systémy (Enterprice Resource Planning), ako 1C7, 1C8, MS Dynamics AX, majú užívateľsky orientované softvérové ​​rozhrania (vkladanie a oprava dokumentov atď.) a relačné databázy (DB) na ukladanie a získavanie informácií prezentovaných v súčasnosti. softvérové ​​produkty typu MS SQL Server (SS).

Upozorňujeme, že informácie evidované v databáze ERP systému sú skutočne veľmi cenným zdrojom. Nejde len o to, aby evidované informácie poskytovali aktuálny workflow korporácie (vystavenie dokladov, ich oprava, možnosť tlače a odsúhlasenia atď.), ale nielen možnosť výpočtu finančné výkazy(dane, audit a pod.). Z pohľadu manažmentu je oveľa dôležitejšie, že systém OLTP (relačná databáza) je v skutočnosti skutočným digitálnym modelom aktivít korporácie v plnej veľkosti.

Na riadenie procesu však nestačí len registrovať informácie o ňom. Proces by mal byť prezentovaný ako systém číselných ukazovateľov (KPI) charakterizujúcich jeho priebeh. Okrem toho musia byť pre ukazovatele definované prípustné rozsahy hodnôt. A iba ak hodnota ukazovateľa prekročí povolený interval, mala by nasledovať kontrolná akcia.

V súvislosti s takouto logikou (alebo mytológiou) riadenia („manažment deviáciou“) konvergujú a starogrécky filozof Platón, ktorý vytvoril obraz kormidelníka (kybernos), ktorý sa opiera o veslo, keď sa loď odchýli z kurzu, a americký matematik Norbert Wiener, ktorý vytvoril vedu kybernetiky v predvečer éry počítačov.

Okrem bežného systému na zaznamenávanie informácií metódou OLTP je potrebný ešte jeden systém - systém na analýzu zozbieraných informácií. Tento doplnok, ktorý v riadiacej slučke plní úlohu spätnej väzby medzi manažmentom a riadiacim objektom, je OLAP systém alebo v skratke OLAP kocka.

Za softvérovú implementáciu OLAP budeme považovať utilitu MS Analysis Services, ktorá je súčasťou štandardnej dodávky MS SQL Server, skrátene SSAS. Všimnite si, že podľa myšlienky E. Codda by kocka OLAP v analytike mala poskytovať rovnakú vyčerpávajúcu slobodu konania, akú poskytuje systém OLTP a relačná databáza (SQL Server) pri ukladaní a získavaní informácií.

Logistika OLAP

Teraz sa pozrime na konkrétnu konfiguráciu externých zariadení, aplikácií a technologických operácií, na ktorých je založená automatizovaná prevádzka OLAP kocky.

Budeme predpokladať, že spoločnosť používa ERP systém, napríklad 1C7 alebo 1C8, v rámci ktorého sa informácie evidujú obvyklým spôsobom. Databáza tohto ERP systému je umiestnená na určitom serveri a je spravovaná MS SQL Serverom.

Budeme tiež predpokladať, že softvér je nainštalovaný na inom serveri, vrátane MS SQL Server s obslužným programom MS Analysis Services (SSAS), ako aj programov MS SQL Server Management Studio, MS C#, MS Excel a MS Visual Studio. Tieto programy spolu tvoria požadovaný kontext: nástroje a potrebné rozhrania pre vývojára kociek OLAP.

Server SSAS má nainštalovaný freeware blat, ktorý sa volá (s parametrami) z príkazový riadok a poskytovanie poštových služieb.

Na pracoviskách zamestnancov, v rámci lokálna sieť, okrem iného sú nainštalované programy MS Excel (verzia 2003 alebo vyššia) a prípadne aj špeciálny ovládač umožňujúci prácu MS Excel s MS Analysis Services (pokiaľ príslušný ovládač už nie je súčasťou MS Excel).

Pre istotu budeme predpokladať, že na pracovných staniciach zamestnancov je nainštalovaný operačný systém Windows XP a na serveroch je nainštalovaný Windows Server 2008. Okrem toho nech sa ako SQL Server používa MS SQL Server 2005 a Enterprise Edition (EE ) resp. Developer Edition (DE). V týchto vydaniach je možné použiť tzv. „poloaditívne opatrenia“, t.j. dodatočné súhrnné funkcie (štatistiky) iné ako bežné súčty (napr. extrémna alebo stredná hodnota).

Dizajn kocky OLAP (kubizmus OLAP)

Povedzme si pár slov o dizajne samotnej OLAP kocky. V jazyku štatistík je kocka OLAP súbor ukazovateľov výkonnosti vypočítaných vo všetkých potrebných častiach, napríklad ukazovateľ zásielky v častiach podľa kupujúcich, podľa tovaru, podľa dátumov atď. Kvôli priamemu prekladu z angličtiny v ruskej literatúre o kockách OLAP sa ukazovatele nazývajú „opatrenia“ a rezy sa nazývajú „rozmery“. Ide o matematicky správny, no syntakticky a sémanticky nie príliš vydarený preklad. Ruské slová „measure“, „measurement“, „dimension“ sa takmer nelíšia vo význame a pravopise, zatiaľ čo anglické „measure“ a „dimension“ sa líšia pravopisom aj významom. Preto dávame prednosť tradičným ruským štatistickým výrazom podobným významu ako „ukazovateľ“ a „rez“.

Existuje niekoľko možností softvérovej implementácie kocky OLAP vo vzťahu k systému OLTP, kde sa údaje zaznamenávajú. Budeme brať do úvahy iba jednu schému, najjednoduchšiu, najspoľahlivejšiu a najrýchlejšiu.

V tejto schéme OLAP a OLTP nemajú spoločné tabuľky a analýzy OLAP sa vypočítavajú čo najpodrobnejšie vo fáze aktualizácie kocky (proces) pred fázou používania. Táto schéma sa nazýva MOLAP (Multidimenzionální OLAP). Jeho nevýhodou je asynchrónnosť s ERP a vysoké náklady na pamäť.

Hoci formálne možno kocku OLAP zostaviť pomocou všetkých (tisícov) tabuliek relačnej databázy systému ERP ako zdroja údajov a všetkých (stoviek) ich polí ako ukazovateľov alebo sekcií, v skutočnosti by sa to nemalo robiť. Naopak. Na načítanie do kocky je správnejšie pripraviť samostatnú databázu s názvom „showcase“ alebo „sklad“ (sklad).

Dôvodov, prečo je to tak, je viacero.

• po prvé, prepojenie kocky OLAP s tabuľkami skutočná základňaúdaje určite spôsobia technické problémy. Zmena údajov v tabuľke môže spustiť obnovenie kocky a obnovenie kocky nie je nevyhnutne rýchly proces, takže kocka bude v stave neustáleho prestavovania; zároveň môže procedúra aktualizácie kocky zablokovať (počas čítania) údaje databázových tabuliek, čím sa spomalí práca používateľov pri evidencii údajov v ERP systéme.
• Po druhé, Prítomnosť príliš veľkého množstva indikátorov a rezov dramaticky zväčší úložnú plochu kocky na serveri. Nezabúdajme, že kocka OLAP ukladá nielen počiatočné údaje ako v systéme OLTP, ale aj všetky ukazovatele zhrnuté nad všetkými možnými sekciami (a dokonca aj nad všetkými kombináciami všetkých sekcií). Okrem toho sa úmerne spomalí rýchlosť aktualizácie kocky a prípadne aj rýchlosť vytvárania a aktualizácie analytiky a užívateľských reportov na nich založených.
• Po tretie, príliš veľa polí (opatrení a aspektov) spôsobí problémy vo vývojárskom rozhraní OLAP, pretože zoznamy prvkov budú nekonečné.
• po štvrté, Kocka OLAP je veľmi citlivá na porušenie integrity údajov. Kocku nemožno zostaviť, ak sa kľúčové údaje nenachádzajú pomocou prepojenia špecifikovaného v štruktúre prepojenia polí kocky. Dočasné alebo trvalé narušenie integrity, prázdne polia sú bežné v databáze ERP systému, ale to kategoricky nie je vhodné pre OLAP.

Môžete tiež dodať, že systém ERP a kocka OLAP by sa mali nachádzať na rôznych serveroch, aby sa zdieľala záťaž. Ale ak existujú spoločné tabuľky pre OLAP a OLTP, je tu aj problém sieťovej prevádzky. Prakticky neriešiteľné problémy nastávajú v tomto prípade, ak je potrebné konsolidovať viacero heterogénnych ERP systémov (1C7, 1C8, MS Dynamics AX) do jednej OLAP kocky.

Pravdepodobne je možné nahromadiť technické problémy ďalej. Ale čo je najdôležitejšie, nezabudnite, že na rozdiel od OLTP nie je OLAP prostriedkom na registráciu a ukladanie údajov, ale analytickým nástrojom. To znamená, že nie je potrebné načítať a načítať „špinavé“ dáta z ERP do OLAP „pre každý prípad“. Naopak, najprv musíte vyvinúť koncepciu riadenia spoločnosti, aspoň na úrovni systému KPI, a potom navrhnúť aplikačný dátový sklad (sklad) umiestnený na rovnakom serveri ako kocka OLAP a obsahujúci malé prepracované množstvo ERP. údaje potrebné na riadenie .

Nepropagovať zlé návyky OLAP-kocku vo vzťahu k OLTP možno prirovnať k známej „alembickej kocke“, pomocou ktorej sa z „fermentovanej hmoty“ skutočnej registrácie extrahuje „čistý produkt“.

Zistili sme, že zdrojom údajov pre OLAP je špeciálna databáza (sklad) umiestnená na rovnakom serveri ako OLAP. V zásade to znamená dve veci. Najprv musia existovať špeciálne postupy, ktoré vytvoria sklad z ERP databáz. Po druhé, kocka OLAP je asynchrónna s jej systémami ERP.

Berúc do úvahy vyššie uvedené, navrhujeme nasledujúcu verziu architektúry výpočtového procesu.

Architektúra riešenia

Nech je veľa ERP systémov určitej korporácie (držiacich) na rôznych serveroch, pre ktoré by sme radi videli konsolidované analytické údaje v rámci jednej kocky OLAP. Zdôrazňujeme, že v opísanej technológii kombinujeme dáta z ERP systémov na úrovni skladu, pričom dizajn OLAP kocky ponechávame nezmenený.

Na OLAP serveri vytvárame obrazy (prázdne kópie) databáz všetkých týchto ERP systémov. K týmto prázdnym kópiám pravidelne (v noci) vykonávame čiastočnú replikáciu databáz zodpovedajúcich aktívne bežiacich ERP.

Ďalej sa spustí SP (uložená procedúra), ktorá na tom istom OLAP serveri bez sieťovej prevádzky na základe čiastočných replík databáz ERP systémov vytvorí (alebo doplní) úložisko (sklad) - dátový zdroj OLAP. kocka.

Potom sa spustí štandardný postup aktualizácie / zostavenia kocky podľa údajov skladu (operácia Proces v rozhraní SSAS).

Poďme sa vyjadriť k niektorým aspektom technológie. Aký druh práce vykonávajú SP?

V dôsledku čiastočnej replikácie sa skutočné údaje objavia v obraze niektorého systému ERP na serveri OLAP. Mimochodom, čiastočná replikácia môže byť vykonaná dvoma spôsobmi.

Po prvé, zo všetkých tabuliek v databáze ERP systému sa pri čiastočnej replikácii skopírujú len tie, ktoré sú potrebné na vybudovanie skladu. Toto je riadené pevným zoznamom názvov tabuliek.

Po druhé, čiastočná replikácia môže tiež znamenať, že sa neskopírujú všetky polia tabuľky, ale iba tie, ktoré sa podieľajú na budovaní skladu. Zoznam polí, ktoré sa majú skopírovať, je buď špecifikovaný alebo dynamicky vytvorený v SP z obrazu kopírovania (ak kópia tabuľky pôvodne neobsahuje všetky polia).

Samozrejme je možné nekopírovať celé riadky tabuľky, ale iba pridávať nové záznamy. To však vytvára vážnu nepríjemnosť pri účtovaní revízií ERP „spätným dátumom“, ktoré sa často vyskytuje v systémoch reálneho života. Takže je jednoduchšie, bez ďalších okolkov, skopírovať všetky záznamy (alebo aktualizovať „chvost“ od nejakého dátumu).

Ďalej je hlavnou úlohou SP konvertovať dáta z ERP systémov do skladového formátu. Ak existuje len jeden ERP systém, potom sa úloha transformácie redukuje hlavne na kopírovanie a prípadne preformátovanie potrebných údajov. Ale ak potrebujete konsolidovať niekoľko ERP systémov v rovnakej kocke OLAP odlišná štruktúra, potom sa transformácie skomplikujú.

Zvlášť náročná je úloha konsolidovať niekoľko rôznych ERP systémov v kocke, ak sa množiny ich objektov (adresáre tovaru, dodávateľov, sklady a pod.) čiastočne prelínajú, objekty majú rovnaký význam, ale prirodzene sú v v adresároch rôznych systémov(v zmysle kódov, identifikátorov, mien a pod.).

V skutočnosti takýto obraz vzniká vo veľkom holdingu, keď niekoľko autonómnych spoločností rovnakého typu, ktoré ho tvoria, vykonáva približne rovnaké druhy činností na približne rovnakom území, ale používa vlastné a nekoordinované registračné systémy. V tomto prípade sa pri konsolidácii údajov na úrovni skladu nezaobídete bez pomocných mapovacích tabuliek.

Venujme trochu pozornosti architektúre skladových priestorov. Typicky je schéma kocky OLAP reprezentovaná ako "hviezda", t.j. ako dátová tabuľka obklopená "lúčmi" adresárov - tabuliek hodnôt sekundárnych kľúčov. Tabuľka je blok "ukazovateľov", referenčné knihy sú ich rezy. Zároveň môže byť adresárom ľubovoľný nevyvážený strom alebo vyvážená hierarchia, napríklad viacúrovňová klasifikácia tovaru alebo protistrán. V kocke OLAP sa číselné polia tabuľky údajov zo skladu automaticky stanú "ukazovateľmi" (alebo mierami) a sekcie (alebo rozmery) môžu byť definované prostredníctvom tabuliek sekundárnych kľúčov.

Toto je vizuálny „pedagogický“ popis. V skutočnosti môže byť architektúra OLAP kocky oveľa zložitejšia.

Po prvé, sklad môže pozostávať z niekoľkých "hviezdičiek", ktoré môžu byť prepojené prostredníctvom spoločných adresárov. V tomto prípade bude kocka OLAP spojením niekoľkých kociek (viacnásobných dátových blokov).

Po druhé, „lúčom“ hviezdičky nemusí byť jeden adresár, ale celý (hierarchický) súborový systém.

Po tretie, na základe existujúcich rozmerových rezov je možné definovať nové hierarchické rezy pomocou vývojárskeho rozhrania OLAP (povedzme s menším počtom úrovní, s iným poradím úrovní atď.)

Po štvrté, nové ukazovatele (výpočty) možno definovať na základe existujúcich ukazovateľov a sekcií pomocou výrazu jazyka MDX. Je dôležité poznamenať, že nové kocky, nové ukazovatele, nové sekcie sú automaticky plne integrované s pôvodnými prvkami. Treba tiež poznamenať, že zle formulované výpočty a hierarchické škrty môžu citeľne spomaliť prácu OLAP kocky.

MS Excel ako rozhranie s OLAP

Zaujímavé je najmä používateľské rozhranie s kockami OLAP. Prirodzene, samotný nástroj SSAS poskytuje najkompletnejšie rozhranie. Ide o súpravu nástrojov pre vývojárov kociek OLAP, návrhára interaktívnych zostáv a okno pre interaktívnu prácu s kockou OLAP pomocou dotazov v jazyku MDX.

Okrem samotného SSAS existuje mnoho programov, ktoré poskytujú rozhranie pre OLAP, pokrývajúce ich funkčnosť vo väčšej či menšej miere. Ale medzi nimi je jeden, ktorý má podľa nás nepopierateľné výhody. Toto je MS Excel.

Rozhranie s MS Excel zabezpečuje špeciálny ovládač, ktorý je možné stiahnuť samostatne alebo je súčasťou Excelu. Nepokrýva všetky funkcie OLAP, ale s rastom počtu verzií MS Excel sa toto pokrytie rozširuje (povedzme v MS Excel 2007 sa objaví grafika KPI, ktorá nebola v MS Excel 2003 atď.).

Samozrejme, okrem pomerne kompletnej funkčnosti je hlavnou výhodou MS Excel všadeprítomná distribúcia tohto programu a úzka znalosť drvivej väčšiny kancelárskych používateľov. V tomto zmysle, na rozdiel od iných programov rozhrania, firma nepotrebuje nič dodatočne získavať a nemusí nikoho dodatočne školiť.

Veľkou výhodou MS Excel ako rozhrania s OLAP je možnosť ďalšieho samostatného spracovania údajov získaných v OLAP zostave (čiže pokračovanie v štúdiu údajov získaných z OLAP na ďalších hárkoch toho istého Excelu, už bez použitia nástroje OLAP, ale pomocou bežných nástrojov Excelu).

Nočný facubi liečebný cyklus

Teraz si popíšeme denný (nočný) výpočtový cyklus prevádzky OLAP. Výpočet sa vykonáva pod kontrolou programu facubi, napísaného v C # 2005 a spúšťa sa pomocou Plánovača úloh na serveri so skladom a SSAS. Na začiatku facubi pristupuje na internet a číta aktuálne výmenné kurzy (používané na reprezentáciu množstva ukazovateľov v mene). Ďalej sa vykonajú nasledujúce kroky.

Po prvé, facubi spúšťa SP, ktoré vykonávajú čiastočnú replikáciu databázy rôznych ERP systémov (holdingových prvkov) dostupných v lokálnej sieti. Replikácia sa vykonáva, ako sme povedali, na vopred pripravených „yardoch“ – obrazoch vzdialených ERP systémov umiestnených na serveri SSAS.

Po druhé, prostredníctvom SP sa vykoná mapovanie z replík ERP do skladového úložiska - špeciálnej databázy, ktorá je zdrojom údajov kocky OLAP a nachádza sa na serveri SSAS. Tým sa dosiahnu tri hlavné úlohy:

• ERP údaje sú uvedené v požadovaných formátoch kocky; hovoríme o tabuľkách a tabuľkových poliach. (Niekedy je potrebné „vyformovať“ požadovanú tabuľku, povedzme z niekoľkých listov MS Excel.) Podobné údaje môžu mať v rôznych ERP rôzny formát, napríklad kľúčové polia ID v adresároch 1C7 majú 36-miestny kód s dĺžkou 8 a polia _idrref v adresároch 1C8 - hexadecimálne čísla s dĺžkou 32;
• počas spracovania vykonáva sa logická kontrola údajov (vrátane predpisovania „predvolených“ štandardných nastavení namiesto chýbajúcich údajov, ak je to možné) a kontrola integrity, t.j. kontrola prítomnosti primárnych a sekundárnych kľúčov v zodpovedajúcich klasifikátoroch;
• konsolidácia kódu objekty, ktoré majú rovnaký význam v rôznych ERP. Napríklad zodpovedajúce prvky adresárov rôznych ERP môžu mať rovnaký význam, povedzme, ide o rovnakú protistranu. Úloha konsolidácie kódov je riešená konštrukciou mapovacích tabuliek, kde sa rôzne kódy tých istých objektov spájajú do jednoty.

Po tretie, facubi spúšťa štandardnú procedúru aktualizácie dát procesnej kocky (z procedúr pomôcky SSAS).

Podľa kontrolných zoznamov facubi posiela e-mailové správy o priebehu krokov spracovania.

Po spustení facubi plánovač úloh postupne spustí niekoľko excelových súborov, v ktorých sú vopred vytvorené zostavy na základe indikátorov kocky OLAP. Ako sme povedali, MS Excel má špeciálne programovacie rozhranie (samostatne stiahnuteľné alebo vstavaný ovládač) na prácu s OLAP kockami (so SSAS). Po spustení MS Excel sú zahrnuté programy na MS VBA (napríklad makrá), ktoré zabezpečujú aktualizáciu údajov v zostavách; správy sa v prípade potreby upravia a zašlú poštou (program Blat) používateľom podľa kontrolných zoznamov.

Používatelia lokálnej siete s prístupom k serveru SSAS budú dostávať „živé“ správy nakonfigurované pre kocku OLAP. (V zásade môžu sami, bez akejkoľvek pošty, aktualizovať zostavy OLAP v MS Excel, ležiace na svojich lokálnych počítačoch.) Používatelia mimo lokálnej siete buď dostanú originálne zostavy, ale s obmedzenou funkcionalitou, alebo pre nich (po aktualizácii zostavy OLAP v MS Excel) budú vypočítané špeciálne "mŕtve" správy, ktoré nekontaktujú server SSAS.

Vyhodnotenie výsledkov

Vyššie sme hovorili o asynchrónnosti OLTP a OLAP. V uvažovanej verzii technológie sa cyklus aktualizácie kocky OLAP vykonáva v noci (povedzme, že začína o 1:00). To znamená, že v aktuálny pracovný deň používatelia pracujú s údajmi zo včera. Pretože OLAP nie je nástroj na zaznamenávanie (pozri najnovšiu verziu dokumentu), ale nástroj na správu (rozumej trend procesu), tento backlog zvyčajne nie je kritický. V prípade potreby je však možné aj v opísanej verzii architektúry kocky (MOLAP) aktualizovať niekoľkokrát denne.

Čas vykonania aktualizačných procedúr závisí od konštrukčných vlastností kocky OLAP (väčšia či menšia zložitosť, viac či menej úspešné definície ukazovateľov a sekcií) a od objemu databáz externých systémov OLTP. Podľa skúseností postupy výstavby skladu trvajú niekoľko minút až dve hodiny, postup aktualizácie kocky (Proces) trvá od 1 do 20 minút. Hovoríme o zložitých OLAP kockach, ktoré kombinujú desiatky hviezdnych štruktúr, o desiatkach pre ne bežných „lúčov“ (referenčných rezov), o stovkách indikátorov. Pri odhadovaní objemu databáz externých ERP systémov expedíciou dokladov hovoríme o stovkách tisíc dokladov a teda o miliónoch produktových radov ročne. Historická hĺbka spracovania záujmu používateľa bola tri až päť rokov.

Opísaná technológia sa používa v mnohých veľkých korporáciách: od roku 2008 v Russian Fish Company (RRK) a Russian Sea Company (RM), od roku 2012 v Santa Bremor Company (SB). Niektoré z korporácií sú prevažne obchodné firmy (RRK), iné sú výrobné firmy (závody na spracovanie rýb a morských plodov v Moldavskej republike a Bezpečnostná rada). Všetky korporácie sú veľké holdingy, ktoré združujú niekoľko spoločností s nezávislými a rôznymi počítačovými účtovnými systémami – od štandardných ERP systémov ako 1C7 a 1C8 až po „reliktné“ účtovné systémy založené na DBF a Excel. Dodám, že opísaná technológia na prevádzku kociek OLAP (bez zohľadnenia štádia vývoja) buď vôbec nevyžaduje špeciálnych zamestnancov, alebo je zahrnutá do zodpovednosti jedného obchodného analytika na plný úväzok. Úloha sa točí už roky v automatickom režime, denne zásobuje rôzne kategórie firemných zamestnancov aktuálnymi výkazmi.

Výhody a nevýhody riešenia

Ako ukazujú skúsenosti, variant navrhovaného riešenia je celkom spoľahlivý a ľahko ovládateľný. Je ľahko modifikovateľný (pripojenie / odpojenie nových ERP, vytváranie nových ukazovateľov a sekcií, vytváranie a úprava správ Excel a ich zoznamov adries) s invariantnosťou ovládacieho programu facubi.

MS Excel ako rozhranie s OLAP poskytuje dostatočnú expresivitu a umožňuje rôznym kategóriám kancelárskych pracovníkov rýchlo sa pripojiť k technológii OLAP. Používateľ dostáva denne „štandardné“ správy OLAP; pomocou rozhrania MS Excel s OLAP, môže nezávisle vytvárať OLAP správy v MS Excel. Okrem toho môže používateľ nezávisle pokračovať v skúmaní informácií zo správ OLAP pomocou obvyklých možností svojho MS Excel.

„Prepracovaná“ skladová databáza, v ktorej je konsolidovaných niekoľko heterogénnych ERP systémov (pri konštrukcii kocky) aj bez akéhokoľvek OLAP, umožňuje riešiť (na SSAS serveri, metódou Transact SQL dotaz alebo SP metódou a pod.) a veľa aplikovaných manažérskych úloh. Pripomeňme, že štruktúra databáz skladu je jednotná a oveľa jednoduchšia (čo sa týka počtu tabuliek a počtu polí tabuľky) ako databázové štruktúry pôvodného ERP.

Osobitne upozorňujeme, že v našom navrhovanom riešení existuje možnosť konsolidácie rôznych systémov ERP do jednej kocky OLAP. To vám umožňuje získať analytiku pre celý holding a udržiavať dlhodobú kontinuitu v analytike, keď spoločnosť prejde na iný účtovný systém ERP, povedzme pri prechode z 1C7 na 1C8.

Použili sme model kocky MOLAP. Výhodou tohto modelu je spoľahlivosť v prevádzke a vysoká rýchlosť spracovania užívateľských požiadaviek. Nevýhody - asynchrónne OLAP a OLTP, ako aj veľké množstvo pamäte na ukladanie OLAP.

Na záver uveďme ešte jeden argument v prospech OLAP, ktorý by bol možno vhodnejší v stredoveku. Pretože jeho dôkazná sila spočíva na autorite. Skromný, jasne podceňovaný britský matematik E. Codd vyvinul teóriu relačných databáz koncom 60. rokov. Sila tejto teórie bola taká, že teraz, po 50 rokoch, je už ťažké nájsť nerelačnú databázu a databázový dopytovací jazyk iný ako SQL.

Prvou myšlienkou E. Codda bola technológia OLTP, založená na teórii relačných databáz. V skutočnosti je koncept OLAP kociek jeho druhou myšlienkou, ktorú vyjadril na začiatku 90. rokov. Aj keď nie ste matematik, môžete očakávať, že druhý nápad bude rovnako účinný ako prvý. To znamená, že pokiaľ ide o počítačovú analýzu, nápady OLAP čoskoro ovládnu svet a nahradia všetky ostatné. Jednoducho preto, že téma analytiky nachádza svoje vyčerpávajúce matematické riešenie v OLAP a toto riešenie je „adekvátne“ (pojem B. Spinoza) na praktickú úlohu analytiky. „Adekvátne“ znamená v Spinozovi, že ani sám Boh by nemohol prísť s lepším nápadom...

1. Larson B. Vývoj business intelligence v Microsoft SQL Server 2005. - Petrohrad: "Piter", 2008.
2. Codd E. Relačná úplnosť databázových podjazykov, databázové systémy, Courant Computer Science Sumposia Series 1972, v. 6, Englwood cliffs, NY, Prentice–Hall.

V kontakte s

Čo je dnes OLAP, vo všeobecnosti vie každý špecialista. Prinajmenšom pojmy „OLAP“ a „multidimenzionálne údaje“ sú v našich mysliach pevne spojené. Napriek tomu skutočnosť, že táto téma sa opäť otvára, dúfam, bude schválená väčšinou čitateľov, pretože aby myšlienka, že časom nezostarla, musíte pravidelne komunikovať s chytrí ľudia alebo si prečítajte články v dobrej publikácii...

Dátové sklady (miesto OLAP v informačnej štruktúre podniku)

Pojem „OLAP“ je neoddeliteľne spojený s pojmom „dátový sklad“ (Data Warehouse).

Tu je definícia formulovaná „otcom zakladateľom“ dátových skladov Billom Inmonom: „Dátový sklad je doménovo špecifický, časovo viazaný a nemenný zber údajov na podporu procesu prijímania manažérskych rozhodnutí.“

Dáta v úložisku pochádzajú z operačných systémov (OLTP systémy), ktoré sú určené na automatizáciu obchodných procesov. Úložisko je navyše možné dopĺňať z externých zdrojov, ako sú štatistické výkazy.

Načo budovať dátové sklady – veď obsahujú evidentne nadbytočné informácie, ktoré už „žijú“ v databázach či súboroch operačných systémov? Odpoveď môže byť krátka: priamo analyzovať údaje operačných systémov je nemožné alebo veľmi ťažké. Je to spôsobené rôznymi dôvodmi, medzi ktoré patrí fragmentácia údajov, ich ukladanie vo formátoch rôznych DBMS a v rôznych „rohoch“ podnikovej siete. Ale aj keď sú všetky údaje v podniku uložené na centrálnom databázovom serveri (čo je extrémne zriedkavé), analytik takmer určite nepochopí ich zložité, niekedy mätúce štruktúry. Autor má dosť smutnú skúsenosť so snahou "nakŕmiť" hladných analytikov "surovými" dátami z operačných systémov - ukázalo sa to byť pre nich príliš tvrdé.

Úlohou úložiska je teda poskytnúť „suroviny“ na analýzu na jednom mieste a v jednoduchej, zrozumiteľnej štruktúre. Ralph Kimball v predslove ku svojej knihe „The Data Warehouse Toolkit“ píše, že ak čitateľ po prečítaní celej knihy pochopí iba jednu vec, a to, že štruktúra skladu by mala byť jednoduchá, autor zváži svoju úlohu dokončené.

Existuje ďalší dôvod, ktorý ospravedlňuje vzhľad samostatného úložiska - zložité analytické dotazy na prevádzkové informácie spomaľujú súčasnú prácu spoločnosti, blokujú tabuľky na dlhú dobu a zaberajú zdroje servera.

Podľa môjho názoru nie je úložisko nevyhnutne obrovskou akumuláciou údajov - hlavnou vecou je, že je vhodné na analýzu. Vo všeobecnosti je pre malé úložiská určený samostatný pojem – Data Marts (dátové kiosky), ale v našej ruskej praxi ho často nepočuť.

OLAP je užitočný analytický nástroj

Centralizácia a pohodlná štruktúra nie sú zďaleka všetko, čo analytik potrebuje. Koniec koncov, stále potrebuje nástroj na prezeranie, vizualizáciu informácií. Tradičným reportom, dokonca vybudovaným na základe jediného úložiska, chýba jedna vec – flexibilita. Nemožno ich "skrútiť", "rozbaliť" alebo "zbaliť", aby ste získali požadovaný pohľad na údaje. Samozrejme, môžete zavolať programátorovi (ak chce prísť), a ten (ak nie je zaneprázdnený) urobí novú správu pomerne rýchlo - povedzme do hodiny (píšem a sám tomu neverím - v živote to nejde tak rýchlo; dajme mu tri hodiny) . Ukazuje sa, že analytik nemôže skontrolovať viac ako dva nápady za deň. A on (ak je dobrý analytik) dokáže prísť s niekoľkými nápadmi za hodinu. A čím viac „výrezov“ a „výrezov“ údajov analytik vidí, tým viac nápadov má, čo si zase vyžaduje stále viac nových „výrezov“ na overenie. Prial by som si, aby mal taký nástroj, ktorý by mu umožnil jednoducho a pohodlne rozbaliť a zbaliť údaje! OLAP je jedným z takýchto nástrojov.

Hoci OLAP nie je nevyhnutným atribútom dátového skladu, stále viac sa používa na analýzu informácií nahromadených v tomto dátovom sklade.

Komponenty zahrnuté v typickom sklade sú znázornené na obr. 1.

Ryža. 1. Štruktúra dátového skladu

Prevádzkové údaje sa zhromažďujú z rôznych zdrojov, čistia sa, integrujú a vkladajú do relačného úložiska. Zároveň sú už dostupné na analýzu pomocou rôznych reportovacích nástrojov. Potom sa údaje (celé alebo ich časti) pripravia na analýzu OLAP. Môžu byť načítané do špeciálnej databázy OLAP alebo ponechané v relačnom obchode. Jeho najdôležitejším prvkom sú metadáta, teda informácie o štruktúre, umiestnení a transformácii údajov. Vďaka nim je zabezpečená efektívna súhra rôznych skladovacích komponentov.

Stručne povedané, môžeme OLAP definovať ako súbor nástrojov na multidimenzionálnu analýzu údajov nahromadených v sklade. Teoreticky možno nástroje OLAP aplikovať priamo na prevádzkové údaje alebo ich presné kópie (aby nezasahovali do prevádzkových používateľov). Tým sa však vystavujeme riziku, že šliapneme na už popísané hrable, t. j. začneme analyzovať prevádzkové údaje, ktoré nie sú priamo vhodné na analýzu.

Definícia a základné pojmy OLAP

Na začiatok dešifrujeme: OLAP je online analytické spracovanie, to znamená online analýza údajov. 12 definujúcich princípov OLAP sformuloval v roku 1993 E. F. Codd, „vynálezca“ relačných databáz. Neskôr bola jeho definícia prepracovaná na takzvaný test FASMI, ktorý vyžaduje aplikáciu OLAP, ktorá poskytuje schopnosť rýchlej analýzy zdieľaných viacrozmerných informácií ().

FASMI test

Rýchlo(Rýchlo) – analýza by mala byť vykonaná rovnako rýchlo vo všetkých aspektoch informácií. Prijateľná doba odozvy je 5 sekúnd alebo menej.

Analýza(Analýza) – Malo by byť možné vykonávať základné typy numerických a štatistických analýz, preddefinované vývojárom aplikácie alebo ľubovoľne definované používateľom.

zdieľané(Zdieľané) – K údajom musí mať prístup viacero používateľov, pričom prístup k citlivým informáciám musí byť kontrolovaný.

Viacrozmerný(Multidimenzionálny) je hlavnou, najpodstatnejšou charakteristikou OLAP.

Informácie(Informácie) – aplikácia musí mať prístup ku všetkým potrebným informáciám bez ohľadu na ich objem a miesto uloženia.

OLAP = Multidimenzionálny pohľad = Kocka

OLAP poskytuje pohodlné, vysokorýchlostné prostriedky na prístup, prezeranie a analýzu obchodných informácií. Používateľ získa prirodzený, intuitívny dátový model, ktorý ich organizuje vo forme viacrozmerných kociek (Cubes). Osi viacrozmerného súradnicového systému sú hlavnými atribútmi analyzovaného podnikového procesu. Napríklad pri predaji to môže byť produkt, región, typ kupujúceho. Ako jedno z meraní sa používa čas. Na priesečníkoch osí – merania (Dimensions) – sú údaje, ktoré kvantitatívne charakterizujú proces – miery (Measures). Môžu to byť objemy predaja v kusoch alebo v peňažnom vyjadrení, stavy zásob, náklady atď. Používateľ, ktorý analyzuje informácie, môže kocku „rezať“ rôznymi smermi, získať súhrn (napríklad podľa rokov) alebo naopak podrobný (týždenný). informácie a vykonávať ďalšie manipulácie, ktoré mu prídu na myseľ v procese analýzy.

Ako miery v trojrozmernej kocke znázornenej na obr. 2 sa používajú predajné množstvá a ako merania sa používa čas, produkt a sklad. Merania sú prezentované na konkrétnych úrovniach zoskupenia: produkty sú zoskupené podľa kategórie, obchody sú zoskupené podľa krajiny a časy transakcií sú zoskupené podľa mesiacov. O niečo neskôr sa budeme podrobnejšie zaoberať úrovňami zoskupovania (hierarchie).

Ryža. 2. Príklad kocky

"rezanie" kocky

Dokonca aj trojrozmernú kocku je ťažké zobraziť na obrazovke počítača, aby bolo možné vidieť hodnoty meraní, ktoré nás zaujímajú. Čo môžeme povedať o kockách s viac ako tromi rozmermi? Na vizualizáciu dát uložených v kocke sa spravidla používajú bežné dvojrozmerné, t. j. tabuľkové zobrazenia, ktoré majú zložité hierarchické hlavičky riadkov a stĺpcov.

Dvojrozmernú reprezentáciu kocky možno získať jej „rozrezaním“ cez jednu alebo viacero osí (rozmerov): zafixujeme hodnoty všetkých rozmerov okrem dvoch a získame pravidelnú dvojrozmernú tabuľku . Vodorovná os tabuľky (hlavičky stĺpcov) predstavuje jednu dimenziu, zvislá os (hlavičky riadkov) predstavuje ďalšiu dimenziu a bunky tabuľky predstavujú namerané hodnoty. V tomto prípade je množina mier skutočne považovaná za jednu z dimenzií - buď vyberieme jednu mieru na zobrazenie (a potom môžeme umiestniť dve dimenzie do hlavičiek riadkov a stĺpcov), alebo zobrazíme niekoľko mier (a potom jednu osí tabuľky budú obsadené názvami mier a druhá - hodnota jedného "neorezaného" rozmeru).

Pozrite sa na obr. 3 - tu je dvojrozmerný výrez kocky na jednu mieru - Unit Sales (predané kusy) a dva "nerozrezané" rozmery - Store (Store) a Time (Time).

Ryža. 3. Výrez dvojrozmernej kocky na jeden takt

Na obr. 4 zobrazuje iba jednu „nevystrihnutú“ dimenziu – Obchod, ale zobrazuje hodnoty niekoľkých meraní – Jednotkový predaj (predané kusy), Predaj v obchode (množstvo predaja) a Náklady na predajňu (výdavky v obchode).

Ryža. 4. 2D krájanie kociek pre viacero meraní

Dvojrozmerné znázornenie kocky je možné aj vtedy, keď zostanú „nerozrezané“ viac ako dva rozmery. V tomto prípade sa na osi rezu (riadky a stĺpce) umiestnia dva alebo viac rozmerov "narezanej" kocky - viď obr. 5.

Ryža. 5. Dvojrozmerný rez kocky s niekoľkými rozmermi na tej istej osi

Tagy

Hodnoty „odložené“ pozdĺž dimenzií sa nazývajú členy alebo štítky (členy). Štítky slúžia ako na „rezanie“ kocky, tak aj na obmedzenie (filtrovanie) vybraných údajov – keď nás v dimenzii, ktorá ostane „neorezaná“ nezaujímajú všetky hodnoty, ale ich podmnožinu, napríklad tri mestá z viacerých tucet. Hodnoty štítkov sa zobrazujú v zobrazení 2D kocky ako hlavičky riadkov a stĺpcov.

Hierarchie a úrovne

Štítky je možné kombinovať do hierarchií pozostávajúcich z jednej alebo viacerých úrovní. Napríklad štítky dimenzie „Obchod“ (Obchod) sú prirodzene spojené do hierarchie s úrovňami:

Krajina (krajina)

štát (štát)

Mesto (mesto)

Obchod (Obchod).

Podľa úrovní hierarchie sa počítajú súhrnné hodnoty, ako sú predaje pre USA (úroveň „Krajina“) alebo pre Kaliforniu (úroveň „Štát“). V jednej dimenzii je možné implementovať viac ako jednu hierarchiu – povedzme pre čas: (Rok, Štvrťrok, Mesiac, Deň) a (Rok, Týždeň, Deň).

Aplikačná architektúra OLAP

Všetko, čo bolo povedané vyššie o OLAP, sa v skutočnosti týkalo viacrozmernej prezentácie údajov. Spôsob, akým sú dáta uchovávané, sa, zhruba povedané, netýka ani koncového používateľa, ani vývojárov nástroja, ktorý klient používa.

Multidimenzionalitu v OLAP aplikáciách možno rozdeliť do troch úrovní:

• Multidimenzionálna reprezentácia údajov – nástroje pre koncových používateľov, ktoré poskytujú viacrozmernú vizualizáciu a manipuláciu s údajmi; vrstva viacrozmernej reprezentácie abstrahuje od fyzickej štruktúry údajov a zaobchádza s nimi ako s viacrozmernými.
• Multidimenzionálne spracovanie - nástroj (jazyk) na formulovanie viacrozmerných dotazov (tradičný relačný jazyk SQL je tu nevhodný) a procesor, ktorý dokáže takýto dotaz spracovať a vykonať.
• Multidimenzionálne úložisko - prostriedky fyzickej organizácie údajov, ktoré poskytujú efektívne vykonávanie viacrozmerných dopytov.

Prvé dve úrovne sú povinné vo všetkých nástrojoch OLAP. Tretia úroveň, aj keď je široko používaná, nie je potrebná, pretože údaje pre viacrozmernú reprezentáciu možno získať aj z bežných relačných štruktúr; procesor viacrozmerných dotazov v tomto prípade prekladá viacrozmerné dotazy na dotazy SQL, ktoré sú vykonávané relačným DBMS.

Špecifické produkty OLAP sú zvyčajne buď multidimenzionálny nástroj na prezentáciu údajov, klient OLAP (napríklad kontingenčné tabuľky v Exceli 2000 od Microsoftu alebo ProClarity od Knosys), alebo multidimenzionálny back-end DBMS, OLAP server (napríklad Oracle Express Server alebo Microsoft OLAP Services).

Vrstva viacrozmerného spracovania je zvyčajne zabudovaná do klienta OLAP a/alebo servera OLAP, ale môže byť izolovaná vo svojej najčistejšej forme, ako napríklad komponent služby kontingenčnej tabuľky od spoločnosti Microsoft.

Technické aspekty viacrozmerného ukladania dát

Ako bolo uvedené vyššie, analytické nástroje OLAP môžu tiež extrahovať údaje priamo z relačných systémov. Tento prístup bol atraktívnejší v čase, keď OLAP servery neboli v cenníkoch popredných predajcov databáz. Dnes však Oracle, Informix a Microsoft ponúkajú plnohodnotné OLAP servery a dokonca aj tí IT manažéri, ktorí neradi vysádzajú do svojich sietí „zoo“ softvéru od rôznych výrobcov, si môžu kúpiť (presnejšie požiadať s príslušnou žiadosťou vedeniu spoločnosti ) OLAP server rovnakej značky ako hlavný databázový server.

Servery OLAP alebo viacrozmerné databázové servery môžu ukladať svoje viacrozmerné údaje rôznymi spôsobmi. Pred zvážením týchto metód musíme hovoriť o takom dôležitom aspekte, akým je skladovanie kameniva. Faktom je, že v akomkoľvek dátovom sklade - v bežnom aj viacrozmernom - sa spolu s podrobnými dátami získanými z operačných systémov ukladajú aj sumárne ukazovatele (agregované ukazovatele, agregáty), ako sú súčty objemov predaja podľa mesiacov, podľa kategórií. tovar atď. Agregáty sa ukladajú výslovne len za účelom urýchlenia vykonania dopytu. Koniec koncov, na jednej strane sa v úložisku spravidla hromadí veľmi veľké množstvo údajov a na druhej strane sa analytici vo väčšine prípadov nezaujímajú o podrobné, ale o zovšeobecnené ukazovatele. A ak by sa na výpočet objemu predaja za rok museli zakaždým sčítať milióny jednotlivých predajov, rýchlosť by bola s najväčšou pravdepodobnosťou neprijateľná. Preto sa pri načítavaní údajov do multidimenzionálnej databázy vypočítajú a uložia všetky celkové ukazovatele alebo ich časť.

Ale ako viete, za všetko musíte zaplatiť. A za rýchlosť spracovania dopytov na súhrnné údaje musíte zaplatiť zvýšením množstva údajov a času potrebného na ich načítanie. Navyše nárast objemu môže byť doslova katastrofálny - v jednom z publikovaných štandardných testov si kompletný počet agregátov na 10 MB počiatočných dát vyžiadal 2,4 GB, teda dáta narástli 240-krát! Miera "napučania" údajov pri výpočte agregátov závisí od počtu rozmerov kocky a štruktúry týchto rozmerov, teda pomeru počtu "otcov" a "detí" na rôznych úrovniach dimenzie. Na vyriešenie problému skladovania kameniva sa niekedy používajú komplexné schémy, ktoré umožňujú pri výpočte ďaleko od všetkých možných agregátov dosiahnuť výrazné zvýšenie výkonu vykonávania dotazu.

Teraz o rôznych možnostiach ukladania informácií. Podrobné údaje aj agregáty môžu byť uložené v relačných alebo viacrozmerných štruktúrach. Viacrozmerné úložisko vám umožňuje zaobchádzať s údajmi ako s viacrozmerným poľom, ktoré poskytuje rovnako rýchly výpočet súčtov a rôzne viacrozmerné transformácie na ľubovoľnej z dimenzií. Pred časom produkty OLAP podporovali buď relačné alebo viacrozmerné úložisko. Dnes spravidla rovnaký produkt poskytuje oba tieto typy skladovania, ako aj tretí typ - zmiešaný. Platia nasledujúce podmienky:

• MOLAP(Multidimenzionálny OLAP) – podrobné údaje aj agregáty sú uložené vo viacrozmernej databáze. V tomto prípade sa získa najväčšia redundancia, pretože viacrozmerné údaje úplne obsahujú relačné údaje.
• ROLAP(Relational OLAP) - podrobné údaje zostávajú tam, kde pôvodne "žili" - v relačnej databáze; agregáty sú uložené v rovnakej databáze v špeciálne vytvorených tabuľkách služieb.
• HOLAP(Hybrid OLAP) - podrobné dáta zostávajú na mieste (v relačnej databáze), zatiaľ čo agregáty sú uložené v multidimenzionálnej databáze.

Každá z týchto metód má svoje výhody a nevýhody a mala by sa používať v závislosti od podmienok – množstva dát, výkonu relačnej DBMS atď.

Pri ukladaní dát vo viacrozmerných štruktúrach vzniká potenciálny problém „nafúknutia“ v dôsledku ukladania prázdnych hodnôt. Ak je totiž v multidimenzionálnom poli rezervované miesto pre všetky možné kombinácie meracích štítkov a v skutočnosti je vyplnená len malá časť (napríklad množstvo produktov sa predáva len v malom počte regiónov), potom väčšina kocka bude prázdna, hoci miesto bude obsadené. Moderné produkty OLAP sa s týmto problémom dokážu vyrovnať.

Pokračovanie nabudúce. V budúcnosti budeme hovoriť o konkrétnych produktoch OLAP vyrábaných poprednými výrobcami.

OLAP nie je jediný softvérový produkt, ani programovací jazyk a dokonca ani špecifická technológia. Ak sa pokúsite pokryť OLAP vo všetkých jeho prejavoch, potom ide o súbor konceptov, princípov a požiadaviek, ktoré sú základom softvérových produktov, ktoré uľahčujú analytikom prístup k údajom. Poďme zistiť Prečo analytici potrebujú niečo špeciálne uľahčiť prístup k údajom.

Faktom je, že analytici sú špeciálnymi spotrebiteľmi podnikových informácií. Úlohou analytika je nájsť vzory vo veľkých dátových poliach. Preto analytik nebude venovať pozornosť jedinej skutočnosti, že vo štvrtok štvrtý deň bola dávka čierneho atramentu predaná protistrane Černovovi - potrebuje informácie o stovkách a tisíckach podobné udalosti. Jednotlivé fakty v databáze môžu zaujímať napríklad účtovníka alebo vedúceho obchodného oddelenia, v kompetencii ktorého sa transakcia nachádza. Jeden záznam analytikovi nestačí – môže napríklad potrebovať všetky transakcie danej pobočky alebo zastúpenia na mesiac alebo rok. Zároveň analytik vyhodí zbytočné detaily ako DIČ kupujúceho, jeho presnú adresu a telefónne číslo, index zmluvy a podobne. Zároveň údaje, ktoré analytik potrebuje na prácu, nevyhnutne obsahujú číselné hodnoty - je to kvôli samotnej podstate jeho činnosti.

Analytik teda potrebuje veľa údajov, tieto údaje sú selektívne a majú tiež charakter “ súbor atribútov - číslo". To znamená, že analytik pracuje s tabuľkami nasledujúceho typu:

Tu " Krajina", "Produkt", "rok“ sú atribúty resp merania, A " Objem predaja“ – teda číselná hodnota resp opatrenie. Opakujeme, že úlohou analytika je identifikovať pretrvávajúce vzťahy medzi atribútmi a číselnými parametrami.. Pri pohľade na tabuľku môžete vidieť, že sa dá ľahko preložiť do troch rozmerov: na jednu z osí umiestnime krajiny, na druhú - tovar, na tretiu - roky. A hodnoty v tomto trojrozmernom poli budú zodpovedajúce objemy predaja.

3D znázornenie tabuľky. Sivý segment ukazuje, že pre Argentínu v roku 1988 neexistujú žiadne údaje

Presne takémuto trojrozmernému poľu v zmysle OLAP hovoríme kocka. V skutočnosti z pohľadu prísnej matematiky nebude takéto pole vždy kockou: pre skutočnú kocku musí byť počet prvkov vo všetkých rozmeroch rovnaký, zatiaľ čo OLAP kocky takéto obmedzenie nemajú. Napriek týmto detailom sa však pojem „kocky OLAP“ vďaka svojej stručnosti a obraznosti stal všeobecne akceptovaným. Kocka OLAP vôbec nemusí byť 3D. Môže byť dvojrozmerný aj viacrozmerný v závislosti od riešeného problému. Najmä skúsení analytici môžu potrebovať asi 20 meraní – a seriózne produkty OLAP sú určené práve pre takýto počet. Jednoduchšie desktopové aplikácie podporujú približne 6 rozmerov.

merania OLAP kocky sú tvorené tzv známky alebo členov. Napríklad dimenzia „Krajina“ pozostáva zo štítkov „Argentína“, „Brazília“, „Venezuela“ atď.

Nie všetky prvky kocky by mali byť vyplnené: ak neexistujú žiadne informácie o predaji gumových výrobkov v Argentíne v roku 1988, hodnota v zodpovedajúcej bunke sa jednoducho nestanoví. Nie je tiež potrebné, aby aplikácia OLAP ukladala údaje nevyhnutne vo viacrozmernej štruktúre - hlavné je, že pre používateľa tieto údaje vyzerajú presne tak. Mimochodom, práve pri špeciálnych spôsoboch kompaktného ukladania multidimenzionálnych dát nevedie „vákuovanie“ (nevyplnené prvky) v kockách k plytvaniu pamäťou.

Samotná kocka však nie je vhodná na analýzu. Ak je ešte možné primerane znázorniť alebo zobraziť trojrozmernú kocku, potom so šiestimi alebo devätnástimi rozmermi je situácia oveľa horšia. Preto pred použitím obyčajné kocky sú extrahované z viacrozmernej kocky dvojrozmerné tabuľky. Táto operácia sa nazýva "rezanie" kocky. Tento výraz je opäť obrazný. Analytik, ako to bolo, vezme a "vyreže" rozmery kocky podľa značiek, ktoré ho zaujímajú. Analytik tak dostane dvojrozmerný výsek kocky a pracuje s ním. Približne rovnako počítajú drevorubači letokruhy na reze píly.

V súlade s tým spravidla zostávajú "neorezané" iba dva rozmery - podľa počtu rozmerov tabuľky. Stáva sa, že „neorezaný“ zostane len rozmer – ak kocka obsahuje viacero typov číselných hodnôt, dajú sa vykresliť podľa jedného z rozmerov tabuľky.

Ak sa bližšie pozriete na tabuľku, ktorú sme zobrazili ako prvú, môžete vidieť, že údaje v nej s najväčšou pravdepodobnosťou nie sú primárne, ale sú získané v dôsledku zhrnutie pre menšie predmety. Napríklad rok je rozdelený na štvrťroky, štvrťroky na mesiace, mesiace na týždne, týždne na dni. Krajina sa skladá z regiónov a regióny sa skladajú z lokalít. Napokon v samotných mestách možno rozlíšiť okresy a konkrétne maloobchodné predajne. Produkty je možné spájať do skupín produktov a pod. Z hľadiska OLAP sa takéto viacúrovňové spojenia celkom logicky nazývajú hierarchie. Nástroje OLAP umožňujú kedykoľvek prejsť na požadovanú úroveň hierarchie. Okrem toho je pre rovnaké prvky spravidla podporovaných niekoľko typov hierarchií: napríklad deň-týždeň-mesiac alebo deň-dekáda-štvrťrok. Zdrojové údaje sa preberajú z nižších úrovní hierarchií a potom sa sumarizujú, aby sa získali hodnoty z vyšších úrovní. Aby sa proces prechodu urýchlil, súhrnné hodnoty pre rôzne úrovne sú uložené v kocke. To, čo vyzerá ako jedna kocka zo strany používateľa, teda zhruba povedané pozostáva z mnohých primitívnejších kociek.

Príklad hierarchie

Toto je jeden z podstatných bodov, ktorý viedol k vzniku OLAP – produktivita a efektívnosť. Predstavme si, čo sa stane, keď analytik potrebuje získať informácie a nástroje OLAP nie sú v podniku dostupné. Analytik nezávisle (čo je nepravdepodobné) alebo s pomocou programátora vytvorí vhodný SQL dotaz a dostane údaje, ktoré ho zaujímajú, vo forme správy alebo ich exportuje do tabuľky. S tým je veľa problémov. Po prvé, analytik je nútený robiť niečo iné ako svoju prácu (programovanie SQL) alebo čakať na programátorov, ktorí to urobia za neho - to všetko negatívne ovplyvňuje produktivitu práce, zvyšuje sa napadnutie, srdcový infarkt a mozgová príhoda atď. . Po druhé, jediná správa alebo tabuľka spravidla nezachráni myšlienkových gigantov a otcov ruskej analýzy - a celý postup sa bude musieť znova a znova opakovať. Po tretie, ako sme už zistili, analytici sa nepýtajú na maličkosti - potrebujú všetko naraz. To znamená (hoci technológia napreduje míľovými krokmi), že podnikový relačný databázový server, ku ktorému pristupuje analytik, môže myslieť hlboko a na dlhú dobu a blokovať zvyšok transakcií.

Koncept OLAP sa objavil práve na riešenie takýchto problémov. Kocky OLAP sú v podstate meta-správy. Rozrezaním meta-správ (čiže kociek) podľa dimenzií analytik v skutočnosti dostáva „bežné“ dvojrozmerné správy, ktoré ho zaujímajú (nie sú to nevyhnutne správy v bežnom zmysle slova – hovoríme o dátových štruktúrach). s rovnakými funkciami). Výhody kociek sú zrejmé - údaje je potrebné vyžiadať z relačného DBMS iba raz - pri zostavovaní kocky. Keďže analytici spravidla nepracujú s informáciami, ktoré sa dopĺňajú a menia za chodu, vygenerovaná kocka je relevantná pomerne dlho. Vďaka tomu sú nielen eliminované prerušenia prevádzky relačného DBMS servera (odpadajú dopyty s tisíckami a miliónmi odpovedí), ale dramaticky sa zvyšuje aj rýchlosť prístupu k dátam pre samotného analytika. Okrem toho, ako už bolo uvedené, výkon sa zlepšuje aj výpočtom čiastkových súčtov hierarchií a iných agregovaných hodnôt v čase konštrukcie kocky. To znamená, že ak naše údaje pôvodne obsahovali informácie o denných príjmoch za konkrétny produkt v jednom obchode, potom pri vytváraní kocky aplikácia OLAP vypočíta súčty pre rôzne úrovne hierarchií (týždne a mesiace, mestá a krajiny).

Za zvýšenie produktivity týmto spôsobom musíte samozrejme platiť. Niekedy sa hovorí, že dátová štruktúra jednoducho "exploduje" - OLAP kocka môže zaberať desiatky a dokonca stokrát viac miesta ako pôvodné údaje.

Odpovedz na otázku:

Čo sa stalo kocka OLAP?

Čo sa stalo štítky konkrétny rozmer? Uveďte príklady.

Môžu Opatrenia v kocke OLAP obsahujú nečíselné hodnoty.