Domov › Sazby › Úvod do OLAP a multidimenzionálních databází. Olap v užším slova smyslu se vykládá jako: olap kostky

Úvod do OLAP a multidimenzionálních databází. Olap v užším slova smyslu se vykládá jako: olap kostky

Informační systémy seriózního podniku zpravidla obsahují aplikace určené pro komplexní analýzu dat, jejich dynamiku, trendy atd. V souladu s tím se top management stává hlavním konzumentem výsledků analýzy. Taková analýza má v konečném důsledku podpořit rozhodování. A aby bylo možné učinit jakékoli manažerské rozhodnutí, je nutné mít potřebné informace, obvykle kvantitativní. K tomu je nutné shromáždit tato data ze všech informačních systémů podniku, uvést je do společného formátu a teprve poté analyzovat. Za tímto účelem jsou vytvořeny Datové sklady.

Co je to datový sklad?

Obvykle - místo, kde se shromažďují všechny informace analytické hodnoty. Požadavky na takové obchody odpovídají klasické definici OLAP a budou vysvětleny níže.

Někdy má Warehouse jiný cíl – integraci všech podnikových dat, zachovat integritu a relevanci informací ve všech informačních systémech. Že. úložiště shromažďuje nejen analytické, ale téměř všechny informace a může je poskytovat ve formě adresářů zpět do jiných systémů.

Typický datový sklad se obvykle liší od typické relační databáze. Za prvé, běžné databáze jsou navrženy tak, aby uživatelům pomáhaly provádět každodenní práci, zatímco datové sklady jsou určeny pro rozhodování. Například prodej zboží a vystavování faktur se provádí pomocí databáze určené pro zpracování transakcí a analýza dynamiky prodeje v průběhu několika let, která umožňuje plánovací práci s dodavateli, se provádí pomocí datového skladu.

Za druhé, zatímco tradiční databáze podléhají neustálým změnám, jak uživatelé pracují, datový sklad je relativně stabilní: data v něm se obvykle aktualizují podle plánu (například týdně, denně nebo po hodině, v závislosti na potřebách). V ideálním případě je proces obohacování jednoduše přidáváním nových dat po určitou dobu, aniž by se měnily předchozí informace již v obchodě.

A za třetí, běžné databáze jsou nejčastěji zdrojem dat, která končí ve skladu. Úložiště lze navíc doplňovat z externích zdrojů, jako jsou statistické výkazy.

Jak se staví sklad?

ETL– základní koncept: Tři fáze:

Extrakce – extrakce dat z externích zdrojů ve srozumitelném formátu;
Transformace – transformace struktury zdrojových dat do struktur vhodných pro vybudování analytického systému;

Přidejme ještě jednu fázi – čištění dat ( Čištění) – proces odfiltrování irelevantních nebo opravy chybných údajů na základě statistických nebo expertních metod. Aby se později negenerovaly zprávy jako „Tržby za rok 20011“.

Vraťme se k analýze.

Co je to analýza a proč je potřeba?

Analýza je studium dat za účelem rozhodování. Analytické systémy se nazývají systémy pro podporu rozhodování ( DSS).

Zde je vhodné poukázat na rozdíl mezi prací s DSS a jednoduchou sadou regulovaných a neregulovaných hlášení. Analýza v DSS je téměř vždy interaktivní a iterativní. Tito. analytik se prohrabává v datech, skládá a upravuje analytické dotazy a dostává zprávy, jejichž struktura může být předem neznámá. K tomu se podrobněji vrátíme níže, až budeme probírat dotazovací jazyk. MDX.

OLAP

Systémy pro podporu rozhodování mají obvykle prostředky k tomu, aby poskytly uživateli souhrnná data pro různé vzorky z původního souboru ve formě vhodné pro vnímání a analýzu (tabulky, grafy atd.). Tradiční přístup k segmentaci zdrojových dat zahrnuje extrakci ze zdrojových dat jedné nebo více vícerozměrných datových sad (často nazývaných hyperkrychle nebo metakrychle), jejichž osy obsahují atributy a buňky obsahují agregovaná kvantitativní data. (Taková data mohou být také uložena v relačních tabulkách, ale v tomto případě mluvíme o logické organizaci dat, a nikoli o fyzické implementaci jejich uložení.) Podél každé osy mohou být atributy organizovány ve formě hierarchií, představující různé úrovně jejich detailů. Díky tomuto datovému modelu mohou uživatelé formulovat složité dotazy, generovat sestavy a získávat podmnožiny dat.

Technologie pro komplexní multidimenzionální analýzu dat se nazývá OLAP (On-Line Analytical Processing). OLAP je klíčovou součástí tradičního datového skladu. Koncept OLAP byl popsán v roce 1993 Edgarem Coddem, renomovaným databázovým výzkumníkem a autorem relačního datového modelu. V roce 1995 byl na základě požadavků stanovených Coddem formulován tzv. FASMI test (Fast Analysis of Shared Multidimensional Information), zahrnující následující požadavky na aplikace pro multidimenzionální analýzu:

poskytování výsledků analýzy uživateli v přijatelném čase (obvykle ne více než 5 s), a to i za cenu méně podrobné analýzy;
schopnost provádět jakoukoli logickou a statistickou analýzu specifickou pro danou aplikaci a uložit ji ve formě přístupné koncovému uživateli;
víceuživatelský přístup k datům s podporou vhodných zamykacích mechanismů a prostředků autorizovaného přístupu;
vícerozměrná koncepční reprezentace dat, včetně plné podpory hierarchií a více hierarchií (to je klíčový požadavek OLAP);
možnost přístupu k jakýmkoli nezbytným informacím bez ohledu na jejich objem a umístění úložiště.

Je třeba poznamenat, že funkcionalitu OLAP lze implementovat různými způsoby, od nejjednodušších nástrojů pro analýzu dat v kancelářských aplikacích až po distribuované analytické systémy založené na serverových produktech. Tito. OLAP není technologie, ale ideologie.

Než si povíme o různých implementacích OLAP, podívejme se blíže na to, co jsou kostky z logického hlediska.

Vícerozměrné koncepty

Pro ilustraci principů OLAP použijeme databázi Northwind, která je součástí Microsoft SQL Server a je typickou databází, která uchovává obchodní informace pro velkoobchodní distribuční společnosti potravin. Mezi tyto údaje patří informace o dodavatelích, klientech, seznam dodávaného zboží a jeho kategorií, údaje o objednávkách a objednaném zboží, seznam zaměstnanců společnosti.

Krychle

Vezměme si například tabulku Faktury1, která obsahuje zakázky společnosti. Pole v této tabulce budou následující:

Datum objednávky
Země
Město
Jméno zákazníka
Doručovací společnost
jméno výrobku
Množství zboží
Cena objednávky

Jaká souhrnná data můžeme z tohoto pohledu získat? Obvykle se jedná o odpovědi na otázky jako:

Jaká je celková hodnota objednávek zadaných zákazníky z konkrétní země?
Jaká je celková hodnota objednávek zadaných zákazníky v určité zemi a dodaných určitou společností?
Jaká je celková hodnota objednávek zadaných zákazníky v konkrétní zemi v daném roce a dodaných konkrétní společností?

Všechna tato data lze z této tabulky získat pomocí zcela zjevných SQL dotazů se seskupováním.

Výsledkem tohoto dotazu bude vždy sloupec čísel a seznam atributů, které jej popisují (například země) - jedná se o jednorozměrný soubor dat nebo matematicky řečeno vektor.

Představme si, že potřebujeme získat informace o celkové ceně objednávek ze všech zemí a jejich rozložení mezi doručovací společnosti – získáme tabulku (matici) čísel, kde budou v záhlaví sloupců uvedeny doručovací společnosti, v řádku země a v buňkách bude množství objednávek. Toto je dvourozměrné pole dat. Tato sada dat se nazývá kontingenční tabulka ( kontingenční tabulka) nebo křížová tabulka.

Pokud chceme získat stejná data, ale i podle roku, tak se objeví další změna, tzn. sada dat se stane trojrozměrnou (podmíněný tenzor 3. řádu nebo trojrozměrná „krychle“).

Je zřejmé, že maximální počet dimenzí je počet všech atributů (Datum, Země, Zákazník atd.), které popisují naše agregovaná data (množství objednávek, počet produktů atd.).

Tak se dostáváme ke konceptu multidimenzionality a jejího ztělesnění - vícerozměrná krychle. Takovému stolu budeme říkat „ tabulka faktů" Rozměry nebo osy krychle ( rozměry) jsou atributy, jejichž souřadnice jsou vyjádřeny jednotlivými hodnotami těchto atributů přítomnými v tabulce faktů. Tito. např. pokud byly v systému udržovány informace o objednávkách od roku 2003 do roku 2010, bude letošní osa sestávat z 8 odpovídajících bodů. Pokud objednávky pocházejí ze tří zemí, bude osa země obsahovat 3 body atd. Bez ohledu na to, kolik zemí je zahrnuto v adresáři Země. Body na ose se nazývají její „členy“ ( členové).

V tomto případě se samotné agregované údaje budou nazývat „opatření“ ( Opatření). Aby se předešlo záměně s "rozměry", posledně jmenované se s výhodou nazývají "osy". Soubor opatření tvoří další osu „Opatření“ ( Opatření). Má tolik členů (bodů), kolik je měr (agregovaných sloupců) v tabulce faktů.

Členy dimenzí nebo os lze kombinovat pomocí jedné nebo více hierarchií ( hierarchie). Vysvětleme si na příkladu, co je to hierarchie: města z řádů lze sdružovat do okresů, okresy do regionů, regiony země, země do světadílů nebo jiných celků. Tito. existuje hierarchická struktura - kontinent- země-okres-okres-město- 5 úrovní ( Úroveň). Pro region jsou data agregována pro všechna města, která jsou v něm zahrnuta. Pro region napříč všemi okresy, které obsahují všechna města atd. Proč potřebujeme více hierarchií? Například na ose data objednávky můžeme chtít seskupit body (tj. dny) do hierarchie Rok měsíc den nebo podle Rok-Týden-Den: v obou případech jsou tři úrovně. Je zřejmé, že týden a měsíc seskupují dny odlišně. Existují také hierarchie, jejichž počet úrovní není deterministický a závisí na datech. Například složky na disku počítače.

Agregace dat může probíhat pomocí několika standardních funkcí: součet, minimum, maximum, průměr, počet.

MDX

Přejděme k dotazovacímu jazyku ve vícerozměrných datech.
Jazyk SQL nebyl původně navržen pro programátory, ale pro analytiky (a proto má syntaxi, která se podobá přirozenému jazyku). Postupem času to ale bylo čím dál složitější a nyní jen málo analytiků ví, jak to dobře používat, pokud vůbec. Stal se nástrojem pro programátory. Dotazovací jazyk MDX, o kterém se říká, že jej vyvinul náš bývalý krajan Mosha (nebo Mosha) Posumansky v divočině Microsoftu, měl být původně také zaměřen na analytiky, ale jeho koncepty a syntaxe (která matně připomíná SQL a zcela v vain, t. j. protože to jen mate), ještě složitější než SQL. Jeho základy jsou však stále snadno pochopitelné.

Podíváme se na něj podrobně, protože je to jediný jazyk, který získal standardní status v rámci obecného standardu protokolu XMLA, a za druhé proto, že existuje jeho open-source implementace v podobě projektu Mondrian od spol. Pentaho. Jiné analytické systémy OLAP (například Oracle OLAP Option) obvykle používají vlastní rozšíření syntaxe SQL, deklarují však také podporu pro MDX.

Práce s analytickými datovými sadami znamená pouze jejich čtení a neznamená jejich zápis. Že. MDX nemá žádné klauzule pro změnu dat, ale pouze jednu výběrovou klauzuli - select.

V OLAP můžete vytvářet vícerozměrné kostky plátky- tj. když jsou data filtrována podél jedné nebo více os, popř projekce– když krychle „spadne“ podél jedné nebo více os, agreguje se data. Například naším prvním příkladem s množstvím objednávek ze zemí je projekce krychle na osu Země. Dotaz MDX pro tento případ bude vypadat takto:

Vyberte ...Děti na řádcích od
Co je tady?

Vybrat– klíčové slovo je v syntaxi zahrnuto pouze pro krásu.
je název osy. Všechna vlastní jména v MDX jsou zapsána v hranatých závorkách.
je název hierarchie. V našem případě se jedná o hierarchii Země-město
– toto je jméno člena osy na první úrovni hierarchie (tj. země) Vše – jedná se o metačlen, který spojuje všechny členy osy. V každé ose je takový meta-termín. Například na ose roku je „Všechny roky“ atd.
Děti je členská funkce. Každý člen má k dispozici několik funkcí. Jako například Parent. Úroveň, Hierarchie, vracející předka, úroveň v hierarchii a samotnou hierarchii, do které člen v tomto případě patří. Děti – vrátí sadu podřízených členů tohoto člena. Tito. v našem případě – země.
na řádcích– Označuje, jak uspořádat tato data ve výsledné tabulce. V tomto případě - v záhlaví řádků. Možné hodnoty zde: na sloupcích, na stránkách, na odstavcích atd. Je také možné jednoduše označit indexem počínaje 0.
z– jedná se o označení krychle, ze které se vybírá.

Co když nepotřebujeme všechny země, ale jen pár konkrétních? K tomu můžeme v požadavku výslovně specifikovat země, které potřebujeme, místo abychom vše vybírali pomocí funkce Děti.

Vyberte ( ..., ... ) na řádcích od
Složené závorky jsou v tomto případě deklarací množiny ( Soubor). Množina je seznam, výčet členů z jedné osy.

Nyní napíšeme dotaz pro náš druhý příklad – výstup v kontextu doručovatele:

Vyberte ...Děti na řádcích .Členové na sloupcích od
Přidáno zde:
– osa;
.Členové– funkce osy, která vrací všechny členy na ní. Hierarchie a úroveň mají stejnou funkci. Protože V této ose je pouze jedna hierarchie, pak lze její označení vynechat, protože úroveň a hierarchie jsou také stejné, pak můžete zobrazit všechny členy v jednom seznamu.

Myslím, že už je zřejmé, jak v tom můžeme pokračovat s naším třetím příkladem s podrobnostmi po roce. Ale raději se nevrtejme podle roku, ale filtrujme – tzn. postavit plátek Za tímto účelem napíšeme následující dotaz:

Vyberte ..Děti na řádcích .Členové na sloupcích, odkud (.)
Kde je tady filtrace?

kde- klíčové slovo
je jedním členem hierarchie . Celý název včetně všech výrazů by byl: .. , ale protože Vzhledem k tomu, že název tohoto členu je v rámci osy jedinečný, mohou být vynechána všechna přechodná objasnění názvu.

Proč je datum v závorce? Závorky jsou n-tice ( tuple). N-tice je jedna nebo více souřadnic podél rozličný sekery Chcete-li například filtrovat podle dvou os najednou, v závorce uvádíme dva termíny z odlišný míry oddělené čárkami. To znamená, že n-tice definuje „výřez“ krychle (nebo „filtrování“, pokud je taková terminologie bližší).

N-tice se používá k více než pouhému filtrování. N-tice mohou být také v záhlaví řádků/sloupců/stránek atd.

To je nutné například pro zobrazení výsledku trojrozměrného dotazu ve dvourozměrné tabulce.

Vyberte crossjoin(...Children, ..Children) na řádcích .Members na sloupcích, odkud (.)
Crossjoin je funkce. Vrací množinu n-tic (ano, množina může obsahovat n-tice!) vyplývající z kartézského součinu dvou množin. Tito. výsledná sada bude obsahovat všechny možné kombinace zemí a roků. Záhlaví řádků tak bude obsahovat dvojici hodnot: Země-rok.

Otázkou je, kde je údaj o tom, jaké číselné charakteristiky by se měly zobrazovat? V tomto případě se použije výchozí míra definovaná pro tuto krychli, tzn. Cena objednávky. Pokud chceme odvodit další míru, pak si pamatujeme, že míry jsou členy dimenze Opatření. A jednáme úplně stejně jako u ostatních os. Tito. filtrování dotazu podle jednoho z ukazatelů zobrazí v buňkách přesně tento údaj.

Otázka: Jaký je rozdíl mezi filtrováním v místě a filtrováním určením členů os v řádcích. Odpověď: prakticky nic. Jednoduše tam, kde je naznačen řez pro ty osy, které se nepodílejí na tvorbě nadpisů. Tito. stejná osa nemůže být přítomen zároveň na řádcích a v kde.

Vypočítaní členové

Pro složitější dotazy můžete deklarovat vypočítané členy. Členové osy atributu a osy měření. Tito. Můžete deklarovat například nové opatření, které bude zobrazovat příspěvek každé země k celkovému množství objednávek:

S členem. jako '.CurrentMember / ..', FORMAT_STRING='0.00%' vyberte ...Children na řádcích odkud .
Výpočet probíhá v kontextu buňky, ve které jsou známy všechny její atributy souřadnic. Odpovídající souřadnice (členy) lze získat funkcí CurrentMember pro každou z os krychle. Zde musíme pochopit, že výraz .CurrentMember/..“ nerozděluje jeden termín druhým, ale rozděluje relevantní agregovaná data kostky! Tito. řez pro aktuální území bude rozdělen na řez pro všechna území, tzn. celkovou hodnotu všech objednávek. FORMAT_STRING – nastavuje formát pro zobrazení hodnot, tzn. %.

Další příklad počítaného členu, ale na ose let:

S členem. tak jako '. - .'
Je zřejmé, že sestava nebude obsahovat jednotku, ale rozdíl odpovídajících sekcí, tzn. rozdíl ve výši objednávek v těchto dvou letech.

Zobrazení v ROLAP

Systémy OLAP jsou tak či onak založeny na nějakém druhu úložiště dat a systému organizace. Když mluvíme o RDBMS, mluvíme o ROLAP (MOLAP a HOLAP necháme na samostatné studium). ROLAP – OLAP na relační databázi, tzn. popsány ve formě běžných dvourozměrných tabulek. Systémy ROLAP převádějí dotazy MDX na SQL. Hlavním výpočetním problémem databází je rychlá agregace. Pro rychlejší agregaci jsou data v databázi obvykle vysoce denormalizovaná, tzn. nejsou ukládány příliš efektivně z hlediska zabraného místa na disku a monitorování integrity databáze. Navíc navíc obsahují pomocné tabulky, které ukládají částečně agregovaná data. Pro OLAP je proto obvykle vytvořeno samostatné databázové schéma, které pouze částečně replikuje strukturu původních transakčních databází z hlediska adresářů.

Navigace

Mnoho systémů OLAP nabízí interaktivní navigační nástroje pro již vygenerovaný dotaz (a podle toho vybraná data). V tomto případě se používá tzv. „vrtání“ nebo „vrtání“. Vhodnějším překladem do ruštiny by bylo slovo „prohlubování“. Ale to je věc vkusu, v některých prostředích se slovo „vrtání“ zaseklo.

Vrtat– jedná se o podrobnou zprávu o snížení stupně agregace dat v kombinaci s filtrováním podél nějaké jiné osy (nebo několika os). Existuje několik typů vrtání:

rozbalit– filtrování podél jedné ze zdrojových os sestavy se zobrazením detailních informací o potomcích v rámci hierarchie vybraného filtrujícího člena. Pokud například existuje sestava o rozdělení objednávek rozdělená podle zemí a roků, kliknutím na rok 2007 se zobrazí sestava rozdělená podle stejných zemí a měsíců roku 2007.
vrtací strana– filtrování podle jedné nebo více vybraných os a odstranění agregace podél jedné nebo více dalších os. Pokud například existuje sestava o rozdělení objednávek v členění podle zemí a roků, tak kliknutím na rok 2007 se zobrazí další sestava členěná například podle zemí a dodavatelů s filtrováním podle roku 2007.
vrtací žlab– odstranění agregace podél všech os a současné filtrování podél nich – umožňuje zobrazit zdrojová data z tabulky faktů, ze kterých byla získána hodnota ve zprávě. Tito. Když kliknete na hodnotu buňky, zobrazí se zpráva se všemi objednávkami, které tuto částku poskytly. Jakési okamžité vrtání do samotných „hloubek“ krychle.

To je vše. Pokud se nyní rozhodnete věnovat Business Intelligence a OLAP, je čas začít číst seriózní literaturu.

Štítky: Přidat štítky

Anotace: Tato přednáška pokrývá základy návrhu datových kostek pro datové sklady OLAP. Příklad ukazuje způsob konstrukce datové krychle pomocí nástroje CASE.

Účel přednášky

Po prostudování materiálu v této přednášce budete vědět:

v čem je datová kostka datový sklad OLAP ;
jak navrhnout datovou kostku pro Datové sklady OLAP ;
co je dimenze datové krychle;
jak fakt souvisí s datovou krychlí;
co jsou atributy dimenze;
co je hierarchie;
co je metrika datové krychle;

a učit:

stavět vícerozměrné grafy ;
design jednoduchý vícerozměrné grafy.

Úvod

Technologie OLAP není jediná software, Ne programovací jazyk. Pokud se pokusíme pokrýt OLAP ve všech jeho projevech, pak je to soubor konceptů, principů a požadavků, které jsou základem softwarových produktů, které analytikům usnadňují přístup k datům.

Analytici jsou hlavními spotřebiteli podnikových informací. Úkolem analytika je najít vzory ve velkém množství dat. Analytik proto nebude věnovat pozornost jednotlivé skutečnosti, že v určitý den byla prodána dávka propisovacích per kupci Ivanovovi - potřebuje informace o stovkách a tisících podobných událostí. Jednotlivé skutečnosti v datovém skladu mohou zajímat např. účetní nebo vedoucího obchodního oddělení, v jehož kompetenci je podpora určité zakázky. Pro analytika nestačí jeden záznam - může například potřebovat informace o všech smlouvách prodejního místa za měsíc, čtvrtletí nebo rok. Analytika nemusí zajímat DIČ kupujícího nebo jeho telefonní číslo - pracuje s konkrétními číselnými údaji, což je podstatou jeho profesionální činnosti.

Centralizace a pohodlné strukturování nejsou vše, co analytik potřebuje. Potřebuje nástroj k prohlížení a vizualizaci informací. Tradiční reporty, i ty postavené na bázi jednoho datového skladu, však postrádají určitou flexibilitu. Nelze je „zkroutit“, „rozbalit“ nebo „sbalit“, abyste získali požadovaný pohled na data. Čím více „řezů“ a „sekcí“ dat může analytik prozkoumat, tím více má nápadů, které zase vyžadují další a další „řezy“ pro ověření. OLAP slouží jako takový nástroj pro analýzu dat analytikem.

Ačkoli OLAP není nezbytným atributem datového skladu, stále více se používá k analýze informací nashromážděných v tomto datovém skladu.

Provozní data se shromažďují z různých zdrojů, čistí, integrují a ukládají do datového skladu. Navíc jsou již k dispozici pro analýzu pomocí různých reportovacích nástrojů. Poté jsou data (celá nebo jejich část) připravena pro analýzu OLAP. Mohou být načteny do speciální databáze OLAP nebo ponechány v relační databázi. Nejdůležitějším prvkem používání OLAP jsou metadata, tedy informace o struktuře, umístění a transformace dat. Díky nim je zajištěna efektivní souhra různých komponent úložiště.

Tím pádem, OLAP lze definovat jako sadu nástrojů pro multidimenzionální analýzu dat akumulovaných v datovém skladu. Teoreticky lze nástroje OLAP aplikovat přímo na provozní data nebo jejich přesné kopie. Existuje však riziko podrobení dat analýze, která není pro tuto analýzu vhodná.

OLAP na klientovi a serveru

OLAP je založen na multidimenzionální analýze dat. Lze jej vyrábět pomocí různých nástrojů, které lze rozdělit na klientské a serverové OLAP nástroje.

Klientské nástroje OLAP jsou aplikace, které počítají agregovaná data (součty, průměry, maximální nebo minimální hodnoty) a zobrazují je, přičemž samotná agregovaná data jsou obsažena v mezipaměti v adresním prostoru takového nástroje OLAP.

Pokud jsou zdrojová data obsažena v desktopové DBMS, výpočet agregovaných dat provádí samotný nástroj OLAP. Pokud je zdrojem počátečních dat server DBMS, mnoho klientských nástrojů OLAP odešle na server dotazy SQL obsahující operátor GROUP BY a v důsledku toho obdrží agregovaná data vypočítaná na serveru.

Funkčnost OLAP je zpravidla implementována v nástrojích pro statistické zpracování dat (z produktů této třídy jsou na ruském trhu široce používány produkty Stat Soft a SPSS) a v některých tabulkových procesorech. Dobré nástroje pro vícerozměrnou analýzu má zejména Microsoft Excel 2000. Pomocí tohoto produktu můžete vytvořit a uložit jako soubor malou lokální vícerozměrnou krychli OLAP a zobrazit její dvourozměrné nebo trojrozměrné části.

Mnoho vývojové nástroje obsahují knihovny tříd nebo komponent, které umožňují vytvářet aplikace implementující jednoduché funkce OLAP (jako jsou například komponenty Decision Cube v Borland Delphi a Borland C++Builder). Navíc mnoho společností nabízí řízení ActiveX a další knihovny, které implementují podobnou funkcionalitu.

Všimněte si, že klientské nástroje OLAP se zpravidla používají s malým počtem dimenzí (obvykle se nedoporučuje více než šest) a malou rozmanitostí hodnot těchto parametrů - výsledná agregovaná data se přece musí vejít do adresního prostoru takového nástroje a jejich počet roste exponenciálně s tím, jak počet zvyšuje měření Proto i ty nejprimitivnější klientské nástroje OLAP zpravidla umožňují předběžný výpočet množství požadované paměti RAM k vytvoření vícerozměrné krychle.

Mnoho (ale ne všechny) klientské nástroje OLAP umožňují uložit obsah mezipaměti s agregovanými daty jako soubor, což vám zase umožní vyhnout se jejich přepočítávání. Všimněte si, že tato příležitost se často využívá k odcizení agregovaných dat za účelem jejich přenosu do jiných organizací nebo ke zveřejnění. Typickým příkladem takto zcizitelných agregovaných dat jsou statistiky nemocnosti v různých regionech a v různých věkových skupinách, což jsou otevřené informace vydávané ministerstvy zdravotnictví různých zemí a Světovou zdravotnickou organizací. Přitom samotná původní data, která představují informace o konkrétních případech onemocnění, jsou důvěrnými daty zdravotnických zařízení a v žádném případě by se neměla dostat do rukou pojišťoven, natož aby byla veřejná.

Myšlenka ukládání do mezipaměti agregovaných dat v souboru byla dále rozvinuta v serverových nástrojích OLAP, ve kterých ukládání a změna agregovaných dat, stejně jako údržba úložiště, které je obsahuje, provádí samostatná aplikace nebo proces nazývaný OLAP server. Klientské aplikace mohou požadovat takové vícerozměrné úložiště a přijímat určitá data jako odpověď. Některé klientské aplikace mohou také taková úložiště vytvářet nebo je aktualizovat na základě změněných zdrojových dat.

Výhody použití serverových nástrojů OLAP ve srovnání s klientskými nástroji OLAP jsou podobné výhodám použití serverových DBMS ve srovnání s desktopovými: v případě použití serverových nástrojů dochází k výpočtu a ukládání agregovaných dat na serveru a klientské aplikaci přijímá pouze výsledky dotazů proti nim, což umožňuje obecně snížit provoz v síti, dodací lhůta požadavky a požadavky na prostředky spotřebované klientskou aplikací. Upozorňujeme, že nástroje pro analýzu a zpracování dat v podnikovém měřítku jsou zpravidla založeny na serverových nástrojích OLAP, například Oracle Express Server, Microsoft SQL Server 2000 Analysis Services, Hyperion Essbase, produkty od Crystal Decisions, Business Objects, Cognos, SAS. Ústav. Vzhledem k tomu, že všichni přední výrobci serverových DBMS vyrábějí (nebo mají licenci od jiných společností) ten či onen serverový OLAP nástroj, výběr je poměrně široký a téměř ve všech případech si můžete zakoupit OLAP server od stejného výrobce jako samotný databázový server. .

Všimněte si, že mnoho klientských nástrojů OLAP (zejména Microsoft Excel 2003, Seagate Analysis atd.) umožňuje přístup k serverovým úložištím OLAP, které v tomto případě fungují jako klientské aplikace, které provádějí takové dotazy. Kromě toho existuje mnoho produktů, které jsou klientskými aplikacemi pro nástroje OLAP od různých výrobců.

Technické aspekty ukládání vícerozměrných dat

Vícerozměrné datové sklady obsahují agregovaná data různého stupně podrobnosti, například objemy prodeje podle dne, měsíce, roku, podle kategorie produktu atd. Účelem ukládání souhrnných dat je snížení dodací lhůta požadavky, protože ve většině případů pro analýzy a prognózy nejde o podrobné, ale o souhrnné údaje, které jsou zajímavé. Proto se při vytváření vícerozměrné databáze vždy vypočítá a uloží nějaká agregovaná data.

Upozorňujeme, že ukládání všech agregovaných dat není vždy opodstatněné. Faktem je, že když jsou přidány nové dimenze, objem dat, která tvoří kostku, roste exponenciálně (někdy se mluví o „explozivním růstu“ objemu dat). Přesněji řečeno, míra růstu objemu agregovaných dat závisí na počtu dimenzí krychle a členech dimenzí na různých úrovních hierarchií těchto dimenzí. K vyřešení problému „výbušného růstu“ se používají různá schémata, která umožňují dosáhnout přijatelné rychlosti provádění dotazu při výpočtu ne všech možných agregovaných dat.

Nezpracovaná i agregovaná data mohou být uložena v relačních nebo vícerozměrných strukturách. Proto se v současnosti používají tři způsoby ukládání dat.

MOLAP(Multidimenzionální OLAP) - zdrojová a agregovaná data jsou uložena ve vícerozměrné databázi. Ukládání dat do vícerozměrných struktur umožňuje manipulovat s daty jako s vícerozměrným polem, díky čemuž je rychlost výpočtu agregovaných hodnot stejná pro kteroukoli z dimenzí. V tomto případě je však vícerozměrná databáze nadbytečná, protože vícerozměrná data zcela obsahují původní relační data.
ROLAP(Relační OLAP) – původní data zůstávají ve stejné relační databázi, kde byla původně umístěna. Souhrnná data jsou umístěna v tabulkách služeb speciálně vytvořených pro jejich uložení ve stejné databázi.
HOLAP(Hybridní OLAP) – původní data zůstávají ve stejné relační databázi, kde byla původně umístěna, a souhrnná data jsou uložena ve vícerozměrné databázi.

Některé nástroje OLAP podporují ukládání dat pouze v relačních strukturách, některé pouze ve vícerozměrných. Většina moderních serverových OLAP nástrojů však podporuje všechny tři způsoby ukládání dat. Volba způsobu ukládání závisí na objemu a struktuře zdrojových dat, požadavcích na rychlost provádění dotazů a četnosti aktualizace OLAP kostek.

Všimněte si také, že naprostá většina moderních nástrojů OLAP neukládá „prázdné“ hodnoty (příkladem „prázdné“ hodnoty by byla absence prodeje sezónního produktu mimo sezónu).

Základní koncepty OLAP

FAMSI test

Technologie pro komplexní multidimenzionální analýzu dat se nazývá OLAP (On-Line Analytical Processing). OLAP je klíčovou součástí organizace datového skladu. Koncept OLAP byl popsán v roce 1993 Edgarem Coddem, slavným databázovým výzkumníkem a autorem relačního datového modelu. V roce 1995 na základě požadavků stanovených Coddem, tzv FASMI test(Fast Analysis of Shared Multidimensional Information) - rychlá analýza sdílených multidimenzionálních informací, včetně následujících požadavků na aplikace pro multidimenzionální analýzu:

Rychle(Fast) - poskytuje uživateli výsledky analýzy v přijatelném čase (obvykle ne více než 5 s), a to i za cenu méně podrobné analýzy;
Analýza(Analýza) - schopnost provádět jakoukoli logickou a statistickou analýzu specifickou pro danou aplikaci a uložit ji ve formě přístupné koncovému uživateli;
Sdíleno(Shared) - víceuživatelský přístup k datům s podporou vhodných zamykacích mechanismů a prostředků autorizovaného přístupu;
Multidimenzionální(Multidimenzionální) - vícerozměrná koncepční reprezentace dat, včetně plné podpory hierarchií a více hierarchií (toto je klíčový požadavek OLAP);
Informace(Informace) – aplikace musí mít přístup ke všem potřebným informacím bez ohledu na jejich objem a umístění.

Vícerozměrná reprezentace informace

kostky

OLAP poskytuje pohodlné a rychlé prostředky pro přístup, prohlížení a analýzu obchodních informací. Uživatel obdrží přirozené, intuitivní datový model, který je organizuje ve formě vícerozměrných krychlí (Cubes). Osy vícerozměrného souřadnicového systému jsou hlavními atributy analyzovaného podnikového procesu. Například u prodeje to může být produkt, region, typ kupujícího. Čas se používá jako jedna z dimenzí. Na průsečících os měření (Dimensions) jsou data, která kvantitativně charakterizují proces - míry (Measures). Mohou to být objemy prodeje v kusech nebo v peněžním vyjádření, zůstatky zásob, náklady atd. Uživatel analyzující informace může kostku „rozřezat“ v různých směrech, získat souhrn (například podle roku) nebo naopak podrobný (po týdnu ) informace a provádět další manipulace, které ho během procesu analýzy napadnou.

Jak se měří v trojrozměrné krychli znázorněné na Obr. 26.1 se používají prodejní částky a jako rozměry se používají čas, produkt a sklad. Měření jsou prezentována na konkrétních úrovních seskupení: produkty jsou seskupeny podle kategorie, obchody podle země a údaje o načasování transakcí podle měsíců. O něco později se podíváme na úrovně seskupení (hierarchie) podrobněji.

Rýže. 26.1.

"řezání" kostky

Dokonce i trojrozměrná krychle je obtížné zobrazit na obrazovce počítače, aby byly viditelné hodnoty požadovaných mír. Co můžeme říci o kostkách s více než třemi rozměry? Pro vizualizaci dat uložených v krychli se zpravidla používají známé dvourozměrné, tj. tabulkové pohledy se složitými hierarchickými záhlavími řádků a sloupců.

Dvourozměrnou reprezentaci krychle lze získat jejím „řezáním“ napříč podél jedné nebo více os (rozměrů): zafixujeme hodnoty všech rozměrů kromě dvou a získáme pravidelnou dvourozměrnou tabulku. Vodorovná osa tabulky (záhlaví sloupců) představuje jeden rozměr, svislá osa (záhlaví řádků) jiný a buňky tabulky představují hodnoty měr. V tomto případě je sada měr ve skutečnosti považována za jednu z dimenzí: buď vybereme jednu míru k zobrazení (a pak můžeme umístit dvě kóty do záhlaví řádků a sloupců), nebo zobrazíme několik měr (a pak jednu z osy tabulky budou obsazeny názvy měr a druhé hodnotami jediné "neoříznuté" dimenze).

(úrovně). Například popisky uvedené v nejsou podporovány všemi nástroji OLAP. Například Microsoft Analysis Services 2000 podporuje oba typy hierarchie, ale Microsoft OLAP Services 7.0 podporuje pouze ty vyvážené. Počet úrovní hierarchie, maximální povolený počet členů jedné úrovně a maximální možný počet samotných dimenzí se mohou v různých nástrojích OLAP lišit.

Architektura aplikací OLAP

Vše, co bylo řečeno výše o OLAP, se v podstatě týkalo vícerozměrné prezentace dat. Jak jsou data uložena, zhruba řečeno, se netýká ani koncového uživatele, ani vývojářů nástroje, který klient používá.

Multidimenzionalitu v aplikacích OLAP lze rozdělit do tří úrovní.

Multidimenzionální reprezentace dat – nástroje pro koncové uživatele, které poskytují vícerozměrnou vizualizaci a manipulaci s daty; Vrstva vícerozměrné reprezentace abstrahuje od fyzické struktury dat a zachází s daty jako s vícerozměrnými.
Vícerozměrné zpracování je prostředek (jazyk) pro formulování vícerozměrných dotazů (tradiční relační jazyk SQL je zde nevhodný) a procesor, který takový dotaz dokáže zpracovat a provést.
Vícerozměrné úložiště je prostředek fyzické organizace dat, který zajišťuje efektivní provádění vícerozměrných dotazů.

První dvě úrovně jsou povinné ve všech nástrojích OLAP. Třetí úroveň, i když je rozšířená, není nutná, protože data pro vícerozměrnou reprezentaci lze extrahovat z běžných relačních struktur; Procesor vícerozměrných dotazů v tomto případě převádí vícerozměrné dotazy na dotazy SQL, které jsou prováděny relačním DBMS.

Konkrétní produkty OLAP jsou zpravidla buď multidimenzionálním nástrojem pro prezentaci dat (OLAP klient - např. kontingenční tabulky v Excelu 2000 od Microsoftu nebo ProClarity od Knosys) nebo multidimenzionálním serverem DBMS (OLAP server - např. Oracle Express Server resp. Služby Microsoft OLAP).

Vrstva vícerozměrného zpracování je obvykle zabudována do klienta OLAP a/nebo serveru OLAP, ale lze ji izolovat v čisté formě, jako je například komponenta služby kontingenční tabulky společnosti Microsoft.

V sérii článků „Úvod do databází“ publikovaných nedávno (viz ComputerPress č. 3'2000 - 3'2001) jsme diskutovali o různých technologiích a softwaru používaných při tvorbě informačních systémů - desktopové a serverové DBMS, nástroje pro návrh dat, vývoj aplikací nástroje, stejně jako Business Intelligence - nástroje pro analýzu a zpracování dat v podnikovém měřítku, které jsou v současnosti ve světě, včetně nás, stále populárnější. Podotýkáme však, že problematika využití nástrojů Business Intelligence a technologií používaných k tvorbě aplikací této třídy není v tuzemské literatuře dosud dostatečně zpracována. V nové sérii článků se pokusíme tuto mezeru zaplnit a pohovoříme o tom, jaké technologie jsou základem takových aplikací. Jako příklady implementace použijeme především technologie Microsoft OLAP (hlavně Analysis Services v Microsoft SQL Server 2000), ale doufáme, že většina materiálů bude užitečná pro uživatele jiných nástrojů.

První článek této série je věnován základům OLAP (On-Line Analytical Processing) – technologii pro multidimenzionální analýzu dat. V něm se podíváme na koncepty datových skladů a OLAP, požadavky na datové sklady a nástroje OLAP, logické uspořádání dat OLAP a základní pojmy a koncepty používané při diskusi o vícerozměrné analýze.

Co je datový sklad

Podnikové informační systémy zpravidla obsahují aplikace určené pro komplexní multidimenzionální analýzu dat, jejich dynamiku, trendy atd. Taková analýza má v konečném důsledku podpořit rozhodování. Tyto systémy se často nazývají systémy pro podporu rozhodování.

Bez potřebných informací, obvykle kvantitativních, není možné učinit žádné manažerské rozhodnutí. To vyžaduje vytvoření datových skladů, tedy proces sběru, třídění a předzpracování dat za účelem poskytnutí výsledných informací uživatelům pro statistickou analýzu (a často i tvorbu analytických reportů).

Ralph Kimball, jeden z tvůrců konceptu datového skladu, popsal datový sklad jako „místo, kde mají lidé přístup ke svým datům“ (viz například Ralph Kimball, „The Data Warehouse Toolkit: Praktické techniky pro datové sklady o rozměrech budov). “, John Wiley & Sons, 1996 a „The Data Webhouse Toolkit: Building the Web-Enabled Data Warehouse“, John Wiley & Sons, 2000). Také formuloval základní požadavky na datové sklady:

podpora vysokorychlostního načítání dat z úložiště;
udržování vnitřní konzistence dat;
schopnost získávat a porovnávat tzv. datové řezy (slice and dice);
dostupnost pohodlných nástrojů pro prohlížení dat v úložišti;
úplnost a spolehlivost uložených dat;
podpora vysoce kvalitního procesu doplňování dat.

Často není možné splnit všechny výše uvedené požadavky v rámci jednoho produktu. K implementaci datových skladů se proto obvykle používá několik produktů, z nichž některé jsou skutečnými nástroji pro ukládání dat, jiné jsou nástroji pro jejich načítání a prohlížení, jiné jsou nástroji pro jejich doplňování atd.

A za třetí, běžné databáze jsou nejčastěji zdrojem dat, která končí ve skladu. Úložiště lze navíc doplňovat z externích zdrojů, jako jsou statistické výkazy.

Co je OLAP

Systémy pro podporu rozhodování mají obvykle prostředky, které uživateli poskytují souhrnná data pro různé vzorky z původního souboru ve formě vhodné pro vnímání a analýzu. Obvykle takové agregační funkce tvoří vícerozměrný (a tedy nerelační) soubor dat (často nazývaný hyperkrychle nebo metakrychle), jehož osy obsahují parametry a jejichž buňky obsahují agregovaná data, která na nich závisí. Podél každé osy lze data uspořádat do hierarchie představující různé úrovně podrobností. Díky tomuto datovému modelu mohou uživatelé formulovat složité dotazy, generovat sestavy a získávat podmnožiny dat.

Technologie pro komplexní multidimenzionální analýzu dat se nazývá OLAP (On-Line Analytical Processing). OLAP je klíčovou součástí datového skladu. Koncept OLAP byl popsán v roce 1993 Edgarem Coddem, renomovaným databázovým výzkumníkem a autorem relačního datového modelu (viz E.F. Codd, S.B. Codd a C.T. Salley, Poskytování OLAP (online analytické zpracování) uživatelským analytikům: An IT mandát. Technická zpráva, 1993). V roce 1995 byl na základě požadavků stanovených Coddem formulován tzv. FASMI test (Fast Analysis of Shared Multidimensional Information), zahrnující následující požadavky na aplikace pro multidimenzionální analýzu:

poskytování výsledků analýzy uživateli v přijatelném čase (obvykle ne více než 5 s), a to i za cenu méně podrobné analýzy;
schopnost provádět jakoukoli logickou a statistickou analýzu specifickou pro danou aplikaci a uložit ji ve formě přístupné koncovému uživateli;
víceuživatelský přístup k datům s podporou vhodných zamykacích mechanismů a prostředků autorizovaného přístupu;
vícerozměrná koncepční reprezentace dat, včetně plné podpory hierarchií a více hierarchií (to je klíčový požadavek OLAP);
možnost přístupu k jakýmkoli nezbytným informacím bez ohledu na jejich objem a umístění úložiště.

Vícerozměrné kostky

V této části se blíže podíváme na koncept OLAP a vícerozměrných kostek. Jako příklad relační databáze, kterou použijeme k ilustraci principů OLAP, použijeme databázi Northwind, která je součástí Microsoft SQL Server nebo Microsoft Access a je typickou databází, která uchovává obchodní informace pro velkoobchodní distribuční společnosti potravin. Mezi tyto údaje patří informace o dodavatelích, klientech, doručovacích společnostech, seznam dodávaného zboží a jeho kategorií, údaje o objednávkách a objednaném zboží, seznam zaměstnanců společnosti. Podrobný popis databáze Northwind naleznete v systémech nápovědy Microsoft SQL Server nebo Microsoft Access - zde jej z důvodu nedostatku místa neuvádíme.

K prozkoumání konceptu OLAP použijeme pohled Faktury a tabulky Produkty a kategorie z databáze Northwind k vytvoření dotazu, jehož výsledkem budou podrobné informace o veškerém objednaném zboží a vystavených fakturách:

SELECT dbo.Invoices.Country, dbo.Invoices.City, dbo.Invoices.CustomerName, dbo.Invoices.Salesperson, dbo.Invoices.OrderDate, dbo.Name.Categories.CategoryName, dbo.ProductNapperhivoices. .Faktury.ExtendedPrice FROM dbo.Products INNER JOIN dbo.Categories ON dbo.Products.CategoryID = dbo.Categories.CategoryID INNER JOIN dbo.Fuices ON dbo.Products.ProductID = dbo.ProductIDInvoices

V Accessu 2000 vypadá podobný dotaz takto:

JO (V hlasy INNER JOIN Products ON Invoices.ProductID = Products.ProductID) ON Categories.CategoryID = Products.CategoryID;

Tento dotaz přistupuje do pohledu Faktury, který obsahuje informace o všech vystavených fakturách, a dále do tabulek Kategorie a Produkty, které obsahují informace o kategoriích produktů, které byly objednány, respektive o produktech. Výsledkem tohoto požadavku je soubor údajů o objednávce, který obsahuje kategorii a název objednaného zboží, datum zadání objednávky, jméno fakturující osoby, město, zemi a název společnosti objednávající společnosti, jakož i jako název přepravní společnosti.

Pro usnadnění uložme tento požadavek jako pohled a nazvěme jej Faktury1. Výsledek přístupu k této reprezentaci je znázorněn na Obr. 1.

Jaká souhrnná data můžeme z tohoto pohledu získat? Obvykle se jedná o odpovědi na otázky jako:

Jaká je celková hodnota objednávek zadaných zákazníky z Francie?
Jaká je celková hodnota objednávek zadaných zákazníky ve Francii a doručených Speedy Express?
Jaká je celková hodnota objednávek zadaných zákazníky ve Francii v roce 1997 a doručených společností Speedy Express?

Pojďme si tyto otázky převést na dotazy v SQL (tabulka 1).

Výsledkem kteréhokoli z výše uvedených dotazů je číslo. Pokud v prvním dotazu nahradíte parametr „Francie“ výrazem „Rakousko“ nebo názvem jiné země, můžete tento dotaz spustit znovu a získat jiné číslo. Provedením tohoto postupu se všemi zeměmi získáme následující soubor dat (úryvek je uveden níže):

Země	SUM (rozšířená cena)
Argentina	7327.3
Rakousko	110788.4
Belgie	28491.65
Brazílie	97407.74
Kanada	46190.1
Dánsko	28392.32
Finsko	15296.35
Francie	69185.48
Německo	209373.6
…	…

Výsledný soubor agregovaných hodnot (v tomto případě součtů) lze interpretovat jako jednorozměrný soubor dat. Stejný soubor dat lze také získat jako výsledek dotazu s klauzulí GROUP BY v následujícím tvaru:

VYBERTE zemi, SOUČET (ExtendedPrice) FROM faktur1 GROUP BY Country

Nyní se podíváme na druhý dotaz výše, který obsahuje dvě podmínky v klauzuli WHERE. Pokud spustíme tento dotaz a zapojíme všechny možné hodnoty pro parametry Country a ShipperName, získáme dvourozměrnou sadu dat, která vypadá takto (úryvek je uveden níže):

	Jméno odesílatele
Země	Federální doprava	Rychlý expres	Sjednocený balíček
Argentina	1 210.30	1 816.20	5 092.60
Rakousko	40 870.77	41 004.13	46 128.93
Belgie	11 393.30	4 717.56	17 713.99
Brazílie	16 514.56	35 398.14	55 013.08
Kanada	19 598.78	5 440.42	25 157.08
Dánsko	18 295.30	6 573.97	7 791.74
Finsko	4 889.84	5 966.21	7 954.00
Francie	28 737.23	21 140.18	31 480.90
Německo	53 474.88	94 847.12	81 962.58
…	…	…	…

Takový soubor dat se nazývá kontingenční tabulka nebo křížová tabulka. Mnoho tabulek a desktopových DBMS umožňuje vytvářet takové tabulky – od Paradoxu pro DOS až po Microsoft Excel 2000. Takto například vypadá podobný dotaz v Microsoft Access 2000:

TRANSFORM Sum(Faktury1.ExtendedPrice) AS SumOfExtendedPrice SELECT Invoices1.country FROM Invoices1 GROUP BY Invoices1.Country PIVOT Invoices1.ShipperName;

Souhrnná data pro takovou kontingenční tabulku lze také získat pomocí běžného dotazu GROUP BY:

SELECT Country,ShipperName, SUM (ExtendedPrice) FROM facts1 GROUP BY COUNTRY,ShipperName Upozorňujeme však, že výsledkem tohoto dotazu nebude samotná kontingenční tabulka, ale pouze sada agregovaných dat pro její konstrukci (fragment je uveden níže ):

Země	Jméno odesílatele	SUM (rozšířená cena)
Argentina	Federální doprava	845.5
Rakousko	Federální doprava	35696.78
Belgie	Federální doprava	8747.3
Brazílie	Federální doprava	13998.26
…	…	…

Třetí z výše diskutovaných dotazů již má tři parametry v podmínce WHERE. Jejich variováním získáme trojrozměrný soubor dat (obr. 2).

Buňky krychle znázorněné na Obr. 2 obsahují agregovaná data odpovídající hodnotám parametrů dotazu v klauzuli WHERE umístěné na osách krychle.

Sadu dvourozměrných tabulek získáte řezáním krychle s rovinami rovnoběžnými s jejími plochami (k jejich označení se používají pojmy průřezy a řezy).

Je zřejmé, že data obsažená v buňkách krychle lze také získat pomocí vhodného dotazu s klauzulí GROUP BY. Některé tabulky (zejména Microsoft Excel 2000) navíc umožňují vykreslit trojrozměrnou datovou sadu a zobrazit různé průřezy krychle rovnoběžně s její plochou, jak je znázorněno na listu sešitu.

Pokud klauzule WHERE obsahuje čtyři nebo více parametrů, výsledná sada hodnot (také nazývaná krychle OLAP) může být 4-rozměrná, 5-rozměrná atd.

Poté, co jsme se podívali na to, co jsou vícerozměrné OLAP kostky, přejděme k některým klíčovým termínům a konceptům používaným při analýze vícerozměrných dat.

Některé termíny a pojmy

Spolu se součty mohou buňky OLAP kostky obsahovat výsledky provádění dalších agregačních funkcí jazyka SQL, jako je MIN, MAX, AVG, COUNT a v některých případech i další (rozptyl, směrodatná odchylka atd.). Pro popis datových hodnot v buňkách se používá pojem sumář (obecně jich může být v jedné krychli více), pojmem míra se označují zdrojová data, na základě kterých se počítají a termín dimenze se používá k označení parametrů dotazu (přeložený do ruštiny se obvykle označuje jako „dimenze“, když mluvíme o OLAP kostkách, a jako „dimenze“, když mluvíme o datových skladech). Hodnoty vynesené na osách se nazývají dimenze.

Když mluvíme o měření, stojí za zmínku, že hodnoty vynesené na osách mohou mít různé úrovně detailů. Například nás může zajímat celková hodnota objednávek uskutečněných zákazníky v různých zemích nebo celková hodnota objednávek uskutečněných zákazníky mimo město nebo dokonce jednotlivými zákazníky. Přirozeně bude výsledný soubor agregovaných dat ve druhém a třetím případě podrobnější než v prvním. Všimněte si, že možnost získat agregovaná data s různou mírou podrobnosti splňuje jeden z požadavků na datové sklady – požadavek na dostupnost různých datových segmentů pro porovnání a analýzu.

Protože v uvažovaném příkladu obecně může mít každá země několik měst a město může mít několik klientů, můžeme mluvit o hierarchiích hodnot v dimenzích. V tomto případě jsou země umístěny na první úrovni hierarchie, města na druhé a klienti na třetí (obr. 3).

Všimněte si, že hierarchie mohou být vyvážené, jako je hierarchie znázorněná na Obr. 3, stejně jako hierarchie založené na datu a času a nevyvážených datech. Typickým příkladem nevyvážené hierarchie je hierarchie „nadřazená-podřízená“ (lze ji sestavit například pomocí hodnot pole Prodejce původní datové sady z příkladu diskutovaného výše), znázorněná na Obr. 4.

Někdy se pro takové hierarchie používá termín Rodič-dítě hierarchie.

Existují také hierarchie, které zaujímají mezipolohu mezi vyváženými a nevyváženými (označují se pojmem ragged). Obvykle obsahují členy, jejichž logičtí „rodiče“ nejsou na bezprostředně vyšší úrovni (například geografická hierarchie má úrovně Země, Město a Stát, ale v datové sadě jsou země, které nemají žádné státy ani regiony mezi Zemí a Úrovně města, obr. 5).

Všimněte si, že nevyvážené a „nerovné“ hierarchie nejsou podporovány všemi nástroji OLAP. Například Microsoft Analysis Services 2000 podporuje oba typy hierarchie, ale Microsoft OLAP Services 7.0 podporuje pouze ty vyvážené. Počet úrovní hierarchie, maximální povolený počet členů jedné úrovně a maximální možný počet samotných dimenzí se mohou v různých nástrojích OLAP lišit.

Závěr

V tomto článku jsme se naučili základy OLAP. Dozvěděli jsme se následující:

Účelem datových skladů je poskytovat uživatelům informace pro statistické analýzy a rozhodování managementu.
Datové sklady musí zajistit vysokou rychlost načítání dat, možnost získávat a porovnávat tzv. datové řezy a také konzistenci, úplnost a spolehlivost dat.
OLAP (On-Line Analytical Processing) je klíčovou součástí budování a používání datových skladů. Tato technologie je založena na konstrukci vícerozměrných datových sad – OLAP kostek, jejichž osy obsahují parametry a buňky obsahují agregovaná data, která na nich závisí.
Aplikace s funkčností OLAP musí uživateli poskytovat výsledky analýzy v přijatelném čase, provádět logické a statistické analýzy, podporovat víceuživatelský přístup k datům, poskytovat vícerozměrnou koncepční reprezentaci dat a mít přístup ke všem nezbytným informacím.

Kromě toho jsme si zopakovali základní principy logické organizace OLAP kostek a také jsme se naučili základní termíny a koncepty používané ve vícerozměrné analýze. Nakonec jsme se dozvěděli, jaké jsou různé typy hierarchií v dimenzích krychle OLAP.

V dalším článku této série se podíváme na typickou strukturu datových skladů, pohovoříme si o tom, co je klientský a serverový OLAP, a zaměříme se také na některé technické aspekty vícerozměrného ukládání dat.

ComputerPress 4"2001

Možná se někomu bude zdát použití technologie OLAP (On-line Analytic Processing) při vytváření sestav poněkud exotické, takže použití OLAP-CUBE pro ně není vůbec jedním z nejdůležitějších požadavků při automatizaci rozpočtování a manažerského účetnictví.

Ve skutečnosti je velmi výhodné používat vícerozměrnou CUBE při práci s manažerským reportingem. Při vývoji rozpočtových formátů se můžete setkat s problémem vícerozměrných formulářů (více se o tom můžete dočíst v knize 8 „Technologie pro nastavení rozpočtování ve společnosti“ a v knize „Nastavení a automatizace manažerského účetnictví“).

Je to dáno tím, že efektivní řízení společnosti vyžaduje stále podrobnější manažerské výkaznictví. To znamená, že systém využívá stále více různých analytických sekcí (v informačních systémech je analytika určena sadou referenčních knih).

To přirozeně vede k tomu, že manažeři chtějí dostávat reporting ve všech analytických úsecích, které je zajímají. To znamená, že hlášení musí nějak „dýchat“. Jinými slovy, můžeme říci, že v tomto případě mluvíme o tom, že stejná zpráva by měla poskytovat informace v různých analytických aspektech. Statické sestavy proto již mnoha moderním manažerům nevyhovují. Potřebují dynamiku, kterou může poskytnout multidimenzionální CUBE.

Technologie OLAP se tak již stala povinným prvkem moderních a budoucích informačních systémů. Při výběru softwarového produktu je proto potřeba věnovat pozornost tomu, zda využívá technologii OLAP.

Navíc musíte být schopni rozlišit skutečné KOSTKY od imitací. Jednou z takových simulací jsou kontingenční tabulky v MS Excel. Ano, tento nástroj vypadá jako KOSTKA, ale ve skutečnosti jím není, protože se jedná o statické, nikoli dynamické tabulky. Navíc mají mnohem horší implementaci možnosti sestavovat sestavy pomocí prvků z hierarchických adresářů.

Abychom potvrdili relevanci použití CUBE při sestavování manažerského reportingu, můžeme uvést jednoduchý příklad s rozpočtem prodeje. V uvažovaném příkladu jsou pro společnost relevantní následující analytické sekce: produkty, pobočky a prodejní kanály. Pokud jsou tyto tři analýzy pro společnost důležité, pak lze prodejní rozpočet (nebo report) zobrazit v několika verzích.

Je třeba poznamenat, že pokud vytvoříte rozpočtové řádky založené na třech analytických sekcích (jako v uvažovaném příkladu), umožní vám to vytvářet poměrně složité rozpočtové modely a vytvářet podrobné sestavy pomocí CUBE.

Například prodejní rozpočet lze sestavit pouze pomocí jedné analýzy (adresáře). Příklad prodejního rozpočtu sestaveného na základě jedné analýzy „Produkty“ je uveden na Obrázek 1.

Rýže. 1. Příklad prodejního rozpočtu sestaveného na základě jedné analýzy „Produkty“ v OLAP-CUBE

Stejný prodejní rozpočet lze sestavit pomocí dvou analýz (adresářů). Příklad prodejního rozpočtu sestaveného na základě dvou analytických „Produktů“ a „Poboček“ je uveden na Obrázek 2.

Rýže. 2. Příklad prodejního rozpočtu sestaveného na základě dvou analytických „Produktů“ a „Poboček“ v OLAP-CUBE softwarového balíku INTEGRAL

Pokud je potřeba sestavit podrobnější reporty, pak lze stejný prodejní rozpočet sestavit pomocí tří analytiků (adresářů). Příklad prodejního rozpočtu sestaveného na základě tří analytických „Produktů“, „Poboček“ a „Prodejních kanálů“ je uveden na Obrázek 3.

Rýže. 3. Příklad prodejního rozpočtu sestaveného na základě tří analytických „Produktů“, „Poboček“ a „Prodejních kanálů“ v OLAP-CUBE softwarového balíku INTEGRAL

Je třeba připomenout, že CUBE používaný pro generování reportů umožňuje zobrazovat data v různých sekvencích. Na Obrázek 3 Prodejní rozpočet se nejprve „rozšíří“ o produkt, poté o pobočku a poté o prodejní kanál.

Stejná data mohou být prezentována v různém pořadí. Na Obrázek 4 stejný prodejní rozpočet je „rozšířen“ nejprve podle produktu, poté podle prodejního kanálu a poté podle pobočky.

Rýže. 4. Příklad prodejního rozpočtu sestaveného na základě tří analytických „Produktů“, „Distribučních kanálů“ a „Poboček“ v OLAP-CUBE softwarového balíku INTEGRAL

Na Obrázek 5 stejný prodejní rozpočet „rozbalují“ nejprve pobočky, poté produkty a poté prodejní kanály.

Rýže. 5. Příklad prodejního rozpočtu sestaveného na základě tří analytických „Poboček“, „Produktů“ a „Prodejních kanálů“ v softwarovém balíčku OLAP-CUBE „INTEGRAL“

Ve skutečnosti to nejsou všechny možné možnosti pro stažení prodejního rozpočtu.

Kromě toho je třeba věnovat pozornost skutečnosti, že KUB umožňuje pracovat s hierarchickou strukturou adresářů. V uvedených příkladech jsou hierarchickými adresáři „Produkty“ a „Distribuční kanály“.

Z pohledu uživatele v tomto příkladu obdrží několik manažerských zpráv (viz. Rýže. 1-5), a z pohledu nastavení v softwarovém produktu se jedná o jednu zprávu. Jednoduše pomocí CUBE si ji můžete prohlédnout několika způsoby.

Přirozeně je v praxi možné velmi velké množství možností pro výstup různých manažerských zpráv, pokud jsou jejich články založeny na jednom nebo více analyticích. A samotná sada analýz závisí na potřebách uživatelů na detaily. Je pravda, že bychom neměli zapomínat, že na jedné straně, čím větší je analytik, tím podrobnější zprávy lze sestavit. Ale na druhou stranu to znamená, že model finančního rozpočtování bude složitější. V každém případě, pokud bude existovat KUB, bude mít společnost možnost prohlédnout si potřebné reportingy v různých verzích v souladu se zájmovými analytickými sekcemi.

Je nutné zmínit několik dalších vlastností OLAP-CUBE.

Ve vícerozměrném hierarchickém OLAP-CUBE existuje několik dimenzí: typ řádku, datum, řádky, adresář 1, adresář 2 a adresář 3 (viz. Rýže. 6). Sestava samozřejmě zobrazuje tolik tlačítek s adresáři, kolik je v rozpočtové položce obsahující maximální počet adresářů. Pokud v žádné rozpočtové položce není jediná referenční kniha, nebude mít sestava jediné tlačítko s referenčními knihami.

Zpočátku je OLAP-CUBE postaven ve všech rozměrech. Ve výchozím nastavení, když je sestava původně sestavována, jsou dimenze umístěny přesně v oblastech zobrazených v Obrázek 6. To znamená, že dimenze jako „Datum“ se nachází v oblasti vertikálních rozměrů (rozměry v oblasti sloupců), dimenzí „Řádky“, „Adresář 1“, „Adresář 2“ a „Adresář 3“ - v oblast vodorovných rozměrů (rozměry v řádcích oblasti) a dimenze „Typ řádku“ je v oblasti „nerozbalených“ rozměrů (rozměry v oblasti stránky). Pokud je dimenze v poslední oblasti, data v přehledu se o tuto dimenzi „nerozšíří“.

Každý z těchto rozměrů lze umístit do kterékoli ze tří oblastí. Jakmile jsou měření přenesena, zpráva je okamžitě přestavěna tak, aby odpovídala nové konfiguraci měření. Můžete například zaměnit datum a řádky s referenčními knihami. Nebo můžete přesunout jednu z referenčních knih do oblasti vertikálního měření (viz. Rýže. 7). Jinými slovy, můžete sestavu „otočit“ v OLAP-CUBE a vybrat možnost výstupu sestavy, která je pro uživatele nejpohodlnější.

Rýže. 7. Příklad opětovného sestavení zprávy po změně konfigurace měření softwarového balíku INTEGRAL

Konfiguraci měření lze změnit buď v hlavním formuláři CUBE nebo v editoru změnových map (viz. Rýže. 8). V tomto editoru můžete také přetahovat měření z jedné oblasti do druhé pomocí myši. Navíc můžete zaměnit měření v jedné oblasti.

Kromě toho můžete ve stejném formuláři nakonfigurovat některé parametry měření. Pro každou dimenzi můžete přizpůsobit umístění součtů, pořadí řazení prvků a názvy prvků (viz. Rýže. 8). Můžete také určit, který název prvku se má v sestavě zobrazit: zkrácený (Name) nebo úplný (FullName).

Rýže. 8. Editor map měření softwarového balíku INTEGRAL

Parametry měření můžete upravovat přímo v každém z nich (viz. Rýže. 9). Chcete-li to provést, klikněte na ikonu umístěnou na tlačítku vedle názvu měření.

Rýže. 9. Příklad úpravy adresáře 1 Produkty a služby v

Pomocí tohoto editoru můžete vybrat prvky, které chcete v sestavě zobrazit. Ve výchozím nastavení jsou v sestavě zobrazeny všechny prvky, ale v případě potřeby lze některé prvky nebo složky vynechat. Pokud například potřebujete v přehledu zobrazit pouze jednu skupinu produktů, musíte v editoru měření zrušit zaškrtnutí všech ostatních. Poté bude sestava obsahovat pouze jednu skupinu produktů (viz. Rýže. 10).

V tomto editoru můžete také prvky třídit. Prvky lze navíc různě přeskupovat. Po takovém přeskupení je sestava okamžitě znovu sestavena.

Rýže. 10. Příklad výstupu ve zprávě pouze jedné produktové skupiny (složky) v softwarovém balíku INTEGRAL

V editoru dimenzí můžete rychle vytvářet vlastní skupiny, přetahovat tam prvky z adresářů atd. Ve výchozím nastavení se automaticky vytvoří pouze skupina Jiné, ale lze vytvořit i jiné skupiny. Pomocí editoru dimenzí tedy můžete nakonfigurovat, které prvky referenčních knih a v jakém pořadí se mají ve zprávě zobrazit.

Je třeba poznamenat, že všechna taková přeskupení nejsou zaznamenána. To znamená, že po uzavření sestavy nebo po jejím přepočtu se v sestavě zobrazí všechny adresáře v souladu s nakonfigurovanou metodikou.

Ve skutečnosti všechny takové změny mohly být provedeny zpočátku při nastavování linek.

Pomocí omezení můžete například také určit, které prvky nebo skupiny adresářů se mají v sestavě zobrazovat a které ne.

Poznámka: téma tohoto článku je podrobněji rozebráno na workshopech "Řízení rozpočtu podniku" A "Organizace a automatizace manažerského účetnictví" vede autor tohoto článku Alexander Karpov.

Pokud uživatel téměř pravidelně potřebuje v sestavě zobrazovat pouze určité prvky nebo adresářové složky, pak je lepší takové nastavení provést předem při vytváření řádků sestavy. Pokud jsou pro uživatele důležité různé kombinace adresářových prvků v sestavách, pak není potřeba při nastavování metodiky nastavovat žádná omezení. Všechna taková omezení lze rychle nakonfigurovat pomocí editoru měření.

Mechanismus OLAP je dnes jednou z populárních metod analýzy dat. Existují dva hlavní přístupy k řešení tohoto problému. První z nich se nazývá Multidimenzionální OLAP (MOLAP) - implementace mechanismu pomocí multidimenzionální databáze na straně serveru a druhý Relační OLAP (ROLAP) - stavba kostek za chodu na základě SQL dotazů do relačního DBMS. Každý z těchto přístupů má své pro a proti. Jejich srovnávací analýza přesahuje rámec tohoto článku. Popíšeme naši implementaci jádra desktopového modulu ROLAP.

Tento úkol vznikl po použití systému ROLAP postaveného na bázi komponent Decision Cube obsažených v Borland Delphi. Bohužel použití této sady komponent ukázalo špatný výkon na velkém množství dat. Tento problém lze zmírnit tím, že se před vložením do krychlí pokusíte vyjmout co nejvíce dat. Ne vždy to ale stačí.

Na internetu a v tisku najdete o OLAP systémech spoustu informací, ale téměř nikde se neříká, jak to uvnitř funguje. Proto nám řešení většiny problémů bylo dáno metodou pokus-omyl.

Schéma práce

Obecné schéma fungování stolního systému OLAP lze znázornit takto:

Operační algoritmus je následující:

Příjem dat ve formě ploché tabulky nebo výsledku provedení SQL dotazu.
Ukládání dat do mezipaměti a jejich převod na vícerozměrnou krychli.
Zobrazení vytvořené krychle pomocí kontingenční tabulky nebo grafu atd. Obecně lze k jedné krychli připojit libovolný počet pohledů.

Uvažujme, jak lze takový systém vnitřně uspořádat. Začneme od té strany, na kterou je vidět a na kterou se dá sáhnout, tedy od displejů.

Displeje používané v systémech OLAP se nejčastěji dodávají ve dvou typech: křížové karty a grafy. Podívejme se na křížovou tabulku, což je základní a nejběžnější způsob zobrazení krychle.

Křížový stůl

Na obrázku níže jsou řádky a sloupce obsahující agregované výsledky zobrazeny žlutě, buňky obsahující fakta jsou světle šedé a buňky obsahující rozměrová data jsou tmavě šedé.

Tabulku lze tedy rozdělit na následující prvky, se kterými budeme v budoucnu pracovat:

Při vyplňování matice fakty musíme postupovat následovně:

Na základě naměřených dat určete souřadnice prvku, který má být přidán do matice.
Určete souřadnice sloupců a řádků součtů, které jsou ovlivněny přidaným prvkem.
Přidejte prvek do matice a odpovídající celkové sloupce a řádky.

Je třeba poznamenat, že výsledná matice bude velmi řídká, a proto je její organizace ve formě dvourozměrného pole (možnost ležící na povrchu) nejen iracionální, ale s největší pravděpodobností nemožná kvůli velkému rozměr této matice, pro kterou není k dispozici Žádné množství RAM nestačí. Pokud například naše kostka obsahuje informace o prodejích za jeden rok a má-li pouze 3 dimenze – Zákazníci (250), Produkty (500) a Datum (365), získáme matici faktů o následujících dimenzích:

Počet prvků = 250 x 500 x 365 = 45 625 000

A to přesto, že v matici může být jen pár tisíc vyplněných prvků. Navíc, čím větší počet rozměrů, tím řidší bude matice.

Proto, abyste mohli pracovat s touto maticí, musíte použít speciální mechanismy pro práci s řídkými maticemi. Jsou možné různé možnosti pro uspořádání řídké matice. Docela dobře jsou popsány v programátorské literatuře, například v prvním díle klasické knihy „Umění programování“ od Donalda Knutha.

Uvažujme nyní, jak můžeme určit souřadnice skutečnosti, když známe rozměry, které tomu odpovídají. Chcete-li to provést, podívejme se blíže na strukturu záhlaví:

V tomto případě můžete snadno najít způsob, jak určit čísla odpovídající buňky a součty, do kterých spadá. Zde lze navrhnout několik přístupů. Jedním z nich je použití stromu k nalezení odpovídajících buněk. Tento strom lze sestavit procházením výběru. Navíc lze snadno definovat analytický vzorec opakování pro výpočet požadované souřadnice.

Příprava dat

Data uložená v tabulce je potřeba transformovat, aby mohla být použita. Aby se tedy zlepšil výkon při sestavování hyperkrychle, je žádoucí najít jedinečné prvky uložené ve sloupcích, které jsou rozměry krychle. Kromě toho můžete provést předběžnou agregaci faktů pro záznamy, které mají stejné hodnoty dimenzí. Jak bylo uvedeno výše, jedinečné hodnoty dostupné v polích měření jsou pro nás důležité. Potom lze pro jejich uložení navrhnout následující strukturu:

Použitím této struktury výrazně snižujeme nároky na paměť. Což je docela relevantní, protože... Pro zvýšení provozní rychlosti je vhodné ukládat data do RAM. Kromě toho můžete uložit pouze pole prvků a uložit jejich hodnoty na disk, protože je budeme potřebovat pouze při zobrazení křížové karty.

Knihovna komponent CubeBase

Výše popsané myšlenky byly základem pro vytvoření knihovny komponent CubeBase.

TCubeSource provádí cachování a konverzi dat do interního formátu a také předběžnou agregaci dat. Komponent TCubeEngine provádí výpočty hyperkrychle a operace s ní. Ve skutečnosti se jedná o OLAP engine, který transformuje plochou tabulku na multidimenzionální datovou sadu. Komponent TCubeGrid zobrazí křížovou kartu a řídí zobrazení hyperkrychle. TCubeChart umožňuje zobrazit hyperkrychli ve formě grafů a komponentu TCubePivoteřídí činnost krychlového jádra.

Porovnání výkonu

Tato sada komponent vykazovala mnohem vyšší výkon než Decision Cube. Na sadě 45 tisíc záznamů tedy komponenty Decision Cube vyžadovaly 8 minut. k vytvoření kontingenční tabulky. CubeBase načetla data za 7 sekund. a sestavení kontingenční tabulky za 4 sekundy. Při testování na 700 tisíc záznamech Decision Cube jsme neobdrželi odpověď do 30 minut, poté jsme úlohu zrušili. CubeBase načetla data za 45 sekund. a sestavení krychle za 15 sekund.

Na objemech dat tisíců záznamů zpracovával CubeBase desítkykrát rychleji než Decision Cube. Na tabulkách se stovkami tisíc záznamů – stokrát rychleji. A vysoký výkon je jedním z nejdůležitějších ukazatelů systémů OLAP.

Oblíbené v kategorii: